Kubernetes Deployment

Introduction

A Kubernetes Deployment is a fundamental resource in Kubernetes that provides declarative updates for Pods and ReplicaSets. It allows developers and operators to manage application lifecycles efficiently—automating everything from rollouts and rollbacks to scaling and self-healing.

Instead of manually creating and updating pods, Kubernetes Deployments act as controllers that continuously maintain the desired application state.

What Is a Kubernetes Deployment?

A Kubernetes Deployment is an object defined in YAML or JSON that tells the Kubernetes control plane:

• What container images to run
• How many replicas are needed
• What strategy to use when updating
• What labels and selectors to apply
• How to monitor application health

It ensures that your application is always running in the desired state, even if individual pods crash or nodes go down.

Core Benefits

Basic Architecture

Deployment
   ↓
ReplicaSet
   ↓
Pods

• Deployment: Manages the desired state
• ReplicaSet: Ensures the correct number of pods
• Pods: Run containers

Example: Basic Deployment YAML

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-container
          image: myregistry/my-app:1.0.0
          ports:
            - containerPort: 80

This deployment:

• Runs 3 replicas of my-app
• Uses image myregistry/my-app:1.0.0
• Listens on port 80

Applying a Deployment

Use the kubectl apply command:

kubectl apply -f my-app-deployment.yaml

To view it:

kubectl get deployments

To see the associated pods:

kubectl get pods -l app=my-app

Update Strategies

Kubernetes supports multiple deployment strategies:

1. RollingUpdate (default)

Gradually replaces old pods with new ones.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

• maxUnavailable: How many pods can be down during update
• maxSurge: How many extra pods can be created

2. Recreate

Deletes all old pods before creating new ones.

strategy:
  type: Recreate

Used when app state must not be duplicated (e.g., database pods).

Performing an Update

Update the image tag in your YAML file:

image: myregistry/my-app:1.0.1

Then reapply:

kubectl apply -f my-app-deployment.yaml

Kubernetes will begin a rolling update automatically.

Rollback to Previous Version

If something goes wrong:

kubectl rollout undo deployment my-app

To check rollout history:

kubectl rollout history deployment my-app

Scaling a Deployment

Change the replica count in YAML:

replicas: 5

Or do it with kubectl:

kubectl scale deployment my-app --replicas=5

Liveness and Readiness Probes

To improve reliability:

livenessProbe:
  httpGet:
    path: /healthz
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 3
  periodSeconds: 5

• Liveness Probe: Restarts the container if the check fails
• Readiness Probe: Avoids routing traffic to unready pods

Environment Variables and Configs

You can inject settings into your pods via:

env:
  - name: ENVIRONMENT
    value: production

Or use ConfigMaps and Secrets:

envFrom:
  - configMapRef:
      name: my-app-config
  - secretRef:
      name: my-app-secrets

Exposing the Deployment

To access the app from outside:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80

Apply it:

kubectl apply -f my-app-service.yaml

Monitoring and Logs

Monitor rollout status:

kubectl rollout status deployment my-app

Get logs from pods:

kubectl logs <pod-name>

Use labels to fetch dynamically:

kubectl logs -l app=my-app

Helm Integration

If using Helm, deployments are managed via templates:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "mychart.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  ...

Helm allows versioned, reusable deployments with parameterization.

Blue-Green and Canary Deployments

Kubernetes Deployments can support advanced rollout patterns:

• Blue-Green: Use two separate deployments and switch traffic via services
• Canary: Use multiple deployments with traffic weighting via service mesh (e.g., Istio)

Best Practices

Troubleshooting

Summary

Related Keywords

• Blue Green Deployment
• Canary Deployment
• ConfigMap
• Deployment Strategy
• Helm Chart
• Kustomize
• Pod Lifecycle
• ReplicaSet
• Rollback
• Rolling Update