OpenKruise通用控制器

OpenKruise通用控制器

目录

[TOC]

实验环境

实验环境：1、win10,vmwrokstation虚机；2、k8s集群：3台centos7.61810虚机，1个master节点,2个node节点k8sversion：v1.22.2containerd:+ apiVersion:apps.kruise.io/v1beta1kind:StatefulSetmetadata:name:samplespec:#...

1.最大不可用

💘 实验：最大不可用

Advanced StatefulSet 在滚动更新策略中新增了 maxUnavailable 来支持并行 Pod 发布，它会保证发布过程中最多有多少个 Pod 处于不可用状态。 注意，maxUnavailable 只能配合 podManagementPolicy为 Parallel 来使用。

这个策略的效果和 Deployment 中的类似，但是可能会导致发布过程中的 order 顺序不能严格保证，如果不配置 maxUnavailable，它的默认值为 1，也就是和原生 StatefulSet 一样只能串行发布 Pod，即使把 podManagementPolicy 配置为 Parallel 也是这样。

• 比如现在我们创建一个如下所示的 Advanced StatefulSet：

#01-sts-RollingUpdate-Parallel.yamlapiVersion:apps.kruise.io/v1beta1kind:StatefulSetmetadata:name:webnamespace:defaultspec:serviceName:"nginx-headless"podManagementPolicy:Parallelreplicas:5updateStrategy:type:RollingUpdaterollingUpdate:maxUnavailable:3# partition:4selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginx# @spec:containers:- name:nginximage:nginxports:- name:webcontainerPort:80

• 直接创建该对象，由于对象名称也是 StatefulSet，所以不能直接用 get sts来获取了，要通过 get asts获取：

$kubectlapply-f01-sts-RollingUpdate-Parallel.yamlstatefulset.apps.kruise.io/webcreated[root@master1 ~]#kubectl get astsNAMEDESIREDCURRENTUPDATEDREADYAGEweb555524s[root@master1 ~]#kubectl get po -l app=nginxNAMEREADYSTATUSRESTARTSAGEweb-01/1Running033sweb-11/1Running033sweb-21/1Running032sweb-31/1Running032sweb-41/1Running032s

注意：查看advanced statsfulset的简写

[root@master1 ~]#kubectl get crd|grepkruiseadvancedcronjobs.apps.kruise.io2022-03-10T13:09:22Zbroadcastjobs.apps.kruise.io2022-03-10T13:09:22Zclonesets.apps.kruise.io2022-03-10T13:09:22Zcontainerrecreaterequests.apps.kruise.io2022-03-10T13:09:22Zdaemonsets.apps.kruise.io2022-03-10T13:09:22Zimagepulljobs.apps.kruise.io2022-03-10T13:09:22Znodeimages.apps.kruise.io2022-03-10T13:09:22Zpodunavailablebudgets.policy.kruise.io2022-03-10T13:09:22Zresourcedistributions.apps.kruise.io2022-03-10T13:09:22Zsidecarsets.apps.kruise.io2022-03-10T13:09:22Zstatefulsets.apps.kruise.io2022-03-10T13:09:22Zuniteddeployments.apps.kruise.io2022-03-10T13:09:22Zworkloadspreads.apps.kruise.io2022-03-10T13:09:22Z[root@master1 ~]#kubectl get crd statefulsets.apps.kruise.io -oyaml|less

🍀 该应用下有五个 Pod，假设应用能容忍 3 个副本不可用，当我们把 StatefulSet 里的 Pod 升级版本的时候，可以通过以下步骤来做：

1. 设置 maxUnavailable=3

1. (可选) 如果需要灰度升级，设置 partition=4，Partition 默认的意思是 order 大于等于这个数值的 Pod 才会更新，在这里就只会更新 P4，即使我们设置了 maxUnavailable=3。

1. 在 P4 升级完成后，把 partition 调整为 0，此时，控制器会同时升级 P1、P2、P3 三个 Pod。注意，如果是原生 StatefulSet，只能串行升级 P3、P2、P1。

1. 一旦这三个 Pod 中有一个升级完成了，控制器会立即开始升级 P0。😥

