Mastering Kubernetes InitContainers, Static Pods, and Node Scheduling

InitContainers (Initialization Containers)

Kubernetes introduced init containers in version 1.3 to run one or more containers before the main application container starts, allowing preparation steps such as setting up files or performing checks.

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

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 manifest starts the init container first; only after it succeeds does the nginx container run. If the init container fails (e.g., an invalid command), the pod remains in Init:CrashLoopBackOff and the main container never starts.

# kubectl apply -f initContainer.yml
pod/initpod02 created
# kubectl get pods
NAME        READY   STATUS            RESTARTS   AGE
initpod02   0/1     PodInitializing   0          3s
# ... after init succeeds ...
initpod02   1/1     Running           0          4s

When the init container command is deliberately wrong, the pod fails and shows an error like "executable file not found in $PATH".

# kubectl describe pod/initpod02
Events:
  Type     Reason   Message
  Warning  Failed   exec: "lssssssss": executable file not found in $PATH
  Warning  BackOff  Back-off restarting failed container initc

Init containers are useful for tasks such as creating files in a shared volume before the main container starts.

apiVersion: v1
kind: Pod
metadata:
  name: initpod02
spec:
  containers:
  - name: initpod02
    image: nginx
    volumeMounts:
    - name: testvolume
      mountPath: /test
  initContainers:
  - name: initc
    image: centos
    volumeMounts:
    - name: testvolume
      mountPath: /initdir
    command: ["sh", "-c", "echo 123 > /initdir/initfile"]
    securityContext:
      privileged: true
  volumes:
  - name: testvolume
    emptyDir: {}

After applying, the file /test/initfile appears inside the nginx container with the content "123".

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

Static Pods

Static pods are defined by placing a pod manifest file in the kubelet's manifest directory (default /etc/kubernetes/manifests). The kubelet automatically creates the pod when the file exists and deletes it when the file is removed.

# ls /etc/kubernetes/manifests
etcd.yaml  kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml
# copy a new manifest to the directory
# kubelet creates the pod automatically

Removing the file causes the pod to disappear, demonstrating the declarative nature of static pods.

Pod Scheduling (Node Selection)

Kubernetes schedules pods onto nodes based on resource availability and labels. By default, pods are distributed across nodes, but you can force placement using nodeSelector and matching node labels.

# Label a node
kubectl label nodes node2 cloud=666

# Create a pod manifest with matching selector
apiVersion: v1
kind: Pod
metadata:
  name: pod07
  labels:
    cloud: "666"
spec:
  containers:
  - name: pod07
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    cloud: "666"

Applying the manifest schedules the pod onto node2 because the node carries the cloud=666 label.

# kubectl apply -f label.yaml
pod/pod07 created
# Verify placement
kubectl get pods -o wide
NAME    NODE    ...
pod07   node2   ...

Labels can be removed with a trailing hyphen, e.g., kubectl label nodes node2 cloud-.