Deployments
Manage Kubernetes Deployments with scaling, rolling restarts, and rollout controls.
Deployment List
View all deployments in a cluster with status, replicas, and availability.
| Column | Description |
|---|---|
| Name | Deployment name |
| Namespace | Kubernetes namespace |
| Replicas | Desired / Current / Available |
| Strategy | RollingUpdate or Recreate |
| Age | Time since creation |
Deployment Details
Click a deployment to view:
- Deployment strategy and settings
- ReplicaSet history
- Pod template spec
- Rollout status
- Conditions and events
Scaling Deployments
Via UI:
- Open deployment detail panel
- Use replica slider or enter count
- Click "Scale" to apply
- Watch rollout progress
Scaling Behavior:
- New pods created gradually
- Old pods terminated after new ones are ready
- Max surge / max unavailable controls
Restarting Deployments
Perform a rolling restart without changing configuration:
- Click "Restart" on deployment
- Confirm action
- Pods restart one-by-one
Use Cases:
- Force pull latest image (imagePullPolicy: Always)
- Clear in-memory cache
- Apply ConfigMap/Secret changes
Rollout History
View previous ReplicaSets and revisions:
| Revision | Change Cause | Created | Replicas |
|---|---|---|---|
| 3 | Update to v1.2.3 | 2h ago | 3 |
| 2 | Update to v1.2.2 | 1d ago | 3 |
| 1 | Initial deployment | 5d ago | 2 |
Rollback Deployments
Revert to a previous revision:
- Click "Rollback" on deployment
- Select revision number
- Confirm rollback
- Watch rollout to previous version
Rollout Status
Monitor ongoing rollouts:
- Progress percentage
- Pods updated / total
- Conditions (Progressing, Available, ReplicaFailure)
Deployment Strategies
RollingUpdate (Default)
Gradually replace old pods with new ones:
maxSurge: Max extra pods during updatemaxUnavailable: Max pods down during update
Recreate
Terminate all old pods before creating new ones:
- Causes downtime
- Use for stateful apps that can't run multiple versions
Troubleshooting
| Issue | Cause | Solution |
|---|---|---|
| Rollout stuck | ImagePullBackOff or CrashLoop | Check pod events and logs |
| Replicas not scaling | Resource quota exceeded | Increase namespace quota or reduce requests |
| Old ReplicaSets not deleted | RevisionHistoryLimit | Set limit in deployment spec |
Example: Scaling a Deployment
Before Scaling
Deployment: api-gateway
Namespace: production
Replicas: 3/3
Strategy: RollingUpdate (maxSurge: 1, maxUnavailable: 0)
Scaling to 5 Replicas
- Open deployment detail
- Move slider to 5
- Click "Scale"
Rollout Process:
10:30:00 Scaling api-gateway from 3 to 5 replicas
10:30:01 Creating pod api-gateway-7d9f8c6b4d-4th-pod
10:30:02 Creating pod api-gateway-7d9f8c6b4d-5th-pod
10:30:15 Pod 4/5 Running and Ready
10:30:18 Pod 5/5 Running and Ready
10:30:18 Deployment successfully scaled to 5 replicas
After Scaling
Deployment: api-gateway
Namespace: production
Replicas: 5/5
Pods: api-gateway-7d9f8c6b4d-2xkjp (Running)
api-gateway-7d9f8c6b4d-9vwrt (Running)
api-gateway-7d9f8c6b4d-kp3mn (Running)
api-gateway-7d9f8c6b4d-4th-pod (Running)
api-gateway-7d9f8c6b4d-5th-pod (Running)
Example: Rolling Restart
Scenario
ConfigMap updated with new database connection pool size. Pods need restart to pick up changes.
Restart Workflow
- Click "Restart" on deployment
- Confirm: "This will perform a rolling restart of all pods"
- Rollout begins
Restart Process:
10:45:00 Updating pod template with restart annotation
10:45:01 Terminating pod api-gateway-7d9f8c6b4d-2xkjp
10:45:02 Creating new pod api-gateway-new-rs-abc123
10:45:15 New pod Running and Ready
10:45:16 Terminating pod api-gateway-7d9f8c6b4d-9vwrt
10:45:17 Creating new pod api-gateway-new-rs-def456
...
10:47:00 All 5 pods restarted successfully
Result
All pods running with new ReplicaSet, ConfigMap changes applied.