【云原生】加强理解Pod资源控制器？pod资源限制

Pod控制器

文章目录

什么是Pod Controller 1、Replication Controller (RC) 1.1、RC1.2、RC 应用程序1.3、RC 滚动更新

2. 什么是复制集（RS）2.1、RS2.2和RS应用

3. Deployment3.1、Deployment3.2 指更新节奏和更新逻辑3.3、定制滚动更新策略3.4、部署应用3.5、增长和收缩Pod 应用3.6、滚动更新应用3.6.1、更新3.6.2、返回滚动3.7、其他操作

4.DaemonSet4.1、DaemonSet4.2是DaemonSet应用程序

5、什么是StatefulSet5.1、StatefulSet5.2、StatefulSet5.3？ Headless Service（无头服务）5.4、StatefulSet应用5.5、扩容/缩容5.6、删除5.6.1、级联删除5.6.2、非级联删除

6. 任务6.1、一次性任务（Jobs） 6.2、重复任务（Cronjob）

一、Replication Controller（RC）

1.1、什么是RC

复制控制器称为RC。 RC是Kubernetes系统的核心概念之一。简单来说，RC 保证了pod 运行的副本数量，保证pod 始终可用。如果实际Pod 数量大于指定数量，则终止冗余Pod。如果实际pod 数量小于指定数量，则启动一些pod。如果Pod 失败、被删除或挂起，RC 会自动创建一个新Pod。 Pod 可确保副本数量，因此即使只有一个Pod，您也必须使用RC 来管理您的Pod。

幸运的是，Kubernetes 提供了资源对象，例如：

复制控制器：用于部署和升级Pod 副本集：下一代复制控制器部署：轻松管理Pod 和副本集

1.2、RC应用

接下来，我们创建一个yaml文件来创建RC。

# 类型：复制控制器

#spec.replicas：指定Pod副本数量。默认值为1。

#spec.template：这是之前pod中定义的模块，但apiVersion和kind不是必需的。

#spec.temlate.metadata:labels 注意这里Pod的label必须和spec.selector一样，这样RC才能控制当前的Pod。

# 这个YAML文件的目的是定义一个RC资源对象。它的名字是rc-demo。 Pod 镜像是nginx 镜像。

[root@master ~]# cat nginx_rc.yaml

apiVersion: \’v1\’

kind:复制控制器

元数据：

name:无线电控制演示

标签:

姓名：rc

规格：

复制品： 3

选择器：

姓名：rc

模板：

元数据：

标签:

姓名：rc

规格：

集装箱：

– name: nginx-demo

图片： nginx:1.20

端口：

-集装箱港口： 80

# 部署资源

[root@master ~]# kubectl apply -f nginx_rc.yaml

复制控制器/rc-demo 已创建

您还可以使用#delete 删除Pod。然后您将看到新的Pod 自动出现。

# 显示rc 资源

[root@master ~]# kubectl 获取rc

姓名目前期望的准备年龄

无线电控制演示3 3 3 6 分28 秒

# 显示Pod

[root@master ~]# 获取kubectl pod

姓名准备状态简历年龄

rc-demo-czr2l 1/1 运行0 6 分33 秒

rc-demo-gqwlg 1/1 运行0 6 分34 秒

rc-demo-lldzt 1/1 运行0 6 分33 秒

1.3、RC滚动更新

# 从版本1.11 开始，滚动更新不再支持使用以下格式更新pod 计数，主要使用Deployment。

kubectl 滚动更新rc-demo –image=nginx1.21

二、Replication Set（RS）

2.1、什么是RS

复制集称为RS。随着Kubernetes 的快速发展，官方推荐使用RS 和Deployment 来代替RC。目前，RS 和RC 功能本质上是相同的。仅支持基于wait(env=dev 或deviromment!=qa) 的选择器，但RS 也支持基于set 的选择器（版本（v1.0、12.0））。这对于复杂的运维管理非常有用。 kubectl 命令行工具中的大多数RC 命令也适用于RS 资源对象。然而，RS很少单独应用。我们建议您主要应用Deployment，除非您的用户需要自定义升级功能或者根本不需要升级Pod。而不是直接使用副本集

最后，我们总结了RC/RS的以下特点和功能。