🍀 比如这里我们把上面应用的镜像版本进行修改，更新后查看 Pod 状态，可以看到有3个 Pod 并行升级的：

修改镜像版本：

……image:nginx:latest#修改为nginx:latest……

#部署$kubectlapply-f01-sts-RollingUpdate-Parallel.yamlstatefulset.apps.kruise.io/webconfigured#查看➜kubectlgetpods-lapp=nginxNAMEREADYSTATUSRESTARTSAGEweb-01/1Running02m41sweb-11/1Running02m41sweb-20/1ContainerCreating010sweb-30/1ContainerCreating010sweb-40/1ContainerCreating010s[root@master1 ~]#kubectl get po -l app=nginxNAMEREADYSTATUSRESTARTSAGEweb-01/1Running07m5sweb-11/1Running07m5sweb-20/1ContainerCreating04sweb-30/1ContainerCreating04sweb-40/1ContainerCreating04s[root@master1 ~]#kubectl get po -l app=nginxNAMEREADYSTATUSRESTARTSAGEweb-01/1Running034sweb-11/1Running035sweb-21/1Running052sweb-31/1Running052sweb-41/1Running052s[root@master1 ~]#kubectl describe po web-0Events:TypeReasonAgeFromMessage-------------------------NormalScheduled56sdefault-schedulerSuccessfullyassigneddefault/web-0tonode2NormalPulling55skubeletPullingimage"nginx:latest"NormalPulled26skubeletSuccessfullypulledimage"nginx:latest"in29.501447739sNormalCreated26skubeletCreatedcontainernginxNormalStarted25skubeletStartedcontainernginx

实验结束。😘

2.原地升级

💘 实验：原地升级

Advanced StatefulSet 增加了 podUpdatePolicy来允许用户指定重建升级还是原地升级。此外还在原地升级中提供了 graceful period 选项，作为优雅原地升级的策略。用户如果配置了 gracePeriodSeconds这个字段，控制器在原地升级的过程中会先把 Pod status 改为 not-ready，然后等一段时间（gracePeriodSeconds），最后再去修改 Pod spec 中的镜像版本。这样，就为 endpoints-controller 这些控制器留出了充足的时间来将 Pod 从 endpoints 端点列表中去除。

如果使用 InPlaceIfPossible或 InPlaceOnly策略，必须要增加一个 InPlaceUpdateReady readinessGate，用来在原地升级的时候控制器将 Pod 设置为 NotReady。

• 比如设置上面的应用为原地升级的方式：

#02-sts-RollingUpdate-InPlaceIfPossible.yamlapiVersion:apps.kruise.io/v1beta1kind:StatefulSetmetadata:name:webnamespace:defaultspec:serviceName:"nginx-headless"podManagementPolicy:Parallelreplicas:5updateStrategy:type:RollingUpdaterollingUpdate:podUpdatePolicy:InPlaceIfPossible# 尽可能执行原地升级maxUnavailable:3# 允许并行更新，最大不可以实例数为3selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:readinessGates:- conditionType:InPlaceUpdateReady# 一个新的条件，可确保 Pod 在发生原地更新时保持在 NotReady 状态containers:- name:nginximage:nginx:1.7.9#这里把镜像修改为1.7.9ports:- name:webcontainerPort:80

这里我们设置 updateStrategy.rollingUpdate.podUpdatePolicy为 InPlaceIfPossible模式，表示尽可能使用原地升级的方式进行更新。此外在 Pod 模板中我们还添加了一个 readinessGates属性，可以用来确保 Pod 在发生原地更新时保持在 NotReady 状态。

• 先来查看下当前pod信息(等会原地升级后，我们再核对下pod信息)

[root@master1 ~]#kubectl get po -l app=nginx-owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESweb-01/1Running056s10.244.2.46node2<none>2/2web-11/1Running056s10.244.1.162node1<none>2/2web-21/1Running056s10.244.2.47node2<none>2/2web-31/1Running055s10.244.1.163node1<none>2/2web-41/1Running055s10.244.2.48node2<none>2/2

• 比如我们现在使用上面资源清单更新应用，然后重新修改镜像的版本更新，则会进行原地升级：

