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

11–20 of 65 posts

Re: Kubernetes SidecarContainers feature is merged

#11

Post by tecleandor »

sidcool wrote: post #9

Any documentation on this? What does this mean?

So, until now, a sidecar container was just the idea of running containers in you Kubernetes pod, along with your main service, that were 'helpers' for something: connection to databases or vpns, mesh networking, pulling secrets or config, debugging... But they didn't have special status, they were just regular containers in your pod.

This sometimes posed some problems because they weren't available for the full life cycle of the pod, notably on the init process. So if your init containers needed secrets, connections, networking... that was being provided via a sidecar container, you were going to have a hard time.

With this change, among other things, sidecars containers are going to be available for the whole life cycle of the pod.

There are other implications, probably, but I still haven't finished reading the KEP [0]. Check it out, and there you'll find its motivation and several interesting examples.

  0: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/753-sidecar-containers
Edit: corrected syntax

Re: Kubernetes SidecarContainers feature is merged

#13

Post by chdefrene »

sidcool wrote: post #9

Any documentation on this? What does this mean?

The KEP (Kubernetes Enhancement Proposal) is linked to in the PR [1]. From the summary:

> Sidecar containers are a new type of containers that start among the Init containers, run through the lifecycle of the Pod and don’t block pod termination. Kubelet makes a best effort to keep them alive and running while other containers are running.

[1] https://github.com/kubernetes/enhancements/tree/master/keps/...

Re: Kubernetes SidecarContainers feature is merged

#14

Post by rad_gruchalski »

pluies wrote: post #8
tommiegannert wrote: post #5

Earlier quoted context omitted.

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.

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

Re: Kubernetes SidecarContainers feature is merged

#15

Post by giovannibonetti »

yla92 wrote: post #12

A very welcome change. It's gonna be helpful for the case where the database proxy (CloudSQL) and the main container got terminated out of order. https://cloud.google.com/sql/docs/postgres/connect-kubernete...

That is very annoying. I remember having spent some time with this same issue in Google App Engine as well, which also runs Cloud SQL Proxy as a sidecar container.

https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues...

Re: Kubernetes SidecarContainers feature is merged

#16

Post by phrotoma »

rad_gruchalski wrote: post #14
pluies wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: Kubernetes SidecarContainers feature is merged

#17

Post by numbsafari »

raesene9 wrote: post #4

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.

[flagged]

Re: Kubernetes SidecarContainers feature is merged

#19

Post by plagiarist »

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.

It seems like there could be a better marker for this. Maybe my skill with Kubernetes is too low for it to make sense.

Re: Kubernetes SidecarContainers feature is merged

#20

Post by [deleted] »

tecleandor wrote: post #11
sidcool wrote: post #9

Any documentation on this? What does this mean?

So, until now, a sidecar container was just the idea of running containers in you Kubernetes pod, along with your main service, that were 'helpers' for something: connection to databases or vpns, mesh networking, pulling secrets or config, debugging... But they didn't have special status, they were just regular containers in your pod. This sometimes posed some problems because they weren't available for the full life…

[deleted]
Post reply on HN