Kubernetes Pod Configuration and Lifecycle Management

A Pod can contain one or multiple containers, which fall into two categories:

  • Application Containers: User-defined containers that run application code
  • Pause Container: A root container present in every Pod that serves two purposes:
    • Provides a basis for evaluating the overall health status of the Pod
    • Hosts the Pod IP address, enabling network communication between containers within the Pod

Pod Definition Structure

All Kubernetes resources share a common top-level structure with five main sections:

  • apiVersion <string>: Resource API version (query with kubectl api-versions)
  • kind <string>: Resource type (query with kubectl api-resources)
  • metadata <Object>: Resource identification metadata including name, namespace, labels
  • spec <Object>: Detailed resource configuration specifications
  • status <Object>: Runtime status information (automatically populated by Kubernetes)

Key Specification Properties

  • containers <[]Object>: Container definitions and configurations
  • nodeName <String>: Direct Pod scheduling to specific node
  • nodeSelector <map[]>: Node selection based on label matching
  • hostNetwork <boolean>: Use host network namespace (default: false)
  • volumes <[]Object>: Storage volume definitions
  • restartPolicy <string>: Pod restart behavior on failure

Complete Pod Definition Example

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  namespace: development
  labels:
    app: web-server
spec:
  containers:
  - name: web-container
    image: nginx:1.17.1
    imagePullPolicy: IfNotPresent
    command: ["nginx", "-g", "daemon off;"]
    args: []
    workingDir: /usr/share/nginx/html
    volumeMounts:
    - name: config-volume
      mountPath: /etc/nginx/conf.d
      readOnly: true
    ports:
    - name: http-port
      containerPort: 80
      protocol: TCP
    env:
    - name: ENVIRONMENT
      value: "production"
    resources:
      limits:
        cpu: "2"
        memory: "1Gi"
      requests:
        cpu: "500m"
        memory: "256Mi"
    lifecycle:
      postStart:
        exec:
          command: ["sh", "-c", "echo 'Container started' > /tmp/start.log"]
      preStop:
        exec:
          command: ["nginx", "-s", "quit"]
    livenessProbe:
      httpGet:
        path: /
        port: 80
        scheme: HTTP
      initialDelaySeconds: 30
      timeoutSeconds: 5
      periodSeconds: 10
  restartPolicy: Always
  nodeSelector:
    disktype: ssd
  hostNetwork: false
  volumes:
  - name: config-volume
    configMap:
      name: nginx-config

Exploring Resource Configuration

Kubernetes provides commands to explore resource configuration options:

# View top-level properties of a resource
kubectl explain pod

# View sub-properties of specific fields
kubectl explain pod.metadata
kubectl explain pod.spec.containers

Basic Pod Configuration Examples

Simple Multi-Container Pod

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
  namespace: development
  labels:
    owner: developer
spec:
  containers:
  - name: web-server
    image: nginx:1.17.1
  - name: utility-container
    image: busybox:1.30

Image Pull Policy Configuration

apiVersion: v1
kind: Pod
metadata:
  name: custom-pull-policy
  namespace: development
spec:
  containers:
  - name: app-container
    image: nginx:1.17.1
    imagePullPolicy: Always

Supported pull policies:

  • Always: Always pull from remote registry
  • IfNotPresent: Use local image if available, otherwise pull remotely
  • Never: Use only local images (fails if not present)

Default behavior:

  • Specific version tags: IfNotPresent
  • latest tag: Always

Container Command Execution

apiVersion: v1
kind: Pod
metadata:
  name: command-execution-pod
  namespace: development
spec:
  containers:
  - name: web-server
    image: nginx:1.17.1
  - name: background-process
    image: busybox:1.30
    command: ["/bin/sh", "-c"]
    args:
    - |
      touch /tmp/status.log;
      while true; do
        echo $(date +%T) >> /tmp/status.log;
        sleep 5;
      done

Command and argument behavior:

  • Neither specified: Use Dockerfile ENTRYPOINT and CMD
  • Command specified: Override ENTRYPOINT, ignore CMD
  • Args specified: Use ENTRYPOINT with provided arguments
  • Both specified: Override both ENTRYPOINT and CMD

Environment Variables

apiVersion: v1
kind: Pod
metadata:
  name: env-config-pod
  namespace: development
spec:
  containers:
  - name: app-container
    image: busybox:1.30
    command: ["/bin/sh", "-c", "while true; do echo $(date +%T); sleep 60; done"]
    env:
    - name: DATABASE_USER
      value: "admin"
    - name: DATABASE_PASSWORD
      value: "secure123"

Port Configuration

apiVersion: v1
kind: Pod
metadata:
  name: port-exposure-pod
  namespace: development