$kubectlapply-f02-sts-RollingUpdate-InPlaceIfPossible.yamlstatefulset.apps.kruise.io/webconfigured[root@master1 ~]#kubectl get po -l app=nginx-owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESweb-01/1Running0106s10.244.2.46node2<none>1/2web-11/1Running1(17s ago) 106s 10.244.1.162 node1 <none>2/2web-21/1Running0106s10.244.2.47node2<none>1/2web-31/1Running1(21s ago) 105s 10.244.1.163 node1 <none>2/2web-41/1Running1(21s ago) 105s 10.244.2.48 node2 <none>2/2[root@master1 ~]#kubectl get po -l app=nginx-owide#可以看到采用原地升级后，pod ip和所在node节点信息都没发生改变NAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESweb-01/1Running1(50s ago) 2m34s 10.244.2.46 node2 <none>2/2web-11/1Running1(65s ago) 2m34s 10.244.1.162 node1 <none>2/2web-21/1Running1(69s ago) 2m34s 10.244.2.47 node2 <none>2/2web-31/1Running1(69s ago) 2m33s 10.244.1.163 node1 <none>2/2web-41/1Running1(69s ago) 2m33s 10.244.2.48 node2 <none>2/2[root@master1 ~]#kubectl describe asts webEvents:TypeReasonAgeFromMessage-------------------------NormalSuccessfulCreate3m32sstatefulset-controllercreatePodweb-0inStatefulSetwebsuccessfulNormalSuccessfulCreate3m32sstatefulset-controllercreatePodweb-1inStatefulSetwebsuccessfulNormalSuccessfulCreate3m32sstatefulset-controllercreatePodweb-2inStatefulSetwebsuccessfulNormalSuccessfulCreate3m31sstatefulset-controllercreatePodweb-3inStatefulSetwebsuccessfulNormalSuccessfulCreate3m31sstatefulset-controllercreatePodweb-4inStatefulSetwebsuccessfulNormalSuccessfulUpdatePodInPlace2m7sstatefulset-controllersuccessfullyupdatepodweb-4in-place(revisionweb-67975fc8c9)NormalSuccessfulUpdatePodInPlace2m7sstatefulset-controllersuccessfullyupdatepodweb-3in-place(revisionweb-67975fc8c9)NormalSuccessfulUpdatePodInPlace2m7sstatefulset-controllersuccessfullyupdatepodweb-2in-place(revisionweb-67975fc8c9)NormalSuccessfulUpdatePodInPlace2m3sstatefulset-controllersuccessfullyupdatepodweb-1in-place(revisionweb-67975fc8c9)NormalSuccessfulUpdatePodInPlace108sstatefulset-controllersuccessfullyupdatepodweb-0in-place(revisionweb-67975fc8c9)

• 同样的 Advanced StatefulSet 也支持原地升级自动预热。

• 也可以通过设置 paused 为 true 来暂停发布，不过控制器还是会做 replicas 数量管理：

apiVersion:apps.kruise.io/v1beta1kind:StatefulSetspec:# ...updateStrategy:rollingUpdate:paused:true

• 另外 Advanced StatefulSet 还支持序号保留功能，通过在 reserveOrdinals字段中写入需要保留的序号，Advanced StatefulSet 会自动跳过创建这些序号的 Pod，如果 Pod 已经存在，则会被删除。

注意，spec.replicas是期望运行的 Pod 数量，spec.reserveOrdinals是要跳过的序号。

apiVersion:apps.kruise.io/v1beta1kind:StatefulSetspec:# ...replicas:4reserveOrdinals:- 1

比如上面的描述 replicas=4,reserveOrdinals=[1]的 Advanced StatefulSet，表示实际运行的 Pod 序号为 [0,2,3,4]。

• 如果要把 Pod-3 做迁移并保留序号，则把 3 追加到 reserveOrdinals 列表中，控制器会把 Pod-3 删除并创建 Pod-5（此时运行中 Pod 为 [0,2,4,5]）。
• 如果只想删除 Pod-3，则把 3 追加到 reserveOrdinals 列表并同时把 replicas 减一修改为 3。控制器会把 Pod-3 删除（此时运行中 Pod 为 [0,2,4]）。

