Understanding Kubernetes Deployments, ReplicaSets, Pods and Advanced Deployment Strategies

Kubernetes manages containerized applications through a set of declarative objects. The smallest unit is a Pod , which can contain one or more containers that share network and storage resources.

A Deployment describes the desired state of an application and automatically creates a ReplicaSet to maintain the required number of Pods. The ReplicaSet ensures that the specified number of Pods with matching labels are always running.

Typical commands:

$ kubectl run web --image=nginx
deployment.apps/web created

$ kubectl get all

show the created Deployment, ReplicaSet and Pod objects.

To create a single‑container Pod directly, you can apply a YAML manifest such as:

# pod-nginx.yml
apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Scaling is handled by the ReplicaSet . Changing the replicas field creates or deletes Pods to match the desired count, and the controller continuously monitors node health to replace failed Pods.

When a Deployment is updated (e.g., a new image version), Kubernetes creates a new ReplicaSet with zero replicas and gradually shifts traffic by increasing the new ReplicaSet’s replica count while decreasing the old one. This rolling update respects the maxSurge and maxUnavailable parameters, which control how many extra Pods may be created and how many Pods may be unavailable during the update.

Readiness probes (command, HTTP, or TCP checks) determine when a Pod is considered ready to receive traffic. If a probe continuously fails, the Deployment pauses, keeping the previous version running until the issue is resolved.

Rollback is performed with kubectl rollout undo deployment <name> , which restores the previous ReplicaSet and its Pods.

Advanced deployment strategies:

Blue‑Green: Deploy a new version in a separate Deployment and switch a Service’s selector from the old to the new Deployment instantly.

Canary: Gradually shift a small percentage of traffic to the new version by labeling a subset of Pods and adjusting the Service selector.

Service objects provide stable ClusterIP endpoints and use label selectors to route traffic to the appropriate Pods, automatically adapting to rolling updates without manual reconfiguration.

In summary, Kubernetes’ declarative model, combined with Deployments, ReplicaSets, readiness probes, and flexible Service selectors, enables safe, automated, and observable rollouts, reducing downtime and allowing frequent releases.