spec:
  containers:
  - name: web-service
    image: nginx:1.17.1
    ports:
    - name: http-endpoint
      containerPort: 80
      protocol: TCP

Resource Quotas

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
  namespace: development
spec:
  containers:
  - name: compute-intensive
    image: nginx:1.17.1
    resources:
      limits:
        cpu: "2"
        memory: "2Gi"
      requests:
        cpu: "1"
        memory: "512Mi"

Pod Lifecycle Management

Pod Status Phases

  • Pending: Pod accepted but not yet scheduled or pulling images
  • Running: Pod scheduled and containers created
  • Succeeded: All containers terminated successfully
  • Failed: Atleast one container terminated with failure
  • Unknown: Unable to determine Pod status (typically network issues)

Pod Conditions

  • PodScheduled: Pod asssigned to node
  • Ready: Pod can serve requests
  • Initialized: All init containers completed successfully
  • Unschedulable: Scheduler cannot place Pod
  • ContainersReady: All containers ready

Creation Process

  1. Client submits Pod creation request to API Server
  2. API Server stores Pod definition in etcd
  3. Scheduler assigns Pod to appropriate node
  4. Kubelet on target node pulls images and starts containers
  5. API Server updates Pod status in etcd

Termination Process

  1. Client requests Pod deletion
  2. Pod marked for termination with grace period
  3. Kubelet initiates container shutdown
  4. Endpoint controller removes Pod from service endpoints
  5. prestop hooks executed if defined
  6. Containers receive termination signals
  7. Pod removed after grace period expiration

Initialization Containers

Init containers run before application containers and must complete successfully:

apiVersion: v1
kind: Pod
metadata:
  name: initialization-pod
  namespace: development
spec:
  containers:
  - name: application
    image: nginx:1.17.1
    ports:
    - containerPort: 80
  initContainers:
  - name: database-check
    image: busybox:1.30
    command: ["sh", "-c", "until ping database-service -c 1; do echo waiting; sleep 2; done"]
  - name: cache-validation
    image: busybox:1.30
    command: ["sh", "-c", "until ping cache-service -c 1; do echo waiting; sleep 2; done"]

Lifecycle Hooks

Post-Start and Pre-Stop Hooks

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-hook-pod
  namespace: development
spec:
  containers:
  - name: main-app
    image: nginx:1.17.1
    ports:
    - containerPort: 80
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo 'Application started' > /tmp/start.log"]
      preStop:
        exec:
          command: ["nginx", "-s", "quit"]

Hook implementation methods:

  • Exec: Execute command inside container
  • TCPSocket: Attempt connection to specified port
  • HTTPGet: Make HTTP request to specified endpoint

Container Health Probes

Liveness Probe (Container Restart)

apiVersion: v1
kind: Pod
metadata:
  name: liveness-check-pod
  namespace: development
spec:
  containers:
  - name: web-app
    image: nginx:1.17.1
    livenessProbe:
      exec:
        command: ["cat", "/tmp/healthy"]
      initialDelaySeconds: 15
      timeoutSeconds: 5
      periodSeconds: 10
      failureThreshold: 3

Readiness Probe (Traffic Management)

apiVersion: v1
kind: Pod
metadata:
  name: readiness-check-pod
  namespace: development
spec:
  containers:
  - name: api-service
    image: nginx:1.17.1
    readinessProbe:
      httpGet:
        path: /health
        port: 80
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 5

Startup Probe (Slow-Starting Applications)

apiVersion: v1
kind: Pod
metadata:
  name: startup-probe-pod
  namespace: development
spec:
  containers:
  - name: slow-start-app
    image: nginx:1.17.1
    startupProbe:
      httpGet:
        path: /ready
        port: 80
      failureThreshold: 30
      periodSeconds: 10

Probe configuration options:

  • initialDelaySeconds: Delay before first probe execution
  • timeoutSeconds: Probe timeout duration
  • periodSeconds: Time between probe executions
  • failureThreshold: Consecutive failures before marking unhealthy
  • successThreshold: Consecutive successes required after failure

Restart Policies

Pod-level restart behavior configuration:

apiVersion: v1
kind: Pod
metadata:
  name: restart-policy-pod
  namespace: development
spec:
  containers:
  - name: application
    image: nginx:1.17.1
    livenessProbe:
      httpGet:
        path: /health
        port: 80
  restartPolicy: Never

Supported policies:

  • Always: Restart container on failure (default)
  • OnFailure: Restart only on non-zero exit codes
  • Never: Never restart containers

Restart backoff timing: 10s, 20s, 40s, 80s, 160s, 300s (max delay)

Tags: kubernetes pod containers configuration Lifecycle

Posted on Fri, 31 Jul 2026 17:02:53 +0000 by victor