Skip to main content
In this lesson we’ll cover common Kubernetes deployment and release patterns: RollingUpdate, Recreate, blue–green deployments, and canary releases. We begin with the two fundamental Deployment strategies supported by Kubernetes: RollingUpdate and Recreate. These strategies help you update application pods with predictable availability and resource usage during a rollout. Imagine you’re running a high-traffic web application with thousands of users. You must deploy a new version without causing downtime, but replacing all pods at once could overload the cluster or interrupt service. Kubernetes strategies manage pod replacement safely and predictably.

​
RollingUpdate

A RollingUpdate replaces pods gradually—one or a few at a time—by creating new pods, verifying they are healthy, and then terminating old pods. This approach reduces service disruption and keeps the application available throughout the rollout. Example Deployment (RollingUpdate): 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # Can be an absolute number or a percentage
      maxSurge: 1
      maxUnavailable: 0
  minReadySeconds: 10
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: my-app:1.0
Important parameters:
  • maxSurge: number (or percentage) of extra pods that can be created above the desired replicas during the update.
  • maxUnavailable: number (or percentage) of pods that can be unavailable during the update.
  • minReadySeconds: time a pod must be in Ready state before it counts as available for the rollout decision.
Typical GitOps rollout (with ArgoCD) using RollingUpdate:
  1. Developer updates the image tag in the Deployment manifest (e.g., my-app:1.0 → my-app:2.0) and pushes the change to Git.
  2. The GitOps operator detects the commit and applies the manifest to the cluster.
  3. Kubernetes performs the rolling update: it creates new pods, waits for readiness, then removes old pods.
  4. If the rollout fails or metrics regress, you can pause, investigate, and roll back.
Troubleshooting and common commands: 
# See rollout status
kubectl rollout status deployment/my-app

# Roll back to the previous revision
kubectl rollout undo deployment/my-app
RollingUpdate is the Kubernetes default strategy. It provides continuous availability during upgrades and is well-suited to stateless services or stateful apps that rely on external persistence.

​
Recreate

The Recreate strategy deletes all existing pods before creating any new pods. This is a simpler lifecycle but it introduces downtime while the new pods start. Use Recreate when the application cannot safely run multiple versions simultaneously (no coexistence) or when short downtime is acceptable. Example Deployment (Recreate): 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: my-app:1.0
How Recreate typically works in a GitOps flow:
  1. Update the image tag in the Git manifest.
  2. GitOps operator applies the manifest to the cluster.
  3. Kubernetes deletes all current pods for the Deployment.
  4. Kubernetes creates the new pods for the updated version.
  5. The service is unavailable between pod deletion and the new pods becoming ready.
Comparing RollingUpdate vs Recreate
  • RollingUpdate: minimal downtime, allows coexistence of old and new pods during rollout. Best when continuous availability is required.
  • Recreate: simple lifecycle with downtime while pods are replaced. Best when version coexistence is unsafe.
Comparison table
StrategyDowntimeCoexistence of versionsWhen to use
RollingUpdateMinimal (configurable)YesStateless apps or stateful apps with external persistence; continuous availability required
RecreateTemporary downtimeNoWhen concurrency between versions causes problems, or when brief downtime is acceptable

​
Next steps

Once you’re comfortable with RollingUpdate and Recreate, explore blue–green deployments and canary releases for more controlled traffic shifting and progressive rollouts. These patterns often require traffic management tooling such as an Ingress controller, a service mesh (e.g., Istio), or external load balancers, together with observability and automation to safely promote or rollback releases. Links and references

Watch Video