Kubernetes Deployment Strategies Step by Step

author

By Freecoderteam

Nov 18, 2025

1

image

Kubernetes Deployment Strategies: Step by Step Guide

Deploying applications to Kubernetes is a critical task that requires careful planning and execution. Kubernetes offers several deployment strategies, each with its own advantages and use cases. In this comprehensive guide, we’ll explore the different deployment strategies, provide step-by-step examples, and share best practices to help you make informed decisions.


Table of Contents

  1. Introduction to Kubernetes Deployments
  2. Understanding Deployment Strategies
  3. Step-by-Step Implementation
  4. Best Practices
  5. Conclusion

Introduction to Kubernetes Deployments

In Kubernetes, a Deployment is a resource that manages the rollout of applications. It ensures that the desired state of the application is maintained, even in the face of failures. Deployments use ReplicaSets to manage the number of identical pods running at any given time. Kubernetes provides several strategies to control how pods are updated during deployments.


Understanding Deployment Strategies

1. Rolling Update

Rolling Update is the default deployment strategy in Kubernetes. It gradually replaces existing pods with new ones, ensuring that the application remains available during the process. This strategy minimizes downtime and avoids interrupting active user sessions.

Key Features:

  • Pod replacement happens one at a time (or in batches, depending on configuration).
  • Existing pods are terminated only after new ones are successfully running.
  • Supports configuration of maxUnavailable and maxSurge to control scaling.

Example YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Maximum number of pods above the desired replicas
      maxUnavailable: 1  # Maximum number of pods that can be unavailable
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:v1
        ports:
        - containerPort: 8080

Configuration Explanation:

  • maxSurge: 1: Allows Kubernetes to create one additional pod beyond the desired replica count.
  • maxUnavailable: 1: Ensures that at least two pods are always available during the update.

2. Recreate

The Recreate strategy terminates all existing pods before creating new ones. This strategy is useful when the application cannot run alongside older versions or when a complete restart is necessary.

Key Features:

  • All pods are terminated before new ones are created.
  • Can result in downtime if not used carefully.
  • Suitable for stateful applications or when rolling updates are not feasible.

Example YAML:

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

Use Case:

  • Deploying stateful applications where data consistency is critical.
  • Applications that cannot run with multiple versions simultaneously.

3. Blue/Green Deployment

Blue/Green Deployment involves running two identical environments (Blue and Green) and switching traffic between them. One environment is active (serving traffic), while the other is used for deployment and testing. This ensures zero downtime and easy rollback.

Key Features:

  • Two identical environments with distinct versions.
  • Traffic is redirected to the new environment after deployment and testing.
  • Rollback is as simple as switching traffic back to the old environment.

Implementation Steps:

  1. Deploy Two Environments:

    • Create two Deployments: my-app-blue and my-app-green.
    • Use Ingress or Service to manage traffic routing.
  2. Traffic Management:

    • Use an Ingress controller or Kubernetes Service to route traffic to the active environment.
  3. Switch Traffic:

    • After deploying the new version to the Green environment, test it thoroughly.
    • Redirect traffic to the Green environment and decommission the Blue environment.

Example YAML:

# Deployment for Blue environment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      env: blue
  template:
    metadata:
      labels:
        app: my-app
        env: blue
    spec:
      containers:
      - name: my-app-container
        image: my-app:v1
        ports:
        - containerPort: 8080

# Deployment for Green environment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      env: green
  template:
    metadata:
      labels:
        app: my-app
        env: green
    spec:
      containers:
      - name: my-app-container
        image: my-app:v2
        ports:
        - containerPort: 8080

# Ingress for traffic routing
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-blue
            port:
              number: 80

Use Case:

  • When zero downtime is critical.
  • For applications that require extensive testing before going live.

4. Canary Deployment

Canary Deployment involves gradually rolling out a new version to a subset of users or traffic. This allows for incremental testing and reduces the risk of introducing bugs to all users at once.

Key Features:

  • A small percentage of traffic is routed to the new version.
  • Metrics are monitored to ensure the new version performs as expected.
  • Traffic is gradually increased to the new version if it passes testing.

