rollout

K8S中五种控制器的介绍以及使⽤

⽬录

k8s的控制器类型

pod与控制器之间的关系

Deployment（⽆状态化应⽤）

状态与⽆状态化对特点

Deployment的更新

Deployment的回滚

CronJob控制器

总结

k8s的控制器类型

Kubernetes中内建了很多controller（控制器），这些相当于⼀个状态机，⽤来控制Pod的具体状态和⾏为

Deployment：适合⽆状态的服务部署

StatefullSet：适合有状态的服务部署

DaemonSet：⼀次部署，所有的node节点都会部署，例如⼀些典型的应⽤场景：

运⾏集群存储daemon，例如在每个Node上运⾏glusterd、ceph

在每个Node上运⾏⽇志收集daemon，例如fluentd、logstash

在每个Node上运⾏监控daemon，例如PrometheusNodeExporter

Job：⼀次性的执⾏任务

Cronjob：周期性的执⾏任务

总体来说，K8S有五种控制器，分别对应处理⽆状态应⽤、有状态应⽤、守护型应⽤和批处理应⽤

pod与控制器之间的关系

controllers：在集群上管理和运⾏容器的对象通过label-lector相关联

Pod通过控制器实现应⽤的运维，如伸缩，升级等

Deployment（⽆状态化应⽤）

应⽤场景：web服务

Deployment中⽂意思为部署、调度，通过Deployment我们能操作RS（ReplicaSet），你可以简单的理解为它是⼀种通过yml

⽂件的声明，在Deployment⽂件⾥可以定义Pod数量、更新⽅式、使⽤的镜像，资源限制等。⽆状态应⽤都⽤Deployment来

创建

通过Deployment对象，你可以轻松的做到以下事情：

创建ReplicaSet和Pod

滚动升级（不停⽌旧服务的状态下升级）和回滚应⽤（将应⽤回滚到之前的版本）

平滑地扩容和缩容

暂停和继续Deployment

Deployment创建

[root@mastershuai]#

apiVersion:apps/v1

kind:Deployment'定义是Deployment'

metadata:

name:nginx-deployment

labels:

app:nginx

spec:

replicas:3'副本数量为3'

lector:

matchLabels:

app:nginx

template:

metadata:

labels:

app:nginx

spec:

containers:

-name:nginx

image:nginx:1.15.4

ports:

-containerPort:80

'创建资源'

[root@mastershuai]#

/nginx-deploymentcreated

//Replicat是控制版本，副本数，回滚就是通过此来实现

'//查看所有资源'

[root@mastershuai]#kubectlgetall

NAMEREADYSTATUSRESTARTSAGE

pod/nginx-deployment-d55b94fd-cndf21/1Running03m31s

pod/nginx-deployment-d55b94fd-ghlwk1/1Running03m31s

pod/nginx-deployment-d55b94fd-tm4sw1/1Running03m31s

pod/pod-example1/1Running010h

NAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGE

rvice/kubernetesClusterIP10.0.0.1443/TCP3d6h

NAMEDESIREDCURRENTUP-TO-DATEAVAILABLEAGE

/nginx-deployment33333m31s

NAMEDESIREDCURRENTREADYAGE

/nginx-deployment-d55b94fd3333m31s

查看控制器信息

kubectldeitdeployment/nginx-deployment

.....省略信息.....

strategy:

rollingUpdate:'版本更新为滚动更新机制'

maxSurge:25%'最⼤更新副本数是25%，最多扩容125%''为了保持副本数量，增加的百分⽐同时要销毁多少'

maxUnavailable:25%'最⼤删除副本是25%，最多缩容到75%'

type:RollingUpdate

...省略信息....

'执⾏kubectldescribedeploynginx-deployment也可以查看'

....省略信息....

RollingUpdateStrategy:25%maxunavailable,25%maxsurge

查看历史版本

[root@mastershuai]#kubectlrollouthistorydeploy/nginx-deployment

ions/nginx-deployment

REVISIONCHANGE-CAUSE

1'//这边只有⼀个，证明还没有滚动更新'

状态与⽆状态化对特点

⽆状态服务的特点：

1）deployment认为所有的pod都是⼀样的

2）不⽤考虑顺序的要求

3）不⽤考虑在哪个node节点上运⾏

4）可以随意扩容和缩容

1）实例之间有差别，每个实例都有⾃⼰的独特性，元数据不同，例如etcd，zookeeper

2）实例之间不对等的关系，以及依靠外部存储的应⽤。

Deployment的更新

如果想要让nginxpod使⽤nginx:1.9.1的镜像来代替原来的nginx的镜像，运⾏以下命令

