[Cloud Native丨Kubernetes Series⑪] In-depth study of the use of Deployment

foreword

Earlier we learned about two resource objects, Replication Controller and Replica Set. Their functions are basically the same. The only difference is that RS supports the selector of the set. We also talked about how to control the number of Pod replicas through RC/RS, and also implemented the function of rolling Pod upgrades.

Difference between RC/RS and Deployment

First, RC is a core concept of Kubernetes. When we deploy an application to a cluster, we need to ensure that the application can run continuously and stably. RC is the key to this guarantee.

Its main functions are as follows:

• Ensure the number of Pods: It will ensure that the specified number of Pods are running in Kubernetes. If there are less than the specified number of Pods, RC will create new ones. Otherwise, it will delete the redundant ones, ensuring that the number of copies of Pods remains unchanged.
• Make sure the Pod is healthy: When the Pod is unhealthy, for example, when the operation fails and cannot provide normal services, RC will also kill the unhealthy Pod and create a new one.
• Elastic scaling: During business peaks or low peaks, you can use RC to dynamically adjust the number of Pods to provide resource utilization. Of course, we also mentioned that if you use HPA as a resource object, you can Dynamic expansion.
• Rolling upgrade: Rolling upgrade is a smooth upgrade method. Through the strategy of gradual replacement, the stability of the overall system is guaranteed. We have demonstrated this to you before.

Deployment It is also Kubernetesa core concept of the system. The main responsibility is to ensure the number and health of Pods like RC. Most of the functions of the two are completely the same. We can regard it as an upgraded version of RC control. , Deployment what new features does it have?

• Full functionality of RC: Deployment has full functionality of RC described above
• Event and status viewing: You can view the detailed progress and status of the Deployment's upgrade
• Rollback: If there is a problem when upgrading Pods, you can use the rollback operation to roll back to any previous version
• Version record: Every operation on the Deployment can be saved, which is also the basis for ensuring that it can be rolled back to any version
• Pause and Start: Pause and start at any time for each upgrade

As a comparison, we know that Deployment the new generation is RCnot only richer in functions, but we also said that it is now recommended Deploymentfor management Podby the official, such as some official components kube-dns, kube-proxy which are also It is Deployment used to manage, so when everyone is using it, it is best to use Deployment it to manage Pod.

---

Create Deployment

It can be seen that a Deployment has multiple Replica Sets, and a Replica Set has one or more Pods. A Deployment controls multiple rs mainly to support the rollback mechanism. Whenever a Deployment operates, Kubernetes will regenerate a Replica Set and keep it, and it can be rolled back to the previous state if necessary. Let's create a Deployment, which creates a Replica Set to start 3 nginx pods. The yaml file is as follows:

apiVersion: apps/v1beta1 
kind: Deployment 
metadata: 
name: nginx-deploy 
labels: 
k8s-app: nginx-demo 
spec: 
replicas: 3 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx:1.7.9 
ports: 
- containerPort: 80 

Save the above content as: nginx-deployment.yaml, execute the command:

$ kubectl create -f nginx-deployment.yaml 
deployment "nginx-deploy" created 

Then execute the following command to view the Deployment just created:

$ kubectl get deployments 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-deploy 3 0 0 0 1s 

Execute the above command again after a while:

$ kubectl get deployments 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-deploy 3 3 3 3 4m 

We can see that Deployment has created a Replica Set, execute the following commands to view rs and pods:

$ kubectl get rs 
NAME DESIRED CURRENT READY AGE 
nginx-deploy-431080787 3 3 3 6m 

$ kubectl get pod --show-labels 
NAME READY STATUS RESTARTS AGE LABELS 
nginx-deploy-431080787-53z8q 1/1 Running 0 7m app=nginx,pod-temp 
late-hash=431080787 
nginx-deploy-431080787-bhhq0 1/1 Running 0 7m app=nginx,pod-temp 
late-hash=431080787 
nginx-deploy-431080787-sr44p 1/1 Running 0 7m app=nginx,pod-temp 
late-hash=431080787 

The replicas:3 in the Deployment's yaml file above will ensure that we always have 3 PODs running.

Since most of the functions of Deployment and RC are the same, we have demonstrated most of the functions with you in the last lesson. Here, we will focus on demonstrating the rolling upgrade and rollback functions of Deployment.

---

rolling upgrade

Now we modify the nginx image in the yaml file we just saved to nginx:1.13.3, and then add the rolling upgrade policy under the spec:

minReadySeconds: 5 
strategy: 
# indicate which strategy we want for rolling update 
type: RollingUpdate 
rollingUpdate: 
maxSurge: 1 
maxUnavailable: 1 

• minReadySeconds:
  • Kubernetes waits a set time before upgrading
  • If this value is not set, Kubernetes will assume that the container is ready to serve
  • If this value is not set, it may cause the service to run normally in some extreme cases