大多数情况下，您可以通过定义RC 来控制Pod 的创建和副本数量。 RC 通过标签选择器机制包含完整的Pod 定义模块。通过改变RC中Pod副本的数量，可以实现Pod扩容/缩容功能。通过更改RC中Pod模板的镜像版本可以实现Pod滚动升级功能。不支持一键回滚，必须使用同样的方法更改镜像地址）

2.2、RS应用

[root@master ~]# cat nginx_rs.yaml

apiVersion: \’应用程序/v1\’

kind: 复制品套装

元数据：

name: nginx

标签:

app: nginx

规格：

复制品： 3

选择器：

匹配标签:

app: nginx

模板：

元数据：

标签:

app: nginx

规格：

集装箱：

-名称： nginx

图片： nginx:1.20

# 部署资源

[root@master ~]# kubectl apply -f nginx_rs.yaml

Replicaset.apps/nginx 已创建

# 显示RS

[root@master ~]# kubectl 获取rs

姓名目前期望的准备年龄

nginx 3 3 3 81s

# 显示pod资源

[root@master ~]# 获取kubectl pod

姓名准备状态简历年龄

nginx-9b8x2 1/1 运行0 96 秒

nginx-dlrsz 1/1 运行0 96 秒

nginx-wh7gt 1/1 运行0 96 秒

三、Deployment

3.1、什么是Deployment

Deployment 和RC、RS 一样，也是Kubernetes 系统中的核心概念，定义一个Deployment 控制器就会创建一个新的ReplicaSet 控制器。 Deployment 控制也被删除，控制器也删除Deployment 控制器下对应的ReplicaSet 控制器和Pod 资源。两者之间的大部分功能完全相同。那么部署有什么作用呢？

所有RC 功能：部署包括上述所有RC 功能。

查看事件和状态：您可以查看部署的详细升级进度和状态。 回滚：如果您在升级pod 时遇到任何问题，可以使用回滚操作来回滚到之前版本的记录（所有操作）。部署可以存储：这也是一个基本的暂停和开始，允许您回滚到任何版本。您可以随时暂停和开始每次升级。 对比：作为对比，甚至还有部署。新一代的RC不仅功能丰富，现在官方推荐使用deployments来管理pod。例如，一些官方组件kube-dns 和kube-proxy 也是如此。它是使用Deployments 进行管理的，如果您使用Deployments 来管理pod，建议使用它。无状态服务通常使用部署进行管理。

什么是无状态服务：

服务不依赖于它们自己的状态，任何请求都可以由任何实例处理。请求无法水平扩展。通常存在于整体架构中的单个集群中。

3.2、更新节奏和更新逻辑

例如，如果部署控制5 个pod 副本，则pod 的预期值为5，但如果升级过程中需要更多pod，则控制器控制除了5 个pod 副本之外还可以添加的pod 数量。您可以控制份数。可以加1，但不能减1，所以升级过程就是先加1，再去掉1，加1，去掉1，再加1，再去掉1，然后会一直保持个数副本5 份。允许的最大值多一，最小值少一。所以，最好是六个，至少四个，第一次添加一个，删除两个，第二次添加两个，删除两个。这种类型的滚动更新需要添加readinessProbe。 livenessProbe 检测可确保Pod 内容器中的应用程序在前一个Pod 被删除之前成功启动。开始的第一步允许您在更新第一批后立即暂停。目标是5，少了也不允许，加5就可以控制节奏了。我们更新了自己的方法。

Deployment 对象允许您轻松：

1. ReplicaSet 和Pod2 创建、滚动升级（不停止旧服务升级）、回滚应用（将应用回滚到之前版本） 3. 平滑扩容和缩容4. 暂停和继续部署

3.3、自定义滚动更新策略

maxSurge和maxUnavailable用于控制滚动更新的更新策略。

maxUnavailable：预期就绪副本数与最大不可用副本数（或最大值）的比率，该值越低，服务越稳定，更新越流畅。该值越高，复制越精细、速度越快。

比率

maxUnavailable：[0%, 100%] 向下取整（例如5%==0.5 是10 份，但计算是基于0） maxSurge：[0%, 100%]，向上取整（例如10）份。如果5%==0.5，则以1为基础计算。

注意：两者不能同时为0

推荐配置：

最大不可用==0 最大浪涌==1

3.4、Deployment应用

[root@master ~]# cat nginx_deployment.yaml

apiVersion: \’应用程序/v1\’

部署kind:

元数据：

name: nginx

标签:

app: nginx

规格：

复制品： 6