[root@master~]#kubectltimagedeployment/nginx-deploymentnginx=nginx:1.9.1

/nginx-deploymentimageupdated

或者我们可以使⽤edit命令来编辑Deployment，将image从nginx改写成nginx:1.9.1

kubectleditdeployment/nginx-deployment

查看更新进度

[root@master~]#kubectlrolloutstatusdeployment/nginx-deployment

Waitingfordeployment"nginx-deployment"rollouttofinish:1oldreplicasarependingtermination...

Waitingfordeployment"nginx-deployment"rollouttofinish:1oldreplicasarependingtermination...

deployment"nginx-deployment"successfullyrolledout

Deployment更新时会创建⼀个新的ReplicaSet，然后将新的ReplicaSet中的Pod慢慢扩容到指定的副本数，将旧的ReplicaSet

慢慢缩容到0。因此，更新时总能够确保旧的服务不会停⽌，这就是滚动更新。

Deployment的回滚

当我们像上⽂⼀样更新了Deployment之后，我们发现nginx:1.9.1的镜像不是很稳定，因此想要修改回nginx:1.7.9的版本，此

时我们不需要⼿动更改Deployment⽂件，⽽是利⽤Deployment的回滚功能。

使⽤rollouthistory命令查看Deployment的版本（revision）：

[root@master~]#kubectlrollouthistorydeployment/nginx-deployment

/nginx-deployment

REVISIONCHANGE-CAUSE

1kubectlcreate--filename=--record=true

2kubectlcreate--filename=--record=true

因为我们创建Deployment的时候使⽤了—recored参数可以记录命令，我们可以很⽅便的查看每次revison的变化。

查看单个revision的详细信息：

[root@master~]#kubectlrollouthistorydeployment/nginx-deployment--revision=2

/nginx-deploymentwithrevision#2

PodTemplate:

Labels:app=nginx

pod-template-hash=658d7f4b4b

Annotations:/change-cau:kubectlcreate--filename=--record=true

Containers:

nginx:

Image:nginx:1.9.1

Port:80/TCP

HostPort:0/TCP

Environment:

Mounts:

Volumes:

可以使⽤rolloutundo命令回滚到前⼀个revision

[root@master~]#kubectlrolloutundodeployment/nginx-deployment

/nginx-deploymentrolledback

[root@master~]#kubectldescribedeployment/nginx-deployment

Name:nginx-deployment

Namespace:default

CreationTimestamp:Fri,24Dec202122:24:10+0800

Labels:

Annotations:/revision:3

/change-cau:kubectlcreate--filename=--record=true

Selector:app=nginx

Replicas:3desired|3updated|3total|3available|0unavailable

StrategyType:RollingUpdate

MinReadySeconds:0

RollingUpdateStrategy:25%maxunavailable,25%maxsurge

PodTemplate:

Labels:app=nginx

Containers:

nginx:

Image:nginx

Port:80/TCP

HostPort:0/TCP

Environment:

Mounts:

Volumes:

也可以使⽤–to-revision参数指定某个历史版本：

[root@master~]#kubectlrolloutundodeployment/nginx-deployment--to-revision=2

/nginx-deploymentrolledback

[root@master~]#kubectldescribedeployment/nginx-deployment

Name:nginx-deployment

Namespace:default

CreationTimestamp:Fri,24Dec202122:24:10+0800

Labels:

Annotations:/revision:4

/change-cau:kubectlcreate--filename=--record=true

Selector:app=nginx

Replicas:3desired|3updated|4total|3available|1unavailable

StrategyType:RollingUpdate

MinReadySeconds:0

RollingUpdateStrategy:25%maxunavailable,25%maxsurge

PodTemplate:

Labels:app=nginx

Containers:

nginx:

Image:nginx:1.9.1

Port:80/TCP

HostPort:0/TCP

Environment:

Mounts:

Volumes:

你可以通过设置.nHistoryLimit项来指定deployment最多保留多少revison历史记录。默认的会保留所有的

revision；如果将该项设置为0，Deployment就不允许回退了。

只有Deployment的rollout被触发才会创建⼀个revision！注意！当且仅当Deployment的Podtemplate被更改，例如更新

template中的label和容器镜像时，才会触发⼀个rollout，从⽽为Deployment创建出⼀个新的revision。

rollout命令的更多⽤法：

history（查看历史版本）

pau（暂停Deployment）

resume（恢复暂停的Deployment）

status（查看资源状态）

undo（回滚版本）

JobController负责根据JobSpec创建Pod，并持续监控Pod的状态，直⾄其成功结束。如果失败，则根据restartPolicy（只⽀

