Kubernetes Deployment Patterns

Kubernetes Deployment Patterns

Expert guidance for production-grade Kubernetes deployments covering deployment strategies, workload types, configuration management, resource optimization, and autoscaling patterns for cloud-native applications.

When to Use This Skill

• Implementing deployment strategies (rolling updates, blue-green, canary releases)
• Choosing appropriate workload types (Deployment, StatefulSet, DaemonSet, Job)
• Designing rollout strategies for zero-downtime deployments
• Implementing configuration management with ConfigMaps and Secrets
• Setting up resource management and autoscaling (HPA, VPA)
• Configuring health checks and probe strategies
• Designing highly available applications on Kubernetes
• Implementing batch processing and scheduled jobs

Core Concepts

Deployment Strategies

Rolling Update: Gradually replace old pods with new ones (zero-downtime, default) Recreate: Terminate all old pods before creating new ones (brief downtime) Blue-Green: Run two environments, switch traffic instantly (2x resources) Canary: Gradually shift traffic to new version while monitoring (risk mitigation)

Workload Types

Deployment: Stateless applications (web servers, APIs, microservices) StatefulSet: Stateful applications (databases, message queues) DaemonSet: Node-level services (log collectors, monitoring agents) Job: One-time tasks (batch processing, migrations) CronJob: Scheduled tasks (backups, periodic reports)

Resource Management

Requests: Guaranteed resources for scheduling Limits: Maximum resources enforced by kubelet HPA: Horizontal Pod Autoscaler (scale replicas based on metrics) VPA: Vertical Pod Autoscaler (adjust resource requests/limits)

Quick Reference

Workflow

1. Choose Deployment Strategy

# Rolling update for standard deployments
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

# Recreate for incompatible versions
strategy:
  type: Recreate

2. Select Workload Type

• Stateless? → Use Deployment
• Stateful with persistent identity? → Use StatefulSet
• One pod per node? → Use DaemonSet
• Run to completion? → Use Job
• Run on schedule? → Use CronJob

3. Configure Resources

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "1000m"

4. Add Configuration

# ConfigMap for non-sensitive config
envFrom:
- configMapRef:
    name: app-config

# Secret for sensitive data
env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-credentials
      key: password

5. Implement Health Checks

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

6. Enable Autoscaling

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef:
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Common Mistakes

1. Using `latest` tag: Always use specific version tags for reproducibility 2. No resource limits: Can cause resource starvation and cluster instability 3. Missing health checks: Kubernetes can't manage pod health without probes 4. Single replica in production: No high availability or resilience 5. Secrets in ConfigMaps: Use Secrets for sensitive data, not ConfigMaps 6. No update strategy: Leads to unpredictable deployment behavior 7. Running as root: Security vulnerability, violates least privilege 8. No monitoring: Can't detect or debug issues in production

Resources

• Official Docs: https://kubernetes.io/docs/concepts/workloads/
• Deployment Strategies: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• StatefulSets: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
• Autoscaling: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
• Configuration: https://kubernetes.io/docs/concepts/configuration/
• Best Practices: https://kubernetes.io/docs/concepts/configuration/overview/

Configuration Management

ConfigMaps

Use for: Non-sensitive configuration, application settings, config files

As Environment Variables

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: production
  LOG_LEVEL: info
  MAX_CONNECTIONS: "100"
  CACHE_TTL: "3600"
---
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        envFrom:
        - configMapRef:
            name: app-config
        # Or individual keys
        env:
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: LOG_LEVEL

As Mounted Files

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-files
data:
  nginx.conf: |
    server {
      listen 80;
      location / {
        proxy_pass http://backend:8080;
      }
    }
  app.properties: |
    server.port=8080
    logging.level=INFO
---
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        volumeMounts:
        - name: config
          mountPath: /etc/config
      volumes:
      - name: config
        configMap:
          name: app-config-files

Update Strategies

# ConfigMaps mounted as volumes update automatically
# Env vars do NOT update - need pod restart

