序
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 0deployment文件
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可以設置爲系統完全啓動起來所需的最大時間+若干秒。
本文轉自SegmentFault-使用kubernetes的deployment進行RollingUpdate這幾個參數配置好了之後，基本就可以實現近乎無縫地平滑升級了。對於使用服務發現的應用來說，readinessProbe可以去執行命令，去查看是否在服務發現裏頭應該註冊成功了，纔算成功。