测验：应用设计与构建

我列出了三个初始化容器，但第二个容器一直失败。 Pod 的状态如何？

• 跳过第三个 init 容器并启动主容器。
• Pod 立即更改为 Failed 并且不会重试。
• 保持状态Init:1/3并且主容器未启动
• 主容器启动但未变为“就绪”状态。

为 initContainers 中的容器设置 restartPolicy: Always 后会有什么变化？

• 订单保证解除，与主集装箱同时启动。
• 作为原生 sidecar，它在 main 之前启动并继续存在，而在 Job 中，它在 main 结束时一起结束。
• 只有 init 容器会忽略 pod 级别的 restartPolicy 并且永远不会重新启动。
• 即使 init 容器失败，Pod 也会继续运行

为 Job 设置 completions: 6、parallelism: 2、backoffLimit: 3。如何正确理解这些设置？

• 每次运行 2 次，持续 6 分钟，然后重试 3 次
• 2个pod各重复使用6次，失败时3秒后重试。
• 一次启动 6 个 pod，只有 2 个成功。
• 最多同时执行2个Pod，直到成功的Pod数量达到6个，如果累计失败数量超过3个，则确认作业失败。

concurrencyPolicy: Replace和startingDeadlineSeconds: 120给了 CronJob。正确的解释是什么？

• 如果先前的运行仍在运行，则它会终止并开始新的作业。如果错过预定时间超过 120 秒，则跳过该运行。
• 执行只允许 120 秒，然后终止。
• 如果之前的运行正在运行，则新的运行将排队并在 120 秒后开始。
• 如果之前的运行正在运行，则将跳过新的运行并每 120 秒重试一次。

pod 规范中的command和args分别在容器镜像中覆盖什么？

• command覆盖 CMD，args覆盖 ENTRYPOINT
• 两者都覆盖CMD并按顺序连接。
• command从 shell 运行，args从 exec 运行
• command覆盖 ENTRYPOINT，args覆盖 CMD

为什么Job创建的pod中不能使用restartPolicy: Always？

• 这是因为只有当并行度为 1 时才允许使用 Always。
• 这是因为如果使用 Always，则会忽略 backoffLimit 并发生无限重试。
• Job无法统计成功次数，因为Pod并没有进入终止状态，而是不断重启。
• Always 是仅部署值，因此它在 API 验证中被阻止，但它在作业中也适用。