[javaunsafe2019]

Widely? I lived in this helm, kubernetes, pulumi world the past 4 years and we followed the simple rule of one service/container per pod. Why add complexity where it’s not needed. Like running a dB a and a service in the same docker container - a no go for me and many.

[ossm1db]

Kubernetes official documentation states, "A Pod is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers."

Running more than one container in a pod is a fundamental concept of Kubernetes. Init containers and sidecars allow for a separation of concerns, which is essential for non-cloud-native workloads. Logging and telemetry are just a couple of features which may be designed and built into cloud-native applications, but legacy applications need this flexibility without modifying the application itself.

The fact you ran K8S for four years without it demonstrates only that it is not required by your workload -- not that it is "unnecessary complexity" or an "anti-pattern."

[kuhsaft]

The thing is you might not be adding the sidecars yourself.

Kubernetes has a resource called MutatingAdmissionWebhook that allows mutations of the Pod object before creation.

I think the most common use case is for service meshes. Your Deployment might not have any sidecars, but the service mesh controller will automatically add a network proxy container to your pod via the admission webhook.

Another use case would be OpenTelemetry or some other observability service sidecar injection for auto-instrumentation.

[javaunsafe2019]

Ok that was something inward missing on my end. Thanks for all the explanations and sorry for me being wrong

[qeternity]

Nobody would suggest this. But what about a metrics scraper for your db pod? That’s where sidecars come in.