使用kubernetes的deployment進行RollingUpdate

序

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

replication controller與deployment的差別

replication controller

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 readinessProbe: #kubernetes認為該pod是啟動成功的 httpGet: path: /health port: 8080 scheme: HTTP initialDelaySeconds: 30 ## equals to minimum startup time of the application 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可以去執行指令，去檢視是否在服務發現裡頭應該注冊成功了，才算成功。

本文轉自SegmentFault-

使用kubernetes的deployment進行RollingUpdate