KIND: DaemonSet
VERSION: apps/v1
RESOURCE: updateStrategy <Object>
DESCRIPTION:
An update strategy to replace existing DaemonSet pods with new pods.
DaemonSetUpdateStrategy is a struct used to control the update strategy for
a DaemonSet.
FIELDS:
rollingUpdate <Object>
Rolling update config params. Present only if type = "RollingUpdate".
type <string>
Type of daemon set update. Can be "RollingUpdate" or "OnDelete". Default is
RollingUpdate.
查看 rollingUpdate 支持的更新策略
] kubectl explain ds.spec.updateStrategy.rollingUpdate
KIND: DaemonSet
VERSION: apps/v1
RESOURCE: rollingUpdate <Object>
DESCRIPTION:
Rolling update config params. Present only if type = "RollingUpdate".
Spec to control the desired behavior of daemon set rolling update.
FIELDS:
maxUnavailable <string>表示 rollingUpdate 更新策略只支持 maxUnavailabe,先删除在更新;因为我们不支持一个
节点运行两个 pod,因此需要先删除一个,在更新一个。
更新镜像版本,可以按照如下方法:
kubectl set image daemonsets fluentd-elasticsearch *=ikubernetes/filebeat:5.6.6-alpine -n kube-system
kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N [options]
Job 控制器用于管理 Pod 对象运行一次性任务,比方说我们对数据库备份,可以直接在 k8s 上启动一个 mysqldump 备份程序,也可以启动一个 pod,这个 pod 专门用来备份用的,备份结束 pod 就可以终止了,不需要重启,而是将 Pod 对象置于"Completed"(完成)状态,若容器中的进程因错误而终止,则需要按照重启策略配置确定是否重启,对于 Job 这个类型的控制器来说,需不需要重建 pod 就看任务是否完成,完成就不需要重建,没有完成就需要重建 pod。
Job 控制器的 Pod 对象的状态转换如下图所示:
Job 用来创建 1 个或多个 Pod,并保证指定数量(.spec.completions)的 Pod 成功完成。当一个 Pod成功完成时(.status.phase=Succeeded),Job 会记录已完成的 Pod 的数量,但完成的数量达到指定值时,这个 Job 就完成了。
可以通过以下 3 种方式来判断一个 Job 是否已完成:
.status.completionTime 是否为空。Job 完成时该字段会被设置成 Job 完成的时间,否则为空
.spec.completions 和.status.succeeded 是否相等,即对比期望完成数和已成功数,当二者相等时,表示 Job 已经完成
.status.conditions[0].type:type 为 Complete 和 Failed 时,分别表示 Job 执行成功和失败
Pod 中的容器可能因为各种各样的原因失败,比如退出码不为 0、超出内存限制被 kill 掉,容器失败分两种情况:
.spec.template.spec.restartPolicy = "OnFailure":容器失败后会不断重启,直到成功(退出码为 0)
.spec.template.spec.restartPolicy = "Never":容器不会重启,Pod 的状态转为 Failed当 Pod 执行失败时,Job 会不断创建一个新的 Pod 进行重试,直到失败次数达到.spec.backoffLimit 指定的数值,整个 Job 的执行失败。可以通过判断.status.failed和.spec.backoffLimit 是否相等,即已失败数是否已经达到上限,来判断 Job 是否已经执行失败。
如下,当.spec.backoffLimit 设置为 3 时,.status.failed 已经达到 3,Job 失败,不会再尝试创建新的Pod
Job 三种使用场景:
1、非并行任务:只启一个 pod,pod 成功,job 正常结束
2、并行任务同时指定成功个数:.spec.completions 为指定成功个数,可以指定也可以不指定.spec.parallelism(指定>1,会有多个任务并行运行)。当成功个数达到.spec.completions,任务结束。
3、有工作队列的并行任务:.spec.completions 默认为 1,.spec.parallelism 为大于 0 的整数。此时并行启动多个 pod,只要有一个成功,任务结束,所有 pod 结束
适用场景:
Job 不是设计用来完成通信密集型的并行程序,如科学计算领域常见的场景。它支持并行地处理一组独立但相关的 work item,如发送邮件,渲染帧,转码文件和扫描 NoSql 数据库中的 key
相关配置:
.spec.completions:完成该 Job 需要执行成功的 Pod 数
.spec.parallelism:能够同时运行的 Pod 数
.spec.backoffLimit:允许执行失败的 Pod 数,默认值是 6,0 表示不允许 Pod 执行失败。如果Pod 是 restartPolicy 为 Nerver,则失败后会创建新的 Pod,如果是 OnFailed,则会重启 Pod,不管是哪种情况,只要 Pod 失败一次就计算一次,而不是等整个 Pod 失败后再计算一个。当失败的次数达到该限制时,整个 Job 随即结束,所有正在运行中的 Pod 都会被删除。
.spec.activeDeadlineSeconds: Job 的超时时间,一旦一个 Job 运行的时间超出该限制,则 Job失败,所有运行中的 Pod 会被结束并删除。该配置指定的值必须是个正整数。不指定则不会超时
网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。
加入交流群
请使用微信扫一扫!