Cloud Knowledge

Your Go-To Hub for Cloud Solutions & Insights

Advertisement
Kubernetes

kubectl-Managing Application Updates and Rollbacks

Shivam Tiwari 2

Core Kubernetes Topics: Deployments — Managing Application Updates and Rollbacks

A deep, practical guide for Kubernetes engineers, DevOps teams, and platform owners. Includes YAML examples, troubleshooting PowerShell steps for Windows/PowerShell users (including AKS-focused commands), kubectl commands, rollout strategies, and FAQs for every major topic. SEO-optimized and WordPress-ready.

Introduction

In Kubernetes, a Deployment is a higher-level object that manages ReplicaSets and provides declarative updates for Pods. Deployments are the primary way to manage stateless applications on Kubernetes clusters — they handle scaling, updates, rollbacks, and self-healing. This post covers everything from definitions to advanced rollout strategies (Canary, Blue-Green), troubleshooting commands (kubectl and PowerShell examples), and best practices you can paste directly into WordPress.

Table of Contents

  1. What is a Kubernetes Deployment?
  2. Purpose & Benefits
  3. How Deployments Work (ReplicaSets, Pods)
  4. Deployment Strategies (RollingUpdate, Recreate, Canary, Blue-Green)
  5. Key Deployment Fields (updateStrategy, revisionHistoryLimit, progressDeadlineSeconds)
  6. Examples: Deployment YAML + Readiness/Liveness Probes
  7. kubectl Commands: rollout status/history/undo/pause/resume
  8. Scaling and Self-Healing
  9. Integration with CI/CD (Jenkins, GitHub Actions, Argo CD)
  10. Monitoring & Observability
  11. Troubleshooting with PowerShell & kubectl (AKS-focused examples)
  12. Best Practices
  13. FAQs and Key Points per section
  14. Appendix: Useful Scripts & Cheat Sheet

1. What is a Kubernetes Deployment?

A Deployment is a Kubernetes API object that declares the desired state for stateless application Pods, including the container image, number of replicas, and update strategy. Kubernetes continuously works to match the current cluster state to the declared state.

Key points

  • Declarative: you express the desired state; Kubernetes implements it.
  • Manages ReplicaSets: Deployments create and manage ReplicaSets to keep pods running.
  • Supports automated updates and rollbacks.

FAQs (FQUs)

Q: Is a Deployment required for all workloads?
A: No — StatefulSets, DaemonSets, Jobs exist for other workload types. Use Deployments for stateless apps.

2. Purpose & Benefits of Deployments

Deployments give you a single declarative object to manage rolling updates, version history, rollbacks, and scaling. They are the recommended abstraction for most production stateless applications.

Major benefits

  • Zero-downtime updates (with RollingUpdate when configured correctly).
  • Automatic rollbacks on failure.
  • Versioned rollouts and auditability (revision history).
  • Easy scaling with kubectl or API calls.

Key points

  • Use readiness probes to guarantee traffic only reaches healthy pods during updates.
  • Use revisionHistoryLimit to manage old ReplicaSets.

3. How Deployments Work (ReplicaSets & Pods)

When you create a Deployment, Kubernetes creates a ReplicaSet that holds the desired Pod template. The Deployment controller ensures the ReplicaSet maintains the desired number of replicas. When you update the Deployment spec, Kubernetes creates a new ReplicaSet for the updated template and gradually shifts traffic from the old ReplicaSet to the new one (for RollingUpdate).

Key points

  • A Deployment → manages ReplicaSets → ReplicaSet manages Pods.
  • ReplicaSets are versioned implicitly; each updated template gets a new ReplicaSet.

FAQs

Q: Can I manage ReplicaSets directly?
A: Yes, but it is recommended to use Deployments to get automatic updates and rollbacks.

4. Deployment Strategies

RollingUpdate (default)

