关于kubernetes:k8s集群Job-Pod-容器可能因为多种原因失效想要更加稳定的使用Job负载有哪些需要注意的地方

k8s 集群 Job Pod 容器可能因为多种起因生效，想要更加稳固的应用 Job 负载，有哪些须要留神的中央？

面试官：“计数性 Job 默认实现模式是什么？Indexed 模式如何公布自定义索引呢？”

面试官：“k8s 的 Job Pod 中的容器可能因为多种不同起因生效，想要更加稳固的应用 Job 负载，有哪些能够留神的中央？“

面试官：“为什么 k8s 倡议在调试 Job 时将 `restartPolicy` 设置为 "Never"？”

面试官：“Job 终止与清理理解嘛？Pod 重试次数还未 达到 `backoffLimit` 所设的限度，为什么忽然被终止了？猜想起因？“

囧么肥事 - 胡言乱语

计数性 Job 默认实现模式是什么？Indexed 模式如何公布自定义索引呢？

计数性 Job 默认实现模式是无索引模式NonIndexed。

实际上，带有 确定实现计数 的 Job，即 .spec.completions 不为 null 的 Job，都能够在其 .spec.completionMode 中设置实现模式：NonIndexed（默认）和Indexed 两种。

先看默认模式 NonIndexed，无索引模式👨‍💻‍

1、每个 Job 实现事件都是独立无关且同质的
2、胜利实现的 Pod 个数达到.spec.completions 值时认为 Job 曾经实现
3、当.spec.completions 取值 null 时，Job 被隐式解决为 NonIndexed

再看 Indexed，索引模式👨‍💻‍

1、Job 的 Pod 会调配对应的实现索引
2、索引取值为 0 到.spec.completions-1
3、当每个索引都对应一个实现的 Pod 时，Job 被认为是已实现的
4、同一索引值可能被调配给多个 Pod，然而只有一个会被记入实现计数

对于索引模式来说，我下发 10 个索引，我不关注 10 个索引别离由多少个 Pod 去实现，我只关注 10 个索引工作是否按需实现即可。

Indexed 模式下，索引有三种获取形式：🤓

• 第一种：基于注解，Pod 索引在注解 batch.kubernetes.io/job-completion-index中出现，具体示意为一个十进制值字符串。
• 第二种：基于主机名，作为 Pod 主机名的一部分，遵循模式 $(job-name)-$(index)。当你同时应用带索引的 Job（Indexed Job）与服务（Service），Job 中的 Pods 能够通过 DNS 应用确切的主机名相互寻址。
• 第三种：基于环境变量，对于容器化的工作，在环境变量 JOB_COMPLETION_INDEX 中体现。

Indexed 模式如何公布自定义索引呢？

下面提到了三种获取索引的形式：注解，主机名，环境变量。

Downward API 机制有两种形式能够把将 Pod 和 Container 字段信息出现给 Pod 中运行的容器：

• 环境变量
• 卷文件

你应用 Job 控制器为所有容器设置的内置 JOB_COMPLETION_INDEX 环境变量。Init 容器将索引映射到一个动态值 ，并将其写入一个文件，该文件 通过 emptyDir 卷与运行 worker 的容器共享。

举例👨‍💻‍

1. 定义应用 带索引实现信息的 Job 清单。
2. Downward API 将 Pod 索引正文作为环境变量 或文件 传递给容器。例如环境变量管制立体主动设置 downward API 以在 JOB_COMPLETION_INDEX 环境变量中公开索引
3. 依据该清单启动一个带索引（Indexed）的 Job。

Pod 中的容器可能因为多种不同起因生效，想要更加稳固的应用 Job 负载，有哪些能够留神的中央？

首先须要了解的是，生效有两种模式，须要适配的能力也不同。

第一种 Pod 治理的局部容器生效

第二种 Pod 生效

第一种 Pod 治理的局部容器生效

Pod 中的容器可能因为多种不同起因生效，例如因为其中的过程退出时返回值非零，或者容器因为超出内存束缚而被杀死等。

如果产生这类事件，并且 .spec.template.spec.restartPolicy = "OnFailure"，Pod 则持续留在以后节点，但容器会被从新运行。

面对这种场景，你的程序须要具备可能解决在本地被重启的状况的能力，或者容器设置 .spec.template.spec.restartPolicy = "Never"

留神 ，即便你将 .spec.parallelism 设置为 1，且将 .spec.completions 设置为 1，并且 .spec.template.spec.restartPolicy 设置为 “Never”， 同一程序依然有可能被启动两次😈，程序猿思维：“永远不要假想某某状况不会产生🤣🤣🤣”。

它就产生了，你能咋滴，不论啊？？？🤡🤡🤡

第二种 Pod 生效

整个 Pod 也可能会失败，且起因各不相同。😇😇😇

例如，当 Pod 启动时，节点生效（被降级、被重启、被删除等）🙃

