Deployments Types

1. Recreate Strategy

Deployment YAML Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-recreate
spec:
  replicas: 3
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.0
        ports:
        - containerPort: 80

Notes:

During deployment, all pods are terminated first → causes downtime.
Simple & fast but not suitable if your app requires continuous availability.

2. Rolling Update (Default)

Deployment YAML Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-rolling
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.1
        ports:
        - containerPort: 80

Key Fields:

maxUnavailable: max pods down during update (here 1).
maxSurge: max extra pods above desired during update (here 1).

Notes:

Ensures zero downtime.
If a pod fails readiness check, rollout pauses.
Best for most apps.

3. Blue/Green Deployment

Conceptual Setup

You maintain two deployments:

my-app-blue (currently live)
my-app-green (new version)

Service YAML (switch traffic)

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app-blue  # Switch to my-app-green to deploy new version
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Deployments (blue and green)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app-blue
  template:
    metadata:
      labels:
        app: my-app-blue
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.0
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app-green
  template:
    metadata:
      labels:
        app: my-app-green
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.1
        ports:
        - containerPort: 80

How to switch traffic:

kubectl patch service my-app-service -p '{"spec":{"selector":{"app":"my-app-green"}}}'

Notes:

Zero downtime by switching traffic instantaneously.
Requires double resources during rollout.
Rollback by switching selector back.

4. Canary Deployment

Simple Kubernetes Only Example (Manual)

Two Deployments:

my-app-primary (90% traffic)
my-app-canary (10% traffic)

Because Kubernetes Service cannot do traffic weighting natively, you'd need an Ingress controller or Service Mesh for real traffic splitting.

Canary Deployment Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-primary
spec:
  replicas: 9
  selector:
    matchLabels:
      app: my-app
      version: stable
  template:
    metadata:
      labels:
        app: my-app
        version: stable
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.0
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
      version: canary
  template:
    metadata:
      labels:
        app: my-app
        version: canary
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.1

Using an Ingress or Service Mesh for traffic split:

Example: Istio VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
  - my-app.example.com
  http:
  - route:
    - destination:
        host: my-app
        subset: stable
      weight: 90
    - destination:
        host: my-app
        subset: canary
      weight: 10

Notes:

Gradually increase canary weight to 100% after validation.
Requires monitoring (metrics, logs, errors).
Rollback by removing canary.

Additional Tips for Production

Topic	Tips
Health Checks	Use readinessProbe to avoid sending traffic to unhealthy pods during rollout
Resource Management	Define resource requests & limits to avoid over/under-provisioning during deployments
Autoscaling	Use Horizontal Pod Autoscaler to scale deployments during and after rollout
Monitoring & Alerts	Set up Prometheus/Grafana, Alertmanager to watch rollout health and rollback if necessary
CI/CD Integration	Automate deployments with Helm + ArgoCD or Flux for safe versioning and rollback

Affinity Labelselector