The default strategy replaces Pods gradually to ensure availability. Two parameters control it:

  • maxUnavailable — the maximum number of Pods that can be unavailable during an update.
  • maxSurge — the maximum number of extra Pods that can be created during the update.
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 25%

Recreate

Stops all existing Pods before starting new ones. Use when your app cannot run multiple versions concurrently (rare for stateless apps).

Canary

Not built into Deployment API, but implemented using multiple Deployments, traffic splitting (Service/Ingress), or advanced tools like Flagger or Argo Rollouts. Canary releases send a small percentage of traffic to the new version first.

Blue-Green

Maintain two environments (blue = current, green = new). After validating green, switch traffic from blue to green by changing Service selectors or load balancer configuration.

Key points

  • RollingUpdate is safe for zero-downtime when probes are used.
  • Canary and Blue-Green require more orchestration or external tools for automated traffic shift and observability.

FAQs

Q: Which strategy is best?
A: Start with RollingUpdate + readiness probes. Use Canary/Blue-Green when you need stronger validation and traffic control.

5. Important Deployment Fields

Key fields in a Deployment spec that control behavior:

  • replicas — desired number of Pods.
  • selector — label selector matching Pods managed by the Deployment.
  • template — Pod template for containers, probes, volumes.
  • strategy — RollingUpdate or Recreate.
  • revisionHistoryLimit — how many old ReplicaSets to keep.
  • progressDeadlineSeconds — timeout for rollout to make progress.

Key points

  • Set revisionHistoryLimit to a reasonable number (e.g., 5) to avoid large numbers of ReplicaSets.
  • progressDeadlineSeconds default is 600 seconds; adjust for larger apps.

FAQs

Q: What happens when progressDeadlineSeconds is exceeded?
A: Kubernetes marks the rollout as failed and you can inspect events and logs to decide to rollback or retry.

6. Deployment YAML Example (with readiness & liveness probes)

Basic nginx deployment with RollingUpdate parameters and probes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  revisionHistoryLimit: 5
  progressDeadlineSeconds: 600
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 15
          periodSeconds: 20
          failureThreshold: 5

Key points

  • Readiness probe ensures the Pod is ready to accept traffic before service routes to it.
  • Liveness probe restarts containers that are unhealthy.

FAQs

Q: How do probes affect rolling updates?
A: If readiness probe fails during update, old pods remain serving and new pods won't receive traffic — this can trigger automatic rollback if progressDeadlineSeconds elapses.

7. Essential kubectl Commands for Deployment Lifecycle

Common kubectl commands you will use daily to manage Deployments and rollouts:

  • kubectl apply -f deployment.yaml — create or update a Deployment.
  • kubectl get deployments — list Deployments.
  • kubectl describe deployment nginx-deployment — inspect events and status.
  • kubectl rollout status deployment/nginx-deployment — watch rollout progress.
  • kubectl rollout history deployment/nginx-deployment — view revision history.
  • kubectl rollout undo deployment/nginx-deployment --to-revision=2 — rollback to a previous revision.
  • kubectl rollout pause deployment/nginx-deployment — pause a rollout for manual intervention.
  • kubectl rollout resume deployment/nginx-deployment — resume a paused rollout.

Troubleshooting tips

  • When rollout fails, immediately run kubectl describe deployment <name> and kubectl get events --sort-by='.metadata.creationTimestamp' to find events.
  • Check ReplicaSet and Pod logs: kubectl get rs, then kubectl logs <pod-name>.
  • Use kubectl get pods -o wide to inspect node placement and restarts.

FAQs

Q: How do I quickly rollback a bad deployment?
A: Use kubectl rollout undo deployment/<name>. If you need to revert image only, patch the deployment image to a previous tag.

8. Deployment Scaling & Self-Healing

Deployments support both manual and autoscaling:

  • Manual scale: kubectl scale deployment/nginx-deployment --replicas=6
  • Autoscale with HPA (Horizontal Pod Autoscaler): kubectl autoscale deployment nginx-deployment --min=3 --max=10 --cpu-percent=70

