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
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?