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

1–10 of 65 posts

Re: Kubernetes SidecarContainers feature is merged

#2

Post by xdasf »

KEP: https://github.com/kubernetes/enhancements/tree/master/keps/...

TLDR: Introduce a restartPolicy field to init containers and use it to indicate that an init container is a sidecar container. Kubelet will start init containers with restartPolicy=Always in the order with other init containers, but instead of waiting for its completion, it will wait for the container startup completion.

Re: Kubernetes SidecarContainers feature is merged

#3

Post by hunta2097 »

xdasf wrote: post #2

KEP: https://github.com/kubernetes/enhancements/tree/master/keps/... TLDR: Introduce a restartPolicy field to init containers and use it to indicate that an init container is a sidecar container. Kubelet will start init containers with restartPolicy=Always in the order with other init containers, but instead of waiting for its completion, it will wait for the container startup completion.

Hopefully these changes should make Envoy sidecars (and sidecar co-existence in general) more reliable.

Re: Kubernetes SidecarContainers feature is merged

#4

Post by raesene9 »

Worth noting that this is hitting Alpha in Kubernetes 1.28, so won't be available by default at this stage.

If you've got self-managed clusters, it'd be possible to enable with a feature gate on the API server, but it's unlikely to be available on managed Kubernetes until it gets to GA.

Re: Kubernetes SidecarContainers feature is merged

#5

Post by tommiegannert »

hunta2097 wrote: post #3
xdasf wrote: post #2

KEP: https://github.com/kubernetes/enhancements/tree/master/keps/... TLDR: Introduce a restartPolicy field to init containers and use it to indicate that an init container is a sidecar container. Kubelet will start init containers with restartPolicy=Always in the order with other init containers, but instead of waiting for its completion, it will wait for the container startup completion.

Hopefully these changes should make Envoy sidecars (and sidecar co-existence in general) more reliable.

What's the use-case for Envoy as a sidecar? (As someone using Envoy Gateway.)

Re: Kubernetes SidecarContainers feature is merged

#6

Post by CSDude »

It's a shame it took so long. If the main container shutdown (i.e connection drain, processing inflight queue items) takes a while, and your service mesh dies (nice go binary) and main container cannot communicate with internet anymore.

But I'm not sure about initContainers being used. init keyword implies it'd run and die in order for others to continue. Using restartPolicy with init instead of a dedicated sideCars field feels weird.

Re: Kubernetes SidecarContainers feature is merged

#8

Post by pluies »

tommiegannert wrote: post #5
hunta2097 wrote: post #3

Earlier quoted context omitted.

Hopefully these changes should make Envoy sidecars (and sidecar co-existence in general) more reliable.

What's the use-case for Envoy as a sidecar? (As someone using Envoy Gateway.)

Service mesh. Istio for example injects an envoy sidecar to each pod, and manages everything "meshy" (routing, retries, mTLS, etc) via this sidecar.

This is also how linkerd works, though they're using their own purpose-built sidecar rather than envoy.

Re: Kubernetes SidecarContainers feature is merged

#10

Post by zeeZ »

CSDude wrote: post #6

It's a shame it took so long. If the main container shutdown (i.e connection drain, processing inflight queue items) takes a while, and your service mesh dies (nice go binary) and main container cannot communicate with internet anymore. But I'm not sure about initContainers being used. init keyword implies it'd run and die in order for others to continue. Using restartPolicy with init instead of a dedicated sideCars…

Without restart policy, a failing init container is retried forever. With a policy of never, the entire pod is marked as having failed. The init containers still have to run and succeed before the main pod continues.
Post reply on HN