Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kubernetes SidecarContainers feature is merged

github.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Kubernetes SidecarContainers feature is merged

#31

Post by orf »

jauntywundrkind wrote: post #24

On the one hand, great. The other hand, one of the main criticisms of Kubernetes is that it has no composition or orchestration capabilities. It's great about defining pieces of state, but managing blocks of state & multiple things at once is left almost entirely to external tools. The ability to compose &sequence multiple containers feels like a very specific example of a much broader general capability. There's bed…

I like it this way to be honest. We needed to create a custom controller for Dask clusters consisting of a single scheduler, an auto-scaling set of nodes, an ingress and a myriad of secrets, configmaps and other resources.

It wasn’t simple, but with meta controller[1] it was relatively easy to orchestrate the complex state transitions this single logical resource needed and to treat the whole thing as a single unit.

I’m not saying Kubernetes can’t make simple patterns easier, but baking it into core leads to the classic “tragedy of the standard library” problem where it becomes hard to change that implementation. And the k8s ecosystem is definitely all about change.

1. https://metacontroller.github.io/metacontroller/intro.html

Re: Kubernetes SidecarContainers feature is merged

#32

Post by AtNightWeCode »

When I first learned about the sidecar pattern I thought it was great. I am not sure about it anymore. Most of it could be propagated to custom images or layers at the boundary. To me this feels a bit sketchy. Too have containers that kinda is part of the mesh but then does not share the same lifecycle as the mesh.

Re: Kubernetes SidecarContainers feature is merged

#33

Post by jauntywundrkind »

numbsafari wrote: post #28
jauntywundrkind wrote: post #27

Earlier quoted context omitted.

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.

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.

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.

Re: Kubernetes SidecarContainers feature is merged

#34

Post by politelemon »

NathanKP wrote: post #30
jauntywundrkind wrote: post #24

On the one hand, great. The other hand, one of the main criticisms of Kubernetes is that it has no composition or orchestration capabilities. It's great about defining pieces of state, but managing blocks of state & multiple things at once is left almost entirely to external tools. The ability to compose &sequence multiple containers feels like a very specific example of a much broader general capability. There's bed…

Yeah I work on the team that builds Amazon Elastic Container Service so I can't help but compare this implementation with how we solved this same problem in ECS. Inside of an ECS task you can add multiple containers and on each container you can specify two fields: `dependsOn` and `essential`. ECS automatically manages container startup order to respect the dependencies you have specified, and on shutdown it tears th…

As a consumer, ECS + Fargate is my happy path. I appreciate the lack of complexity. Thanks.

Re: Kubernetes SidecarContainers feature is merged

#35

Post by nrmitchi »

While this is a very welcome improvement in terms of functionality, I can't help by feel that the re-use of "restartPolicy" to mean something similar, but different, when used in a different context, is a very poor decision.

Kubernetes already has an issue with having a (perceived) high barrier to entry, and I'm not sure that "restartPolicy on a container means this, unless isn't used in this list of containers, in which case it means this".

I would have preferred to see a separate attribute (such as `sidecar: true`), rather than overloading (and in my opinion, abusing) the existing `restartPolicy`.

Re: Kubernetes SidecarContainers feature is merged

#36

Post by hosh »

jauntywundrkind wrote: post #24

On the one hand, great. The other hand, one of the main criticisms of Kubernetes is that it has no composition or orchestration capabilities. It's great about defining pieces of state, but managing blocks of state & multiple things at once is left almost entirely to external tools. The ability to compose &sequence multiple containers feels like a very specific example of a much broader general capability. There's bed…

Compositions of blocks of state may not end up with a more reliable software. Each of state management are controlled by independent processes that may interact with each other (example: horizontal pod autoscalers are not directly aware of cluster-autoscaler). The whole system is more like an ecology or a complex adaptive system than it is something you can reason directly with abstractions.

In the Cynefin framework (https://en.wikipedia.org/wiki/Cynefin_framework), you can reason through "complicated" domains the way you are suggesting, but it will not work when working in the "complex" domain. And I think what Kubernetes help manage is in "complex" not "complicated" domain.

Re: Kubernetes SidecarContainers feature is merged

#37

Post by jauntywundrkind »

NathanKP wrote: post #30
jauntywundrkind wrote: post #24

On the one hand, great. The other hand, one of the main criticisms of Kubernetes is that it has no composition or orchestration capabilities. It's great about defining pieces of state, but managing blocks of state & multiple things at once is left almost entirely to external tools. The ability to compose &sequence multiple containers feels like a very specific example of a much broader general capability. There's bed…

Yeah I work on the team that builds Amazon Elastic Container Service so I can't help but compare this implementation with how we solved this same problem in ECS. Inside of an ECS task you can add multiple containers and on each container you can specify two fields: `dependsOn` and `essential`. ECS automatically manages container startup order to respect the dependencies you have specified, and on shutdown it tears th…

Your approach sounds a lot like systemd's, with explicit dependencies in units coupling them to each other.

It's pretty cool how one can have a .device or what not that then wants a service- plug in a device & it's service starts. The arbitrary composability enables lots of neat system behaviors.

Re: Kubernetes SidecarContainers feature is merged

#38

Post by cacois »

In case anyone else was looking for a clear, concise summary of the new feature:

"The new feature gate "SidecarContainers" is now available. This feature introduces sidecar containers, a new type of init container that starts before other containers but remains running for the full duration of the pod's lifecycle and will not block pod termination."

Re: Kubernetes SidecarContainers feature is merged

#39

Post by [deleted] »

nrmitchi wrote: post #35

While this is a very welcome improvement in terms of functionality, I can't help by feel that the re-use of "restartPolicy" to mean something similar, but different, when used in a different context, is a very poor decision. Kubernetes already has an issue with having a (perceived) high barrier to entry, and I'm not sure that "restartPolicy on a container means this, unless isn't used in this list of containers, in w…

[deleted]

Re: Kubernetes SidecarContainers feature is merged

#40

Post by rad_gruchalski »

phrotoma wrote: post #16
rad_gruchalski wrote: post #14

Earlier quoted context omitted.

Isn’t the new ambient mesh available in istio 1.18 sidecar-less?

Yep, it’s also alpha, under intense development, and by every account (including those vendors who are chomping at the bit to start selling it to customers) absolutely not production ready.

Oh, good to know. I was about to pack a spike into an upcoming sprint.
Post reply on HN