使用kubernetes的deployment進行RollingUpdate

Lycheeee 發(fā)布于2019-07-01 16:30 / 2006人閱讀

摘要：序，可以使得服務近乎無縫地平滑升級，即在不停止對外服務的前提下完成應用的更新。如果少于指定數(shù)量的，會創(chuàng)建新的，反之則會刪除掉多余的以保證數(shù)量不變。對于應用，默認的帶有接口，可以用來進行啟動成功的判斷。

序

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

replication controller與deployment的區(qū)別 replication controller

Replication Controller為Kubernetes的一個核心內(nèi)容，應用托管到Kubernetes之后，需要保證應用能夠持續(xù)的運行，Replication Controller就是這個保證的key，主要的功能如下：

確保pod數(shù)量：它會確保Kubernetes中有指定數(shù)量的Pod在運行。如果少于指定數(shù)量的pod，Replication Controller會創(chuàng)建新的，反之則會刪除掉多余的以保證Pod數(shù)量不變。

確保pod健康：當pod不健康，運行出錯或者無法提供服務時，Replication Controller也會殺死不健康的pod，重新創(chuàng)建新的。

彈性伸縮：在業(yè)務高峰或者低峰期的時候，可以通過Replication Controller動態(tài)的調(diào)整pod的數(shù)量來提高資源的利用率。同時，配置相應的監(jiān)控功能（Hroizontal Pod Autoscaler），會定時自動從監(jiān)控平臺獲取Replication Controller關聯(lián)pod的整體資源使用情況，做到自動伸縮。

滾動升級：滾動升級為一種平滑的升級方式，通過逐步替換的策略，保證整體系統(tǒng)的穩(wěn)定，在初始化升級的時候就可以及時發(fā)現(xiàn)和解決問題，避免問題不斷擴大。

Deployment

Deployment同樣為Kubernetes的一個核心內(nèi)容，主要職責同樣是為了保證pod的數(shù)量和健康，90%的功能與Replication Controller完全一樣，可以看做新一代的Replication Controller。但是，它又具備了Replication Controller之外的新特性：

Replication Controller全部功能：Deployment繼承了上面描述的Replication Controller全部功能。

事件和狀態(tài)查看：可以查看Deployment的升級詳細進度和狀態(tài)。

回滾：當升級pod鏡像或者相關參數(shù)的時候發(fā)現(xiàn)問題，可以使用回滾操作回滾到上一個穩(wěn)定的版本或者指定的版本。

版本記錄: 每一次對Deployment的操作，都能保存下來，給予后續(xù)可能的回滾使用。

暫停和啟動：對于每一次升級，都能夠隨時暫停和啟動。

多種升級方案：Recreate：刪除所有已存在的pod,重新創(chuàng)建新的; RollingUpdate：滾動升級，逐步替換的策略，同時滾動升級時，支持更多的附加參數(shù)，例如設置最大不可用pod數(shù)量，最小升級間隔時間等等。

deployment的常用命令 查看部署狀態(tài)

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

繼續(xù)升級

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:   
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個數(shù)在2-4個之間
      maxSurge: 1      #滾動升級時會先啟動1個pod
      maxUnavailable: 1 #滾動升級時允許的最大Unavailable的pod個數(shù)
  template:
    metadata:
      labels:
        app: review-demo
    spec:
      terminationGracePeriodSeconds: 60 ##k8s將會給應用發(fā)送SIGTERM信號，可以用來正確、優(yōu)雅地關閉應用,默認為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

幾個重要參數(shù)說明 maxSurge與maxUnavailable

maxSurge: 1 表示滾動升級時會先啟動1個pod
maxUnavailable: 1 表示滾動升級時允許的最大Unavailable的pod個數(shù)
由于replicas為3,則整個升級,pod個數(shù)在2-4個之間

terminationGracePeriodSeconds

k8s將會給應用發(fā)送SIGTERM信號，可以用來正確、優(yōu)雅地關閉應用,默認為30秒。

如果需要更優(yōu)雅地關閉，則可以使用k8s提供的pre-stop lifecycle hook 的配置聲明，將會在發(fā)送SIGTERM之前執(zhí)行。

livenessProbe與readinessProbe

livenessProbe是kubernetes認為該pod是存活的，不存在則需要kill掉，然后再新啟動一個，以達到replicas指定的個數(shù)。

