Kubernetes的deployment使用

Deployment管理Pods和ReplicaSets,提供聲明式更新。和老的ReplicationController(命令式管理)對應,發展趨勢是取代老的,因此後面也不會起文章單獨討論ReplicationController了。java

備註:但由Deployment-controller管理的Pods和ReplicaSets最好自始至終都由Deployment-controller管理,最好不要手動去管理,以避免發生衝突。node

建立Deploymentnginx

以下一個Deployment的配置(nginx-deployment.yaml),建立一個ReplicaSet包含3個nginx Podsweb

apiVersion: apps/v1spring

kind: Deploymentdocker

metadata:  數據庫

  name: nginx-deployment  api

  labels:    瀏覽器

    app: nginxtomcat

spec:  

  replicas: 3  

  selector:    

    matchLabels:      

      app: nginx  

  template:    

     metadata:      

       labels:        

          app: nginx    

     spec:      

       containers:      

         - name: nginx        

           image: nginx:1.7.9        

           ports:        

           - containerPort: 80

  • apiVersion這裏爲apps/v1,若是是1.9以前的版本爲extensions/v1beta1

  • replicas:3 起3個replicated Pods

  • selector指明哪一個pod被管理,這裏咱們指定了label(app:nginx)

  • template: spec 指明瞭運行一個容器nginx(以nginx:1.7.9爲鏡像)

  • 開放80端口給container,以使container之間能發送和接收流量

備註:注意這裏定義name 或 label 時不要和其餘的重複,k8s不會檢查這個,須要人工本身確認

要建立此部署,執行下面的命令(在這以前咱們提早下好nginx相關的鏡像,docker pull nginx:1.7.9)

[root@master yaml]# kubectl create -f nginx-deployment.yaml --record

deployment "nginx-deployment" created

  • --record會記錄操做歷史,以便於後面回滾操做

查看deployments

[root@master yaml]# kubectl get deployments

NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE 

nginx-deployment   3         0         0            0           1s

  • NAME:在集羣中的部署名稱

  • DESIRED:顯示配置裏定義的副本數量,這是應該達到的副本數量

  • CURRENT:當前正在運行的副本數量

  • UP-TO-DATE:更新到當前所需狀態的副本數量

  • AVAILABLE:可供使用的副本數量

  • AEG:顯示app存活的時間

經過下面語句可查追蹤部署狀況

[root@master ~]# kubectl rollout status deployment/nginx-deployment

deployment "nginx-deployment" successfully rolled out

# 這是部署完成的狀態

# 未完成的會顯示當前部署哪一步了

[root@master ~]# kubectl rollout status deployment/nginx-deployment

Waiting for rollout to finish: 2 out of 3 new replicas have been updated... 

deployment "nginx-deployment" successfully rolled out

過一會咱們再查看,就全

[root@master ~]# kubectl get deployments

NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE 

nginx-deployment   3         3         3            3           51s

這裏注意若是定義了.spec.minReadySeconds,那麼必須通過定義的時間纔會達到AVAILABLE 狀態

經過下面的命令查看Deployment建立的ReplicaSet(rs)

[root@master ~]# kubectl get rs

NAME                          DESIRED   CURRENT   READY     AGE 

nginx-deployment-6c54bd5869   3         3         3         56m

注意ReplicaSet的名稱格式爲[DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VALUE],後面的hash值是由Deployment自動建立的

查看Pods

[root@master ~]# kubectl get pods --show-labels

NAME                                READY     STATUS    RESTARTS   AGE       LABELS nginx-deployment-6c54bd5869-9brqp   1/1       Running   0          58m       app=nginx,pod-template-hash=2710681425

nginx-deployment-6c54bd5869-dkmgh   1/1       Running   0          58m       app=nginx,pod-template-hash=2710681425

nginx-deployment-6c54bd5869-vzsht   1/1       Running   0          58m       app=nginx,pod-template-hash=2710681425

建立的ReplicaSet 會確保時刻有3個nginx Pods的副本在運行


