A dashboard exporter needs a helper that continuously reshapes the app’s metrics format for a scrape endpoint. Why is an adapter sidecar chosen instead of an init container?
Select an answer to reveal the explanation.
Short Explanation
Init is a setup crew that leaves when the room is ready. An adapter is a live interpreter who stays for the whole meeting, turning the app’s metrics dialect into what the scraper understands.
Full Explanation
A dashboard exporter that needs a helper continuously reshaping the app’s metrics format for a scrape endpoint should use an adapter sidecar rather than an init container. Sidecars keep running alongside the application for the entire Pod lifetime, transforming live output that the city’s Prometheus-compatible stack scrapes. An init container exits before application containers start and therefore cannot reshape metrics for ongoing scrapes.
The idea that init containers keep running forever while adapters must exit immediately reverses the Kubernetes model. Claiming adapter sidecars only work with PersistentVolumeClaims and never emptyDir is false; many adapters listen on localhost or share scratch volumes. Kubernetes does not forbid additional containers after init containers finish—multi-container Pods are first-class.
Exam caveat: Choose init containers for run-to-completion setup gates; choose sidecars for ongoing helpers. Adapter sidecars are a standard CKAD teaching pattern for metrics or format translation on municipal dashboards.
Operational check: kubectl get pod -o jsonpath='{.status.containerStatuses[].name}{" "}{.status.containerStatuses[].ready}{"\n"}'; scrape the metrics port; stop the adapter in a lab build and observe scrapes fail even if the exporter process still runs.