资讯专栏INFORMATION COLUMN

使用kubernetes的deployment进行RollingUpdate

Lycheeee / 2043人阅读

摘要:序,可以使得服务近乎无缝地平滑升级,即在不停止对外服务的前提下完成应用的更新。如果少于指定数量的,会创建新的,反之则会删除掉多余的以保证数量不变。对于应用,默认的带有接口,可以用来进行启动成功的判断。

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的常用命令 查看部署状态

</>复制代码

  1. kubectl rollout status deployment/review-demo --namespace=scm
  2. kubectl describe deployment/review-demo --namespace=scm

或者这种写法

</>复制代码

  1. kubectl rollout status deployments review-demo --namespace=scm
  2. kubectl describe deployments review-demo --namespace=scm
升级

</>复制代码

  1. kubectl set image deployment/review-demo review-demo=library/review-demo:0.0.1 --namespace=scm

或者

</>复制代码

  1. kubectl edit deployment/review-demo --namespace=scm

编辑.spec.template.spec.containers[0].image的值

终止升级

</>复制代码

  1. kubectl rollout pause deployment/review-demo --namespace=scm
继续升级

</>复制代码

  1. kubectl rollout resume deployment/review-demo --namespace=scm
回滚

</>复制代码

  1. kubectl rollout undo deployment/review-demo --namespace=scm
查看deployments版本

</>复制代码

  1. kubectl rollout history deployments --namespace=scm

回滚到指定版本

</>复制代码

  1. kubectl rollout undo deployment/review-demo --to-revision=2 --namespace=scm
升级历史

</>复制代码

  1. kubectl describe deployment/review-demo --namespace=scm
  2. Name: review-demo
  3. Namespace: scm
  4. CreationTimestamp: Tue, 31 Jan 2017 16:42:01 +0800
  5. Labels: app=review-demo
  6. Selector: app=review-demo
  7. Replicas: 3 updated | 3 total | 3 available | 0 unavailable
  8. StrategyType: RollingUpdate
  9. MinReadySeconds: 0
  10. RollingUpdateStrategy: 1 max unavailable, 1 max surge
  11. OldReplicaSets:
  12. NewReplicaSet: review-demo-2741031620 (3/3 replicas created)
  13. Events:
  14. FirstSeen LastSeen Count From SubobjectPath Type Reason Message
  15. --------- -------- ----- ---- ------------- -------- ------ -------
  16. 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 1
  17. 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 2
  18. 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 2
  19. 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 1
  20. 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620 to 3
  21. 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649 to 0
deployment文件

</>复制代码

  1. apiVersion: extensions/v1beta1
  2. kind: Deployment
  3. metadata:
  4. name: review-demo
  5. namespace: scm
  6. labels:
  7. app: review-demo
  8. spec:
  9. replicas: 3
  10. # minReadySeconds: 60 #滚动升级时60s后认为该pod就绪
  11. strategy:
  12. rollingUpdate: ##由于replicas为3,则整个升级,pod个数在2-4个之间
  13. maxSurge: 1 #滚动升级时会先启动1个pod
  14. maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
  15. template:
  16. metadata:
  17. labels:
  18. app: review-demo
  19. spec:
  20. terminationGracePeriodSeconds: 60 ##k8s将会给应用发送SIGTERM信号,可以用来正确、优雅地关闭应用,默认为30秒
  21. containers:
  22. - name: review-demo
  23. image: library/review-demo:0.0.1-SNAPSHOT
  24. imagePullPolicy: IfNotPresent
  25. livenessProbe: #kubernetes认为该pod是存活的,不存活则需要重启
  26. httpGet:
  27. path: /health
  28. port: 8080
  29. scheme: HTTP
  30. initialDelaySeconds: 60 ## equals to the maximum startup time of the application + couple of seconds
  31. timeoutSeconds: 5
  32. successThreshold: 1
  33. failureThreshold: 5
  34. readinessProbe: #kubernetes认为该pod是启动成功的
  35. httpGet:
  36. path: /health
  37. port: 8080
  38. scheme: HTTP
  39. initialDelaySeconds: 30 ## equals to minimum startup time of the application
  40. timeoutSeconds: 5
  41. successThreshold: 1
  42. failureThreshold: 5
  43. resources:
  44. # keep request = limit to keep this container in guaranteed class
  45. requests:
  46. cpu: 50m
  47. memory: 200Mi
  48. limits:
  49. cpu: 500m
  50. memory: 500Mi
  51. env:
  52. - name: PROFILE
  53. value: "test"
  54. ports:
  55. - name: http
  56. 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可以设置为系统完全启动起来所需的最大时间+若干秒。