🍀 为了避免在一个新 Advanced StatefulSet 创建后有大量失败的 pod 被创建出来，从 Kruise v0.10.0 版本开始引入了在 scale strategy 中的 maxUnavailable 策略。

apiVersion:apps.kruise.io/v1beta1kind:StatefulSetspec:# ...replicas:100scaleStrategy:maxUnavailable:10%# percentage or absolute number

当这个字段被设置之后，Advanced StatefulSet 会保证创建 pod 之后不可用 pod 数量不超过这个限制值。比如说，上面这个 StatefulSet 一开始只会一次性创建 100*10%=10 个 pod，在此之后，每当一个 pod 变为 running、ready 状态后，才会再创建一个新 pod 出来。

注意，这个功能只允许在 podManagementPolicy 是 Parallel的 StatefulSet 中使用。

实验结束。😘

2、Advanced DaemonSet

这个控制器基于原生 DaemonSet 上增强了发布能力，比如灰度分批、按 Node label 选择、暂停、热升级等。同样的该对象的 Kind 名字也是 DaemonSet，只是 apiVersion 是 apps.kruise.io/v1alpha1，这个 CRD 的所有默认字段、默认行为与原生 DaemonSet 完全一致，除此之外还提供了一些 optional 字段来扩展增强的策略。

因此，用户从原生 DaemonSet 迁移到 Advanced DaemonSet，只需要把 apiVersion 修改后提交即可：

- apiVersion:apps/v1+ apiVersion:apps.kruise.io/v1alpha1kind:DaemonSetmetadata:name:sample-dsspec:#...

1.升级

💘 实验：升级

Advanced DaemonSet 在 spec.updateStrategy.rollingUpdate中有一个 rollingUpdateType字段，标识了如何进行滚动升级：

• Standard:对于每个节点，控制器会先删除旧的 daemon Pod，再创建一个新 Pod，和原生 DaemonSet 行为一致。
• Surging:对于每个 node，控制器会先创建一个新 Pod，等它 ready 之后再删除老 Pod。

🍀 创建如下所示的资源对象：

#03-daemonset-demo.yamlapiVersion:apps.kruise.io/v1alpha1kind:DaemonSetmetadata:name:nginxnamespace:defaultspec:updateStrategy:type:RollingUpdaterollingUpdate:rollingUpdateType:Standardselector:matchLabels:k8s-app:nginxtemplate:metadata:labels:k8s-app:nginxspec:containers:- image:nginx:1.7.9name:nginxports:- name:httpcontainerPort:80

• 创建后需要通过 get daemon来获取该对象：

#部署$kubectlapply-f03-daemonset-demo.yamldaemonset.apps.kruise.io/nginxcreated[root@master1 ~]#kubectl get daemonNAMEDESIREDNUMBERCURRENTNUMBERUPDATEDNUMBERSCHEDULEDAGEnginx22211s[root@master1 ~]#kubectl get pods -l k8s-app=nginx-owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESnginx-gbz5h1/1Running017s10.244.2.49node2<none>1/1nginx-hgx4b1/1Running017s10.244.1.164node1<none>1/1

我们这里只有两个 Work 节点，所以一共运行了2个 Pod，每个节点上一个，和默认的 DaemonSet 行为基本一致。

• 此外这个策略还支持用户通过配置 node 标签的 selector，来指定灰度升级某些特定类型 node 上的 Pod。比如现在我们只升级 node1 节点的应用，则可以使用 selector标签来标识：

注意：这个功能还是比较实用的，在恢复发布方面，可以把故障域缩小到一定区间。

apiVersion:apps.kruise.io/v1alpha1kind:DaemonSetspec:# ...updateStrategy:type:RollingUpdaterollingUpdate:rollingUpdateType:Standardselector:#添加节点selectormatchLabels:#只会针对node1节点做做更新kubernetes.io/hostname:node1# ...

完整yaml代码如下：