• maxSurge:
  • During the upgrade process, the maximum number of PODs can be more than the original setting.
  • For example: maxSurage=1, replicas=5, it means that Kubernetes will start a new Pod before deleting an old POD, and there will be a maximum of 5+1 PODs in the entire upgrade process.
• maxUnavaible:
  • The maximum number of PODs in an unserviceable state during the upgrade process
  • When maxSurge is not 0, the value cannot be 0 either
  • For example: maxUnavaible=1, it means that at most one POD will be in an unserviceable state during the entire Kubernetes upgrade process.

---

Then execute the command:

$ kubectl apply -f nginx-deployment.yaml 
deployment "nginx-deploy" configured 

Then we can use the rollout command:

• Check status:

$ kubectl rollout status deployment/nginx-deploy 
Waiting for rollout to finish: 1 out of 3 new replicas have been updated.. 
deployment "nginx-deploy" successfully rolled out 

• Pause upgrade

$ kubectl rollout pause deployment <deployment> 

• continue to upgrade

$ kubectl rollout resume deployment <deployment> 

After the upgrade is complete, continue to check the status of rs:

$ kubectl get rs 
NAME DESIRED CURRENT READY AGE 
nginx-deploy-2078889897 0 0 0 47m 
nginx-deploy-3297445372 3 3 3 42m 
nginx-deploy-431080787 0 0 0 1h 

According to AGE, we can see that the current state closest to us is: 3, which is consistent with our yaml file, which proves that the upgrade was successful.

Use the describe command to view full information about the upgrade:

Name: nginx-deploy 
Namespace: default 
CreationTimestamp: Wed, 18 Oct 2017 16:58:52 +0800 
Labels: k8s-app=nginx-demo 
Annotations: deployment.kubernetes.io/revision=3 
kubectl.kubernetes.io/last-applied-configuration={
    
    "apiVersion":"apps/v1beta1","kind": 
"Deployment","metadata":{
    
    "annotations":{
    
    },"labels":{
    
    "k8s-app":"nginx-demo"},"name":"nginx- 
deploy","namespace":"defa... 
Selector: app=nginx 
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable 
StrategyType: RollingUpdate 
MinReadySeconds: 0 
RollingUpdateStrategy: 25% max unavailable, 25% max surge 
Pod Template: 
Labels: app=nginx 
Containers: 
nginx: 
Image: nginx:1.13.3 
Port: 80/TCP 
Environment: <none> 
Mounts: <none> 
Volumes: <none> 
Conditions: 
Type Status Reason 
---- ------ ------ 
Progressing True NewReplicaSetAvailable 
Available True MinimumReplicasAvailable 
OldReplicaSets: <none> 
NewReplicaSet: nginx-deploy-3297445372 (3/3 replicas created) 
Events: 
FirstSeen LastSeen Count From SubObjectPath Type Reason Message 
--------- -------- ----- ---- ------------- -------- ------ ------- 
50m 50m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set 
nginx-deploy-2078889897 to 1 
45m 45m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica 
set nginx-deploy-2078889897 to 0 
45m 45m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set 
nginx-deploy-3297445372 to 1 
39m 39m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica 
set nginx-deploy-431080787 to 2 
39m 39m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set 
nginx-deploy-3297445372 to 2 
38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica 
set nginx-deploy-431080787 to 1 
38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set 
nginx-deploy-3297445372 to 3 
38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica 
set nginx-deploy-431080787 to 0 

---

Rollback Deployment

We've been able to roll out a smooth upgrade of our Deployment, but what if something goes wrong with the upgraded POD? The best and fastest way we can think of is of course to roll back to the last version that provided normal work, and Deployment provides us with a rollback mechanism.

First, check the deployment's upgrade history:

$ kubectl rollout history deployment nginx-deploy 
deployments "nginx-deploy" 
REVISION CHANGE-CAUSE 
1 <none> 
2 <none> 
3 kubectl apply --filename=Desktop/nginx-deployment.yaml --record=true

From the above results, we can see that it is better to bring the record parameter when performing Deployment upgrade, so that we can view historical version information.

Similarly, we can use the following command to view the information of a single revison:

$ kubectl rollout history deployment nginx-deploy --revision=3 
deployments "nginx-deploy" with revision #3 
Pod Template: 
Labels: app=nginx 
pod-template-hash=3297445372 
Annotations: kubernetes.io/change-cause=kubectl apply --filename=nginx-deployment.yaml 
--record=true 
Containers: 
nginx: 
Image: nginx:1.13.3 
Port: 80/TCP 
Environment: <none> 
Mounts: <none> 
Volumes: <none> 

If you want to roll back directly to the previous version of the current version:

$ kubectl rollout undo deployment nginx-deploy 
deployment "nginx-deploy" rolled back 
当然也可以⽤ revision 回退到指定的版本： 
$ kubectl rollout undo deployment nginx-deploy --to-revision=2 
deployment "nginx-deploy" rolled back 

You can now use the command to view the current status of the Deployment.

---