Self-healing

Kubernetes automatically replaces Pods that fail (CrashLoopBackoff, node failure), ensuring the desired replica count is maintained. Combine this with liveness probes and resource requests/limits to avoid flapping.

Key points

  • Always set resource requests/limits to make HPA effective.
  • Monitor Pod restarts to identify unstable images or probe misconfiguration.

FAQs

Q: Why is my HPA not scaling?
A: Likely missing resource requests (HPA targets metrics like CPU). Ensure metrics-server is installed and your pods expose the metrics.

9. Integration with CI/CD Pipelines

Automating Deployments via CI/CD is essential for fast, safe delivery. Popular tools include Jenkins, GitHub Actions, GitLab CI, Argo CD, and Flux.

Patterns

  • Build → run tests → push image to registry → update Deployment manifest (bump image tag) → apply manifest to cluster.
  • Use GitOps (Argo CD / Flux) to manage Deployments declaratively from Git repositories.

Example GitHub Actions step (patch image)

- name: Set Kubernetes image
  run: |
    kubectl set image deployment/nginx-deployment nginx=ghcr.io/myorg/myapp:${{ github.sha }} --record

Key points

  • Use immutable tags (SHA-based) instead of latest.
  • Record rollout history by using --record or by annotating manifests.

FAQs

Q: Should I use GitOps or imperative kubectl updates from CI?
A: GitOps offers better auditability and reconciliation. Use imperative updates for quick fixes, GitOps for day-to-day deployment automation.

10. Monitoring Deployments & Observability

Monitoring rollout health and performance is critical. Use Prometheus + Grafana for metrics, EFK/ELK for logs, and tracing tools (Jaeger/Zipkin) for distributed traces.

What to monitor

  • Pod readiness/liveness status.
  • ReplicaSet replica counts and restarts.
  • Request latency, error rates, CPU/memory usage.
  • Rollout success/failure counts and duration.

Key points

  • Create dashboards that map rollouts to application-level metrics (errors, latency).
  • Use alerting on progressive degradation during rollout (e.g., spike in 5xx responses).

FAQs

Q: How to detect a rollback-worthy issue automatically?
A: Use tools like Flagger that integrate with metrics providers to automatically rollback failing canaries.

11. Troubleshooting Deployments — PowerShell & kubectl (AKS examples)

This section provides Windows/PowerShell friendly commands and scripts that help debug and fix deployment issues, especially for Azure Kubernetes Service (AKS) users. If you operate in a mixed Windows environment or prefer PowerShell scripting, these commands are directly runnable in PowerShell (with kubectl installed) or Azure Cloud Shell.

Prerequisites (PowerShell)

  • Install kubectl and az CLI or use Azure Cloud Shell.
  • Connect to AKS: az aks get-credentials --resource-group <rg> --name <cluster>

PowerShell: Basic AKS connection & Deployment rollout status

# Login and get AKS credentials
az login

az aks get-credentials --resource-group "rg-myapp" --name "aks-prod"

# Check rollout status (PowerShell)
kubectl rollout status deployment/nginx-deployment -n default

PowerShell: Inspect events, ReplicaSets, and pod logs

# Describe deployment and view recent events
kubectl describe deployment nginx-deployment -n default

# Sort events by creation timestamp (PowerShell-friendly)
kubectl get events -n default --sort-by='.metadata.creationTimestamp' | Select-String -Pattern "Warning" -Context 0,2

# List ReplicaSets
kubectl get rs -n default

# View pods and container restarts
kubectl get pods -n default -o wide

# View logs from a failing pod
kubectl logs nginx-deployment-xxxxx -n default --previous

PowerShell: Auto-rollback helper script

Script to monitor rollout and rollback automatically on failure. Use with care in production; adapt to your CI/CD safety rules.