#04-daemonset-demo2.yamlapiVersion:apps.kruise.io/v1alpha1kind:DaemonSetmetadata:name:nginxnamespace:defaultspec:updateStrategy:type:RollingUpdaterollingUpdate:rollingUpdateType:Standardselector:#修改点1：添加节点selectormatchLabels:#只会针对node1节点做做更新kubernetes.io/hostname:node1selector:matchLabels:k8s-app:nginxtemplate:metadata:labels:k8s-app:nginxspec:containers:- image:nginx#修改点2：修改nginx镜像name:nginxports:- name:httpcontainerPort:80

• 更新应用后可以看到只会更新 node1 节点上的 Pod：

#部署$kubectlapply-f04-daemonset-demo2.yamldaemonset.apps.kruise.io/nginxconfigured[root@master1 ~]#kubectl get pods -l k8s-app=nginx-owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESnginx-d67ms1/1Running017s10.244.1.165node1<none>1/1nginx-gbz5h1/1Running06m24s10.244.2.49node2<none>1/1[root@master1 ~]#kubectl describe daemon nginx......Events:TypeReasonAgeFromMessage-------------------------NormalSuccessfulCreate7m22sdaemonset-controllerCreatedpod:nginx-hgx4bNormalSuccessfulCreate7m22sdaemonset-controllerCreatedpod:nginx-gbz5hNormalSuccessfulDelete76sdaemonset-controllerDeletedpod:nginx-hgx4bNormalSuccessfulCreate75sdaemonset-controllerCreatedpod:nginx-d67ms

• 和前面两个控制器一样，Advanced DaemonSet 也支持分批灰度升级，使用 Partition 进行配置，Partition 的语义是保留旧版本 Pod 的数量，默认为 0，如果在发布过程中设置了 partition，则控制器只会将 (status.DesiredNumberScheduled - partition)数量的 Pod 更新到最新版本。

apiVersion:apps.kruise.io/v1alpha1kind:DaemonSetspec:# ...updateStrategy:type:RollingUpdaterollingUpdate:partition:10#如果大于期望运行的pod数量，则不会更新。paused:true# 暂停发布

• 同样 Advanced DaemonSet 也是支持原地升级的，只需要设置 rollingUpdateType为支持原地升级的类型即可，比如这里我们将上面的应用升级方式设置为 InPlaceIfPossible即可：

apiVersion:apps.kruise.io/v1alpha1kind:DaemonSetspec:# ...updateStrategy:type:RollingUpdaterollingUpdate:rollingUpdateType:InPlaceIfPossible#设置为尽可能地原地升级。

完整yam代码如下：

#05-daemonset-demo3.yamlapiVersion:apps.kruise.io/v1alpha1kind:DaemonSetmetadata:name:nginxnamespace:defaultspec:updateStrategy:type:RollingUpdaterollingUpdate:rollingUpdateType:InPlaceIfPossible#修改点1selector:matchLabels:k8s-app:nginxtemplate:metadata:labels:k8s-app:nginxspec:containers:- image:nginx:1.7.9#修改点2：修改nginx镜像,只修改镜像的版本会当成原地升级的场景name:nginxports:- name:httpcontainerPort:80

• 在测试之前，我们准备下当前环境：

#清空下当前环境，然后重新部署下05-daemonset-demo3.yaml，并查看下当前pod信息[root@master1 ~]#kubectl delete daemon nginx daemonset.apps.kruise.io"nginx"deleted$kubectlapply-f05-daemonset-demo3.yamldaemonset.apps.kruise.io/nginxcreated[root@master1 ~]#kubectl get po -owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESnginx-7h2nw1/1Running04s10.244.1.168node1<none>2/2nginx-bmzcq1/1Running04s10.244.2.52node2<none>2/2#然后把05-daemonset-demo3.yaml里面的镜像改下，再部署下，观察下效果……-image:nginx……

• 更新后可以通过查看控制器的事件来验证是否是通过原地升级方式更新应用：