# Pattern 1: Version ConfigMaps for env vars
metadata:
  name: app-config-v2  # Increment version

# Pattern 2: Rolling restart after ConfigMap update
kubectl rollout restart deployment/app

Secrets

Use for: Passwords, API keys, certificates, tokens

Creating Secrets

# From literal values
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=secret123

# From files
kubectl create secret generic tls-cert \
  --from-file=tls.crt=./server.crt \
  --from-file=tls.key=./server.key

# From environment file
kubectl create secret generic app-secrets \
  --from-env-file=./secrets.env

Using Secrets

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  username: admin
  password: supersecret
  connection-string: "postgresql://admin:supersecret@db:5432/myapp"
---
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        env:
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: username
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password
        # Or mount as files
        volumeMounts:
        - name: db-creds
          mountPath: /etc/secrets
          readOnly: true
      volumes:
      - name: db-creds
        secret:
          secretName: db-credentials
          defaultMode: 0400  # Read-only for owner

Security Best Practices

• Never commit secrets to Git
• Use external secret management (Sealed Secrets, External Secrets Operator, Vault)
• Enable encryption at rest for etcd
• Use RBAC to limit secret access
• Rotate secrets regularly
• Consider using workload identity for cloud credentials

Deployment Strategies

1. Rolling Update (Default)

Pattern: Gradually replace old pods with new ones

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # Max 2 extra pods during update
      maxUnavailable: 1  # Max 1 pod can be unavailable
  template:
    spec:
      containers:
      - name: app
        image: myapp:v2

Characteristics:

• Zero downtime for stateless applications
• Gradual traffic shift from old to new version
• Easy rollback with kubectl rollout undo
• Both versions run simultaneously during update

Best for: Standard web applications, microservices, stateless workloads

Configuration guidelines:

# Zero-downtime (conservative)
rollingUpdate:
  maxSurge: 1
  maxUnavailable: 0

# Fast rollout (acceptable brief impact)
rollingUpdate:
  maxSurge: 50%
  maxUnavailable: 25%

# Gradual rollout (large deployments)
rollingUpdate:
  maxSurge: 1
  maxUnavailable: 1

2. Recreate Strategy

Pattern: Terminate all old pods before creating new ones

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  strategy:
    type: Recreate
  template:
    spec:
      containers:
      - name: app
        image: myapp:v2

Characteristics:

• Brief downtime during deployment
• Only one version runs at a time
• Useful when old/new versions cannot coexist
• Faster than rolling updates for compatible workloads

Best for: Legacy applications, database schema migrations, resource-constrained environments

Use cases:

• Applications requiring exclusive resource access
• Database migrations that change schema
• When running multiple versions causes conflicts
• Development/testing environments where downtime is acceptable

3. Blue-Green Deployment

Pattern: Run two identical environments, switch traffic between them

# Blue deployment (current production)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
  labels:
    version: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: app
        image: myapp:v1
---
# Green deployment (new version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
  labels:
    version: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: app
        image: myapp:v2
---
# Service - switch traffic by changing selector
apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  selector:
    app: myapp
    version: blue  # Change to 'green' to switch traffic
  ports:
  - port: 80
    targetPort: 8080

Characteristics:

• Instant traffic switch
• Full rollback capability
• Requires 2x resources during deployment
• Can test green environment before switching

Best for: Mission-critical applications, large-scale deployments, compliance requirements

Switching process:

# 1. Deploy green environment
kubectl apply -f deployment-green.yaml

# 2. Test green environment
kubectl port-forward deployment/app-green 8080:8080

# 3. Switch service to green
kubectl patch service app -p '{"spec":{"selector":{"version":"green"}}}'

# 4. Rollback if needed
kubectl patch service app -p '{"spec":{"selector":{"version":"blue"}}}'

# 5. Delete blue after validation
kubectl delete deployment app-blue

4. Canary Deployment

Pattern: Gradually shift traffic to new version while monitoring

