Understanding Kubernetes Multi-Container Pod Patterns and Init- Containers

Sidecar:

apiVersion: v1
kind: Pod
metadata:
name: sidecar-pod
labels:
app: sidecar-app
spec:
volumes:
- name: logs
emptyDir: {}
containers:
- name: app-container
image: alpine
command: ["/bin/sh"]
args: ["-c", "while true; do date >> /var/log/index.html; sleep 2;done"]
volumeMounts:
- name: logs
mountPath: /var/log
- name: log-exporter-sidecar
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: logs
mountPath: /usr/share/nginx/htmlkubectl create -f sidecar.yml

Adapter:

apiVersion: v1
kind: Pod
metadata:
name: adapter-pod
labels:
app: adapter-app
spec:
volumes:
- name: logs
emptyDir: {}
containers:
- name: app-container
image: alpine
command: ["/bin/sh"]
args: ["-c", "while true; do date >> /var/log/app.log; sleep 2;done"]
volumeMounts:
- name: logs
mountPath: /var/log
- name: log-adapter
image: alpine
command: ["/bin/sh"]
args: ["-c", "tail -f /var/log/app.log|sed -e 's/^/Date /' > /var/log/out.log"]
volumeMounts:
- name: logs
mountPath: /var/log

Ambassador:

apiVersion: v1
kind: Pod
metadata:
name: ambassador-pod
labels:
app: ambassador-app
spec:
volumes:
- name: shared
emptyDir: {}
containers:
- name: app-container-poller
image: yauritux/busybox-curl
command: ["/bin/sh"]
args: ["-c", "while true; do curl 127.0.0.1:81 > /usr/share/nginx/html/index.html; sleep 10; done"]
volumeMounts:
- name: shared
mountPath: /usr/share/nginx/html
- name: app-container-server
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: shared
mountPath: /usr/share/nginx/html
- name: ambassador-container
image: bharamicrosystems/nginx-forward-proxy
ports:
- containerPort: 81

InitContainers:

  • Init containers always run to completion.
  • Each init container must complete successfully before the next one starts.

Differences from regular containers

Using init containers

  • Init containers can contain utilities or custom code for setup that are not present in an app image. For example, there is no need to make an image FROM another image just to use a tool like sed, awk, python, or dig during setup.
  • The application image builder and deployer roles can work independently without the need to jointly build a single app image.
  • Init containers can run with a different view of the filesystem than app containers in the same Pod. Consequently, they can be given access to Secrets that app containers cannot access.
  • Because init containers run to completion before any app containers start, init containers offer a mechanism to block or delay app container startup until a set of preconditions are met. Once preconditions are met, all of the app containers in a Pod can start in parallel.
  • Init containers can securely run utilities or custom code that would otherwise make an app container image less secure. By keeping unnecessary tools separate you can limit the attack surface of your app container image.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store