更新Deployment

假設咱們想把nginx從1.7.9更新到1.9.1,有如下3種方式

1. 直接set命令設置變動的部分

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

deployment "nginx-deployment" image updated

以上命令會自動回滾更改Pods,即中止必定量的老的,新建新的,直到來的終止完,新的啓動完

經過describe便可查看全部的細節

[root@master yaml]# kubectl describe deployment/nginx-deployment

Name:                   nginx-deployment

Namespace:              default

CreationTimestamp:      Thu, 15 Mar 2018 02:51:06 -0400

Labels:                 app=nginx

Annotations:       deployment.kubernetes.io/revision=2                        

                           kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

Selector:               app=nginx

Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable

StrategyType:           RollingUpdate

MinReadySeconds:        0RollingUpdateStrategy:  25% max unavailable, 25% max surge 

Pod Template:  

     Labels:  app=nginx  

     Containers:   

        nginx:    

        Image:        nginx:1.9.1    

        Port:         80/TCP    

        Environment:  <none>    

        Mounts:       <none>  

        Volumes:        <none>

Conditions:  Type           Status  Reason  

----           ------  ------  

Available      True    MinimumReplicas

Available  Progressing    True    NewReplicaSetAvailable

OldReplicaSets:  <none>

NewReplicaSet:   nginx-deployment-5964dfd755 (3/3 replicas created)

Events:  Type    Reason             Age   From                   Message 

 ----    ------             ----  ----                   -------  

Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-5964dfd755 to 1  

Normal  ScalingReplicaSet  2m    deployment-controller  Scaled down replica set nginx-deployment-6c54bd5869 to 2  

Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-5964dfd755 to 2  

Normal  ScalingReplicaSet  2m    deployment-controller  Scaled down replica set nginx-deployment-6c54bd5869 to 1  

Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-5964dfd755 to 3  

Normal  ScalingReplicaSet  2m    deployment-controller  Scaled down replica set nginx-deployment-6c54bd5869 to 0

  • 可見image已經變了

  • 另外Events可查看滾動更新的過程

  • 另外上面的說的中止和新建的比例在這裏體現RollingUpdateStrategy:  25% max unavailable, 25% max surge,25% max unavailable確保在更新時只有部分會關閉(這裏是pod數的25%會關閉)。25% max surge確保建立新的pod也在必定比例上(這裏默認也是25%)

2. 經過直接修改線上的配置也可直接修改

kubectl edit deployment/nginx-deployment


會打開一個編輯器,修改指定的部分便可,這裏是.spec.template.spec.containers[0].image

3. 修改yaml文件,經過apply從新部署

[root@master yaml]# kubectl apply -f nginx-deployment.yaml 

 Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply

deployment "nginx-deployment" configured

但這裏有個警告: 也就是apply方式更新的資源應該是由kubectl create 加--save-config參數建立的 或 由apply建立的 (apply當資源不存在時會建立)

這時咱們查看rs,會顯示新起了一個rs並將副本擴到3個,舊的rs都縮減爲0

[root@master yaml]# kubectl get rs

NAME                          DESIRED   CURRENT   READY     AGE 

nginx-deployment-5964dfd755   3         3         3         21m 

nginx-deployment-6c54bd5869   0         0         0         1h

回滾Deployment

有時須要回滾的操做,好比更新錯誤,手誤等一系列問題

好比上面的操做更新到1.9.1時,寫錯了,寫成1.91了

[root@master yaml]# kubectl set image deployment/nginx-deployment nginx=nginx:1.91

deployment "nginx-deployment" image updated

追蹤狀態

[root@master yaml]# kubectl rollout status deployments nginx-deployment

Waiting for rollout to finish: 1 out of 3 new replicas have been updated...

可見卡住不動了, Ctrl+C終止,查看rs以下

[root@master yaml]# kubectl get rs

NAME                          DESIRED   CURRENT   READY     AGE 

nginx-deployment-5964dfd755   3         3         3         40m 

