[arianvanp]

I guess you mean something like Compose or Kubernetes. I think it's weird these things force you to use the docker runtime, personally. I would really love a more flexible definition in kubernetes of what a "resource to be ran" means. I know they support multiple container runtimes now, but what if I dont want a container runtime at all?

Nomad supports raw executables to be downloaded and scheduled, which is nice(https://nomadproject.io) but then again, kubernetes seems miles ahead in what it supports (autoscaling, volume claims, RBAC etc)

Otherwise, more traditional means of managing your services can be employed. I've got a lot of leverage out of systemd myself. Which by the way, supports all the features of a proper container runtime. You can namespace your executable, Chroot it, limit what devices it can access, etc, which is kinda awesome. Check out `man systemd.exec` and `man systemd.resource-control`

[rckrd]

Kubernetes absolutely does not force you to use the docker runtime. In fact, there has been a lot of work to avoid this by creating the CRI[0].

Kubernetes also supports extensions like the Third Party Resource or their successor, Custom Resource Definitions. KubeVirt[1] is an example of extending resources to include VMs

[0] http://blog.kubernetes.io/2016/12/container-runtime-interfac...

[1] https://github.com/kubevirt/kubevirt

[oso2k]

And CRI-O [0] is another open project making head way in that space.

[0] https://github.com/kubernetes-incubator/cri-o

[arianvanp]

CRI looks very interesting! Thanks for the pointer.