持OnFailure和Never，不⽀持Always）决定是否创建新的Pod再次重试任务。

Job负责批量处理短暂的⼀次性任务(shortlivedone-offtasks)，即仅执⾏⼀次的任务，它保证批处理任务的⼀个或多个Pod成

功结束。

Kubernetes⽀持以下⼏种Job：

⾮并⾏Job：通常创建⼀个Pod直⾄其成功结束

固定结束次数的Job：设置.tions，创建多个Pod，直到.tions个Pod成功结束

带有⼯作队列的并⾏Job：设置.elism但不设置.tions，当所有Pod结束并且⾄少⼀个成功

时，Job就认为是成功

根据.tions和.elism的设置，可以将Job划分为以下⼏种pattern

JOB类型使⽤实例⾏为completionsparallelism

⼀次性Job数据库迁移创建⼀个Pod直⾄其成功结束11

固定结束次数的Job处理⼯作队列的Pod

依次创建⼀个Pod运⾏直⾄completions个成功结

束

2+1

固定结束次数的并⾏

Job

多个Pod同时处理⼯作队

列

依次创建多个Pod运⾏直⾄completions个成功结

束

2+2+

并⾏Job

多个Pod同时处理⼯作队

列

创建⼀个或多个Pod直⾄有⼀个成功结束12+

.job的使⽤

[root@master~]#

---

apiVersion:batch/v1

kind:Job

metadata:

name:myjob

spec:

template:

spec:

containers:

-name:myjob

image:busybox

command:["echo","hellok8sjob"]

restartPolicy:Never

[root@master~]#

/myjobcreated

[root@master~]#kubectlgetpods

NAMEREADYSTATUSRESTARTSAGE

myjob-gq27p0/1Completed037s

#查看这个pod的任务

[root@master~]#kubectlgetjob

NAMECOMPLETIONSDURATIONAGE

myjob1/119s5m11s

#查看这个pod的⽇志

[root@master~]#kubectllogsmyjob-gq27p

hellok8sjob

CronJob控制器

CronJob可以⽤来执⾏基于时间计划的定时任务，类似于Linux/Unix系统中的crontable(opensnewwindow)。

CronJob执⾏周期性的重复任务时⾮常有⽤，例如备份数据、发送邮件等。CronJob也可以⽤来指定将来某个时间点执⾏单

个任务，例如将某项任务定时到系统负载⽐较低的时候执⾏。

⼀个CronJob对象就像crontab(crontable)⽂件中的⼀⾏。它⽤Cron格式进⾏编写，并周期性地在给定的调度时间执⾏

Job。

注意：

所有CronJob的schedule:时间都是基于kube-controller-manager.的时区。

如果你的控制平⾯在Pod或是裸容器中运⾏了kube-controller-manager，那么为该容器所设置的时区将会决定Cron

Job的控制器所使⽤的时区。

为CronJob资源创建清单时，请确保所提供的名称是⼀个合法的DNS⼦域名.名称不能超过52个字符。这是因为

CronJob控制器将⾃动在提供的Job名称后附加11个字符，并且存在⼀个限制，即Job名称的最⼤长度不能超过63

个字符。

CronJob⽤于执⾏周期性的动作，例如备份、报告⽣成等。这些任务中的每⼀个都应该配置为周期性重复的（例如：每

天/每周/每⽉⼀次）；你可以定义任务开始执⾏的时间间隔。

下⾯的CronJob⽰例清单会在每分钟打印出当前时间和问候消息：

[root@masterkubenetres]#

---

apiVersion:batch/v1beta1

kind:CronJob

metadata:

name:hello

spec:

schedule:"*/1****"

jobTemplate:

spec:

template:

spec:

containers:

-name:hello

image:busybox

imagePullPolicy:IfNotPrent

command:

-/bin/sh

--c

-date;echoHellonihao

restartPolicy:OnFailure

创建pod查看

[root@master~]#

Warning:batch/v1beta1CronJobisdeprecatedinv1.21+,unavailableinv1.25+;ubatch/v1CronJob

/hellocreated

#等⼀分钟查看

[root@master~]#kubectlgetpods

NAMEREADYSTATUSRESTARTSAGE

hello-27339330-kkfxv0/1Completed02s

#查看⽇志

[root@master~]#kubectllogshello-27339330-kkfxv

FriDec2415:30:00UTC2021

Hellonihao

总结

到此这篇关于K8S中五种控制器及使⽤的⽂章就介绍到这了,更多相关K8S控制器使⽤内容请搜索以前的⽂章或继续浏览下⾯

的相关⽂章希望⼤家以后多多⽀持！