</>复制代码

  1. 这几个参数配置好了之后,基本就可以实现近乎无缝地平滑升级了。对于使用服务发现的应用来说,readinessProbe可以去执行命令,去查看是否在服务发现里头应该注册成功了,才算成功。

doc

【分享】几种常见的不停机发布方式

Deployment vs ReplicationController in Kubernetes

kubernetes-user-guide-deployments

Kubernetes用户指南(三)--在生产环境中使用Pod来工作、管理部署

Kubernetes livenessProbe shutdown during application startup

Kubernetes技术研究容器监控监测

Graceful shutdown of pods with Kubernetes

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/32541.html

相关文章

  • 如何在Kubernetes中管理有状态应用

    摘要:在中,被用来管理有状态应用的对象。并行管理并行管理告诉控制器以并行的方式启动或者终止所有的。如果设置为,则控制器将会删除和重建中的每一。在大部分的情况下,不会使用分隔当希望进行金丝雀发布,或者执行阶段发布时,分隔是很有用的。 在Kubernetes中,StatefulSet被用来管理有状态应用的API对象。StatefulSets在Kubernetes 1.9版本才稳定。Statefu...

    KaltZK 评论0 收藏0
  • 通过一个实际例子理解Kubernetes里pod自动scale - 水平自动伸缩

    摘要:命令用于程序在负载加重或缩小时进行扩容或缩小,我们通过一些实际例子来观察命令到底能达到什么效果。 kubectl scale命令用于程序在负载加重或缩小时进行pod扩容或缩小,我们通过一些实际例子来观察scale命令到底能达到什么效果。 命令行创建一个deployment: kubectl run jerry-nginx --image=nginx:1.12.2 showImg(htt...

    tinylcy 评论0 收藏0
  • 通过一个实际例子理解Kubernetes里pod自动scale - 水平自动伸缩

    摘要:命令用于程序在负载加重或缩小时进行扩容或缩小,我们通过一些实际例子来观察命令到底能达到什么效果。 kubectl scale命令用于程序在负载加重或缩小时进行pod扩容或缩小,我们通过一些实际例子来观察scale命令到底能达到什么效果。 命令行创建一个deployment: kubectl run jerry-nginx --image=nginx:1.12.2 showImg(htt...

    superw 评论0 收藏0
  • 通过一个实际例子理解Kubernetes里pod自动scale - 水平自动伸缩

    摘要:命令用于程序在负载加重或缩小时进行扩容或缩小,我们通过一些实际例子来观察命令到底能达到什么效果。 kubectl scale命令用于程序在负载加重或缩小时进行pod扩容或缩小,我们通过一些实际例子来观察scale命令到底能达到什么效果。 命令行创建一个deployment: kubectl run jerry-nginx --image=nginx:1.12.2 showImg(htt...

    Snailclimb 评论0 收藏0
  • Docker 和 Kubernetes 从听过到略懂:给程序员旋风教程

    摘要:默认监听在端口,所以我们把宿主机的端口映射到容器的端口用下面的命令可以看到正在运行中的容器这时如果你用浏览器访问,就能看到我们刚才创建的页面。这时如果刷新浏览器,就可以看到更新的内容。 早在 Docker 正式发布几个月的时候,LeanCloud 就开始在生产环境大规模使用 Docker,在过去几年里 Docker 的技术栈支撑了我们主要的后端架构。这是一篇写给程序员的 Docker ...

    jackzou 评论0 收藏0

发表评论

0条评论

Lycheeee

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<