摘要:序,可以使得服務近乎無縫地平滑升級,即在不停止對外服務的前提下完成應用的更新。如果少于指定數量的,會創建新的,反之則會刪除掉多余的以保證數量不變。對于應用,默認的帶有接口,可以用來進行啟動成功的判斷。
序
rolling update,可以使得服務近乎無縫地平滑升級,即在不停止對外服務的前提下完成應用的更新。
replication controller與deployment的區別 replication controllerReplication 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的整體資源使用情況,做到自動伸縮。
滾動升級:滾動升級為一種平滑的升級方式,通過逐步替換的策略,保證整體系統的穩定,在初始化升級的時候就可以及時發現和解決問題,避免問題不斷擴大。
DeploymentDeployment同樣為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:deployment文件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
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個之間
k8s將會給應用發送SIGTERM信號,可以用來正確、優雅地關閉應用,默認為30秒。
如果需要更優雅地關閉,則可以使用k8s提供的pre-stop lifecycle hook 的配置聲明,將會在發送SIGTERM之前執行。
livenessProbe與readinessProbelivenessProbe是kubernetes認為該pod是存活的,不存在則需要kill掉,然后再新啟動一個,以達到replicas指定的個數。
readinessProbe是kubernetes認為該pod是啟動成功的,這里根據每個應用的特性,自己去判斷,可以執行command,也可以進行httpGet。比如對于使用java web服務的應用來說,并不是簡單地說tomcat啟動成功就可以對外提供服務的,還需要等待spring容器初始化,數據庫連接連接上等等。對于spring boot應用,默認的actuator帶有/health接口,可以用來進行啟動成功的判斷。
其中readinessProbe.initialDelaySeconds可以設置為系統完全啟動起來所需的最少時間,livenessProbe.initialDelaySeconds可以設置為系統完全啟動起來所需的最大時間+若干秒。
doc這幾個參數配置好了之后,基本就可以實現近乎無縫地平滑升級了。對于使用服務發現的應用來說,readinessProbe可以去執行命令,去查看是否在服務發現里頭應該注冊成功了,才算成功。
【分享】幾種常見的不停機發布方式
Deployment vs ReplicationController in Kubernetes
kubernetes-user-guide-deployments
Kubernetes用戶指南(三)--在生產環境中使用Pod來工作、管理部署
Kubernetes livenessProbe shutdown during application startup
Kubernetes技術研究容器監控監測
Graceful shutdown of pods with Kubernetes
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/32541.html
摘要:在中,被用來管理有狀態應用的對象。并行管理并行管理告訴控制器以并行的方式啟動或者終止所有的。如果設置為,則控制器將會刪除和重建中的每一。在大部分的情況下,不會使用分隔當希望進行金絲雀發布,或者執行階段發布時,分隔是很有用的。 在Kubernetes中,StatefulSet被用來管理有狀態應用的API對象。StatefulSets在Kubernetes 1.9版本才穩定。Statefu...
摘要:命令用于程序在負載加重或縮小時進行擴容或縮小,我們通過一些實際例子來觀察命令到底能達到什么效果。 kubectl scale命令用于程序在負載加重或縮小時進行pod擴容或縮小,我們通過一些實際例子來觀察scale命令到底能達到什么效果。 命令行創建一個deployment: kubectl run jerry-nginx --image=nginx:1.12.2 showImg(htt...
摘要:命令用于程序在負載加重或縮小時進行擴容或縮小,我們通過一些實際例子來觀察命令到底能達到什么效果。 kubectl scale命令用于程序在負載加重或縮小時進行pod擴容或縮小,我們通過一些實際例子來觀察scale命令到底能達到什么效果。 命令行創建一個deployment: kubectl run jerry-nginx --image=nginx:1.12.2 showImg(htt...
摘要:命令用于程序在負載加重或縮小時進行擴容或縮小,我們通過一些實際例子來觀察命令到底能達到什么效果。 kubectl scale命令用于程序在負載加重或縮小時進行pod擴容或縮小,我們通過一些實際例子來觀察scale命令到底能達到什么效果。 命令行創建一個deployment: kubectl run jerry-nginx --image=nginx:1.12.2 showImg(htt...
摘要:默認監聽在端口,所以我們把宿主機的端口映射到容器的端口用下面的命令可以看到正在運行中的容器這時如果你用瀏覽器訪問,就能看到我們剛才創建的頁面。這時如果刷新瀏覽器,就可以看到更新的內容。 早在 Docker 正式發布幾個月的時候,LeanCloud 就開始在生產環境大規模使用 Docker,在過去幾年里 Docker 的技術棧支撐了我們主要的后端架構。這是一篇寫給程序員的 Docker ...
閱讀 2672·2019-08-30 15:55
閱讀 1804·2019-08-30 15:53
閱讀 2656·2019-08-29 18:38
閱讀 928·2019-08-26 13:49
閱讀 502·2019-08-23 15:42
閱讀 3114·2019-08-22 16:33
閱讀 1004·2019-08-21 17:59
閱讀 1083·2019-08-21 17:11