How to Update Your App in Kubernetes

Updating a production application on Kubernetes demands precision and safety. Rolling updates let you deploy new container images without downtime. This guide walks you through updating your app image, tracking rollout status, rolling back when needed, and handling persistent volumes, access controls, and event-driven flows.

TL;DR

• Use kubectl set image to trigger a rolling update.
• Monitor update progress with kubectl rollout status.
• Rollback safely via kubectl rollout undo on failures.
• Design PVCs and StorageClasses to survive upgrades.
• Apply RBAC and securityContext to lock down access.
• Automate updates via CI/CD or event-driven pipelines.

Update Your App – The Basics

Kubernetes deployments manage replica sets of pods. Each pod runs one or more containers defined by an image version. To change an app version, update the image field in the deployment spec. The deployment controller orchestrates a rolling update: it brings up new pods, then terminates old pods, keeping service uptime intact. You can apply updates declaratively via YAML or imperatively with kubectl commands.

Update Your App with kubectl set image

Imperative updates let you patch a deployment without editing YAML. For example, assume you have a deployment named nginx-deployment running image nginx:1.9. To update to nginx:1.9.1, run:

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

The API server records a new revision in the deployment’s history. The deployment controller creates a new ReplicaSet for nginx:1.9.1 and scales it up while scaling down the old ReplicaSet. This rolling update respects maxSurge and maxUnavailable settings (defaults: 25% surge, 25% unavailable) defined in the spec.

Monitoring Your App Update

After triggering the update, confirm rollout progress:

kubectl rollout status deployment/nginx-deployment

The command waits until all new pods reach Ready state or reports failure. You can inspect ReplicaSets:

kubectl get rs --watch

Rollback After Update Your App

If the new version misbehaves, revert to the previous stable revision. Use:

kubectl rollout undo deployment/nginx-deployment

By default, this rolls back one revision. You can view rollout history:

kubectl rollout history deployment/nginx-deployment

To rollback to a specific revision:

kubectl rollout undo deployment/nginx-deployment --to-revision=2

Persistent Volumes and Update Your App

Stateful workloads need stable storage across updates. Kubernetes supports volume types such as emptyDir, hostPath, NFS, awsElasticBlockStore, gcePersistentDisk, and CSI plugins. A PersistentVolume (PV) abstracts physical storage; a PersistentVolumeClaim (PVC) requests a PV. A StorageClass automates dynamic provisioning. The lifecycle:

• Admin defines StorageClass with provisioner (e.g., aws-ebs, gce-pd, or CSI driver).
• App defines PVC with storageClassName and accessModes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany).
• Kubernetes provisions a PV that binds to the PVC.
• When pods mount the PVC, the volume attaches and mounts.
• When a deployment or stateful set updates, PVCs stay bound and data persists.

Example PVC in YAML:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 10Gi

Use this PVC in your pod spec:

volumes:
  - name: data-storage
    persistentVolumeClaim:
      claimName: data-pvc
containers:
  - name: app
    image: myapp:latest
    volumeMounts:
      - mountPath: "/data"
        name: data-storage

Security Contexts and Access Controls

Lock down your update process. Use PodSecurityContext and container-level securityContext to restrict privilege escalation, run as non-root, enforce read-only root file systems, and set SELinux options. Example:

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true

Apply Role-Based Access Control (RBAC) to limit who can update deployments. Create a Role or ClusterRole granting patch and update verbs on deployments, then bind it to a user or service account.

Use Cases for Update Your App

Automate updates via CI/CD. A commit to Git triggers Jenkins, GitLab CI, or Argo CD to build a new image and run kubectl set image. Use webhooks or Tekton pipelines for event-driven flows. In an event-driven architecture, services communicate via Kafka topics. A CI job can publish an update event to Kafka; a Kubernetes operator consumes it and applies the update. This decouples pipelines from clusters and scales updates to multiple environments.

Next Steps

• Parameterize RollingUpdate strategy in your Deployment spec.
• Implement health checks (readiness/liveness probes) to abort bad updates.
• Integrate Helm or Kustomize for declarative version control.
• Set up monitoring and alerting on rollout failures.

References

• Performing a Rolling Update
• Kubernetes Volumes
• Kubernetes Storage Classes
• Using RBAC Authorization
• Kubernetes Container Storage Interface (CSI) Documentation
• Apache Kafka

Suggested Reading

• Rollback Kubernetes Deployments
• StatefulSet vs Deployment: Key Differences and Use Cases
• How to Restart Kubernetes Pods with Kubectl
• Kubernetes 1.33: Volume Populators Graduate to GA | Kubernetes
• Dump a Kubernetes Pod for Analysis

PostHashID: be2245854ef8f39daf819c5ee242cae8648a382a0f8de5169e31c4f0d829f7a0