Deployment Types – ahmadrazalab

In Kubernetes, there are several deployment strategies that you can use depending on your application requirements and the desired impact on your service. The main deployment strategies include:

Recreate Deployment
Rolling Update Deployment
Blue/Green Deployment
Canary Deployment

1. Recreate Deployment

In a recreate deployment, all the existing pods are terminated before new ones are created. This can lead to downtime but is sometimes necessary when the new version is not compatible with the old version.

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.0  # Updated version
        ports:
        - containerPort: 80

Apply the deployment:

kubectl apply -f nginx-recreate-deployment.yaml

2. Rolling Update Deployment

A rolling update deployment replaces the pods gradually, ensuring some instances of the application are always running.

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.0  # Updated version
        ports:
        - containerPort: 80

Apply the deployment:

kubectl apply -f nginx-rolling-update-deployment.yaml

3. Blue/Green Deployment

In a blue/green deployment, two separate environments (blue and green) are maintained. Traffic is switched to the new version (green) once it's verified to be working correctly. This can be managed using service labels to switch traffic between environments.

Example:

Create a deployment for both environments:

Blue Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-blue
  labels:
    app: nginx
    version: blue
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
      version: blue
  template:
    metadata:
      labels:
        app: nginx
        version: blue
    spec:
      containers:
      - name: nginx
        image: nginx:1.19.10  # Blue version
        ports:
        - containerPort: 80

Green Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-green
  labels:
    app: nginx
    version: green
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
      version: green
  template:
    metadata:
      labels:
        app: nginx
        version: green
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.0  # Green version
        ports:
        - containerPort: 80

Create a service to route traffic:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
    version: blue  # Initially route to blue
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

To switch to the green deployment, update the service selector:

kubectl patch service nginx-service -p '{"spec":{"selector":{"app":"nginx","version":"green"}}}'

4. Canary Deployment

In a canary deployment, a small subset of users is routed to the new version initially. If the new version is stable, the traffic is gradually increased. This can be managed using service weights or Ingress controllers.

Example:

Create a deployment for both versions:

Stable Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-stable
  labels:
    app: nginx
    version: stable
spec:
  replicas: 9
  selector:
    matchLabels:
      app: nginx
      version: stable
  template:
    metadata:
      labels:
        app: nginx
        version: stable
    spec:
      containers:
      - name: nginx
        image: nginx:1.19.10  # Stable version
        ports:
        - containerPort: 80

Canary Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-canary
  labels:
    app: nginx
    version: canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
      version: canary
  template:
    metadata:
      labels:
        app: nginx
        version: canary
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.0  # Canary version
        ports:
        - containerPort: 80

Create a service to route traffic:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Initially, the service will route traffic to both versions. You can manage traffic distribution using an ingress controller or service mesh like Istio for more granular control.

Summary

Each deployment strategy has its use cases:

Recreate: Simple but causes downtime.
Rolling Update: Gradual replacement, no downtime.
Blue/Green: Easy rollback, no downtime.
Canary: Test with a small user base, no downtime.

Troubleshooting Reource Limit+namespace