$kubectlapply-f05-daemonset-demo3.yamldaemonset.apps.kruise.io/nginxconfigured[root@master1 ~]#kubectl get po -owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESnginx-7h2nw1/1Running1(10s ago) 2m13s 10.244.1.168 node1 <none>2/2nginx-bmzcq1/1Running1(13s ago) 2m13s 10.244.2.52 node2 <none>2/2[root@master1 ~]#kubectl describe daemon nginx......Events:TypeReasonAgeFromMessage-------------------------NormalSuccessfulCreate2m29sdaemonset-controllerCreatedpod:nginx-bmzcqNormalSuccessfulCreate2m29sdaemonset-controllerCreatedpod:nginx-7h2nwNormalSuccessfulUpdatePodInPlace29sdaemonset-controllersuccessfullyupdatepodnginx-bmzcqin-placeWarningnumUnavailable>=maxUnavailable27s(x7 over29s) daemonset-controller default/nginx number of unavailable DaemonSet pods:1,is equal to or exceeds allowed maximum:1NormalSuccessfulUpdatePodInPlace26sdaemonset-controllersuccessfullyupdatepodnginx-7h2nwin-place

• 注意：这里使用daemon就好。

[root@master1 ~]#kubectl get crd|grepkruiseadvancedcronjobs.apps.kruise.io2022-03-10T13:09:22Zbroadcastjobs.apps.kruise.io2022-03-10T13:09:22Zclonesets.apps.kruise.io2022-03-10T13:09:22Zcontainerrecreaterequests.apps.kruise.io2022-03-10T13:09:22Zdaemonsets.apps.kruise.io2022-03-10T13:09:22Zimagepulljobs.apps.kruise.io2022-03-10T13:09:22Znodeimages.apps.kruise.io2022-03-10T13:09:22Zpodunavailablebudgets.policy.kruise.io2022-03-10T13:09:22Zresourcedistributions.apps.kruise.io2022-03-10T13:09:22Zsidecarsets.apps.kruise.io2022-03-10T13:09:22Zstatefulsets.apps.kruise.io2022-03-10T13:09:22Zuniteddeployments.apps.kruise.io2022-03-10T13:09:22Zworkloadspreads.apps.kruise.io2022-03-10T13:09:22Z[root@master1 ~]#kubectl get crd daemonsets.apps.kruise.io -oyaml……spec:conversion:strategy:Nonegroup:apps.kruise.ionames:kind:DaemonSetlistKind:DaemonSetListplural:daemonsetsshortNames:-daemonsingular:daemonset……

实验结束。😘

3、BroadcastJob

这个控制器将 Pod 分发到集群中每个节点上，类似于 DaemonSet，但是 BroadcastJob 管理的 Pod 并不是长期运行的 daemon 服务，而是类似于 Job 的任务类型 Pod，在每个节点上的 Pod 都执行完成退出后，BroadcastJob 和这些 Pod 并不会占用集群资源。 这个控制器非常有利于做升级基础软件、巡检等过一段时间需要在整个集群中跑一次的工作。

💘 实验：BroadcastJob

• 比如我们声明一个如下所示的 BroadcastJob 对象：

#06-BroadcastJob.yamlapiVersion:apps.kruise.io/v1alpha1kind:BroadcastJobmetadata:name:bcj-demonamespace:defaultspec:template:spec:restartPolicy:Nevercontainers:# 一定不是一个常驻前台的进程，一定是一个任务，执行完成后需要退出的- name:counterimage:busyboxcommand:- "/bin/sh"- "-c"- "for i in 9 8 7 6 5 4 3 2 1;do echo $i;done"

• 直接创建上面的资源对象，

$kubectlapply-f06-BroadcastJob.yamlbroadcastjob.apps.kruise.io/bcj-democreated[root@master1 ~]#kubectl get bcjNAMEDESIREDACTIVESUCCEEDEDFAILEDAGEbcj-demo202087s[root@master1 ~]#kubectl get po -owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESbcj-demo-48b8q0/1Completed090s10.244.1.169node1<none>1/1bcj-demo-w9m790/1Completed090s10.244.2.53node2<none>1/1

我们可以看到创建了一个 BroadcastJob 对象后，同时启动了两个 Pod 任务，每个节点上一个，这和原生的 Job 是不太一样的。

创建的 BroadcastJob 一共有以下几种状态：

• Desired :期望的 Pod 数量（等同于当前集群中匹配的节点数量）
• Active:运行中的 Pod 数量
• SUCCEEDED:执行成功的 Pod 数量
• FAILED:执行失败的 Pod 数量

