Skip to main content
In this lesson we cover common deployment and release patterns in Kubernetes: Rolling Updates, Recreate, Blue-Green, and Canary releases. These patterns help you deploy new application versions safely, minimize downtime, and control traffic during rollouts. We start with the two core strategies supported by Kubernetes Deployments: RollingUpdate and Recreate.

​
Why deployment strategy matters

For a popular web application with thousands of users, deploying a new version must avoid downtime and prevent cluster overload. Kubernetes deployment strategies determine how pods are replaced, how traffic is shifted, and how much control you have over rollout speed and failure recovery.
  • RollingUpdate: Gradual replacement of pods; new pods are created and validated before old ones are removed.
  • Recreate: Terminates all old pods first, then starts new pods—simpler but causes downtime.
  • Blue-Green and Canary: Provide explicit traffic control for staged exposure of new versions.
Rolling updates allow Kubernetes to replace pods incrementally. This ensures continuous availability while gradually shifting to the new version. You can control the pace using maxSurge, maxUnavailable, and readiness probes/minReadySeconds. Key benefits:
  • Minimal disruption—application remains available during rollout.
  • Controlled, incremental changes to limit risk.
  • Ability to pause or rollback if problems are detected.
Typical GitOps workflow:
  1. Developer updates the Deployment manifest in Git (e.g., image tag v1.0 → v2.0).
  2. GitOps operator (Argo CD, Flux, etc.) detects the change and applies it to the cluster.
  3. Kubernetes applies the rolling update according to the Deployment strategy settings.
Example Deployment configured for a rolling update: 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # at most 1 extra pod above desired replicas
      maxUnavailable: 0  # do not allow any unavailable pods during update
  minReadySeconds: 10   # pod must be ready for this many seconds before considered available
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
        - name: web
          image: myrepo/example-app:2.0
          ports:
            - containerPort: 80
RollingUpdate is the default Deployment strategy. Use maxSurge and maxUnavailable to control how many pods are added/removed at each step. Combine readiness probes and minReadySeconds to ensure pods serve traffic only after they are healthy.
You can pause a rollout with kubectl rollout pause deployment/<name> to investigate failures, and resume or roll back with kubectl rollout resume or kubectl rollout undo respectively.

​
Recreate (when multiple versions cannot coexist)

The Recreate strategy terminates all existing pods for a Deployment before creating any new pods. This is appropriate when your application cannot safely run multiple versions simultaneously or requires exclusive access to shared resources during startup. When to choose Recreate:
  • The application cannot safely run multiple versions concurrently.
  • Short, acceptable downtime is preferable to complex coordination.
  • Legacy or stateful services that require exclusive initialization.
How it works with GitOps:
  1. The manifest is updated and pushed to Git.
  2. The GitOps operator applies the change.
  3. Kubernetes deletes all existing pods for that Deployment, then creates the new pods.
Example Deployment using Recreate: 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app-recreate
spec:
  replicas: 3
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: example-app-recreate
  template:
    metadata:
      labels:
        app: example-app-recreate
    spec:
      containers:
        - name: web
          image: myrepo/example-app:2.0
          ports:
            - containerPort: 80
Recreate causes downtime while old pods are terminated and new pods are created. Use it only when coexisting versions are unsafe or when brief downtime is acceptable.

​
Blue-Green Deployments and Canary Releases (advanced traffic control)

In addition to RollingUpdate and Recreate, blue-green and canary patterns offer more granular control over traffic and exposure:
  • Blue-Green: Maintain two separate environments (blue = current, green = new). Switch traffic to green once verified. This enables near-instant rollback by switching back to blue.
  • Canary: Gradually shift a small percentage of user traffic to the new version, monitor behavior, then increase traffic in steps until fully rolled out.
Both patterns are often implemented with service routing, Ingress rules, or service meshes (e.g., Istio, Linkerd), and integrate well with GitOps pipelines for automated promotion.

​
Quick comparison

StrategyDowntimeRollout controlUse case
RollingUpdateMinimal/noneIncremental (maxSurge/maxUnavailable)Stateless services, production web apps
RecreateYes (brief)Simple (all at once)Legacy/stateful apps that can’t run concurrently
Blue-GreenMinimal (switch moment)Full environment swapSafe testing in a production-like environment
CanaryMinimalFine-grained traffic shiftGradual exposure, A/B testing, risk-limited deploys
  • Use RollingUpdate for most stateless workloads.
  • Configure readiness/liveness probes and minReadySeconds to avoid routing traffic to unhealthy pods.
  • Use GitOps (Argo CD, Flux) to keep manifests declarative and reproducible.
  • Employ blue-green or canary patterns for high-risk or business-critical changes; use service meshes for advanced traffic control.
  • Automate monitoring and observability (metrics, tracing, logs) to detect regressions early during rollouts.
This lesson introduced rollout patterns and their trade-offs. Choose the strategy that balances availability, risk, and operational complexity for your application, and integrate it with GitOps pipelines and observability for safe, repeatable deployments.

Watch Video