deployment(如何理解Deployment的操作)

我們通過一些簡單的例子來演示Deployment的創建、查看、更新、刪除等操作,以期快速地掌握Deployment的用法。

創建

首先我們先將以下配置保存到名為deployment.yaml的文件中。

apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentlabels:app:nginxspec:replicas:3selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.19.0

該份配置將創建一個名為nginx-deployment的Deployment資源對象,根據spec.replicas中的信息可知,它期望有3個Pod副本。

接下來使用kubectl create命令將該配置提交給kube-apiserver,如下所示:

[root@ecs-d8b6manifests]#kubectlcreate-fdeployment.yamldeployment.apps/nginx-deploymentcreated

根據命令行輸出內容可知,名為nginx-deployment的Deployment已創建完成。

查看

當創建一個Deployment資源對象時,Deployment控制器不會直接創建Pod,而是通過創建ReplicaSet來間接創建Pod。

查看Deployment

查看新創建的Deployment資源:

[root@ecs-d8b6manifests]#kubectlgetdeploymentNAMEREADYUP-TO-DATEAVAILABLEAGEnginx-deployment3/33390s

命令行輸出中各字段含義如下:

• NAME:Deployment資源名稱,同配置中的metadata.name;

• READY:<已處于Reday狀態的Pod數量>/<期望的Pod數量>;

• UP-TO-DATE:處于最新狀態的Pod數量;

• AVAILABLE:可用的Pod數量;

• AGE:應用運行時間,也是資源自創建至今經過的時間。

此處READY和AVAILABLE有一些細微的區別,當Pod中指定的容器全部運行起來后,就可以認定該Pod為READY,所以READY含義更傾向于Running,而AVAILABLE要求會更嚴格一些,只有當Pod處于READY狀態且持續一段時間后才可被認定為AVAILABLE,其含義更傾向于可用的數量。

UP-TO-DATE表示運行最新配置的Pod數量,當修改Deployment配置中Pod模版時,新版的Pod會被創建且短期內會與舊版的Pod并存,UP-TO-DATE正是表示已創建的新版Pod數量。

查看ReplicaSet

接著查看ReplicaSet:

[root@ecs-d8b6manifests]#kubectlgetreplicasetNAMEDESIREDCURRENTREADYAGEnginx-deployment-6fd78f555b333104s

由Deployment創建的ReplicaSet名稱由Deployment的名稱和一個隨機字符串組成。

查看Pod

接著查看最終生成的Pod:

[root@ecs-d8b6manifests]#kubectlgetpodsNAMEREADYSTATUSRESTARTSAGEnginx-deployment-6fd78f555b-clf9w1/1Running0110snginx-deployment-6fd78f555b-vlvp61/1Running0110snginx-deployment-6fd78f555b-wjslg1/1Running0110s

這些Pod都是由ReplicaSet自動創建出來的,其名稱由ReplicaSet名稱和一個隨機字符串組成。

更新

由于Deployment控制器通過ReplicaSet來創建并管理Pod,當修改Deployment配置中的spec.replicas時,Deployment控制器相應地也會修改Replicaset中spec.replicas值,最終由Replicaset控制器來調整Pod的副本數,該部分功能我們已經在介紹ReplicaSet時演示過,此處不再演示。

我們在此演示一種Deployment相較于ReplicaSet更高階的功能,即應用版本的升降級。當前應用使用的nginx鏡像版本為1.19.0,我們希望把該版本降為1.18.0。

通過以下命令,將spec.template.spec.containers.image值由nginx:1.19.0改為nginx:1.18.0:

[root@ecs-d8b6manifests]#kubectleditdeploymentsnginx-deployment

然后再次查看Deployment、ReplicaSet和Pod:

[root@ecs-d8b6manifests]#kubectlgetdeploymentNAMEREADYUP-TO-DATEAVAILABLEAGEnginx-deployment3/33333m[root@ecs-d8b6manifests]#kubectlgetreplicasetNAMEDESIREDCURRENTREADYAGEnginx-deployment-6fd78f555b00033mnginx-deployment-7df9bc6ff533332s[root@ecs-d8b6manifests]#kubectlgetpodsNAMEREADYSTATUSRESTARTSAGEnginx-deployment-7df9bc6ff5-4rz8l1/1Running040snginx-deployment-7df9bc6ff5-tmxwl1/1Running044snginx-deployment-7df9bc6ff5-vmdzp1/1Running042s

可以看到,之前的ReplicaSet(nginx-deployment-6fd78f555b)副本數已被修改為0,新的ReplicaSet(nginx-deployment-7df9bc6ff5)被創建了出來,進而創建了新的Pod。新的Pod中運行的容器鏡像版本就是我們修改后的容器鏡像版本,讀者可以自行驗證。

刪除

當刪除Deployment資源時,由Deployment控制器創建的ReplicaSet也會被刪除,因此由ReplicaSet創建的Pod也會被刪除。

[root@ecs-d8b6manifests]#kubectldeletedeploymentnginx-deploymentdeployment.apps"nginx-deployment"deleted[root@ecs-d8b6manifests]#kubectlgetreplicasetNoresourcesfoundindefaultnamespace.[root@ecs-d8b6manifests]#kubectlgetpodsNoresourcesfoundindefaultnamespace.

以上就是如何理解Deployment的操作,小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注本站行業資訊頻道。