# Stable deployment (90% traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-stable
spec:
  replicas: 9
  selector:
    matchLabels:
      app: myapp
      track: stable
  template:
    metadata:
      labels:
        app: myapp
        track: stable
        version: v1
    spec:
      containers:
      - name: app
        image: myapp:v1
---
# Canary deployment (10% traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
      track: canary
  template:
    metadata:
      labels:
        app: myapp
        track: canary
        version: v2
    spec:
      containers:
      - name: app
        image: myapp:v2
---
# Service routes to both (proportional to replicas)
apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  selector:
    app: myapp  # Matches both stable and canary
  ports:
  - port: 80
    targetPort: 8080

Traffic distribution:

• Traffic split based on replica ratios
• Example: 9 stable + 1 canary = 10% canary traffic
• Gradually increase canary replicas
• Monitor metrics before full rollout

Best for: High-risk deployments, A/B testing, gradual feature rollouts

Progressive rollout:

# Phase 1: 10% traffic
kubectl scale deployment app-canary --replicas=1  # 1/(9+1) = 10%

# Phase 2: 25% traffic (monitor metrics)
kubectl scale deployment app-canary --replicas=3  # 3/(9+3) = 25%

# Phase 3: 50% traffic (continue monitoring)
kubectl scale deployment app-canary --replicas=9  # 9/(9+9) = 50%

# Phase 4: Full rollout
kubectl scale deployment app-canary --replicas=9
kubectl scale deployment app-stable --replicas=0
kubectl delete deployment app-stable

Advanced canary with Istio/Linkerd:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: app
spec:
  hosts:
  - app
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Chrome.*"
    route:
    - destination:
        host: app
        subset: canary
      weight: 100
  - route:
    - destination:
        host: app
        subset: stable
      weight: 90
    - destination:
        host: app
        subset: canary
      weight: 10

Strategy Selection Guide

Production Best Practices

Deployment Configuration

• [ ] Set appropriate replica count (≥3 for HA)
• [ ] Configure update strategy for zero-downtime
• [ ] Implement pod disruption budgets
• [ ] Set pod anti-affinity for spread across nodes/zones
• [ ] Configure topology spread constraints

Resource Management

• [ ] Set resource requests and limits
• [ ] Configure HPA for automatic scaling
• [ ] Consider VPA for right-sizing
• [ ] Implement namespace quotas
• [ ] Monitor resource usage and adjust

Configuration

• [ ] Use ConfigMaps for configuration
• [ ] Store secrets in Secret manager or external vault
• [ ] Version ConfigMaps for env vars
• [ ] Mount secrets as files, not env vars (when possible)

Health and Monitoring

• [ ] Implement liveness probes
• [ ] Implement readiness probes
• [ ] Add startup probes for slow-starting apps
• [ ] Configure appropriate probe timing
• [ ] Export metrics for monitoring

Security

• [ ] Run as non-root user
• [ ] Use read-only root filesystem
• [ ] Drop all capabilities
• [ ] Enable seccomp profile
• [ ] Implement Pod Security Standards

Anti-Patterns to Avoid

1. Latest tag: Always use specific version tags 2. No resource limits: Causes resource starvation 3. No health checks: Kubernetes can't manage pod health 4. Secrets in ConfigMaps: Use Secrets for sensitive data 5. Single replica in production: No high availability 6. No update strategy: Unpredictable deployment behavior 7. Privileged containers: Security vulnerability 8. HostPath volumes: Not portable, security risk 9. No monitoring: Can't detect issues 10. Manual scaling: Use HPA for automatic scaling

High Availability Patterns

Multi-Replica Deployments

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchLabels:
                  app: myapp
              topologyKey: kubernetes.io/hostname

Pod Disruption Budgets

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

Topology Spread Constraints

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: myapp

Health Check Patterns

Liveness Probe

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

Readiness Probe

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  timeoutSeconds: 3
  successThreshold: 1
  failureThreshold: 3

Startup Probe (for slow-starting apps)

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 0
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 30  # 30 * 10 = 300s max startup time

Security Hardening

