CKAD — Multi-Container Pods Lab
Lab: Init Container + Sidecar
Scenario: Create a Pod where an init container downloads a web page, and a sidecar container serves it.
Step 1: Create the Pod
apiVersion: v1
kind: Pod
metadata:
name: web-setup
spec:
initContainers:
- name: download-page
image: busybox:1.36
command: ['sh', '-c']
args:
- |
echo '<html><body><h1>Ready!</h1><p>Init container set this up.</p></body></html>' > /www/index.html
volumeMounts:
- name: web-content
mountPath: /www
containers:
- name: web-server
image: nginx:1.27
ports:
- containerPort: 80
volumeMounts:
- name: web-content
mountPath: /usr/share/nginx/html
readOnly: true
- name: content-updater
image: busybox:1.36
command: ["/bin/sh", "-c"]
args:
- |
while true; do
echo "<footer>Last updated: $(date)</footer>" >> /www/index.html
sleep 60
done
volumeMounts:
- name: web-content
mountPath: /www
volumes:
- name: web-content
emptyDir: {}
Step 2: Deploy and Verify
kubectl apply -f web-setup.yaml
# Wait for the Pod to be running
kubectl get pod web-setup -w
# Verify the web page
kubectl exec web-setup -c web-server -- curl -s localhost
# Expected: HTML with "Ready!" and "Init container set this up."
What’s Happening
- Init container (
download-page) runs first — creates/www/index.htmland exits - Web server (
web-server) starts — serves the HTML file from the shared volume - Sidecar (
content-updater) runs alongside — periodically appends a footer to the page
This combines two patterns:
- Init container for one-time setup
- Sidecar for ongoing content updates
Practice Questions
Q1: What is the key difference between a sidecar container and an init container?
Show Answer
An **init container** runs to completion before the main containers start. It is used for setup tasks like waiting for dependencies or downloading config. A **sidecar container** runs alongside the main container for the entire Pod lifetime. It is used for ongoing tasks like log shipping, proxying, or monitoring.Q2: Create a Pod with an init container that writes “ready” to /data/status and a main container that reads it.
Show Answer
```yaml apiVersion: v1 kind: Pod metadata: name: init-demo spec: initContainers: - name: setup image: busybox:1.36 command: ['sh', '-c', 'echo "ready" > /data/status'] volumeMounts: - name: shared mountPath: /data containers: - name: app image: busybox:1.36 command: ['sh', '-c', 'cat /data/status && sleep 3600'] volumeMounts: - name: shared mountPath: /data volumes: - name: shared emptyDir: {} ``` ```bash kubectl logs init-demo # Expected: ready ```Q3: A Pod has 3 init containers. The second one fails. What happens?
Show Answer
Init containers run sequentially. If the second init container fails: 1. The third init container does **not** start 2. Kubernetes restarts the Pod based on the `restartPolicy` 3. If `restartPolicy` is `Always` (default), all init containers run again from the beginning — including the first one that already succeeded The main containers never start until **all** init containers complete successfully.Q4: How do you view logs for an init container named setup in a Pod named web-app?
Show Answer
```bash kubectl logs web-app -c setup ``` If the init container has already completed and the Pod has restarted, use: ```bash kubectl logs web-app -c setup --previous ```Q5: In the ambassador pattern, why does the main container connect to localhost instead of the actual service?
