Kubernetes Deployment滚动升级
我们k8s集群使用的是1.7.7版本的,该版本中官方已经推荐使用Deployment代替Replication Controller(rc)了,Deployment继承了rc的全部功能外,还可以查看升级详细进度和状态,当升级出现问题的时候,可以使用回滚操作回滚到指定的版本,每一次对Deployment的操作,都会保存下来,变能方便的进行回滚操作了,另外对于每一次升级都可以随时暂停和启动,拥有多种升级方案:Recreate删除现在的Pod,重新创建;RollingUpdate滚动升级,逐步替换现有Pod,对于生产环境的服务升级,显然这是一种最好的方式。
创建Deployment
可以看出一个Deployment拥有多个Replica Set,而一个Replica Set拥有一个或多个Pod。一个Deployment控制多个rs主要是为了支持回滚机制,每当Deployment操作时,Kubernetes会重新生成一个Replica Set并保留,以后有需要的话就可以回滚至之前的状态。 下面创建一个Deployment,它创建了一个Replica Set来启动3个nginx pod,yaml文件如下:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deploy
labels:
k8s-app: nginx-demo
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
将上面内容保存为: nginx-deployment.yaml,执行命令:
$ kubectl create -f nginx-deployment.yaml
deployment "nginx-deploy" created
然后执行一下命令查看刚刚创建的Deployment:
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deploy 3 0 0 0 1s
隔一会再次执行上面命令:
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deploy 3 3 3 3 4m
我们可以看到Deployment已经创建了3个Replica Set了,执行下面的命令查看rs和pod:
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deploy-431080787 3 3 3 6m
$ kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deploy-431080787-53z8q 1/1 Running 0 7m app=nginx,pod-template-hash=431080787
nginx-deploy-431080787-bhhq0 1/1 Running 0 7m app=nginx,pod-template-hash=431080787
nginx-deploy-431080787-sr44p 1/1 Running 0 7m app=nginx,pod-template-hash=431080787
上面的Deployment的yaml文件中的replicas:3将会保证我们始终有3个POD在运行。
滚动升级Deployment
现在我们将刚刚保存的yaml文件中的nginx镜像修改为nginx:1.13.3,然后在spec下面添加滚动升级策略:
minReadySeconds: 5
strategy:
# indicate which strategy we want for rolling update
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
- minReadySeconds:
- Kubernetes在等待设置的时间后才进行升级
- 如果没有设置该值,Kubernetes会假设该容器启动起来后就提供服务了
- 如果没有设置该值,在某些极端情况下可能会造成服务服务正常运行
- maxSurge:
- 升级过程中最多可以比原先设置多出的POD数量
- 例如:maxSurage=1,replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD,整个升级过程中最多会有5+1个POD。
- maxUnavaible:
- 升级过程中最多有多少个POD处于无法提供服务的状态
- 当
maxSurge不为0时,该值也不能为0 - 例如:maxUnavaible=1,则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态。
然后执行命令:
$ kubectl apply -f nginx-deployment.yaml
deployment "nginx-deploy" configured
然后我们可以使用rollout命令:
查看状态:
$ kubectl rollout status deployment/nginx-deploy
Waiting for rollout to finish: 1 out of 3 new replicas have been updated..
deployment "nginx-deploy" successfully rolled out
暂停升级
$ kubectl rollout pause deployment <deployment>
继续升级
$ kubectl rollout resume deployment <deployment>
升级结束后,继续查看rs的状态:
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deploy-2078889897 0 0 0 47m
nginx-deploy-3297445372 3 3 3 42m
nginx-deploy-431080787 0 0 0 1h
根据AGE我们可以看到离我们最近的当前状态是:3,和我们的yaml文件是一致的,证明升级成功了。用describe命令可以查看升级的全部信息:
Name: nginx-deploy
Namespace: default
CreationTimestamp: Wed, 18 Oct 2017 16:58:52 +0800
Labels: k8s-app=nginx-demo
Annotations: deployment.kubernetes.io/revision=3
kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1beta1","kind":"Deployment","metadata":{"annotations":{},"labels":{"k8s-app":"nginx-demo"},"name":"nginx-deploy","namespace":"defa...
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.13.3
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Progressing True NewReplicaSetAvailable
Available True MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deploy-3297445372 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
50m 50m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-2078889897 to 1
45m 45m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-2078889897 to 0
45m 45m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 1
39m 39m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 2
39m 39m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 2
38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 1
38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled up replica set nginx-deploy-3297445372 to 3
38m 38m 1 deployment-controller Normal ScalingReplicaSet Scaled down replica set nginx-deploy-431080787 to 0
回滚Deployment
我们已经能够滚动平滑的升级我们的Deployment了,但是如果升级后的POD出了问题该怎么办?我们能够想到的最好最快的方式当然是回退到上一次能够提供正常工作的版本,Deployment就为我们提供了回滚机制。
首先,查看Deployment的升级历史:
$ kubectl rollout history deployment nginx-deploy
deployments "nginx-deploy"
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 kubectl apply --filename=Desktop/nginx-deployment.yaml --record=true
从上面的结果可以看出在执行Deployment升级的时候最好带上record参数,便于我们查看历史版本信息。同样我们可以使用下面的命令查看单个REVISION的信息:
$ kubectl rollout history deployment nginx-deploy --revision=3
deployments "nginx-deploy" with revision #3
Pod Template:
Labels: app=nginx
pod-template-hash=3297445372
Annotations: kubernetes.io/change-cause=kubectl apply --filename=nginx-deployment.yaml --record=true
Containers:
nginx:
Image: nginx:1.13.3
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
假如现在要直接回退到当前版本的前一个版本:
$ kubectl rollout undo deployment nginx-deploy
deployment "nginx-deploy" rolled back
当然也可以用revision回退到指定的版本:
$ kubectl rollout undo deployment nginx-deploy --to-revision=2
deployment "nginx-deploy" rolled back
现在可以用命令查看Deployment现在的状态了。
注意清除机制
前面在用apply命令滚动升级Deployment后,无意间在Dashboard中发现了Replica Sets下面有很多Pods为0/0的RS,由于本人有轻微的强迫症,眼里是容不下0/0这种东西的,然后就给删除了,结果后面更新的时候又出现了,以为是yaml脚本有误,结果到现在才清楚这个是用于Deployment回滚用的,不能随便删除的(感觉自己就是个棒槌啊~~~)。
Kubernetes默认是会将Deployments的每次改动操作生成一个新的RS,并保存下来的。不过你可以设置参数.spec.revisonHistoryLimit来来指定Deployment最多保留多少revision 历史记录。如果将该项设置为0,Deployment就不允许回退了。
参考文档
- http://kubernetes.io/docs/user-guide/deployments/
- http://kubernetes.io/docs/user-guide/kubectl/kubectl_rollout_history/
- http://kubernetes.io/docs/user-guide/kubectl/kubectl_rolling-update/
Kubernetes Deployment滚动升级的更多相关文章
- kubernetes之deployment滚动升级
参考:https://blog.51cto.com/wutengfei/2116663 创建和管理多个Pod--Deployment Deployment 为 Pod 和 ReplicaSet 提供了 ...
- k8s的Deployment 滚动升级
首先定义一个Deployment,并创建它 apiVersion: apps/v1beta1 kind: Deployment metadata: name: house-live spec: rep ...
- Kubernetes Deployment与Replica Set
Deployment相对于RC的优势 RS与Deployment主要用于替代RC.RS的全称为Replica Set.相对于RC,RS与Deployment的优势如下: RC只支持基于等式的selec ...
- 入门Kubernetes - 滚动升级/回滚
一.前言 上一篇文章中对yaml文件格式进行了解,并对k8s中各种主要资源通过yaml创建时的定义模板.接来下就进一步学习k8s的各种特点.并应用在示例中. 接下来先实现.Net Core Api程序 ...
- kubernetes云平台管理实战: 滚动升级秒级回滚(六)
一.nginx保证有两个版本 1.查看当前容器运行nginx版本 [root@k8s-master ~]# kubectl get pod -o wide NAME READY STATUS REST ...
- k8s滚动升级
为了服务升级过程中提供可持续的不中断的服务,Kubernetes 提供了rolling update机制,具体配置需要修改对应服务的yaml文件 参数解析: minReadySeconds: 100 ...
- kubernetes集群升级的正确姿势
kubernetes社区非常活跃,每季度都会发布一个release.但是线上集群业务可用性要求较高,场景复杂,任何微小的变更都需要非常小心,此时跟随社区版本进行升级略显吃力.但是为了能够使用到最新的一 ...
- Kubernetes Deployment(部署无状态应用)
Kubernetes Deployment(部署无状态应用) Pod与controllers的关系 • controllers:在集群上管理和运行容器的对象 • 通过label-selector相关联 ...
- kubernetes Pod的升级与回滚
一:Deployment的升级 1.通过kubectl set image命令为Deployment设置新的镜像名称kubectl set image deployment/nginx-deploym ...
随机推荐
- VLP16线用户手册.md
VLP16线用户手册 文档 传感器数据 分组类型和定义 传感器产生两种类型的数据包:数据包和位置数据包.位置包有时也被称为遥测包或GPS包. 数据包包括传感器测量到的三维数据以及返回光脉冲的表面的校 ...
- 日本IT行业劳动力缺口达22万 在日中国留学生迎来就业好时机 2017/07/18 11:25:09
作者:倪亚敏 来源:日本新华侨报 发布时间:2017/07/18 11:25:09 据日本政府提供的数据,日本2018年应届毕业生的“求人倍率”已经达到了1.78倍.换言之,就是100名大学生 ...
- 亚马逊拟斥资15亿美元建航空货运中心 - Amazon to spend $1.49 bln on air cargo hub, fans talk of bigger ambitions - ReutersFebruary 1, 2017
2月1日消息,亚马逊本周二宣布将在肯塔基州开建其第一个航空货运中心,以应对高速增长的航空货运需求.亚马逊预计,该项目将带来2000个工作岗位. 据悉,该项计划总投入约为15亿美元,亚马逊或可从当地政府 ...
- WCF传送大数据时的错误“ 超出最大字符串内容长度配额”
格式化程序尝试对消息反序列化时引发异常: 尝试对参数 http://tempuri.org/ 进行反序列化时出错: GetLzdtArticleResult.InnerException 消息是“反序 ...
- "感应锁屏"Alpha版使用说明
“感应锁屏”Alpha版使用说明 一.产品介绍 感应锁屏是锁屏软件的一大创新.相比传统的锁屏软件,“感应锁屏”从可操作性.方便性.功能全面性都有了很大的提升,可以让用户方便快捷的进行锁屏操作. “感应 ...
- 解决Ubuntu16.04 fatal error: json/json.h: No such file or directory
参考博客 错误产生 安装json-c库之后,根据GitHub上面的readme文件链接到json-c库时出现以下错误: SDMBNJson.h:9:23: fatal error: json/json ...
- C++ Primer Plus学习:第八章
C++入门第八章:函数探幽 本章将介绍C++语言区别于C语言的新特性.包括内联函数.按引用传递变量.默认的参数值.函数重载以及函数模板. 1 C++内联函数 内联函数是C++为提高程序运行速度所做的一 ...
- 浅析GCC下C++多重继承 & 虚拟继承的对象内存布局
继承是C++作为OOD程序设计语言的三大特征(封装,继承,多态)之一,单一非多态继承是比较好理解的,本文主要讲解GCC环境下的多重继承和虚拟继承的对象内存布局. 一.多重继承 先看几个类的定义: 01 ...
- OpenLayers 3 入门教程
OpenLayers 3 入门教程摘要OpenLayers 3对OpenLayers网络地图库进行了根本的重新设计.版本2虽然被广泛使用,但从JavaScript开发的早期发展阶段开始,已日益现实出它 ...
- Redis的sentinel机制(sentinel节点IP为:192.168.23.10) “哨兵”
万一主节点打击,主从模型将会停止工作,为了解决这个问题,Redis提供了一个sentinel(哨兵),以此来实现主从切换的功能,一旦主节点宕机了,sentinel将会在从节点中挑一个作为主节点.与zo ...