或者其中的 容器失败 并且设置了 .spec.template.spec.restartPolicy = "Never"。

当 Pod 失败时，Job 控制器会启动一个新的 Pod 替身，去接替失败的 Pod 未解决实现的工作。

这意味着，你的利用须要解决在一个新 Pod 中被重启的状况。尤其是利用须要 解决之前运行所产生的临时文件、锁、不残缺的输入 等问题。

再次留神😈

如果你将 .spec.parallelism 和 .spec.completions 都设置为比 1 大的值，那就有可能同时呈现多个 Pod 运行的状况。

为此，你的 Pod 也必须可能解决并发性问题☺️。

为什么 k8s 倡议在调试 Job 时将 restartPolicy 设置为 “Never”？

答复这个问题前，先看下 Job Pod 回退生效策略

在有些情景下，你可能心愿 Job 在经验若干次重试之后间接进入失败状态，因为这很可能意味着 Job 遇到了配置谬误。

• .spec.backoffLimit 字段设置 Job Pod 回退生效策略，标识 Job 失败重试次数，生效回退的限度值默认为 6。
• 与 Job 相干的 生效的 Pod 会被 Job 控制器 重建 ，同时 回退重试工夫将会按指数增长（从 10 秒、20 秒到 40 秒）最多至 6 分钟。
• 当 Job 的 Pod 被删除，或者 Pod 胜利时没有其它 Pod 处于失败状态，生效回退的次数也会 被重置（为 0）。

好了，这下能够答复方才的问题，为什么重启策略要设置为 Never?

如果你的 Job 的 restartPolicy 被设置为 “OnFailure“，那么该 Job 治理的 Pod 会在 Job 达到 生效回退次数下限时主动被终止。

Pob 被终止，那么调试 Job 中可执行文件的工作变得十分辣手，难以把控。兴许你刚调试没多久，后果 Pod 终止了，调试过程中断了，失望不！！！

为了 解决 Pod 终止后 Jobs 的输入遗失掉的问题，k8s 倡议在调试 Job 时将 restartPolicy 设置为 “Never”，或者应用日志零碎来确保生效 Jobs 的输入不会意外遗失。

Job 终止与清理理解嘛？Pod 重试次数还未 达到 backoffLimit 所设的限度，为什么忽然被终止了？猜想起因？

Job 终止和清理策略

Job 实现时不会再创立新的 Pod，不过已有的 Pod 也不会被删除。

保留这些 Pod 使得你能够 查看已实现的 Pod 的日志输入，以便查看谬误、正告 或者其它诊断性输入。

Job 实现时 Job 对象也一样被保留下来，这样你就能够查看它的状态。

删除老的 Job 的操作留给了用户本人，在查看了 Job 状态之后，你能够应用 kubectl 来删除 Job（例如，kubectl delete jobs/pi 或者 kubectl delete -f ./job.yaml）。当应用 kubectl 来删除 Job 时，该 Job 所创立的 Pods 也会被删除。

默认状况下，Job 会继续运行，除非某个 Pod 失败（restartPolicy=Never）或者某个容器出错退出（restartPolicy=OnFailure）。这时，Job 基于前述的 spec.backoffLimit 来决定是否以及如何重试。一旦重试次数达到 .spec.backoffLimit 所设的下限，Job 会被标记为失败，其中运行的 Pods 都会被终止。

终止 Job 的 另一种形式是设置一个沉闷期限。你能够为 Job 的 .spec.activeDeadlineSeconds 设置一个秒数值。该值实用于 Job 的整个生命期，无论 Job 创立了多少个 Pod。一旦 Job 运行工夫达到 activeDeadlineSeconds 秒，其所有运行中的 Pod 都会被终止，并且 Job 的状态更新为 type: Failed 及 reason: DeadlineExceeded。

留神 Job 的 .spec.activeDeadlineSeconds 优先级高于其 .spec.backoffLimit 设置。因而，如果一个 Job 正在重试一个或多个生效的 Pod，该 Job 一旦达到 activeDeadlineSeconds 所设的时限，即不再部署额定的 Pod，即便其重试次数还未达到 backoffLimit 所设的限度。

留神问题

Job 规约和 Job 中的 Pod 模版规约都有 activeDeadlineSeconds 字段。请确保你在适合的档次设置正确的字段。

还要留神的是，restartPolicy 对应的是 Pod，而不是 Job 自身：一旦 Job 状态变为 type: Failed，就不会再产生 Job 重启的动作。换言之，由 .spec.activeDeadlineSeconds 和 .spec.backoffLimit 所触发的 Job 终结机制 都会导致 Job 永久性的失败，而这类状态都须要手工干涉能力解决。

Kubernetes 举荐学习书

Kubernetes 权威指南 PDF
链接:https://pan.baidu.com/s/11huL… 提取码:sa88

k8s 系列所有问题更新记录：GitHub Gitee