选择器：

匹配标签:

app: nginx

# 用新pod 替换现有pod 的部署策略

策略：

滚动更新：

# maxSurge: 1 表示在滚动更新期间可以同时运行比所需副本数量多的pod。例如，如果.spec.replicas 为6，在最坏的情况下，您可能会同时运行7 个Pod（6 个旧+ 1 个新）。

最大浪涌： 1

# maxUnavailable: 0 表示滚动更新期间旧Pod 不会变得不可用。这意味着您需要在删除旧Pod 之前确保新Pod 已准备好。这确保至少Pod 的.spec.replica 在更新过程中始终可用。

最大不可用： 0

模板：

元数据：

name: nginx

标签:

app: nginx

规格：

集装箱：

-名称： nginx

图片： nginx:1.20

imagePullPolicy: 如果不存在

# 部署资源

[root@master ~]# kubectl apply -f nginx_deployment.yaml

Deployment.apps/nginx 已创建

# 显示部署

[root@master ~]# 获取kubectl 部署

姓名已准备好最新可用年龄

nginx 6/6 6 6 56s

# 查看容器

[root@master ~]# 获取kubectl pod

姓名准备状态简历年龄

nginx-795ff9d4cc-5zd79 1/1 运行0 89 秒

nginx-795ff9d4cc-6wgjs 1/1 运行0 89 秒

nginx-795ff9d4cc-9pfxs 1/1 运行0 89 秒

nginx-795ff9d4cc-gbzvr 1/1 运行0 86 秒

nginx-795ff9d4cc-hcztd 1/1 运行0 89 秒

nginx-795ff9d4cc-jxz28 1/1 运行0 88 秒

3.5、扩缩容Pod应用

# 更改yaml文件的副本配置并重新应用yaml文件

# 如果replica的值较之前发生了变化，则表示扩张；如果减少了，则表示收缩。

[root@master ~]# cat nginx_deployment.yaml |

复制品： 8

# 重新部署

[root@master ~]# kubectl apply -f nginx_deployment.yaml

配置deployment.apps/nginx

也可以直接使用#edit 来更改

[root@master ~]# 获取kubectl pod

姓名准备状态简历年龄

nginx-795ff9d4cc-5zd79 1/1 运行0 8m

nginx-795ff9d4cc-6wgjs 1/1 运行0 8m

nginx-795ff9d4cc-9pfxs 1/1 运行0 8m

nginx-795ff9d4cc-d4q2f 1/1 运行0 38 秒

nginx-795ff9d4cc-gbzvr 1/1 运行0 7 分57 秒

nginx-795ff9d4cc-gxnhw 1/1 运行0 38 秒

nginx-795ff9d4cc-hcztd 1/1 运行0 8m

nginx-795ff9d4cc-jxz28 1/1 运行0 7 分59 秒

# 找到replica配置，修改后保存，配置文件就会被识别并启用（注）。

[root@master ~]# kubectl 编辑部署nginx

编辑deployment.apps/nginx

# 查看部署资源。将Pod 副本数更改为9。

[root@master ~]# 获取kubectl 部署

姓名已准备好最新可用年龄

nginx 9/9 9 9 9 分46 秒

# 您还可以使用命令行指定数量。使用–replicas 指定数量。

[root@master ~]# kubectl规模部署nginx –replicas=2

扩展部署.apps/nginx

[root@master ~]# 获取kubectl 部署

姓名已准备好最新可用年龄

nginx 2/2 2 2 11m

3.6、滚动更新应用

3.6.1、更新

#将镜像写入yaml文件并重新应用yaml文件

[root@master ~]# vi nginx_deployment.yaml

图片： nginx:1.21

# 重新部署资源

[root@master ~]# kubectl apply -f nginx_deployment.yaml

配置deployment.apps/nginx

[root@master ~]# 获取kubectl pod

姓名准备状态简历年龄

nginx-5ff79c7ff8-2fn4r 0/1 容器创建0 27s

nginx-795ff9d4cc-55h7p 1/1 运行0 27 秒

nginx-795ff9d4cc-8fpqg 1/1 运行0 27 秒

nginx-795ff9d4cc-9pfxs 1/1 运行0 14m

nginx-795ff9d4cc-bmpnn 1/1 运行0 27 秒

nginx-795ff9d4cc-hcztd 1/1 运行0 14 米

