[jauntywundrkind]

Absolutely, no shortage of things atop. Helm is probably the most well used composition tool.

It seems unideal to me to forever bunt on this topic, leaving it out of core forever. Especially when we are slowly adding im very specialized composition orchestration tools in core.

[birdyrooster]

Requiring the user to write their own operators to manage state using the kubernetes api is very much a feature and not something which is missing.

[smarterclayton]

Agreed that is a feature and not a bug.

But! The one thing that custom orchestrators can’t do is easily get the benefit of kubelet isolation of containers and resource management. Part of slowly moving down this path is to allow those orchestrators to get isolation from the node without having to reimplement that isolation. But it will take some time.

[birdyrooster]

Oh I see orchestrating runtimes is quite different. Good points!

[numbsafari]

Helm really solves a different use case than this.

This is about describing the desired coordination among running containers. Helm is about how you template or generate your declarative state. You could certainly add this description to your templates with Helm, but you couldn't actually implement this feature with Helm itself.

[jauntywundrkind]

I bundled both composition & orchestration under the same header.

It so happens that pods have multiple containers, which is another example of Kubernetes having a specialized specific composition or orchestration implementation. One that started as composition, and here iterates towards orchestration.