使用kubernetes的deployment進行RollingUpdate

rolling update，可使得服務近乎無縫地平滑升級，即在不中止對外服務的前提下完成應用的更新。

Replication Controller爲Kubernetes的一個核心內容，應用託管到Kubernetes以後，須要保證應用可以持續的運行，Replication Controller就是這個保證的key，主要的功能以下：

• 確保pod數量：它會確保Kubernetes中有指定數量的Pod在運行。若是少於指定數量的pod，Replication Controller會建立新的，反之則會刪除掉多餘的以保證Pod數量不變。

• 確保pod健康：當pod不健康，運行出錯或者沒法提供服務時，Replication Controller也會殺死不健康的pod，從新建立新的。

• 彈性伸縮 ：在業務高峯或者低峯期的時候，能夠經過Replication Controller動態的調整pod的數量來提升資源的利用率。同時，配置相應的監控功能（Hroizontal Pod Autoscaler），會定時自動從監控平臺獲取Replication Controller關聯pod的總體資源使用狀況，作到自動伸縮。

• 滾動升級：滾動升級爲一種平滑的升級方式，經過逐步替換的策略，保證總體系統的穩定，在初始化升級的時候就能夠及時發現和解決問題，避免問題不斷擴大。

Deployment

Deployment一樣爲Kubernetes的一個核心內容，主要職責一樣是爲了保證pod的數量和健康，90%的功能與Replication Controller徹底同樣，能夠看作新一代的Replication Controller。可是，它又具有了Replication Controller以外的新特性：

• Replication Controller所有功能：Deployment繼承了上面描述的Replication Controller所有功能。

• 事件和狀態查看：能夠查看Deployment的升級詳細進度和狀態。

• 回滾：當升級pod鏡像或者相關參數的時候發現問題，可使用回滾操做回滾到上一個穩定的版本或者指定的版本。

• 版本記錄: 每一次對Deployment的操做，都能保存下來，給予後續可能的回滾使用。

• 暫停和啓動：對於每一次升級，都可以隨時暫停和啓動。

  多種升級方案：Recreate：刪除全部已存在的pod,從新建立新的; RollingUpdate：滾動升級，逐步替換的策略，同時滾動升級時，支持更多的附加參數，例如設置最大不可用pod數量，最小升級間隔時間等等。

  
  

  
  

  deployment的經常使用命令

查看部署狀態

kubectl rollout status deployment/review-demo  --namespace=scm
kubectl describe deployment/review-demo  --namespace=scm

或者這種寫法

kubectl rollout status deployments review-demo --namespace=scm
kubectl describe deployments review-demo  --namespace=scm

升級

kubectl set image deployment/review-demo review-demo=library/review-demo:0.0.1 --namespace=scm

或者

kubectl edit deployment/review-demo --namespace=scm

編輯.spec.template.spec.containers[0].image的值

終止升級

kubectl rollout pause deployment/review-demo --namespace=scm

繼續升級

kubectl rollout resume deployment/review-demo --namespace=scm

回滾

kubectl rollout undo deployment/review-demo --namespace=scm

查看deployments版本

kubectl rollout history deployments --namespace=scm

回滾到指定版本

kubectl rollout undo deployment/review-demo --to-revision=2 --namespace=scm

升級歷史

kubectl describe deployment/review-demo  --namespace=scm 

Name:     review-demo 

Namespace:    scm 

CreationTimestamp:  Tue, 31 Jan 2017 16:42:01 +0800

Labels:     app=review-demo 

Selector:   app=review-demo 

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

StrategyType:   RollingUpdate 

MinReadySeconds:  0

RollingUpdateStrategy:  1 max unavailable, 1 max surge 

OldReplicaSets:   <none> 

NewReplicaSet:    review-demo-2741031620 (3/3 replicas created) 

Events:  FirstSeen LastSeen  Count From        SubobjectPath Type    Reason      Message

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

1m    1m    1 {deployment-controller }    Normal    ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 1  

1m    1m    1 {deployment-controller }    Normal    ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 2  

1m    1m    1 {deployment-controller }    Normal    ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 2  

1m    1m    1 {deployment-controller }    Normal    ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 1  

1m    1m    1 {deployment-controller }    Normal    ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 3  

1m    1m    1 {deployment-controller }    Normal    ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 0

deployment文件

apiVersion: extensions/v1beta1 

kind: Deployment 

metadata:  

  name: review-demo  

  namespace: scm  

  labels:    

    app: review-demo 

spec:  

  replicas: 3

#  minReadySeconds: 60     #滾動升級時60s後認爲該pod就緒  

  strategy:    

    rollingUpdate:  ##因爲replicas爲3,則整個升級,pod個數在2-4個之間      

      maxSurge: 1      #滾動升級時會先啓動1個pod      

      maxUnavailable: 1 #滾動升級時容許的最大Unavailable的pod個數  

template:    

   metadata:      

     labels:        

       app: review-demo    

   spec:      

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

     containers:      

       - name: review-demo        

         image: library/review-demo:0.0.1-SNAPSHOT         

         imagePullPolicy: IfNotPresent        

         livenessProbe: #kubernetes認爲該pod是存活的,不存活則須要重啓          

           httpGet:            

             path: /health            

             port: 8080            

             scheme: HTTP          

           initialDelaySeconds: 60 ## equals to the maximum startup time of the application + couple of seconds          

           timeoutSeconds: 5          

           successThreshold: 1          

           failureThreshold: 5               

     resources:          # keep request = limit to keep this container in guaranteed class          

         requests:            

           cpu: 50m            

           memory: 200Mi          

        limits:            

           cpu: 500m            

           memory: 500Mi        

     env:          

       - name: PROFILE            

          value: "test"        

     ports:          

       - name: http            

          containerPort: 8080

幾個重要參數說明

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能夠設置爲系統徹底啓動起來所需的最大時間+若干秒。

這幾個參數配置好了以後，基本就能夠實現近乎無縫地平滑升級了。對於使用服務發現的應用來講，readinessProbe能夠去執行命令，去查看是否在服務發現裏頭應該註冊成功了，纔算成功。

本文出自https://www.jianshu.com/p/6bc8e0ae65d1