k8s使用deployment升级
概念
Deployment(中文意思为部署、调度)提供了一种更加简单的更新RC和Pod的机制,K8S版本1.2实现的。通过在Deployment中描述所期望的集群状态,Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成所期望的集群状态。Deployment主要职责同样是为了保证pod的数量和健康,90%的功能与RC完全一样,可以看做新一代的RC。
功能
Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务,恢复上线 任务,回滚到以前某一版本(成功/稳定)的Deployment等功能,在某种程度上,Deployment可以实现无人值守的上线,大大降低上线过程的复杂沟通、操作风险。
RC全部功能:Deployment继承了RC全部功能。
事件和状态查看:可以查看Deployment的升级详细进度和状态。
回滚:当升级pod镜像或者相关参数时发现问题,可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。
版本记录:每次对Deployment的操作,都能保存下来,给予后续可能的回滚使用。
暂停和启动:对于每一次升级,都能够随时暂停和启动。
多种升级方案:Recreate--删除所有已存在的pod,重新创建新的; RollingUpdate--滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。
使用场景
使用Deployment来启动(上线/部署)一个Pod或者RS
检查一个Deployment是否成功执行
更新Deployment来重新创建相应的Pods(例如,需要使用一个新的Image)
如果现有的Deployment不稳定,那么回滚到一个早期的稳定的Deployment版本
暂停或者恢复一个Deployment
与RC比较,deployment的优势
Deployment使用了RS,它是更高一层的概念。
RC只支持基于等式的selector(env=dev或environment!=qa),但RS还支持新的,基于集合的selector(version in (v1.0, v2.0)或env notin (dev, qa)),这对复杂的运维管理很方便。
使用Deployment升级Pod,只需要定义Pod的最终状态,K8S会为你执行必要的操作,虽然能够使用命令kubectl rolling-update完成升级,但它是在客户端与服务端多次交互控制RC完成的,所以REST API中并没有rolling-update的接口,这为定制自己的管理系统带来了一些麻烦。
Deployment拥有更加灵活强大的升级、回滚功能。
常用命令
创建
使用子命令create,创建Deployment
kubectl create -f test-dpm.yaml --record
注意--record参数,使用此参数将记录后续创建对象的操作,方便管理与问题追溯
查看部署状态
kubectl rolloutstatus deployment/lykops-dpm
kubectl describe deployment/lykops-dpm
升级
kubectl set image deployment/lykops-dpm lykops-dpm=app:v1
或者使用子命令edit,编辑spec.replicas/spec.template.spec.container.image字段,完成deployment的扩缩容与滚动升级(这要比子命令rolling-update速度快很多)
暂定升级
kubectl rolloutpause deployment/lykops-dpm
继续升级
kubectl rolloutresume deployment/lykops-dpm
回滚
kubectl rolloutundo deployment/lykops-dpm
查看deployments版本
kubectl rollouthistory deployments
回滚到指定版本
kubectl rolloutundo deployment/lykops-dpm --to-revision=2
升级历史
kubectl describedeployment/lykops-dpm
Name: lykops-dpm
Namespace: default
CreationTimestamp: Tue, 01 Aug 2017 16:56:45 +0800
Labels: app=lykops-dpm
project=lykops
software=apache
version=v1
Selector: app=lykops-dpm,name=lykops-dpm,project=lykops,software=apache,version=v1
Replicas: 3updated | 3 total | 3 available | 0 unavailable
StrategyType: Recreate
MinReadySeconds: 30
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet: lykops-dpm-4183418831 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaledup replica set lykops-dpm-2823415590 to 3
28m 28m 1 {deployment-controller } Normal ScalingReplicaSet Scaleddown replica set lykops-dpm-2823415590 to 0
28m 28m 1 {deployment-controller } Normal ScalingReplicaSet Scaledup replica set lykops-dpm-4001949646 to 3
26m 26m 1 {deployment-controller } Normal ScalingReplicaSet Scaleddown replica set lykops-dpm-4001949646 to 0
26m 26m 1 {deployment-controller } Normal ScalingReplicaSet Scaledup replica set lykops-dpm-4183418831 to 3
例子
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: lykops-dpm
labels:
software: apache
project: lykops
app: lykops-dpm
version: v1
spec:
replicas: 3 #副本数量
minReadySeconds: 30 #滚动升级时,容器准备就绪时间最少为30s
strategy:
type: recreate #升级方式
#rollingUpdate:##由于replicas为3,则整个升级,pod个数在2-4个之间
# maxSurge: 3 #滚动升级时会先启动3个pod
# maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数
selector:
matchLabels:
name: lykops-dpm
software: apache
project: lykops
app: lykops-dpm
version: v1
template:
metadata:
labels:
name: lykops-dpm
software: apache
project: lykops
app: lykops-dpm
version: v1
spec:
terminationGracePeriodSeconds: 60 ##k8s将会给应用发送SIGTERM信号,可以用来正确、优雅地关闭应用,默认为30秒
containers:
- name: lykops-dpm
image: web:apache
command: [ "sh", "/etc/run.sh" ]
ports:
- containerPort: 80
name: http
protocol: TCP
resources:
requests:
cpu: 0.05
memory: 16Mi
limits:
cpu: 0.1
memory: 32Mi
livenessProbe:#livenessProbe是K8S认为该pod是存活的,不存在则需要kill掉,然后再新启动一个,以达到RS指定的个数。
httpGet:
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe:#readinessProbe是K8S认为该pod是启动成功的,这里根据每个应用的特性,自己去判断,可以执行command,也可以进行httpGet。
httpGet:
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
参数说明
strategy中的type
升级策略有recreate和rollingUpdate。recreate--删除所有已存在的pod,重新创建新的; rollingUpdate--滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。
如何使用哪种策略,需要看应用场景。recreate策略将会在升级过程中,停止服务,但会保证应用版本一致;使用rollingUpdate不会中断服务,但会导致调用时出现应用版本不一致的情况,输出内容不一致。
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是K8S认为该pod是存活的,不存在则需要kill掉,然后再新启动一个,以达到RS指定的个数。
readinessProbe是K8S认为该pod是启动成功的,这里根据每个应用的特性,自己去判断,可以执行command,也可以进行httpGet。比如对于使用java web服务的应用来说,并不是简单地说tomcat启动成功就可以对外提供服务的,还需要等待spring容器初始化,数据库连接连接上等等。对于spring boot应用,默认的actuator带有/health接口,可以用来进行启动成功的判断。
其中readinessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最少时间,livenessProbe.initialDelaySeconds可以设置为系统完全启动起来所需的最大时间+若干秒。
本文转自CSDN-k8s使用deployment升级
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
K8s(Kubernetes)架构学习笔记
K8s满足的需求 K8s的主要职责是容器编排(Container Orchestration),即在一组服务器上启动、监控、回收容器,在满足排程的同时,保证容器可以健康的运行。 K8s架构的概念/术语 学习K8s架构之前,需要了解一些K8s特有的概念: Cluster 集群 K8s可利用的主机、存储和网络资源的集合。 Node 结点 单台主机,可以是物理的或虚拟的计算机。结点分为主结点(master)和工 作结点(worker)。 Pod K8s中的工作单元,K8s是以Pod而非容器为单位排程的。Pod可以理解为Docker单机环境,每个Pod中包含一至多个容器,总是被启动在一个结点;一个Pod的容器在K8s集群中有相同的地址和端口范围,即容器暴露于K8s集群的端口号不可重复。 K8s架构概览 K8s集群由主结点和工作结点两类结点构成。其中主结点上运行着K8s Control Plane,控制并管理着整个K8s系统;工作结点上运行用户实际部署到K8s应用。 K8s的结点上运行着一些组件,共同协作以完成容器编排,其中主要的组件有: etcd 一款开源软件。提供可靠的分布式数据存储服务,用...
- 下一篇
在 k8s 中部署 Prometheus
k8s 的监控 k8s 默认以及推荐的监控体系是它自己的一套东西:Heapster + cAdvisor + Influxdb + Grafana,具体可以看 这里 。 包括 k8s 自身的 HPA (Horizontal Pod Autoscaler),默认从 Heapster 中获取数据 进行自动伸缩。(顺便提一句,当你部署完 k8s 集群之后,如果从 Dashboard 中看不到监控数据,往往就是因为你没有部署 Heapster,或者网络层有问题, Dashboard 无法访问 Heapster。) 那,这跟我们介绍的 Prometheus 有什么关系? 首先,它们都是一套监控解决方案,而 k8s 没有把 Prometheus 作为默认监控,因此,如果你想直接使用 HPA,你还是需要部署 Heapster。 其次,kubelet 中的 cAdvisor 其实是支持 Prometheus 作为存储的后端的,只是相对于 Prometheus 自己的 SD 解决方案来说,太弱了点。 最后,k8s 1.6 之后,在 annotations 中配置 custom metrics 的方式已经...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Docker安装Oracle12C,快速搭建Oracle学习环境