# AutoRollback.ps1 - monitor a rollout and rollback on failure
param(
  [string]$Deployment = "nginx-deployment",
  [string]$Namespace = "default",
  [int]$TimeoutSeconds = 600
)

$start = Get-Date
Write-Host "Monitoring rollout for $Deployment in $Namespace..."

while ((Get-Date) -lt $start.AddSeconds($TimeoutSeconds)) {
  $status = kubectl rollout status deployment/$Deployment -n $Namespace 2>&1
  Write-Host $status
  if ($status -match "successfully rolled out") {
    Write-Host "Rollout succeeded."
    exit 0
  }
  if ($status -match "progress deadline exceeded") {
    Write-Host "Rollout failed. Initiating rollback..."
    kubectl rollout undo deployment/$Deployment -n $Namespace
    exit 1
  }
  Start-Sleep -Seconds 10
}

Write-Host "Timeout exceeded. Consider manual inspection."
exit 2

Key points

  • Run the helper script from a CI job or operator only after careful validation — automatic rollbacks can hide flakiness if not monitored by metrics.
  • Always inspect kubectl describe and events before taking destructive action.

FAQs

Q: My rollout reports "progress deadline exceeded." What's the fastest safe action?
A: Examine kubectl describe deployment and kubectl get events. If new Pods are failing probes or imagePullBackOff, either fix image/tag or rollback: kubectl rollout undo.

12. Advanced Rollouts: Canary, Blue-Green & Tools

For controlled, observable rollouts consider advanced tooling:

  • Flagger — automates canary promotion using metrics providers (Prometheus, Datadog).
  • Argo Rollouts — advanced rollout strategies, step-based canaries, and analysis runs.
  • Service Mesh (Istio/Linkerd) — enable traffic weighting for canaries and deep telemetry.

Canary pattern (manual using two Deployments)

  1. Deploy new version in a canary Deployment (small replica set).
  2. Configure Service or Ingress to split small % of traffic to canary (e.g., 10%).
  3. Monitor metrics for errors/latency; if stable, increase percentage; otherwise rollback.

Key points

  • Tools automate the traffic shifting and analysis; prefer Flagger/Argo Rollouts for production canaries.
  • Instrumentation and metrics are critical for automated promotion/rollback.

FAQs

Q: Can I implement canary without a service mesh?
A: Yes — use multiple Deployments and adjust Service selectors or use ingress rule weightings supported by many ingress controllers.

13. Best Practices for Deployments

  • Use readiness probes to ensure new Pods receive traffic only when ready.
  • Use resource requests/limits to make scheduling predictable and autoscaling effective.
  • Use immutable image tags (SHA) to ensure reproducibility.
  • Keep YAML modular and in Git for auditability and GitOps workflows.
  • Set revisionHistoryLimit to avoid many old ReplicaSets hogging resources.
  • Monitor during rollouts — map rollout events to business metrics (errors, latency).
  • Automate safety checks using policy gates (Open Policy Agent) and pre-deployment checks.

Key points

  • Fail-fast on bad images: keep progressDeadlineSeconds reasonable but not too low for heavy apps.
  • Prefer rolling updates with small maxUnavailable and controlled maxSurge for large clusters.

FAQs

Q: How often should I bump progressDeadlineSeconds?
A: For complex initializations (large DB migrations on startup), increase it. For typical stateless apps, defaults are fine.

14. Security & RBAC Considerations

Restrict who can update Deployments by using Kubernetes RBAC. Common patterns:

  • Create a CI service account with permission only to patch image fields or create new revision annotations.
  • Use admission controllers (OPA/Gatekeeper) to validate manifest policies (no latest tags, required probes, resource limits).

Key points

  • Least privilege for deployment actions reduces risk of accidental cluster-wide changes.
  • Audit logs (cloud provider or Kubernetes API server) are crucial for post-incident analysis.

FAQs

Q: How to enforce probes in all Deployments?
A: Use an admission policy (OPA) that rejects manifests without liveness/readiness probes.

