Attach a Sidecar and Measure the Resources

Goal

Attach a sidecar for real and confirm its cost in numbers. You ask the cluster how resources add up, who starts first, and what is shared.

Why it matters

A sidecar looks like "adding one more feature," but it actually makes the deployment unit bigger. The Pod's requests add up, startup gets slower, and there is one more point of failure. If you keep adding them without knowing that cost, you end up with a Pod that has five containers.

Environment

This Pod starts a real kube-apiserver with kwok. The Pod is not actually run, but the spec, status, and QoS calculations are all real.

Steps

1. Deployment without a sidecar → /root/sc/01-plain.yaml
2. Add an official sidecar → /root/sc/02-sidecar.yaml
3. Sum of requests → /root/sc/03-sum.txt
4. Startup order → /root/sc/04-order.txt
5. What is shared → /root/sc/05-share.txt
6. Connecting through a volume → /root/sc/06-volume.yaml
7. QoS class → /root/sc/07-qos.txt
8. Comparison with a DaemonSet → /root/sc/08-decide.md

Notes

• An official sidecar is an entry in initContainers with restartPolicy: Always. It is different from simply adding one more entry to containers.
• A sidecar's resources are small requests, generous limits — the opposite of the main container.

Start with a Pod without a sidecar

Write a Deployment without a sidecar → /root/sc/01-plain.yaml

In /root/sc/01-plain.yaml, write a Deployment with a single container. Use the name web, the image nginx:1.27-alpine, replicas 2, and cpu 100m and memory 128Mi in resources.requests. Apply it with kubectl apply -f.

Attach an official sidecar

Add an official sidecar → /root/sc/02-sidecar.yaml

Add a sidecar to the same Deployment, save it as /root/sc/02-sidecar.yaml, and apply it.

Put it in initContainers, not containers, and give it restartPolicy: Always. That is the official sidecar as of Kubernetes 1.29: it starts before the main container and terminates together with it when the main container finishes. Use the name proxy and any image (busybox:1.36 with sleep infinity), and set requests to cpu 50m and memory 64Mi.

A Pod's requests are a sum

Sum of requests → /root/sc/03-sum.txt

Use kubectl get pod <파드> -o jsonpath (the placeholder is the Pod name) to pull out the cpu requests of the two containers separately, then write their sum to /root/sc/03-sum.txt as a single line in the form 본체 + 사이드카 = 합 (the placeholders are the main container's value, the sidecar's value, and the sum; the unit is m). The scheduler looks at this sum when it searches for room.

Who starts first

Startup order → /root/sc/04-order.txt

Check with kubectl get pod <파드> -o jsonpath='{.status.initContainerStatuses[*].name} {.status.containerStatuses[*].name}' (the placeholder is the Pod name), and write two lines in /root/sc/04-order.txt: (1) the name of the container that starts first, and (2) why it has to be in that order. Think about where the first requests would go if the proxy came up late.

What is shared

What is shared → /root/sc/05-share.txt

In /root/sc/05-share.txt, write what the two containers share and what they do not. Four lines: network / filesystem root / process list / volume. Each line has the form <항목>: 공유|비공유 (the placeholder is the item, and the two Korean words mean "shared" and "not shared"), and for each item that is not shared, add how it can be made shared.

Connect through a volume

Connecting through a volume → /root/sc/06-volume.yaml

For the sidecar to read files the main container writes, you must mount the same volume in both. Create one emptyDir, write a manifest that mounts it at /var/log/app in the main container and at /logs in the sidecar into /root/sc/06-volume.yaml, and apply it.

Check the QoS class

QoS class → /root/sc/07-qos.txt

Look at kubectl get pod <파드> -o jsonpath='{.status.qosClass}' (the placeholder is the Pod name) and write two lines in /root/sc/07-qos.txt: (1) the class, and (2) which class you would get if you gave no requests at all, and why that is dangerous. BestEffort is the first to die under memory pressure.

Is a DaemonSet better

Comparison with a DaemonSet → /root/sc/08-decide.md

Write three lines in /root/sc/08-decide.md. (1) Which of the three conditions that justify a sidecar this case falls under, (2) if it falls under none, why a DaemonSet is better, and (3) the difference from a resource standpoint. This is the question to ask before adding one.