Kubernetes

Readiness 与 liveness 回答不同的运维问题。就绪探针判断当前容器是否应该参与一个能够接收普通 Service 流量的 Pod，存活探针则判断是否应该执行预先配置的容器重启恢复。两者都可以使用 HTTP，但协议相同不代表语义相同。应先确定希望平台采取什么动作，再设计触发该动作的条件，否则一个健康接口可能同时承担互相冲突的责任。 Kubernetes 1.34.11 观察属于历史记录，本次未重跑。直接 HTTP 检查仅从同一 Pod 访问自身地址。就绪状态不是网络访问控制；样例不证明优雅排空或生产可用性。执行仍为受阻。 同时观察响应和平台动作 就绪探针失败会让容器变成未就绪，并影响 Pod 的 Ready 条件。对于普通带选择器的 Service，端点协调随后改变哪些后端可以参加正常路由。Pod 可以保持 Running，同时处于未就绪状态，应用进程也可能继续运行。重启次数、Pod 标识和 Ready 条件回答的是不同问题，排查时不能只看其中一个状态就推导全部行为。 存活探针连续失败达到配置阈值后，kubelet 会终止容器并按相应重启规则处理。普通 Always 策略应用 Pod 会在原 Pod 中获得替换容器，而不是必然创建一个新 Pod 对象，也不是发布另一版应用。应在比较 Pod 身份的同时查看容器重启次数与终止状态，避免把一次进程恢复误报为完整工作负载替换。 ...

普通 init container 在 Pod 的应用容器启动之前执行准备工作。它有自己的命令、镜像和文件系统视图，也可以挂载应用稍后读取的共享卷。这让前置步骤与主进程分开，但不意味着任意初始化操作都会自动安全，也不意味着重试默认存在固定次数上限。应根据真实重试方式及产物生命周期设计这个步骤，而不是把启动顺序当成完整容错机制。 原文历史样例，本次未重跑；执行仍受阻。普通初始化顺序仅限单个 Pod。显式 emptyDir 在容器重启后保留，但随 Pod 消失；不表示持久化或整组副本串行化。 顺序约束只属于一个 Pod Kubelet 按声明顺序运行普通初始化容器。每一步必须成功结束，下一步才开始，应用容器则等待整个序列完成。检查 initContainerStatuses，才能区分正在等待的步骤、运行中的步骤和已经终止的某次尝试。仅查看 Pod 的阶段，无法说明哪条命令失败，也无法说明新的尝试是否正在进行；排查需要结合具体容器状态和日志。 共享存储需要显式挂载。emptyDir 可以在初始化容器与应用容器之间传递生成文件，并在同一 Pod 内的容器重启期间保留，但会随着 Pod 消失。不同容器不会自动共享镜像根文件系统，只写在初始化容器可写层中的文件，不会自然出现在应用容器里面。产物的写入位置和读取位置必须通过真实卷定义对应起来。 ...