Key Concepts
Deployment
A controller that manages ReplicaSets and provides declarative updates to Pods.
ReplicaSet
Ensures a specified number of pod replicas are running at any time.
Rolling Update
Gradual replacement of pods with new versions while maintaining availability.
Scaling
Adjusting the number of pod replicas to match demand.
Required Permissions
| Action | Permission |
|---|---|
| View deployments | iam:project:infrastructure:kubernetes:read |
| Scale deployment | iam:project:infrastructure:kubernetes:write |
| Restart deployment | iam:project:infrastructure:kubernetes:write |
| Create deployment | iam:project:infrastructure:kubernetes:write |
| Edit deployment | iam:project:infrastructure:kubernetes:write |
| Delete deployment | iam:project:infrastructure:kubernetes:delete |
Deployment Status Values
| Status | Description |
|---|---|
| Available | Minimum required replicas are available and ready |
| Progressing | Deployment is creating, updating, or scaling pods |
| Failed | Deployment failed to progress (ReplicaFailure condition) |
| Unknown | Deployment status cannot be determined |
Replica Metrics
| Metric | Description |
|---|---|
| Ready | Pods that are ready to serve traffic (ready/desired) |
| Up-to-date | Pods updated to the latest pod template spec |
| Available | Pods available for at least minReadySeconds |
| Unavailable | Pods that are not yet available |
How to View Deployments
How to View Deployment Details
How to Scale a Deployment
How to Restart a Deployment
Restart triggers a rolling restart of all pods without changing the deployment spec.Restart performs a rolling restart, replacing pods gradually to maintain availability. It adds a
kubectl.kubernetes.io/restartedAt annotation to trigger the update.How to Create a Deployment
How to Edit a Deployment
Modify Spec
Edit the deployment specification. Common changes:
- Container image (triggers rolling update)
- Resource requests/limits
- Environment variables
- Replica count
Changes to the pod template spec trigger a rolling update. The deployment controller gradually replaces old pods with new ones.
How to Delete a Deployment
Delete behavior:
- Deletes the deployment, associated ReplicaSets, and all pods (cascade delete)
- Pods are terminated gracefully with default grace period
Update Strategies
Deployments support two update strategies:| Strategy | Description |
|---|---|
| RollingUpdate | Gradually replaces pods (default). Configurable via maxSurge and maxUnavailable. |
| Recreate | Terminates all existing pods before creating new ones. Causes downtime. |
maxSurge- Maximum pods above desired count during update (default: 25%)maxUnavailable- Maximum unavailable pods during update (default: 25%)
Troubleshooting
Deployment stuck in Progressing
Deployment stuck in Progressing
- Insufficient cluster resources (CPU, memory)
- Image pull failures (check image name and pull secrets)
- Pod scheduling failures (check node affinity, taints)
- Readiness probe never passes
- Check deployment events for specific errors
Pods not becoming ready
Pods not becoming ready
- Readiness probe failing (check probe configuration)
- Application not starting correctly (check container logs)
- Dependencies not available (databases, services)
- Resource limits too restrictive
Rolling update taking too long
Rolling update taking too long
maxUnavailableset too low- Pods taking long to become ready
- PodDisruptionBudget blocking evictions
- Consider adjusting update strategy parameters
Scale operation not taking effect
Scale operation not taking effect
- Check for resource quotas limiting pod count
- Verify sufficient node capacity
- HorizontalPodAutoscaler may be overriding manual scale
- Check deployment events for errors
Restart not replacing pods
Restart not replacing pods
- Deployment must have at least 1 replica
- Check if pods are stuck terminating
- Verify deployment controller is healthy
- Review deployment events
Cannot delete deployment
Cannot delete deployment
- Finalizers may be blocking deletion
- Verify you have delete permission
- Check if namespace is terminating
FAQ
What's the difference between scaling and updating?
What's the difference between scaling and updating?
Scaling changes the number of replicas without modifying the pod spec. Updating changes the pod template, triggering a rolling update to replace all pods with the new configuration.
How does rolling update maintain availability?
How does rolling update maintain availability?
The deployment controller creates new pods before terminating old ones, respecting
maxSurge and maxUnavailable settings. Traffic continues to flow to ready pods throughout the update.What happens if I scale during an update?
What happens if I scale during an update?
The new replica count applies to the final state. Kubernetes handles both operations, ensuring the target state is eventually reached.
Can I rollback a deployment?
Can I rollback a deployment?
Yes. Deployments maintain revision history. Use
kubectl rollout undo or edit the deployment to restore a previous pod template spec.Why are some replicas unavailable?
Why are some replicas unavailable?
How do I update without downtime?
How do I update without downtime?
Use RollingUpdate strategy (default) with appropriate
maxSurge and maxUnavailable values. Ensure your application handles graceful shutdown and has proper readiness probes.What's the difference between restart and redeploy?
What's the difference between restart and redeploy?
Restart triggers a rolling restart using the same image and configuration. Redeploy (updating the image or spec) creates pods with the new configuration. Restart is useful for picking up config changes from ConfigMaps/Secrets.
How do I scale to zero?
How do I scale to zero?
Set replicas to 0. The deployment and ReplicaSet remain, but all pods are terminated. Scale back up by setting replicas to a positive number.