Kubernetes

Readiness 与 liveness 回答不同的运维问题。就绪探针判断当前容器是否应该参与一个能够接收普通 Service 流量的 Pod，存活探针则判断是否应该执行预先配置的容器重启恢复。两者都可以使用 HTTP，但协议相同不代表语义相同。应先确定希望平台采取什么动作，再设计触发该动作的条件，否则一个健康接口可能同时承担互相冲突的责任。 同时观察响应和平台动作 就绪探针失败会让容器变成未就绪，并影响 Pod 的 Ready 条件。对于普通带选择器的 Service，端点协调随后改变哪些后端可以参加正常路由。Pod 可以保持 Running，同时处于未就绪状态，应用进程也可能继续运行。重启次数、Pod 标识和 Ready 条件回答的是不同问题，排查时不能只看其中一个状态就推导全部行为。 存活探针连续失败达到配置阈值后，kubelet 会终止容器并按相应重启规则处理。普通 Always 策略应用 Pod 会在原 Pod 中获得替换容器，而不是必然创建一个新 Pod 对象，也不是发布另一版应用。应在比较 Pod 身份的同时查看容器重启次数与终止状态，避免把一次进程恢复误报为完整工作负载替换。 检查应便宜，而且成功条件要具有实际含义。TCP 连接成功只证明监听端能够接受连接，不证明应用能够完成有用工作。HTTP 可以表达更丰富的问题，但如果它递归调用昂贵的依赖检查，也可能成为额外负载来源。探针自己的执行成本应符合工作负载容量和超时预算，不能让健康检查本身把健康服务压慢。 坏掉的样子 把共享数据库故障当成存活失败，可能导致所有正常应用进程不断重启，却完全无法修复数据库。把同一个依赖直接加入就绪检查也需要判断：撤走全部副本可能同时撤掉本来有价值的降级响应，在局部故障中还可能把流量集中到剩余副本。应依据服务实际契约定义就绪，包括已经明确支持的部分可用行为，而不是照抄统一依赖清单。 就绪状态不是网络访问控制。即使某个 Pod 不再属于 Service 的就绪目标，它的地址仍可能被直接访问。既有连接、其他路由层，以及 publishNotReadyAddresses 等 Service 设置，也需要单独分析。因此，不能把 readiness 失败描述成一个瞬时保证，认为从此没有任何请求能够到达进程。它改变的是对应服务发现和路由流程中的资格。 ...

普通 init container 在 Pod 的应用容器启动之前执行准备工作。它有自己的命令、镜像和文件系统视图，也可以挂载应用稍后读取的共享卷。这让前置步骤与主进程分开，但不意味着任意初始化操作都会自动安全，也不意味着重试默认存在固定次数上限。应根据真实重试方式及产物生命周期设计这个步骤，而不是把启动顺序当成完整容错机制。 顺序约束只属于一个 Pod Kubelet 按声明顺序运行普通初始化容器。每一步必须成功结束，下一步才开始，应用容器则等待整个序列完成。检查 initContainerStatuses，才能区分正在等待的步骤、运行中的步骤和已经终止的某次尝试。仅查看 Pod 的阶段，无法说明哪条命令失败，也无法说明新的尝试是否正在进行；排查需要结合具体容器状态和日志。 共享存储需要显式挂载。emptyDir 可以在初始化容器与应用容器之间传递生成文件，并在同一 Pod 内的容器重启期间保留，但会随着 Pod 消失。不同容器不会自动共享镜像根文件系统，只写在初始化容器可写层中的文件，不会自然出现在应用容器里面。产物的写入位置和读取位置必须通过真实卷定义对应起来。 普通初始化容器需要运行到完成。Kubernetes 也支持在 initContainers 中通过容器级 restartPolicy Always 表示可重启边车，它们具有不同生命周期。因此，不能仅因为某个条目位于这个字段，就认定它必须退出后应用才能继续。本例只使用普通初始化容器，不把持续运行的边车混进顺序完成模型。 坏掉的样子 非零退出并不总会让整个 Pod 立即失败。在普通应用 Pod 采用 Always 策略时，失败的普通初始化容器会继续重试，直到成功；已经成功的初始化步骤则不会因为应用仍在运行就不断重启。退避会放慢连续尝试，却不是固定的重试次数限制。如果 Pod 的 restartPolicy 为 Never，初始化失败会使该 Pod 进入失败状态，恢复方式需要另行安排。 准备脚本应能够安全面对前一次留下的内容。中断的下载可能留下半个文件，emptyDir 中的标记也可能在失败进程退出后继续存在。应验证完整产物，再明确交付给消费者。下面用于记录次数的计数器只是诊断数据，不能作为生产逻辑，推断某个外部依赖在第二次尝试时就必然可用。真实条件必须由对应检查来判断。 ...