Deployments Interview Questions

Use kubectl rollout undo deployment/<name> to revert to the previous revision. Kubernetes re-activates the old ReplicaSet and scales down the current one using the configured rollout strategy.

Scale a Deployment by changing the replicas field using kubectl scale, kubectl edit, or kubectl apply. For automatic scaling, use a HorizontalPodAutoscaler that adjusts replicas based on CPU, memory, or custom metrics.

The Recreate strategy kills all existing Pods before creating new ones, causing downtime but avoiding version conflicts. RollingUpdate replaces Pods incrementally with zero downtime but briefly runs two versions simultaneously.

A Deployment is a Kubernetes resource that declaratively manages a set of identical Pods through ReplicaSets. It handles rollouts, rollbacks, and scaling so you never have to manage individual Pods by hand.

Liveness probes restart unhealthy containers, readiness probes control whether Pods receive traffic, and startup probes protect slow-starting containers. In the context of Deployments, readiness probes are critical because they gate rolling updates and prevent broken versions from receiving traffic.

Every change to a Deployment's Pod template creates a new revision backed by a ReplicaSet. Kubernetes retains old ReplicaSets (controlled by revisionHistoryLimit) so you can inspect previous versions and roll back to them.

Use kubectl rollout status to watch a rollout in real time. Combine it with kubectl describe deployment and kubectl get events to diagnose stuck or failed rollouts caused by image pull errors, resource limits, or failing health checks.

Deployments manage stateless Pods that are interchangeable and can be replaced freely. StatefulSets manage stateful Pods with stable network identities, persistent storage, and ordered startup/shutdown semantics.

A ReplicaSet ensures a specified number of identical Pod replicas are running at all times. It uses label selectors to identify its Pods and creates or deletes them to match the desired count. Deployments manage ReplicaSets automatically.

maxSurge controls how many extra Pods can exist above the desired replica count during an update. maxUnavailable controls how many Pods can be down simultaneously. Together they control the speed, resource usage, and safety of a rolling update.

A rolling update gradually replaces old Pods with new ones by creating new ReplicaSet Pods while scaling down the old ReplicaSet, controlled by maxSurge and maxUnavailable parameters to ensure zero-downtime deployments.

Blue-green deployments run two identical environments (blue and green) side by side. Traffic is routed entirely to one version, and you switch instantly by updating the Service selector. This eliminates the risk of partial rollouts.

A canary deployment gradually shifts a small percentage of traffic to a new version while the majority continues hitting the stable version. If metrics look good, traffic is increased until the canary becomes the new production release.

Zero-downtime deployments require a combination of rolling updates with maxUnavailable: 0, readiness probes, graceful shutdown handling, PodDisruptionBudgets, and preStop hooks. No single setting achieves it -- you need all layers working together.