Kubernetes Deployment Management

Kubernetes Deployment Management is the discipline and set of mechanisms for operating Deployment objects throughout their lifecycle: rolling out new versions of an application, controlling the pace and safety of those rollouts, scaling the number of running replicas, and recovering from failed releases. It builds on the Deployment controller's core reconciliation behavior but focuses on the operational practices and configuration choices that determine how changes reach a running cluster.

Rollout Strategies

RollingUpdate

The default strategy replaces Pods incrementally, creating new Pods from the updated template while terminating old ones, governed by two parameters:

• maxUnavailable: The maximum number or percentage of desired Pods that may be unavailable during the rollout.
• maxSurge: The maximum number or percentage of Pods that may be created above the desired replica count during the rollout.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%

Tuning these parameters trades off rollout speed against resource headroom and availability: a maxUnavailable of zero guarantees full capacity throughout the rollout at the cost of requiring surge capacity, while a nonzero value allows a faster, lower-resource rollout at the cost of momentarily reduced capacity.

Recreate

The Recreate strategy terminates all existing Pods before creating any replacement Pods. This produces a period of complete unavailability but guarantees that old and new versions of an application never run simultaneously, which matters for applications that cannot tolerate two versions accessing shared state concurrently.

Revision History and Rollbacks

Tracking Revisions

Each time a Deployment's Pod template changes, a new ReplicaSet is created to represent that revision, and old ReplicaSets are retained, scaled to zero, up to a configurable revisionHistoryLimit. This history allows a Deployment to be inspected and rolled back without needing to reconstruct a previous configuration manually.

kubectl rollout history deployment/codartium-api
kubectl rollout history deployment/codartium-api --revision=3
kubectl rollout undo deployment/codartium-api --to-revision=3

Pausing and Resuming Rollouts

A rollout can be paused mid-flight, allowing multiple changes to a Deployment's template to be batched into a single rollout once resumed, rather than triggering a new rollout for each individual change.

kubectl rollout pause deployment/codartium-api
kubectl set image deployment/codartium-api api=codartium/api:4.2.0
kubectl set resources deployment/codartium-api -c api --limits=cpu=500m
kubectl rollout resume deployment/codartium-api

Scaling

Manual Scaling

The replicas field can be updated directly, either by editing the manifest and reapplying it or through the imperative kubectl scale command, causing the underlying ReplicaSet to converge the running Pod count to the new value.

kubectl scale deployment/codartium-api --replicas=8

Horizontal Pod Autoscaling

A HorizontalPodAutoscaler (HPA) can manage a Deployment's replica count automatically, adjusting it in response to observed metrics such as average CPU utilization, memory usage, or custom application metrics, within a configured minimum and maximum bound.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: codartium-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: codartium-api
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Health Gating During Rollouts

Readiness as a Rollout Gate

A rolling update only proceeds to terminate old Pods once newly created Pods report as ready via their readiness probes. This ties the pace of a rollout directly to the actual health of new instances, preventing a rollout from replacing healthy Pods with broken ones faster than the broken state can be detected.

Progress Deadlines

A Deployment can specify progressDeadlineSeconds, after which, if a rollout has made no progress, it is marked as having exceeded its deadline in the Deployment's conditions, signaling a stalled rollout that requires operator attention even though it has not been explicitly marked as failed.

kubectl rollout status deployment/codartium-api --timeout=120s

Change Cause Tracking

Deployments can record the reason for each revision using the kubernetes.io/change-cause annotation, either set directly in the manifest or via the --record flag on imperative commands, providing a human-readable audit trail alongside the automatically tracked revision history.

kubectl annotate deployment/codartium-api kubernetes.io/change-cause="bump api to 4.2.0 for security patch"

Operational Practices

Effective Deployment management typically combines conservative rollout parameters for production workloads, automated scaling bound to meaningful metrics, readiness probes accurate enough to gate traffic correctly, and a retained revision history sufficient to support a fast rollback if a new release proves faulty after reaching production traffic.