Pods, ReplicaSets and Deployments explained

Kubernetes never runs a bare container. The smallest thing it schedules is a Pod, and in practice you almost never create Pods by hand either. You create a Deployment, which creates a ReplicaSet, which creates the Pods. Each layer adds one job.

Pod: containers that live together

A Pod is one or more containers that always run on the same node, share one IP address and can share volumes. Most Pods have a single application container; extra containers are used for tightly coupled helpers such as a log shipper or a proxy.

Pods are disposable. When a node fails or a Pod is deleted, it is not moved or repaired; a controller creates a new Pod with a new name and usually a new IP address. That is why you reach Pods through a Service instead of by IP.

ReplicaSet: keep N copies running

A ReplicaSet has a Pod template, a label selector and a replica count. Its controller counts the Pods that match the selector and creates or deletes Pods until the count is right. Delete one Pod and a replacement appears within seconds.

Deployment: updates and rollbacks

A Deployment wraps ReplicaSets and adds versioning. When you change the Pod template (for example the image tag), the Deployment creates a new ReplicaSet and gradually scales it up while scaling the old one down. This is a rolling update. By default at most 25% of the desired Pods may be unavailable and at most 25% extra may be created during the change.

Old ReplicaSets are kept (scaled to zero) as revision history, ten by default, controlled by .spec.revisionHistoryLimit. That history is what makes kubectl rollout undo possible.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.27
        ports:
        - containerPort: 80

The selector.matchLabels must match the labels in template.metadata.labels; that link is how the ReplicaSet knows which Pods belong to it.

kubectl apply -f web.yaml
kubectl get deployment,replicaset,pods -l app=web
kubectl scale deployment/web --replicas=5
kubectl set image deployment/web web=nginx:1.28
kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web

Namespaces

A namespace is a named group of objects inside one cluster. Names must be unique within a namespace but can repeat across namespaces, and access rules (RBAC) and quotas are often set per namespace. A new cluster starts with default, kube-system (cluster components), kube-public and kube-node-lease. The Kubernetes docs recommend not putting production work in default.

kubectl create namespace shop
kubectl apply -f web.yaml -n shop
kubectl get pods -n shop
kubectl config set-context --current --namespace=shop

Other workload types

• StatefulSet: Pods with stable names (db-0, db-1) and their own persistent volumes, for databases and clustered software.
• DaemonSet: exactly one Pod on every (or every matching) node, for log collectors and node agents.
• Job and CronJob: Pods that run to completion, once or on a schedule.

Official documentation

• Deployments
• ReplicaSet
• Namespaces