nginx-deployment-5d5cfdbd5f   1         1         0         1m 

nginx-deployment-6c54bd5869   0         0         0         2h

新的rs只啓動了Pod但沒有處於READY狀態

查看Pods

[root@master yaml]# kubectl get pods 

NAME                                READY     STATUS             RESTARTS   AGE 

nginx-deployment-5964dfd755-8z8b7   1/1       Running            0          27m 

nginx-deployment-5964dfd755-bnznj   1/1       Running            0          27m 

nginx-deployment-5964dfd755-pt54q   1/1       Running            0          27m 

nginx-deployment-5d5cfdbd5f-srdcc   0/1       ImagePullBackOff   0          2m

可發現ImagePullBackOff,實際就是鏡像不存在

要修復這個,咱們就須要rollback到前一個ok的版本

查看操做歷史

[root@master yaml]# kubectl rollout history deployment/nginx-deployment

deployments "nginx-deployment"

REVISION    CHANGE-CAUSE 

1           kubectl create -f docs/user-guide/nginx-deployment.yaml --record 

2           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 

3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91

要查看每一個版本的詳細狀況,指定--revision

[root@master yaml]# kubectl rollout history deployment/nginx-deployment --revision=2

deployments "nginx-deployment" with revision #2

Pod Template:  

 Labels:       app=nginx          pod-template-hash=2710681425  

 Annotations:  kubernetes.io/change-cause=kubectl edit deployment/nginx-deployment  

 Containers:  

   nginx:    

     Image:      nginx:1.9.1    

     Port:       80/TCP    

     Environment:        <none>    

     Mounts:     <none>  

     Volumes:      <none>

接下來進行回滾的操做

不指定版本,默認回滾到上一個版本

[root@master yaml]# kubectl rollout undo deployment/nginx-deployment

deployment "nginx-deployment" rolled back

指定版本,經過--to-revision指定

[root@master yaml]# kubectl rollout undo deployment/nginx-deployment --to-revision=2

deployment "nginx-deployment" rolled back

查看

kubectl describe deployment/nginx-deployment

...............

可看到有DeploymentRollback  Reason的事件


擴展Deployment

可經過以下的命令進行擴展

[root@master yaml]# kubectl scale deployment nginx-deployment --replicas=5

deployment "nginx-deployment" scaled

查看Pods

[root@master yaml]# kubectl get pods 

NAME                                READY     STATUS    RESTARTS   AGE 

nginx-deployment-5964dfd755-8z8b7   1/1       Running   0          41m 

nginx-deployment-5964dfd755-bhm2s   1/1       Running   0          1m 

nginx-deployment-5964dfd755-bnznj   1/1       Running   0          41m 

nginx-deployment-5964dfd755-cftfj   1/1       Running   0          6s

nginx-deployment-5964dfd755-pt54q   1/1       Running   0          41m

可見已擴展到5個

使用autoscale還可設置自動水平擴展(hpa),可根據機器負載之類的信息自動擴展或縮減,這個後面細講

$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

deployment "nginx-deployment" autoscaled

暫停和恢復Deployment

有時須要修改多個部分,而不是上面的只修改image,這樣的話每次改完都自動部署,顯然很差,經過pause便可暫停Deployment,更改完了,經過resume便可恢復部署

暫停

[root@master yaml]# kubectl rollout pause deployment/nginx-deployment

deployment "nginx-deployment" paused

修改

[root@master yaml]# kubectl set image deploy/nginx-deployment nginx=nginx:1.7.9

deployment "nginx-deployment" image updated

查看Pods

[root@master yaml]# kubectl get pods 

NAME                                READY     STATUS    RESTARTS   AGE 

nginx-deployment-5964dfd755-8z8b7   1/1       Running   0          57m 

nginx-deployment-5964dfd755-bhm2s   1/1       Running   0          17m 

nginx-deployment-5964dfd755-bnznj   1/1       Running   0          57m 

nginx-deployment-5964dfd755-cftfj   1/1       Running   0          16m 