Implementation Steps:

  1. Deploy Canary Pods:

    • Create a Deployment with a small number of replicas to test the new version.
  2. Traffic Splitting:

    • Use an Ingress controller like Istio or NGINX to split traffic between the main and canary deployments.
  3. Monitoring:

    • Use tools like Prometheus and Grafana to monitor the canary version’s performance.
  4. Gradual Rollout:

    • Increase traffic to the canary version if it performs well. Otherwise, roll back.

Example YAML:

# Main Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-main
spec:
  replicas: 10
  selector:
    matchLabels:
      app: my-app
      version: main
  template:
    metadata:
      labels:
        app: my-app
        version: main
    spec:
      containers:
      - name: my-app-container
        image: my-app:v1
        ports:
        - containerPort: 8080

# Canary Deployment
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:v2
        ports:
        - containerPort: 8080

# Ingress for traffic splitting
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-main
            port:
              number: 80

Use Case:

  • When you want to test a new version with production traffic but limit exposure.
  • For applications with high user traffic where gradual testing is essential.

Step-by-Step Implementation

Using Rolling Update Strategy

  1. Create a Deployment:

    • Define the Deployment YAML with the desired image and replica count.
    • Use the default RollingUpdate strategy.
  2. Apply the Deployment:

    kubectl apply -f my-app-deployment.yaml
    
  3. Update the Image:

    • Modify the image field in the Deployment YAML to the new version.
    • Apply the changes:
      kubectl set image deployment/my-app my-app-container=my-app:v2
      
  4. Monitor the Rollout:

    • Use kubectl rollout status to track the progress:
      kubectl rollout status deployment/my-app
      

Implementing Blue/Green Deployment

  1. Deploy Both Environments:

    • Create two Deployments: my-app-blue and my-app-green.
  2. Create an Ingress:

    • Define an Ingress resource to route traffic to the active environment.
  3. Switch Traffic:

    • Update the Ingress to point to the Green environment after testing:
      kubectl patch ingress my-app-ingress --type merge -p '{"spec": {"rules": [{"http": {"paths": [{"backend": {"service": {"name": "my-app-green"}}}]}}]}}'
      
  4. Decommission the Blue Environment:

    • Scale down the Blue environment to zero replicas:
      kubectl scale deployment/my-app-blue --replicas=0
      

Best Practices

  1. Automate Rollouts:

    • Use CI/CD pipelines to automate deployment processes.
    • Integrate monitoring and testing into the pipeline.
  2. Monitor Metrics:

    • Use tools like Prometheus and Grafana to monitor application performance.
    • Define SLIs (Service Level Indicators) and SLAs (Service Level Agreements).
  3. Implement Rollback:

    • Always ensure that rollbacks are possible.
    • Use Kubernetes’s built-in rollback feature:
      kubectl rollout undo deployment/my-app
      
  4. Use Canary and Blue/Green for Critical Applications:

    • For applications with high uptime requirements, consider Blue/Green or Canary strategies.
    • Gradually test new versions with real traffic.
  5. Document Strategies:

    • Maintain clear documentation on deployment strategies and rollback procedures.
    • Ensure that all team members understand the deployment process.

Conclusion

Kubernetes offers flexible deployment strategies to suit various use cases. Whether you need a quick update with minimal downtime or a controlled rollout to test new versions, Kubernetes provides the tools to achieve your goals. By understanding the trade-offs between strategies and implementing best practices, you can ensure smooth and reliable deployments.

In this guide, we covered:

  • The default Rolling Update strategy and its configuration.
  • The Recreate strategy for stateful applications.
  • The Blue/Green deployment for zero-downtime rollouts.
  • The Canary deployment for gradual testing.

By following these strategies and best practices, you can build robust, scalable, and reliable Kubernetes deployments. Happy deploying!


Feel free to experiment with these strategies and adapt them to your specific use cases. If you have questions or need further clarification, reach out! 🚀

Subscribe to Receive Future Updates

Stay informed about our latest updates, services, and special offers. Subscribe now to receive valuable insights and news directly to your inbox.

No spam guaranteed, So please don’t send any spam mail.