Sign In

Curriculum 4: Understanding Kubernetes Resources

Deployments

15 min · 15 XP

Understanding Deployments

While Pods are the basic building blocks, you almost never create Pods directly in production. Instead, you use a Deployment -- the most common way to run and manage applications in Kubernetes.

What Is a Deployment?

A Deployment is a higher-level resource that manages Pods for you. It provides:

  • Declarative updates -- describe the desired state and Kubernetes makes it happen
  • Self-healing -- if a Pod crashes, the Deployment automatically replaces it
  • Rolling updates -- update your application without downtime
  • Rollback -- revert to a previous version if something goes wrong
  • Scaling -- run more or fewer replicas with a single command

How Deployments Manage ReplicaSets

A Deployment does not manage Pods directly. Instead, it creates a ReplicaSet, which in turn creates the Pods. The hierarchy looks like this:

Deployment
  └── ReplicaSet
        ├── Pod 1
        ├── Pod 2
        └── Pod 3

When you update a Deployment (for example, change the container image), it creates a new ReplicaSet with the updated configuration and gradually scales down the old one. This is how rolling updates work.

# See the ReplicaSets created by a Deployment
kubectl get replicasets

# See the full chain: deployment -> replicaset -> pods
kubectl get deploy,rs,pods

Declarative Updates

The power of Deployments is in declarative management. You describe what you want, and Kubernetes figures out how to get there.

# Update the image for a deployment
kubectl set image deployment/my-app nginx=nginx:1.28

# Check the rollout status
kubectl rollout status deployment/my-app

# View rollout history
kubectl rollout history deployment/my-app

# Roll back to the previous version
kubectl rollout undo deployment/my-app

Scaling

Scaling a Deployment up or down is a single command:

# Scale to 5 replicas
kubectl scale deployment my-app --replicas=5

# Check the result
kubectl get deployment my-app

Kubernetes will create or terminate Pods to match the desired replica count. For production workloads, you can also configure a HorizontalPodAutoscaler to scale automatically based on CPU or memory usage.

Example YAML

Here is a complete Deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "64Mi"
              cpu: "250m"
            limits:
              memory: "128Mi"
              cpu: "500m"
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Apply it with:

# Create or update the deployment
kubectl apply -f deployment.yaml

# Verify the pods are running
kubectl get pods -l app=my-app

# Get detailed deployment info
kubectl describe deployment my-app

Key Takeaways

  • Deployments manage Pods through ReplicaSets and are the standard way to run applications
  • They provide self-healing, rolling updates, and rollback capabilities
  • Scaling is as simple as changing the replica count
  • The strategy section controls how updates are rolled out
  • Always use Deployments instead of creating bare Pods in production