A Deployment controller provides declarative updates for Pods and it manage stateless applications running on your cluster.
Deployments represent a set of multiple, identical Pods and upgrade them in a controlled way, performing a rolling update by default.
A Deployment runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. In this way, Deployments ensure that one or more instances of your application are available to serve user requests.
Here is the Deployment configuration:
apiVersion: apps/v1 kind: Deployment metadata: name: app-fronted labels: app: fronted spec: replicas: 3 selector: matchLabels: app: fronted template: metadata: labels: app: fronted spec: containers: - name: fronted-website image: learninghub/website:1.0 ports: - containerPort: 80
$ kubectl create -f app-deployment.yaml deployment.apps "app-fronted" created
Fetch the Deployment
$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE app-fronted 3 3 3 3 2m
Check the Pods
$ kubectl get pods NAME READY STATUS RESTARTS AGE app-fronted-6cf94d8d7c-7bfpt 1/1 Running 0 3m app-fronted-6cf94d8d7c-9mqkv 1/1 Running 0 3m app-fronted-6cf94d8d7c-xnbnl 1/1 Running 0 3m
Check the Status of Deployment
$ kubectl rollout status deployment/app-fronted deployment "app-fronted" successfully rolled out
Updating the Deployment
$ kubectl set image deployment/app-fronted fronted-website=learninghub/website:2.0 deployment.apps "app-fronted" image updated $ kubectl rollout status deployment/app-fronted Waiting for rollout to finish: 1 out of 3 new replicas have been updated... $ kubectl rollout status deployment/app-fronted deployment "app-fronted" successfully rolled out $ kubectl get pods NAME READY STATUS RESTARTS AGE app-fronted-66dd8dd47d-5pvmf 1/1 Running 0 39s app-fronted-66dd8dd47d-s2zk6 1/1 Running 0 40s app-fronted-66dd8dd47d-tcxkp 1/1 Running 0 56s
Rolling Back to Deployment
$ kubectl rollout undo deployment/app-fronted deployment.apps "app-fronted" $ kubectl rollout status deployment/app-fronted deployment "app-fronted" successfully rolled out $ kubectl get pods NAME READY STATUS RESTARTS AGE app-fronted-6cf94d8d7c-98mps 1/1 Running 0 34s app-fronted-6cf94d8d7c-hnhvl 1/1 Running 0 30s app-fronted-6cf94d8d7c-pg7n8 1/1 Running 0 32s
Checking Rollout History of a Deployment
$ kubectl rollout history deployment/app-fronted deployments "app-fronted" REVISION CHANGE-CAUSE 2 3
Scaling a Deployment
$ kubectl scale deployment/app-fronted --replicas=5 deployment.extensions "app-fronted" scaled $ kubectl get pods NAME READY STATUS RESTARTS AGE app-fronted-6cf94d8d7c-98mps 1/1 Running 0 12m app-fronted-6cf94d8d7c-hnhvl 1/1 Running 0 12m app-fronted-6cf94d8d7c-kpzxq 1/1 Running 0 8s app-fronted-6cf94d8d7c-kvtj9 1/1 Running 0 8s app-fronted-6cf94d8d7c-pg7n8 1/1 Running 0 12m
Writing a Deployment Spec
As like other configurations, a Deployment needs apiVersion, kind, and metadata fields. A Deployment also needs a “spec” section.
The spec.template is the only required field of the .spec.
The spec.template is a pod template. It has exactly the same schema as a Pod, except it is nested and does not have an apiVersion or kind.
spec: template: metadata: labels: app: frontend
Only a spec.template.spec.restartPolicy equal to Always is allowed, which is the default if not specified.
spec: template: metadata: labels: app: frontend spec: restartPolicy : Always containers:
spec.replicas is an optional field that specifies the number of desired Pods. It defaults to 1.
spec: replicas: 3
spec.selector is an optional field that specifies a label selector for the Pods targeted by this deployment.
spec: replicas: 3 selector: matchLabels: app: fronted
spec.selector must match .spec.template.metadata.labels, or it will be rejected by the API.
spec: replicas: 3 selector: matchLabels: app: fronted template: metadata: labels: app: fronted
spec.strategy specifies the strategy used to replace old Pods by new ones. spec.strategy.type can be “Recreate” or “RollingUpdate”. “RollingUpdate” is the default value.
spec: replicas: 3 strategy: type: RollingUpdate
Your Deployment may get stuck trying to deploy its newest ReplicaSet without ever completing.
This can occur due to some of the following factors:
- Insufficient quota
- Readiness probe failures
- Image pull errors
- Insufficient permissions
- Limit ranges
- Application run-time misconfiguration