A sidecar is a container that runs alongside a main container in the same Kubernetes Pod. It adds supporting functionality without requiring changes to the main application. Common uses include logging, monitoring, backups, and service-mesh proxying. section 3.2.6
In a service mesh, a sidecar proxy handles a microservice’s inbound and outbound traffic separately from its application logic. Because traffic passes through the proxy, it can provide metrics and logs to a central control plane. Istio uses Envoy sidecars; istiod supplies their configuration and supports certificate management for secure service-to-service communication. section 4.2 section 4.3.1
Enable automatic injection for a namespace
For an Anthos Service Mesh managed release, run `kubectl label namespace NAMESPACE istio.io/rev=asm-managed --overwrite`, replacing `NAMESPACE` with the application namespace. Injection occurs when Pods are created, so restart existing Deployments with `kubectl rollout restart deployment -n YOUR_NAMESPACE`. Then run `kubectl get pod -n YOUR_NAMESPACE`; a workload showing `2/2` in READY has its main container and sidecar running. Manual injection by editing Pod manifests is another option. Check the injector configuration: the described default webhook configuration uses the `istio-injection=enabled` namespace label. section 4.5.1
Use a shared Pod when the supporting container should follow the main workload’s lifecycle. Pod-level actions affect both containers: scaling a Pod that contains a web server and database scales both. Put components needing independent scaling in separate Pods. A proxyless service-mesh approach is also available where an application can send telemetry directly to the control plane. section 3.2.6 section 4.2
