使用kubernetes的deployment进行RollingUpdate
序
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 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可以设置为系统完全启动起来所需的最大时间+若干秒。
本文转自SegmentFault- 使用kubernetes的deployment进行RollingUpdate这几个参数配置好了之后,基本就可以实现近乎无缝地平滑升级了。对于使用服务发现的应用来说,readinessProbe可以去执行命令,去查看是否在服务发现里头应该注册成功了,才算成功。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Kubelet源码分析(一):启动流程分析
源码版本 kubernetes version: v1.3.0 简介 在Kubernetes急群众,在每个Node节点上都会启动 一个kubelet服务进程。该进程用于处理Master节点下发到本节点的任务,管理Pod及Pod中的容器。每个Kubelet进程会在APIServer上注册节点自身信息,定期向Master节点汇报节点资源的使用情况,并通过cAdvise监控容器和节点资源。 关键结构 KubeletConfiguration type KubeletConfiguration struct { // kubelet的参数配置文件 Config string `json:"config"` // kubelet支持三种源数据: // 1. ApiServer: kubelet通过ApiServer监听etcd目录,同步Pod清单 // 2. file: 通过kubelet启动参数"--config"指定配置文件目录下的文件 // 3. http URL: 通过"--manifest-url"参数设置 // 所以下面会有三种同步的频率配置 // 同步容器和配置的频率。 SyncF...
- 下一篇
大家都较熟悉之 Kubernetes API 分析
Kubernetes概览 以下是 k8s 的整体架构,在 master 节点上主 要是 kube-apiserver(整合了 kube-aggregator),还有 kube-scheduler,以及 kube-controller-manager,包括后端存储 etcd。 其中 kube-apiserver 是一个比较关键的部分,而且前期写得坑很多,导致这一部分虽然看起来是一个 API server 其实代码很复杂,特别冗余,而且目前对 kube-apiserver 还要做拆分,能够支持插入第三方的 apiserver,也就是又一个 aggregated apiserver 的 feature,也是和 kube-apiserver 和里面包的一层 genericserver 揉合在一起了,感觉一个大的系统 API server 越写越挫是一个通病,还好现在 k8s 迷途知返正在调整。 kube-apiserver Kube-apiserver 可以是认为在 generic server 上封装的一层官方默认的 apiserver,有第三方需要的情况下,自己也可以在 generic s...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker安装Oracle12C,快速搭建Oracle学习环境
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2全家桶,快速入门学习开发网站教程
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7,8上快速安装Gitea,搭建Git服务器