Kubernetes Deployment is a declarative update controller for managing Pods and ReplicaSets. It provides declarative application deployment and update capabilities.
Core Functions of Deployment
-
Declarative Management: Define the desired state through YAML files, and Kubernetes automatically implements the transition from the current state to the desired state.
-
Rolling Updates: Supports zero-downtime application updates by gradually replacing old version Pods.
-
Rollback Capability: Can easily roll back to previous versions, supports viewing update history.
-
Auto-scaling: Supports manual or automatic adjustment of the number of Pod replicas.
-
Self-healing: Automatically creates new Pods to maintain the desired replica count when Pods fail or are deleted.
How Deployment Works
Deployment manages Pods through ReplicaSet:
-
ReplicaSet: Ensures that a specified number of Pod replicas are always running.
-
Pod Template: Defines the Pod specification, including container images, resource limits, etc.
-
Update Strategy: Controls the behavior of rolling updates, such as the maximum number of unavailable Pods and the maximum number of surge Pods.
Deployment YAML Example
yamlapiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
Update Strategy
Deployment supports two update strategies:
-
RollingUpdate (default):
- Gradually replaces Pods, ensuring that there are always available Pods
- Can configure maxUnavailable and maxSurge
- Suitable for most applications
-
Recreate:
- First deletes all old Pods, then creates new Pods
- Causes a brief service interruption
- Suitable for applications that cannot run new and old versions simultaneously
Rolling Update Parameters
-
maxUnavailable: The maximum number of Pods that can be unavailable during the update process (default 25%)
-
maxSurge: The maximum number of additional Pods that can be created during the update process (default 25%)
Rollback Operations
View update history:
bashkubectl rollout history deployment/nginx-deployment
Rollback to previous version:
bashkubectl rollout undo deployment/nginx-deployment
Rollback to specific version:
bashkubectl rollout undo deployment/nginx-deployment --to-revision=2
Scaling
Manual scaling:
bashkubectl scale deployment/nginx-deployment --replicas=5
Auto-scaling (HPA):
yamlapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: nginx-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50
Deployment vs Other Controllers
-
vs ReplicaSet:
- Deployment is a higher-level controller of ReplicaSet
- Deployment provides update and rollback capabilities, while ReplicaSet can only maintain replica counts
-
vs StatefulSet:
- Deployment is suitable for stateless applications
- StatefulSet is suitable for stateful applications, providing stable network identities and persistent storage
-
vs DaemonSet:
- Deployment can run a specified number of Pods on any node
- DaemonSet ensures that one Pod replica runs on each node
Best Practices
-
Use declarative configuration: Always use YAML files to define Deployment, not imperative commands.
-
Set reasonable resource limits: Set CPU and memory requests and limits for containers.
-
Configure health checks: Use livenessProbe and readinessProbe to ensure application health.
-
Use multi-stage builds: Optimize image size to improve deployment speed.
-
Set appropriate update strategies: Choose RollingUpdate or Recreate based on application characteristics.
-
Use labels and annotations: Add meaningful labels and annotations to Deployment for easier management and tracking.
-
Monitor the update process: Use
kubectl rollout statusto monitor update progress.