Master Kubernetes InitContainers, Static Pods, and Node Scheduling with Real‑World Examples

InitContainers (Initialization Containers)

Kubernetes introduced init containers in version 1.3 to run one or more containers before the main application container starts, allowing you to set up the environment or perform prerequisite tasks.

init1 → init2 → … → all init containers finish → app container starts

# initContainer.yml
apiVersion: v1
kind: Pod
metadata:
  name: initpod02
spec:
  containers:
  - name: initpod02
    image: nginx
    imagePullPolicy: Never
  initContainers:
  - name: initc
    image: centos
    imagePullPolicy: Never
    securityContext:
      privileged: true
    command: ["ls"]
    dnsPolicy: ClusterFirst
    restartPolicy: Always

Applying this file with kubectl apply -f initContainer.yml creates the pod; the init container runs first. If the init container succeeds, the main nginx container starts. Changing the command to an invalid one (e.g., "lssssssss") causes the init container to fail, the pod enters Init:CrashLoopBackOff, and the application container never starts.

# kubectl apply -f initContainer.yml
pod/initpod02 created
# kubectl get pods -o wide
NAME        READY   STATUS             RESTARTS   AGE   IP               NODE
initpod02   0/1     Init:CrashLoopBackOff   1        3s    10.244.xxx.xxx   node1

When the init container succeeds, you can verify the side‑effect (e.g., a file created in a shared volume) from the main container:

# kubectl exec -it initpod02 -- cat /test/initfile
123

Static Pod

A static pod is defined by placing a pod manifest file directly in the kubelet’s --pod-manifest-path directory (default /etc/kubernetes/manifests). The kubelet watches this directory and automatically creates or deletes the pod when the file appears or disappears, without using kubectl.

# Example static pod manifest (nginx.yaml)
apiVersion: v1
kind: Pod
metadata:
  name: static-nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

Copy the file to /etc/kubernetes/manifests on a node, and the pod appears in kubectl get pods -n kube-system. Deleting the file removes the pod automatically.

Pod Scheduling (Assigning Pods to Specific Nodes)

Kubernetes schedules pods to nodes based on resource availability and other criteria. You can influence placement by labeling nodes and using nodeSelector in the pod spec.

# Label a node
kubectl label nodes node2 cloud=666

Create a pod manifest that selects the labeled node:

# label.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod07
  labels:
    cloud: "666"
spec:
  containers:
  - name: pod07
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    cloud: "666"

# Apply the pod
kubectl apply -f label.yaml
pod/pod07 created
# Verify placement
kubectl get pods -o wide | grep pod07
pod07   1/1   Running   0   10.244.xxx.xxx   node2

Removing the label from the node ( kubectl label nodes node2 cloud-) disables the selector.