Non-Root User

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000

Read-Only Root Filesystem

securityContext:
  readOnlyRootFilesystem: true
  capabilities:
    drop:
    - ALL
  allowPrivilegeEscalation: false

Security Context Complete Example

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 2000
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: app
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop:
            - ALL
        volumeMounts:
        - name: tmp
          mountPath: /tmp
        - name: cache
          mountPath: /app/cache
      volumes:
      - name: tmp
        emptyDir: {}
      - name: cache
        emptyDir: {}

Resource Management & Autoscaling

Resource Requests and Limits

Requests: Guaranteed resources, used for scheduling Limits: Maximum resources, enforced by kubelet

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        resources:
          requests:
            memory: "256Mi"   # Guaranteed memory
            cpu: "250m"       # Guaranteed CPU (0.25 cores)
          limits:
            memory: "512Mi"   # Max memory (OOMKilled if exceeded)
            cpu: "1000m"      # Max CPU (throttled if exceeded)

Resource Units

• CPU: 1 = 1 core, 500m = 0.5 cores, 100m = 0.1 cores
• Memory: 128Mi (mebibytes), 1Gi (gibibytes), 500M (megabytes)

QoS Classes (Auto-Assigned)

# Guaranteed: requests = limits (highest priority)
resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"
    cpu: "500m"

# Burstable: requests < limits (medium priority)
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "1000m"

# BestEffort: no requests/limits (lowest priority, first evicted)
resources: {}

Horizontal Pod Autoscaler (HPA)

Scale based on metrics:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  # CPU-based scaling
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # Scale if avg CPU > 70%
  # Memory-based scaling
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80  # Scale if avg memory > 80%
  # Custom metrics (requires metrics adapter)
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # Wait 5 min before scaling down
      policies:
      - type: Percent
        value: 50  # Scale down max 50% at a time
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0  # Scale up immediately
      policies:
      - type: Percent
        value: 100  # Can double size at once
        periodSeconds: 30

Requirements:

• Metrics Server must be installed
• Resource requests must be set
• Target must support scaling (Deployment, StatefulSet, ReplicaSet)

Vertical Pod Autoscaler (VPA)

Automatically adjust resource requests/limits:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  updatePolicy:
    updateMode: Auto  # Auto, Recreate, Initial, Off
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2000m
        memory: 2Gi
      controlledResources: ["cpu", "memory"]

Update modes:

• Auto: VPA updates pods automatically (requires restart)
• Recreate: VPA recreates pods to apply updates
• Initial: Only set resources on pod creation
• Off: Only generate recommendations

Note: VPA and HPA should not target the same metrics (CPU/memory). Use VPA for right-sizing, HPA for scaling.

LimitRange (Namespace Defaults)

Set default requests/limits per namespace:

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
  namespace: production
spec:
  limits:
  - max:
      cpu: "2"
      memory: 2Gi
    min:
      cpu: 100m
      memory: 128Mi
    default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 250m
      memory: 256Mi
    type: Container
  - max:
      cpu: "4"
      memory: 4Gi
    type: Pod

ResourceQuota (Namespace Limits)

Limit total resource usage per namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    persistentvolumeclaims: "10"
    pods: "50"
    services: "20"

Workload Types

Deployment (Stateless Applications)

Use for: Web servers, APIs, microservices, stateless workers

Characteristics:

• Pods are interchangeable
• No persistent identity
• Scale up/down freely
• Rolling updates supported

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
      - name: api
        image: api:1.0.0
        ports:
        - containerPort: 8080

StatefulSet (Stateful Applications)

Use for: Databases, message queues, distributed systems requiring stable identity

Characteristics:

• Stable, unique network identifiers
• Stable, persistent storage
• Ordered, graceful deployment and scaling
• Ordered, automated rolling updates

