Init Containers and Sidecar Containers
- RNREDDY
- Sep 9
- 3 min read
How to Use Kubernetes Init Containers and Sidecar Containers Effectively
If you are into kubernetes, you cannot miss init and sidecar containers. Most of the time we think only about the main container that runs the application, but real production pods need more.
What is an Init Container?
Init containers run before your application containers and make sure everything is ready for them to start.
They are used for tasks like running database migrations, setting up configuration files, waiting for external services to be reachable, or preparing shared volumes. Each init container runs one after the other and must finish successfully before the main containers begin.
This gives you a clean way to handle startup dependencies without overloading your application code.
What is a Sidecar Container?
A sidecar container runs alongside your main application container in the same pod and extends its functionality without changing the application code.
Common uses include log shippers, monitoring agents, service mesh proxies, or configuration reloaders. Unlike init containers, sidecars keep running as long as the main container is alive, handling operational tasks in parallel.
This pattern lets you separate responsibilities so that your application stays focused while the sidecar takes care of cross cutting concerns.
With this basic understanding, let us look into the implementation of both init and sidecar containers in real world.
Init Container Practical Example
Imagine you have a web app that needs PostgreSQL. If the app starts before the database is up, it will fail. Instead of building that logic into your app, you add an init container.
webapp-deploy.yaml
Step 1. Deploy the pod
$ kubectl apply -f webapp-deploy.yaml
pod/webapp-pod created
Step 2. Check pod status
Right after deployment, the pod will be waiting for the init container to finish:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
webapp-pod 0/1 Init:0/1 0 7s
Once the init container succeeds and the database is reachable, the pod moves to Running:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
webapp-pod 1/1 Running 0 29s
Step 3. Check init container logs
$ kubectl logs webapp-pod -c wait-for-db
db (10.96.25.3:5432) open
This confirms the init container successfully waited for PostgreSQL before the main webapp-container started.
Sidecar Container Practical Example
Let us assume this case
An Orders API writes logs to files under /var/log/orders on a shared volume.
We want a sidecar logging agent that reads the same files and lets the cluster ship logs centrally.
orders-api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: orders-api-pod
spec:
volumes:
- name: orders-logs
emptyDir: {}
containers:
- name: orders-api
volumeMounts:
- name: orders-logs
mountPath: /var/log/orders
- name: logging-agent
image: fluent/fluent-bit:4.0.7
volumeMounts:
- name: orders-logs
mountPath: /var/log/orders
Step 1. Deploy the pod
$ kubectl apply -f orders-api-pod.yaml
pod/orders-api-pod created
Step 2. Check pod status
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
orders-api-pod 2/2 Running 0 12s
Step 3. Confirm the app is writing files
$ kubectl exec orders-api-pod -c orders-api -- ls -l /var/log/orders
# expect to see one or more *.log files here
Step 4. View the sidecar container logs
$ kubectl logs orders-api-pod -c logging-agent | head
How this works
The shared emptyDir volume is mounted at /var/log/orders in both containers
The app writes its logs to files in that path
The sidecar reads the same files and emits to stdout
Your cluster logging pipeline collects container stdout and sends it to your sink
I hope this was an insightful edition. See you in the next edition on Tuesday.
Take care and have a nice weekend.
Comments