15. Troubleshooting Playbook (step-by-step)

When a rollout fails or application misbehaves, follow this structured approach:

  1. Gather data: kubectl describe deployment <name>, kubectl get events, kubectl get pods -o wide.
  2. Inspect failing pods: kubectl logs <pod>, kubectl logs <pod> --previous (for crashed containers).
  3. Check image issues: imagePullBackOff often indicates registry/auth/tag issues.
  4. Check probes: misconfigured readiness/liveness probes are common causes for rollout stalls.
  5. Look at resource constraints: CPU/memory limit exhaustion or scheduler pending due to node constraints.
  6. Decide to rollback or fix: If root cause is clear and quick fix possible (e.g., bad tag), patch and continue. Otherwise rollback: kubectl rollout undo deployment/<name>.

PowerShell snippet: Diagnostic dump

# DiagnosticDump.ps1 - gather cluster deployment diagnostics
param(
  [string]$Namespace = "default",
  [string]$Deployment = "nginx-deployment",
  [string]$OutFile = "diagnostic_dump.txt"
)

"=== Describe Deployment ===" | Out-File $OutFile
kubectl describe deployment $Deployment -n $Namespace | Out-File -Append $OutFile

"`n=== Events ===" | Out-File -Append $OutFile
kubectl get events -n $Namespace --sort-by='.metadata.creationTimestamp' | Out-File -Append $OutFile

"`n=== ReplicaSets ===" | Out-File -Append $OutFile
kubectl get rs -n $Namespace -o wide | Out-File -Append $OutFile

"`n=== Pods ===" | Out-File -Append $OutFile
kubectl get pods -n $Namespace -o wide | Out-File -Append $OutFile

Write-Host "Diagnostic dump saved to $OutFile"

16. Appendix: Quick Cheat Sheet

Action Command
Apply changes kubectl apply -f deployment.yaml
Check rollout kubectl rollout status deployment/nginx-deployment
Rollback kubectl rollout undo deployment/nginx-deployment
Pause rollout kubectl rollout pause deployment/nginx-deployment
View history kubectl rollout history deployment/nginx-deployment

17. SEO Notes & Links

This article is optimized for search engines (Microsoft Edge News, Google Discover, Bing) by using clear headings (H1/H2/H3), descriptive alt-less content (text-first), and targeted keywords: Kubernetes Deployments, Rolling Updates, Canary Deployment, Blue-Green Deployment, kubectl rollback, AKS troubleshooting.

For more cloud and Kubernetes-focused articles and keywords, visit cloudknowledge.in. You can link specific terms to resources on cloudknowledge.in such as Kubernetes and AKS for improved domain relevance.

Key SEO keywords (use in meta description and headings in WordPress editor):

Primary: Kubernetes Deployments, Rolling Update Kubernetes, Kubernetes Rollback
Secondary: Canary Deployment Kubernetes, Blue-Green Deployment Kubernetes, AKS troubleshooting, kubectl rollout

18. Final Checklist Before Production Rollout

  1. Readiness & Liveness probes configured and tested.
  2. CI pipeline uses immutable image tags and updates Deployment manifests declaratively.
  3. Monitoring dashboards show rollout metrics and alerts configured.
  4. Autoscaling configured where necessary and metrics-server available.
  5. RBAC and admission policies in place to enforce deployment standards.
  6. Automated canary/promote tool in place (if using Canary).
  7. Rollback playbook and runbooks are validated with runbook drills.

19. More Reading & Resources

Conclusion

Deployments are the backbone for running stateless applications on Kubernetes. By using readiness and liveness probes, choosing the right strategy, integrating CI/CD, and applying strong monitoring and RBAC controls, you can achieve safe, automated rollouts with fast recovery on failures. Use the PowerShell and kubectl recipes provided here to build robust troubleshooting routines, whether you run vanilla Kubernetes or AKS.

Related Story

Leave a Reply

Your email address will not be published. Required fields are marked *