Managing Pod Topology Spread Constraints

The topologySpreadConstraints field in the Pod specification allows for fine-grained control over how Pods are distributed across failure domains like regions, zones, or nodes.

apiVersion: v1
kind: Pod
metadata:
  name: web-server-pod
spec:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: rack
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          app: frontend

Interaction with Node Affinity

When spec.nodeSelector or spec.affinity.nodeAffinity are defined, the Kubernetes scheduler filters out nodes that do not meet these criteria before calculating the distribution skew. For instance, if you exclude specific zones, the scheduler only balances Pods among the remaining eligible zones.

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: datacenter
          operator: NotIn
          values:
          - dc-01

Application Health Monitoring via Probes

Kubelet uses three types of probes to monitor the status of containers and ensure high availability:

• Readiness Probes: Determine if a container is ready to handle incoming traffic. If the probe fails, the Pod's IP is removed from all Service endpoints.
• Liveness Probes: Verify if the container process is still healthy. A failure triggers a container restart.
• Startup Probes: Used for legacy or slow-starting applications. Other probes are disabled until the startup probe succeeds, preventing premature restarts.

Deployment Lifecycle and Scaling

Manage application replicas and updates using the following kubectl operations:

Scaling Replicas:

kubectl scale --replicas=3 deployment/backend-service -n production

Updating Images and Monitoring Rollouts:

# Update container image
kubectl set image deployment/app-deploy web-container=nginx:1.21.0

# Check update status
kubectl rollout status deployment/app-deploy

# Review revision history
kubectl rollout history deployment/app-deploy

# Rollback to the previous version
kubectl rollout undo deployment/app-deploy

Cluster Provisioning with Kubeadm

During cluster setup, specific configurations are required for the container runtime and network.

Docker Cgroup Driver Configuration

To ensure compatibility with the systemd init system, configure the Docker daemon to use the systemd cgroup driver:

sudo mkdir -p /etc/docker
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m"
  },
  "storage-driver": "overlay2"
}
EOF
sudo systemctl restart docker

Initializing the Control Plane

Use mirrors for the image repository if access to default registries is restricted. Specify the Pod network CIDR for compatibility with CNI plugins like Flannel.

kubeadm init --image-repository registry.aliyuncs.com/google_containers --pod-network-cidr=10.244.0.0/16

After initialization, set up the local kubeconfig:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Configuration and Secret Management

Secret Operations

Create sensitive data entries from literal values or files:

# Create from literal
kubectl create secret generic app-credentials --from-literal=user=admin --from-literal=pass=p@ssword

# Retrieve and decode
kubectl get secret app-credentials -o jsonpath='{.data.pass}' | base64 --decode

ConfigMaps as Volumes

Inject configuration files into containers by mounting ConfigMaps as volumes:

apiVersion: v1
kind: Pod
metadata:
  name: config-test-pod
spec:
  containers:
    - name: app-container
      image: busybox
      volumeMounts:
        - name: settings-vol
          mountPath: /etc/config
  volumes:
    - name: settings-vol
      configMap:
        name: app-settings

Pod and Container Status Reference

Kubernetes tracks the lifecycle of workloads through several states and conditions:

• Pod Phases: Pending (waiting for resources), Running (atleast one container active), Succeeded (terminated successfully), Failed, and Unknown.
• Container States: Waiting, Running, and Terminated. Termination reasons often include OOMKilled (memory limit exceeded) or Completed (exit code 0).
• Pod Conditions:
  • PodScheduled: Node assignment complete.
  • Initialized: Init containers finished.
  • ContainersReady: All application containers are operational.
  • Ready: Pod is ready to serve traffic through a Service.