In a Pod's lifecycle, various operations can be executed as shown in the following diagram:

What are Init Containers?

Init containers, also known as initialization containers, are specialized containers designed to perform setup tasks before the main application containers start. A Pod can have one or multiple Init containers that execute sequentially. Since all containers within a Pod share volumes and Network Namespace, data generated by Init containers can be accessed by the main containers. As illustrated in the Pod lifecycle diagram, Init containers run independently of the main containers, and only after all Init containers complete successfully will the main containers be launched.

Common use cases for Init containers include:

• Waiting for dependencies to be ready: This helps resolve service dependencies. For example, a web service might depend on a database. An Init container can check if the data base is ready before the web service starts, prevanting connection errors.
• Initialization configuration: For instance, detecting existing cluster members and preparing configuration information for the main container to join the cluster.
• Other scenarios: Such as registering the Pod with a central database or configuration center.

Example Configuration:

apiVersion: v1
kind: Pod
metadata:
  name: setup-demo
spec:
  containers:
  - name: web-server
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: data-volume
      mountPath: /usr/share/nginx/html
  initContainers:
  - name: setup
    image: busybox
    command:
    - wget
    - "-O"
    - "/data/index.html"
    - http://kubernetes.io
    volumeMounts:
    - name: data-volume
      mountPath: "/data"
  dnsPolicy: Default
  volumes:
  - name: data-volume
    emptyDir: {}

Understanding Init Containers

Key characteristics of Init containers:

• They always run to completion
• Each must succeed before the next starts
• If an Init container fails, Kubernetes restarts the Pod until it succeeds (unless restartPolicy is Never)
• Init containers support all fields and features of application containers, except Readiness Probes
• Multiple Init containers run sequentially, each requiring success before the next starts
• Init container code should be idempotent due to potential restarts
• Use activeDeadlineSeconds and livenessProbe to prevent infinite failures
• All container names in a Pod must be unique
• Modifying an Init container's image field restarts the Pod

Differences Between Init and Regular Containers

Init containers differ from regular containers in two main aspects:

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

Static Pods

Static Pods are managed directly by kubelet and exist only on specific Nodes. They cannot be managed through the API Server, nor can they be associated with ReplicationControllers, Deployments, or DaemonSets. Static Pods are always created and run on the Node where kubelet resides. They can be created using configuration files or HTTP methods, with configuration files being the most common approach.

Creating via Configuration Files

Configuration files are standard Pod definitions in JSON or YAML format located in a specific directory. Kubelet scans this directory periodical. By default, kubelet looks in /etc/kubernetes/manifests.

Example: Running a Web Service as a Static Pod

To create a static Pod, simply place a standard Pod JSON or YAML file in the designated directory. Note that static Pods can run on any node with kubelet, not just worker nodes.

cat <<eof>/etc/kubernetes/manifests/web-service.yaml
apiVersion: v1
kind: Pod
metadata:
  name: web-service
  labels:
    app: static-web
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: http
          containerPort: 80
EOF
</eof>

When kubelet starts, it automatically launches all Pods defined in the specified directory. You can verify the creation:

$ kubectl get pods | grep web-service
web-service-node01            1/1     Running   0              120s

Static Pods are not managed by any deployment controller. Even if you attempt to delete them via kubectl, they will be recreated:

$ kubectl delete pods web-service-node01
pod "web-service-node01" deleted
$ kubectl get pods | grep web-service
web-service-node01            1/1     Running   0              15s

Static Pods cannot be deleted through the API Server. The only way to remove them is by deleting the manifest file from the kubelet's configuration directory. Kubelet periodically scans this directory and adds/removes Pods based on file presence:

$ rm -f /etc/kubernetes/manifests/web-service.yaml
$ kubectl get pods | grep web-service
web-service-node01            0/1     Terminating   0              5m12s
$ kubectl get pods | grep web-service