readinessProbe是kubernetes認為該pod是啟動成功的，這里根據(jù)每個應用的特性，自己去判斷，可以執(zhí)行command，也可以進行httpGet。比如對于使用java web服務的應用來說，并不是簡單地說tomcat啟動成功就可以對外提供服務的，還需要等待spring容器初始化，數(shù)據(jù)庫連接連接上等等。對于spring boot應用，默認的actuator帶有/health接口，可以用來進行啟動成功的判斷。

其中readinessProbe.initialDelaySeconds可以設置為系統(tǒng)完全啟動起來所需的最少時間，livenessProbe.initialDelaySeconds可以設置為系統(tǒng)完全啟動起來所需的最大時間+若干秒。

這幾個參數(shù)配置好了之后，基本就可以實現(xiàn)近乎無縫地平滑升級了。對于使用服務發(fā)現(xiàn)的應用來說，readinessProbe可以去執(zhí)行命令，去查看是否在服務發(fā)現(xiàn)里頭應該注冊成功了，才算成功。

doc

【分享】幾種常見的不停機發(fā)布方式

Deployment vs ReplicationController in Kubernetes

kubernetes-user-guide-deployments

Kubernetes用戶指南（三）--在生產(chǎn)環(huán)境中使用Pod來工作、管理部署

Kubernetes livenessProbe shutdown during application startup

Kubernetes技術研究容器監(jiān)控監(jiān)測

Graceful shutdown of pods with Kubernetes

GPU云服務器云服務器 kubernetes使用 RollingUpdate 如何使用云服務器進行分配如何使用云服務器進行游戲

文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/32541.html

如何在Kubernetes中管理有狀態(tài)應用

摘要：在中，被用來管理有狀態(tài)應用的對象。并行管理并行管理告訴控制器以并行的方式啟動或者終止所有的。如果設置為，則控制器將會刪除和重建中的每一。在大部分的情況下，不會使用分隔當希望進行金絲雀發(fā)布，或者執(zhí)行階段發(fā)布時，分隔是很有用的。在Kubernetes中，StatefulSet被用來管理有狀態(tài)應用的API對象。StatefulSets在Kubernetes 1.9版本才穩(wěn)定。Statefu...

KaltZK 2019-07-01 16:43 評論0 收藏0
通過一個實際例子理解Kubernetes里pod的自動scale - 水平自動伸縮

摘要：命令用于程序在負載加重或縮小時進行擴容或縮小，我們通過一些實際例子來觀察命令到底能達到什么效果。 kubectl scale命令用于程序在負載加重或縮小時進行pod擴容或縮小，我們通過一些實際例子來觀察scale命令到底能達到什么效果。命令行創(chuàng)建一個deployment： kubectl run jerry-nginx --image=nginx:1.12.2 showImg(htt...

tinylcy 2019-07-01 17:34 評論0 收藏0
通過一個實際例子理解Kubernetes里pod的自動scale - 水平自動伸縮

摘要：命令用于程序在負載加重或縮小時進行擴容或縮小，我們通過一些實際例子來觀察命令到底能達到什么效果。 kubectl scale命令用于程序在負載加重或縮小時進行pod擴容或縮小，我們通過一些實際例子來觀察scale命令到底能達到什么效果。命令行創(chuàng)建一個deployment： kubectl run jerry-nginx --image=nginx:1.12.2 showImg(htt...

superw 2019-06-28 16:52 評論0 收藏0
通過一個實際例子理解Kubernetes里pod的自動scale - 水平自動伸縮

摘要：命令用于程序在負載加重或縮小時進行擴容或縮小，我們通過一些實際例子來觀察命令到底能達到什么效果。 kubectl scale命令用于程序在負載加重或縮小時進行pod擴容或縮小，我們通過一些實際例子來觀察scale命令到底能達到什么效果。命令行創(chuàng)建一個deployment： kubectl run jerry-nginx --image=nginx:1.12.2 showImg(htt...

Snailclimb 2019-07-01 16:55 評論0 收藏0
Docker 和 Kubernetes 從聽過到略懂：給程序員的旋風教程

摘要：默認監(jiān)聽在端口，所以我們把宿主機的端口映射到容器的端口用下面的命令可以看到正在運行中的容器這時如果你用瀏覽器訪問，就能看到我們剛才創(chuàng)建的頁面。這時如果刷新瀏覽器，就可以看到更新的內(nèi)容。早在 Docker 正式發(fā)布幾個月的時候，LeanCloud 就開始在生產(chǎn)環(huán)境大規(guī)模使用 Docker，在過去幾年里 Docker 的技術棧支撐了我們主要的后端架構。這是一篇寫給程序員的 Docker ...

jackzou 2019-06-28 16:32 評論0 收藏0