Example:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mongodb
spec:
  serviceName: mongodb
  replicas: 3
  selector:
    matchLabels:
      app: mongodb
  template:
    metadata:
      labels:
        app: mongodb
    spec:
      containers:
      - name: mongodb
        image: mongo:7.0
        ports:
        - containerPort: 27017
        volumeMounts:
        - name: data
          mountPath: /data/db
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: fast-ssd
      resources:
        requests:
          storage: 100Gi

StatefulSet features:

• Pods named: mongodb-0, mongodb-1, mongodb-2
• Predictable DNS: mongodb-0.mongodb.namespace.svc.cluster.local
• Persistent storage follows pod identity
• Ordered startup: 0 → 1 → 2
• Ordered shutdown: 2 → 1 → 0

Headless Service (required):

apiVersion: v1
kind: Service
metadata:
  name: mongodb
spec:
  clusterIP: None  # Headless
  selector:
    app: mongodb
  ports:
  - port: 27017

DaemonSet (Node-Level Services)

Use for: Log collectors, monitoring agents, node-level storage, network plugins

Characteristics:

• One pod per node (or selected nodes)
• Automatically scales with cluster
• Runs before other pods (priority)
• Useful for infrastructure components

Example:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluent/fluentd:v1.16
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: containers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: containers
        hostPath:
          path: /var/lib/docker/containers

Node selection:

# Run on specific nodes only
spec:
  template:
    spec:
      nodeSelector:
        logging: enabled
      # Or use affinity for more complex selection
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-role.kubernetes.io/worker
                operator: Exists

Job (One-Time Tasks)

Use for: Batch processing, data migration, backup operations, ETL jobs

Characteristics:

• Runs until completion
• Retries on failure
• Can run multiple pods in parallel
• Pods not restarted after success

Example:

apiVersion: batch/v1
kind: Job
metadata:
  name: data-migration
spec:
  completions: 1      # Total successful completions needed
  parallelism: 1      # Pods to run simultaneously
  backoffLimit: 3     # Max retries before marking failed
  activeDeadlineSeconds: 3600  # Job timeout (1 hour)
  template:
    spec:
      restartPolicy: OnFailure  # Required for Jobs
      containers:
      - name: migrator
        image: migration-tool:1.0
        env:
        - name: SOURCE_DB
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: source
        - name: TARGET_DB
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: target

Parallel processing pattern:

apiVersion: batch/v1
kind: Job
metadata:
  name: parallel-processor
spec:
  completions: 10     # Need 10 successful completions
  parallelism: 3      # Run 3 at a time
  template:
    spec:
      restartPolicy: OnFailure
      containers:
      - name: processor
        image: processor:1.0
        env:
        - name: TASK_ID
          valueFrom:
            fieldRef:
              fieldPath: metadata.name

CronJob (Scheduled Tasks)

Use for: Periodic backups, scheduled reports, cleanup jobs, health checks

Characteristics:

• Runs on schedule (cron syntax)
• Creates Jobs on schedule
• Manages Job lifecycle
• Configurable history retention

Example:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-database
spec:
  schedule: "0 2 * * *"  # Every day at 2 AM UTC
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  concurrencyPolicy: Forbid  # Don't allow overlapping runs
  startingDeadlineSeconds: 300  # Start within 5 minutes or skip
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: backup
            image: backup-tool:1.0
            env:
            - name: BACKUP_TIMESTAMP
              value: "$(date +%Y%m%d-%H%M%S)"
            volumeMounts:
            - name: backup-storage
              mountPath: /backups
          volumes:
          - name: backup-storage
            persistentVolumeClaim:
              claimName: backup-pvc

Cron schedule syntax:

# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of week (0 - 6) (Sunday=0)
# │ │ │ │ │
# * * * * *

"0 */6 * * *"      # Every 6 hours
"0 2 * * *"        # Daily at 2 AM
"0 0 * * 0"        # Weekly on Sunday at midnight
"0 0 1 * *"        # Monthly on the 1st at midnight
"*/15 * * * *"     # Every 15 minutes

Concurrency policies:

• Allow: Allow multiple jobs to run (default)
• Forbid: Skip new job if previous still running
• Replace: Cancel running job and start new one