(部署)使用kubernetes的deployment进行RollingUpdate

时间 2019-11-09

标签部署使用 kubernetes deployment 进行 rollingupdate 繁體版

原文原文链接

rolling update，可使得服务近乎无缝地平滑升级，即在不中止对外服务的前提下完成应用的更新。html

replication controller与deployment的区别

replication controller

Replication Controller为Kubernetes的一个核心内容，应用托管到Kubernetes以后，须要保证应用可以持续的运行，Replication Controller就是这个保证的key，主要的功能以下：java

确保pod数量：它会确保Kubernetes中有指定数量的Pod在运行。若是少于指定数量的pod，Replication Controller会建立新的，反之则会删除掉多余的以保证Pod数量不变。web
确保pod健康：当pod不健康，运行出错或者没法提供服务时，Replication Controller也会杀死不健康的pod，从新建立新的。spring
弹性伸缩：在业务高峰或者低峰期的时候，能够经过Replication Controller动态的调整pod的数量来提升资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取Replication Controller关联pod的总体资源使用状况，作到自动伸缩。sql
滚动升级：滚动升级为一种平滑的升级方式，经过逐步替换的策略，保证总体系统的稳定，在初始化升级的时候就能够及时发现和解决问题，避免问题不断扩大。数据库

Deployment

Deployment一样为Kubernetes的一个核心内容，主要职责一样是为了保证pod的数量和健康，90%的功能与Replication Controller彻底同样，能够看作新一代的Replication Controller。可是，它又具有了Replication Controller以外的新特性：api

Replication Controller所有功能：Deployment继承了上面描述的Replication Controller所有功能。tomcat
事件和状态查看：能够查看Deployment的升级详细进度和状态。app
回滚：当升级pod镜像或者相关参数的时候发现问题，可使用回滚操做回滚到上一个稳定的版本或者指定的版本。ide
版本记录: 每一次对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能够去执行命令，去查看是否在服务发现里头应该注册成功了，才算成功。