nginx-795ff9d4cc-rtffd 1/1 运行0 27 秒

nginx-795ff9d4cc-wxvl2 1/1 运行0 27 秒

nginx-795ff9d4cc-xcfbn 1/1 运行0 27 秒

# 要查看发布历史记录，请使用以下命令：

[root@master ~]# kubectl 部署历史部署nginx

部署.apps/nginx

修订变更原因

0 无

1 无

2 无

# 使用–revision 显示有关发布历史的具体信息

[root@master ~]# kubectl 部署历史部署nginx –revision=1

Deployment.apps/nginx（修订版#1）

吊舱模板：

标签:app=nginx

Pod 模板哈希=795ff9d4cc

集装箱：

nginx:

图片：nginx:1.20

没有端口：

没有主机端口：

无环境：

无安装座：

无卷：

[root@master ~]# kubectl 部署历史部署nginx –revision=2

Deployment.apps/nginx（修订版#2）

吊舱模板：

标签:app=nginx

Pod 模板哈希=5ff79c7ff8

集装箱：

nginx:

图片：nginx:1.21

没有端口：

没有主机端口：

无环境：

无安装座：

无卷：

您还可以使用# kubectl set image 命令执行滚动更新

[根

@master ~]# kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 8/8 8 8 16m
[root@master ~]# kubectl set image deployment nginx nginx=nginx:1.22
deployment.apps/nginx image updated
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-7c8489bfcf-4jbc2 1/1 Running 0 13s
nginx-7c8489bfcf-8f575 1/1 Running 0 18s
nginx-7c8489bfcf-8pcp9 1/1 Running 0 14s
nginx-7c8489bfcf-cs2jh 1/1 Running 0 16s
nginx-7c8489bfcf-g8zmh 1/1 Running 0 12s
nginx-7c8489bfcf-t8c4l 1/1 Running 0 11s
nginx-7c8489bfcf-t8q47 1/1 Running 0 15s
# 查看发布状态
[root@master ~]# kubectl rollout status deployment nginx
deployment \”nginx\” successfully rolled out
# 验证是否更新nginx镜像版本
[root@master ~]# kubectl exec -it nginx-7c8489bfcf-wdtgh — nginx -v
nginx version: nginx/1.22.1

3.6.2、回滚

# 查看上线历史
[root@master ~]# kubectl rollout history deployment nginx
deployment.apps/nginx
REVISION CHANGE-CAUSE
0 <none>
1 <none>
2 <none>
3 <none>
# 回滚到上一个版本（nginx:1.21）
[root@master ~]# kubectl rollout undo deployment nginx
deployment.apps/nginx rolled back
# 随便找一个deployment的Pod进行验证即可
[root@master ~]# kubectl exec -it nginx-5ff79c7ff8-pvg74 — nginx -v
nginx version: nginx/1.21.5
# 回滚到指定版本
[root@master ~]# kubectl rollout undo deployment nginx –to-revision=1
deployment.apps/nginx rolled back
# 随便找一个deployment的Pod进行验证即可
[root@master ~]# kubectl exec -it nginx-795ff9d4cc-plm4l — nginx -v
nginx version: nginx/1.20.2
# 查看回滚状态
[root@master ~]# kubectl rollout status deployment nginx
deployment \”nginx\” successfully rolled out

3.7、其他操作

# 暂停deployment更新
[root@master ~]# kubectl rollout pause deployment nginx
deployment.apps/nginx paused
# 恢复deployment更新
[root@master ~]# kubectl rollout resume deployment nginx
deployment.apps/nginx resumed

四、DaemonSet

4.1、什么是DaemonSet

通过该控制器的名称我们可以看出它的用法：Daemon，就是用来部署守护进程的，DaemonSet用于再每个Kubernetes节点中将守护进程的副本作为后台进程运行，说白了就是在每个节点部署一个Pod副本，当节点加入到Kubernetes集群中，Pod会被调度到该节点上运行，当节点从集群只能够能移除后，该节点上的这个Pod也会被移除，当然，如果我们删除DaemonSet，所有和这个对象相关的Pods都会被删除
这哪种情况下我们会需要用到这种业务场景呢？其实这种场景还是比较普通的，比如：

集群存储守护程序：如glusterd、ceph要部署在每个节点上提供持久化存储
节点监视守护进程：如Prometheus监控集群，可以在每个节点上运行一个node-exporter进程来收集监控节点的信息
日志收集守护程序：如fluentd或logstash，在每个节点上运行以收集容器的日志