nginx-deployment-5964dfd755-pt54q   1/1       Running   0          57m

注意後面的AGE仍是以前的Pod,這裏就不會自動更新了

恢復

[root@master yaml]# kubectl rollout resume deploy/nginx-deployment

deployment "nginx-deployment" resumed

這時再查看Pods

[root@master yaml]# kubectl get pods NAME                                READY     STATUS    RESTARTS   AGE nginx-deployment-6c54bd5869-htjxz   1/1       Running   0          25s

nginx-deployment-6c54bd5869-lj288   1/1       Running   0          30s

nginx-deployment-6c54bd5869-nt8lt   1/1       Running   0          30s

nginx-deployment-6c54bd5869-svqz6   1/1       Running   0          29s

nginx-deployment-6c54bd5869-zq8tl   1/1       Running   0          25s


可見已經更新部署了

內部Deployment部分大概就講完了,下面把nginx服務暴露到外面

刪除Deployment

[root@master yaml]# kubectl delete -f nginx-deployment.yaml 

deployment "nginx-deployment" deleted

部署service

服務的暴露須要Service,它是Pod的抽象代理(具體機制見這裏)。見nginx-service.yaml

apiVersion: v1

kind: Service

metadata:  

 name: nginx-service

spec:  

 type: NodePort  

 sessionAffinity: ClientIP  

 selector:    

   app: nginx  

 ports:    

   - port: 80      

   nodePort: 30080


  • kind:Service表明是一個服務

  • type:NodePort k8s將會在每一個Node上打開一個端口而且每一個Node的端口都是同樣的,經過<NodeIP>:NodePort的方式Kubernetes集羣外部的程序能夠訪問Service。

  • selector:哪一個服務須要暴露

  • port:service暴露的端口

  • TargetPort:pod的端口

  • nodePort:對外暴露的端口,不設置會默認分配,範圍:30000-32767

  • 轉發邏輯是:
    <NodeIP>:<nodeport> => <ServiceVIP>:<port>=> <PodIP>:<targetport>

部署service服務:

[root@master yaml]# kubectl create -f nginx-service.yaml s

ervice "nginx-service" created

可看到啓動了一個svc

NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE 

svc/kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        1d

svc/nginx-service   NodePort    10.101.86.235   <none>  80:30080/TCP   4m

瀏覽器測試

本文出自https://my.oschina.net/u/2306127/blog/1647246

幾個重要參數說明

maxSurge與maxUnavailable

maxSurge: 1 表示滾動升級時會先啓動1個pod
maxUnavailable: 1 表示滾動升級時容許的最大Unavailable的pod個數
因爲replicas爲3,則整個升級,pod個數在2-4個之間

terminationGracePeriodSeconds

k8s將會給應用發送SIGTERM信號,能夠用來正確、優雅地關閉應用,默認爲30秒。

若是須要更優雅地關閉,則可使用k8s提供的pre-stop lifecycle hook 的配置聲明,將會在發送SIGTERM以前執行。

livenessProbe與readinessProbe

livenessProbe是kubernetes認爲該pod是存活的,不存在則須要kill掉,而後再新啓動一個,以達到replicas指定的個數。

readinessProbe是kubernetes認爲該pod是啓動成功的,這裏根據每一個應用的特性,本身去判斷,能夠執行command,也能夠進行httpGet。好比對於使用java web服務的應用來講,並非簡單地說tomcat啓動成功就能夠對外提供服務的,還須要等待spring容器初始化,數據庫鏈接鏈接上等等。對於spring boot應用,默認的actuator帶有/health接口,能夠用來進行啓動成功的判斷。

其中readinessProbe.initialDelaySeconds能夠設置爲系統徹底啓動起來所需的最少時間,livenessProbe.initialDelaySeconds能夠設置爲系統徹底啓動起來所需的最大時間+若干秒。

參考使用kubernetes的deployment進行RollingUpdate

https://www.jianshu.com/p/6bc8e0ae65d1

相關文章
相關標籤/搜索