So far, we have seen some advance topics on Kubernetes with Argo CD and Prometheus, now let’s step back and see some basic resources which is useful and may widely used in GitOps and any temporary jobs. In this we are going to see what is Init container and sidecar containers and where can use it.
Init containers run before applications containers run in a pod, by default it supports many features of application containers and sidecar containers run alongside application containers in a pod. You can define any number of sidecar containers to run alongside the main container.
What is Sidecar Container?
A sidecar is just a container that runs on the same Pod as the application container. It shares the same volume and network as the main container, it can “help” or enhance how the application operates. A Sidecar container is a second container to add the pod when it requires to use the any resources that use by the main container.
Let’s say we have requirement to collect the log from existing container in pod, as we cannot stop/breaking existing setup. In this case sidecar helps more here. In this example assume, we have a webserver container running Nginx image. The logs produced by the main container are not enough to be placed on a persistent volume. However, developers need access to the last 24 hours of logs so they can trace issues and bugs. Therefore, we need to ship the access and error logs for the webserver to a log-aggregation service(s).
Following the separation of concerns principle, we implement the Sidecar pattern by deploying a second container that ships the Nginx error and access logs. Since containers are running on the same Pod, we can use a shared empty Dir volume to read and write logs.
apiVersion: v1
kind: Pod
metadata:
name: sidecar
spec:
volumes:
- name: shared-logs
emptyDir: {} containers:
- name: nginx
image: nginx
volumeMounts:
- name: shared-logs
mountPath: /var/log/nginx - name: sidecar-container
image: nginx
command: ["bin/bash","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"]
volumeMounts:
- name: shared-logs
mountPath: /var/log/nginx
The above definition is a standard Kubernetes Pod definition except that it deploys two containers to the same Pod. The sidecar container conventionally comes second in the definition so that when you issue the kubectl execute the command, you target the main container by default.
The main container is a Nginx container that stores its logs on a volume mounted on /var/log/nginx. Mounting a volume at that location prevents Nginx from outputting its log data to the standard output and forces it to write them to access.log and error.log files.
Use case of side-car container
These are some of the scenarios where you can use this pattern
- To extend the functionality of the existing single container pod without touching the existing one.
- To enhance the functionality of the existing single container pod without touching the existing one.
- To synchronize the main container code with the git server, pull.
- For ship log events to the external server.
- Also, we can use sidecar for network-related tasks.
Best Practices of side-car container
It is crucial to follow sidecar best practices during implementation, both for security reasons and to maximize the sidecar’s efficiency and productivity. You’ll learn about some of those practices in this section.
- Make sure there is a reason for separating the containers.
- Strive to make them small, Modular Applications
- Aware of the resource limits, it should not break the main containers.
Continue Reading on https://foxutech.com/sidecar-containers-and-init-containers-in-kubernetes/