🍀 此外在 BroadcastJob 对象中还可以配置任务完成后的一些策略，比如配置 completionPolicy.ttlSecondsAfterFinished:30，表示这个 job 会在执行结束后 30s 被删除。

apiVersion:apps.kruise.io/v1alpha1kind:BroadcastJobspec:completionPolicy:type:AlwaysttlSecondsAfterFinished:30# ......

🍀 配置 completionPolicy.activeDeadlineSeconds为 10，表示这个 job 会在运行超过 10s 之后被标记为失败，并把下面还在运行的 Pod 删除掉。

apiVersion:apps.kruise.io/v1alpha1kind:BroadcastJobspec:completionPolicy:type:AlwaysactiveDeadlineSeconds:10# ......

🍀 completionPolicy 类型除了 Always 之外还可以设置为 Never，表示这个 job 会持续运行即使当前所有节点上的 Pod 都执行完成了。这里老师当时说，好像没看到具体效果……

apiVersion:apps.kruise.io/v1alpha1kind:BroadcastJobspec:completionPolicy:type:Never# ......

4、AdvancedCronJob

💘 实验：AdvancedCronJob

AdvancedCronJob 是对于原生 CronJob 的扩展版本，根据用户设置的 schedule 规则，周期性创建 Job 执行任务，而 AdvancedCronJob 的 template 支持多种不同的 job 资源：

apiVersion:apps.kruise.io/v1alpha1kind:AdvancedCronJobspec:template:# Option 1:use jobTemplate,which is equivalent to original CronJobjobTemplate:# ...# Option 2:use broadcastJobTemplate,which will create a BroadcastJob object when cron schedule triggersbroadcastJobTemplate:# ...

• jobTemplate：与原生 CronJob 一样创建 Job 执行任务
• broadcastJobTemplate：周期性创建 BroadcastJob 执行任务

• 写一个yaml

#07-acj-demo1.yamlapiVersion:apps.kruise.io/v1alpha1kind:AdvancedCronJobmetadata:name:acj-testspec:schedule:"*/1 * * * *"template:broadcastJobTemplate:spec:completionPolicy:type:AlwaysttlSecondsAfterFinished:30template:spec:restartPolicy:Nevercontainers:# 一定不是一个常驻前台的进程，一定是一个任务，执行完成后需要退出的- name:counterimage:busyboxcommand:- "/bin/sh"- "-c"- "for i in 9 8 7 6 5 4 3 2 1;do echo $i;done"

上述 YAML 定义了一个 AdvancedCronJob，每分钟创建一个 BroadcastJob 对象，这个 BroadcastJob 会在所有节点上运行一个 job 任务。

• 部署并查看

$kubectlapply-f07-acj-demo1.yamladvancedcronjob.apps.kruise.io/acj-testcreated[root@master1 ~]#kubectl get acjNAMESCHEDULETYPELASTSCHEDULETIMEAGEacj-test*/1****BroadcastJob25s[root@master1 ~]#kubectl get bcjNAMEDESIREDACTIVESUCCEEDEDFAILEDAGEacj-test-1647045420202018sacj-test-164704548021105s[root@master1 ~]#kubectl get poNAMEREADYSTATUSRESTARTSAGEacj-test-1647045420-56x7j0/1Completed033sacj-test-1647045420-nkrx40/1Completed033s

实验结束。😘

关于我

我的博客主旨：我希望每一个人拿着我的博客都可以做出实验现象，先把实验做出来，然后再结合理论知识更深层次去理解技术点，这样学习起来才有乐趣和动力。并且，我的博客内容步骤是很完整的，也分享源码和实验用到的软件，希望能和大家一起共同进步！

各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人免费帮您解决问题：

1. 个人微信二维码：x2675263825 （舍得）， qq：2675263825。

2. 个人微信公众号：云原生架构师实战

3. 个人博客地址：www.onlyonexl.cn

4. 个人csdn

https:

版权：此文章版权归 One 所有，如有转载，请注明出处!

链接：可点击右上角分享此页面复制文章链接