Do you have a use case for this?

In general, running several apps in a pod is useful to run them together in the same Linux namespaces. But in the case of rkt fly, the apps run in the host namespace, so starting several rkt fly would have the same effect.

Right, fly intentionally subverts the pod model (this should be a lot
clearer once we split it out into a separate subcommand). Is there
something you need with a pod that fly provides and run doesn't?

Alban Crequy notifications@github.com schrieb am Di., 2. Feb. 2016 12:26:

Do you have a use case for this?

In general, running several apps in a pod is useful to run them together
in the same Linux namespaces. But in the case of rkt fly, the apps run in
the host namespace, so starting several rkt fly would have the same
effect.

—
Reply to this email directly or view it on GitHub
#2064 (comment).

I want to run the Kubernetes hyperkube and Docker via rkt fly but couple the versions together.

Bump
Another use case.
I need to run the prometheus node exporter in combination with an aci to provide auto-discovery.
Not for sharing the same namespace , but for the sharing of the lifecycle of the pod.
ie :

if one dies the other die as well.

@nyodas why can't they run in a pod?

They can if i don't run them in fly.
But to have access to all the stuff that the host has, the exporter need to be run within the namespace of the host.

For now as of 1.6.0 when i try to run them into a fly pod

run: flavor "fly" only supports 1 application per Pod for now

Honestly I suspect the best bet here is going to be to start two rkt fly invocations alongside each other in systemd units, and use BindsTo=. @iaguis @alban might have other ideas.

One use-case emerges when one tries to make his Kubernetes cluster use rkt instead the traditional runtime. If that user wants to use fly, or requires it, because he has to run privileged containers (accessing sysctl, devices, ...) for example, annotations make it fairly easy. Except that he will have to split any Kubernetes pods that use multiple applications to do so. It could cause some trouble and frustration to an op. In the case of daemon sets, it could make deployment, lifecycle and management way harder.

In my opinion, any time someone wants to move from docker --privileged to rkt, the answer is not rkt fly, but rather adding support for more granularity in security options for rkt.

Since the --insecure-options parameter exists now, I couldn't agree more. Thanks.