4.2、DaemonSet应用

[root@master ~]# cat nginx-ds.yaml
apiVersion: \”apps/v1\”
kind: DaemonSet
metadata:
name: nginx
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
– name: nginx
image: nginx:1.20
imagePullPolicy: IfNotPresent
# 部署资源
[root@master ~]# kubectl apply -f nginx-ds.yaml
daemonset.apps/nginx created
# 查看ds
[root@master ~]# kubectl get ds
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
nginx 2 2 2 2 2 <none> 35s
# 可以查到node节点上都运行了一个nginx的Pod
[root@master ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-vplg4 1/1 Running 0 72s 10.244.1.30 node2 <none> <none>
nginx-wd7pq 1/1 Running 0 72s 10.244.2.27 node1 <none> <none>
# 仔细观察会发信啊master节点并没有运行Pod，因为这涉及到污点
[root@master ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
master Ready control-plane,master 42h v1.23.0
node1 Ready <none> 42h v1.23.0
node2 Ready <none> 42h v1.23.0

五、StatefulSet

在学习StatefulSet这种控制器之前，要先弄明白一个概念：什么叫无状态服务？

5.1、有状态服务

有状态服务（Stateful Service）：该服务运行的实例需要在本地存储持久化服务，比如上面的MySQL数据库，你现在运行在节点A，那么它的数据就存储在节点A上面的，如果这个时候你把该服务迁移到节点B去的话，那么就没有之前的数据了，因为它需要去对应的数据目录里面恢复数据，而此没有任何数据。
有状态服务的特点：

服务本身依赖或者存在局部的状态数据，这些数据需要自身持久化或者可以通过其他节点恢复一个请求只能被某个节点（或者同等状态的节点）处理存储状态数据，实力的拓展需要整个系统参与状态的迁移在一个封闭的系统中，存在多个数据闭环，需要考虑这些闭环的数据一致性问题通常存在于分布式架构中

5.2、什么是StatefulSet

StatefulSet是用来管理有状态应用的工作负载API对象。和Deployment类似，StatefulSet管理基于相同容器规约的一组Pod。但是Deployment不同的是，StatefulSet为他们的每个Pod维护了一个粘性的ID。这些Pod是雨季相同的规约来创建的，但是不能相互替换：无论怎么调度，每个Pod都有永久不变的ID。StatefulSet类似ReplicaSet，但是它可以处理Pod的启动顺序，为保留每个Pod的状态设置唯一表示，同时具有以下功能：
稳定的、唯一的网络标识符

稳定的、持久化的存储

稳定的、优雅的部署和缩放

有序的、优化的部署的缩放

有序的、优化的删除和终止

有序的、自动滚动更新

5.3、无头服务（Headless service）

Headless service不分配clusterIP，headless service可以通过解析service的DNS返回所有的Pod的dns和ip地址（statefulSet部署的Pod才有DNS），普通的service只能通过解析service的DNS返回service的ClusterIP
为什么要用headless service（没有service ip的service）？
在使用Deployment时，创建的Pod名称是没有顺序的，是随机字符串，在用statefulset管理Pod时要求pod名称必须是有序的，每一个Pod不能被随意取代，Pod重建后pod名称还是一样的。因为pod IP是变化的，所以要用Pod名称来识别。Pod名称是pod唯一性的标识符，必须持久稳定有效。这时要用到无头服务，他可以给每个Pod一个唯一的名称

headless service会为servie分配一个域名，域名格式如下：

<service name>.$<namespace name>.svc.cluster.local

k8s中资源的全局FQDN格式

Service_NAME.NameSpace_NAME.Domain.LTD.
Domain.LTD.=svc.cluster.local.　　　　 #这是默认k8s集群的域名。

StatefulSet会为关联的Pod分配一个dnsName

$<Pod Name>.$<service name>.$<namespace name>.svc.cluster.local

5.4、StatefulSet应用

[root@master ~]# cat nginx_sts.yaml
apiVersion: \”v1\”
kind: Service
metadata:
name: nginx
spec:
clusterIP: None
ports:
– port: 80
targetPort: 80
selector:
app: nginx
—
apiVersion: \”apps/v1\”
kind: StatefulSet
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
serviceName: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
– name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
– containerPort: 80
# 部署资源
[root@master ~]# kubectl apply -f nginx_sts.yaml
service/nginx created
statefulset.apps/nginx unchanged
# 查看sts
[root@master ~]# kubectl get sts
NAME READY AGE
nginx 2/2 45s
# 查看pod
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 63s
nginx-1 1/1 Running 0 46s

5.5、扩容缩容

[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 2m6s
nginx-1 1/1 Running 0 109s
nginx-2 1/1 Running 0 10s
nginx-3 1/1 Running 0 9s# –replicas选项可以调整副本数量
[root@master ~]# kubectl scale sts nginx –replicas=4
statefulset.apps/nginx scaled
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 2m6s
nginx-1 1/1 Running 0 109s
nginx-2 1/1 Running 0 10s
nginx-3 1/1 Running 0 9s

5.6、删除

删除StatefulSet有两种方式：级联删除和非级联删除使用非级联方式删除StatefulSet时，StatefulSet的Pod不会被删除。使用级联方式删除StatefulSet时，StatefulSet和它的Pod都会被删除

5.6.1、级联删除

[root@master ~]# kubectl delete sts nginx
statefulset.apps \”nginx\” deleted

5.6.2、非级联删除

# 重新加载资源用于验证
[root@master ~]# kubectl apply -f nginx_sts.yaml
service/nginx unchanged
statefulset.apps/nginx created
[root@master ~]# kubectl delete sts nginx –cascade=false
warning: –cascade=false is deprecated (boolean value) and can be replaced with –cascade=orphan.
statefulset.apps \”nginx\” deleted
[root@master ~]# kubectl get sts
No resources found in default namespace.
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 38s
nginx-1 1/1 Running 0 36s

六、任务

我们在日常的工作中经常会遇到一些需要进行批量数据处理的分析的需求，当然也会有按时间来进行调度的工作，在我们Kubernetes集群中为我们提供了Job和CronJob两种资源对象来应对我们这种需求Job负载处理任务，即仅执行一次的任务，它保证批处理人物的一个或多个Pod成功结束，而CronJob则就是在Job上加了时间调度

6.1、一次性任务（Job）

我们用Job这个资源对象来创建一个任务，我们顶一个Job来执行一个倒计时的任务，定义Yaml文件
# 注意Job的RestartPolicy仅支持Never和OnFailure两种，不支持Always，我们直到Job就相当于来执行一个批处理任务，执行完就结束了，如果支持Always的话就会陷入死循环
[root@master ~]# cat job-demo.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo
spec:
template:
metadata:
name: job-demo
spec:
restartPolicy: Never
containers:
– name: cunter
image: busybox
command:
– \”bin/sh\”
– \”-c\”
– \”for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 1; done\”

# 部署资源
[root@master ~]# kubectl apply -f job-demo.yaml
job.batch/job-demo created
# 查看job
[root@master ~]# kubectl get job
NAME COMPLETIONS DURATION AGE
job-demo 1/1 27s 46s
# job运行完以后，pod的状态是Completed
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
job-demo-qhr9p 0/1 Completed 0 104s
# 使用kubectl logs可以查看日志
[root@master ~]# kubectl logs job-demo-qhr9p
9
8
7
6
5
4
3
2
1

6.2、周期性任务（Cronjob）

CronJob其实就是在Job的基础上加上了时间调度，我们可以：在给定的时间点运行一个任务，也可以周期性地在给定时间点运行任务。这个实际上和我们Linux长得crontab就非常累死了一个CronJob对象其实就是对应用中的crontab文件中的一行，它根据配置的时间格式周期性地运行一个job，格式和crontab一样的
分 时 日 月 星期 要运行的命令
第1列分钟0～59
第2列小时0～23
第3列日1～31
第4列月1～12
第5列星期0～7（0和7表示星期天）
第6列要运行的命令

现在，我们用CronJob来管理我们上面的Job任务
[root@master ~]# cat cronjob-demo.yaml

# 部署资源
[root@master ~]# kubectl apply -f cronjob-demo.yaml
cronjob.batch/cronjob-demo created
# 查看cronjob
[root@master ~]# kubectl get cronjob
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
cronjob-demo * * * * * False 1 9s 38s
# 查看pod
[root@master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
cronjob-demo-28656169-wdcvh 1/1 Running 0 22s

#以上关于【云原生】加强理解Pod资源控制器的相关内容来源网络仅供参考，相关信息请以官方公告为准！