Kubernetes & Container Patterns

Difficulty: Senior Level | Companies: AWS, Google, Microsoft, Netflix, Uber

Container Orchestration Fundamentals

Kubernetes automates deployment, scaling, and management of containerized applications. Understanding its patterns is essential for production workloads.

ℹ️

Kubernetes is the de facto standard for container orchestration. Mastering its patterns is crucial for cloud-native architecture.

Kubernetes Architecture

Architecture Diagram

┌─────────────────────────────────────────────────────────────┐
│                      Control Plane                          │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐   │
│  │ API      │  │ etcd     │  │Scheduler │  │Controller│   │
│  │ Server   │  │ Store    │  │          │  │ Manager  │   │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘   │
└─────────────────────────┬───────────────────────────────────┘
                          │
┌─────────────────────────┴───────────────────────────────────┐
│                      Worker Nodes                           │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Node 1                                            │   │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐            │   │
│  │  │  Pod A  │  │  Pod B  │  │  Pod C  │            │   │
│  │  └─────────┘  └─────────┘  └─────────┘            │   │
│  │  ┌─────────────────────────────────────────────┐   │   │
│  │  │  kubelet  │  kube-proxy  │  Container Runt │   │   │
│  │  └─────────────────────────────────────────────┘   │   │
│  └─────────────────────────────────────────────────────┘   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Node 2                                            │   │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐            │   │
│  │  │  Pod D  │  │  Pod E  │  │  Pod F  │            │   │
│  │  └─────────┘  └─────────┘  └─────────┘            │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

Pattern 1: Rolling Updates with Health Checks

Deploy updates without downtime.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  labels:
    app: order-service
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: myregistry/order-service:v2.1.0
          ports:
            - containerPort: 8080
          
          # Readiness check - controls when pod receives traffic
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            failureThreshold: 3
          
          # Liveness check - controls when pod is restarted
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 10
            failureThreshold: 3
          
          # Startup check - for slow-starting containers
          startupProbe:
            httpGet:
              path: /health
              port: 8080
            failureThreshold: 30
            periodSeconds: 10
          
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url

⚠️

Always set resource requests AND limits. Requests ensure scheduling; limits prevent runaway processes. Without limits, a single pod can starve the node.

Pattern 2: Horizontal Pod Autoscaler

Scale pods based on metrics.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 20
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
        - type: Pods
          value: 4
          periodSeconds: 60
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "1000"

Pattern 3: Pod Disruption Budget

Maintain availability during voluntary disruptions.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: order-service-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: order-service
---
# Or use maxUnavailable for percentage-based
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: order-service-pdb-max
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: order-service

Pattern 4: Network Policies

Restrict pod-to-pod communication.

# Deny all ingress by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
---
# Allow specific traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-order-service
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: order-service
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-gateway
        - podSelector:
            matchLabels:
              app: payment-service
      ports:
        - protocol: TCP
          port: 8080
---
# Allow egress to specific services
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: order-service-egress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: order-service
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
      ports:
        - protocol: UDP
          port: 53

ℹ️

Network Policies are enforced by the CNI plugin. Ensure your cluster uses Calico, Cilium, or another CNI that supports NetworkPolicy enforcement.

Pattern 5: StatefulSet for Databases

Run stateful applications with stable network identities.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:15
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-credentials
                  key: password
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  selector:
    app: postgres
  clusterIP: None  # Headless service for StatefulSet
  ports:
    - port: 5432

Pattern 6: CronJob for Batch Processing

Schedule recurring tasks.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: data-processor
spec:
  schedule: "0 2 * * *"  # Daily at 2 AM
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 3600
      template:
        spec:
          containers:
            - name: processor
              image: myregistry/data-processor:latest
              command: ["python", "process.py"]
              env:
                - name: BATCH_DATE
                  value: "$(date -d 'yesterday' +%Y-%m-%d)"
              resources:
                requests:
                  cpu: "1"
                  memory: "1Gi"
                limits:
                  cpu: "2"
                  memory: "2Gi"
          restartPolicy: OnFailure

Kubernetes Resource Recommendations

Workload Type	CPU Request	Memory Request	Replicas
API Service	250m-500m	256Mi-512Mi	3+
Worker	500m-1000m	512Mi-1Gi	2+
Database	1000m-2000m	2Gi-8Gi	1 (HA config)
Cache	250m-500m	1Gi-4Gi	3+

Follow-Up Questions

How do you handle resource contention when running multiple services on the same node?
What strategies would you use to manage Kubernetes secrets across multiple environments?
How do you implement blue-green deployments with zero downtime in Kubernetes?