OpenKruise Enhanced LivenessProbe 方案解析：从 kubelet 单机探测到集群级应用可用性保护

云原生容器编排微服务运维【免费下载链接】kruiseAutomated management of large-scale applications on Kubernetes (incubating project under CNCF)项目地址https://gitcode.com/gh_mirrors/kr/kruise点击查看免费下载OpenKruise 提出的增强版 livenessProbeEnhanced LivenessProbe解决方案是一套与 Kubernetes 社区标准 livenessProbe 设计兼容、但能力全面超越后者的容器存活探测与自动恢复体系。它由「Webhook 转换 NodePodProbe 资源映射 集群级决策控制器 节点侧探针执行器」四部分组成把探测与重启决策从 kubelet 单机内部解耦出来并在重启前引入全局熔断开关、黑名单、全局限流、maxUnavailable 保护等韧性策略。读完本文你将掌握该方案的完整架构、Pod 注解与 CRD 数据结构、CRR 容器重建机制、端到端故障处理流程以及如何在 OpenKruise 中开启并使用这一能力。本文以仓库内提案文档 docs/proposals/20240327-enhancedlivenessprobe.md 为主体并结合仓库源码Webhook、NodePodProbe CRD、kruise-daemon 探针执行器、CRR 等进行印证与扩充。一、为什么需要增强版 livenessProbeKubernetes 社区标准 livenessProbe 解决了「进程存活但业务不健康」如服务进程挂起场景下的自动恢复问题kubelet 周期性探测容器探测失败即直接重启容器。但这一机制对在线应用而言存在明显的韧性缺陷提案文档从三个层面总结了它的不足探测配置错误的代价极高。livenessProbe 配置项多、内容复杂一旦配置不当探针生效后会导致所有服务容器被批量触发重启可能造成灾难性的服务中断甚至在重启过程中引发服务雪崩。缺少应用级全局视角。社区方案的设计思想中没有「应用级」概念完全依赖节点机器级别的探测与重启决策即 kubelet 在单节点上独立判断。缺少韧性保护策略。从稳定性角度看社区原生方案缺乏应用级全局高可用与任何弹性保护resilience protection策略。结合上述缺陷OpenKruise 在设计上提出并实现了增强版 livenessProbe 应用存活解决方案计划作为核心能力开源让更多用户受益。二、方案总览四个组件各司其职增强版 livenessProbe 方案由「两个控制器、一个 Webhook 和一个节点探测组件」构成具体如下表组件运行位置职责EnhancedLivenessProbeWebhookKruise-managerPod 创建时将原生 livenessProbe 转换为 Pod 注解中的特定字符串配置字段LivenessNodeProbeControllerKruise-manager将注解中的 livenessProbe 配置转换为 NodePodProbeKruise 自定义资源并维护其增删改EnhancedLivenessProbeControllerKruise-manager监听 NodePodProbe 状态变化结合探测失败 Pod 分析应用负载状态综合韧性保护与 maxUnavailable 保护策略决定是否用 CRR 重启容器LivenessProbeDetectorKruise-daemon与 kubelet 探测逻辑相同的节点侧探测器支持 tcp/http/exec 等探测方式基于 NodePodProbe 资源执行整体架构与决策链路如下图所示其中NodePodProbe 资源在 Pod 不同生命周期事件创建/更新/删除下的流转关系如下三、EnhancedLivenessProbeWebhook把原生探针搬进注解当 Pod 携带注解apps.kruise.io/using-enhanced-liveness: true创建时Webhook 会准入 Pod 资源移除原生 livenessProbe 字段并把探针配置以 JSON 格式写入注解apps.kruise.io/container-probe-context。在仓库中这一逻辑的源码实现位于 pkg/webhook/pod/mutating/enhancedlivenessprobe_handler.gousingEnhancedLivenessProbe判断apps.kruise.io/using-enhanced-liveness trueremoveAndBackUpPodContainerLivenessProbe遍历pod.Spec.Containers收集每个容器的LivenessProbe将其置空移除原生配置再序列化为 JSON 写入注解两个注解常量在 apis/apps/v1alpha1/well_know_annotations.go 与 v1beta1 同名文件中定义AnnotationUsingEnhancedLiveness apps.kruise.io/using-enhanced-livenessAnnotationNativeContainerProbeContext apps.kruise.io/container-probe-context该 Webhook 是 Pod 创建变更链路的一环见 pkg/webhook/pod/mutating/pod_create_update_handler.go仅在EnhancedLivenessProbeGateFeatureGate 开启时生效且仅处理 Create 操作、非子资源请求、由 Kruise 工作负载管理的 PodIsPodOwnedByKruise校验。对应的单元测试在 pkg/webhook/pod/mutating/enhancedlivenessprobe_handler_test.go覆盖了单容器、多容器混合探针、无探针容器以及注解缺失/为false等场景其中期望的注解 JSON 形如[{name:c1,livenessProbe:{httpGet:{path:/health,port:7001,scheme:HTTP},initialDelaySeconds:3000,timeoutSeconds:5,periodSeconds:100,successThreshold:1,failureThreshold:3}}]转换后的 Pod 示例如下来自提案文档apiVersion: v1 kind: Pod metadata: annotations: apps.kruise.io/container-probe-context: [{name:app,livenessProbe:{exec:{command:[/bin/sh,-c,/healthy.sh]},initialDelaySeconds:1000,timeoutSeconds:5,periodSeconds:100,successThreshold:1,failureThreshold:3}}] generateName: clone-foo-crflxhk4hn- name: clone-foo-crflxhk4hn-khlxd namespace: enhanced-livenessprobe-map-nodeprobe-klt8j ownerReferences: - apiVersion: apps.kruise.io/v1alpha1 blockOwnerDeletion: true controller: true kind: CloneSet name: clone-foo-crflxhk4hn uid: a2057688-5f1e-4489-99f3-02a18e2d5442 uid: 1ad8e5b3-0b0c-4367-a64b-1b3c97bf1686 spec: containers: - command: - /bin/sh - -c - sleep 1000 image: nginx:1.14.2 imagePullPolicy: IfNotPresent name: app terminationMessagePath: /dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst enableServiceLinks: true nodeName: node-test-worker preemptionPolicy: PreemptLowerPriority priority: 0 restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: default serviceAccountName: default terminationGracePeriodSeconds: 30注意容器app的spec.containers[].livenessProbe已被移除探针配置整体保存在注解中。四、LivenessNodeProbeController把注解转换为 NodePodProbe 资源为了让 NodePodProbe 控制器能够处理注解中的 livenessProbe 配置必须转换为 Kruise 套件中的 NodePodProbe 自定义资源。该控制器负责创建与更新NodePodProbe 资源其 reconcile 过程按 Pod 的创建/更新/删除事件分别处理Pod 创建若不存在与该 Pod 关联的 NodePodProbe 资源则创建新资源Pod 更新同步更新 NodePodProbe 中的探针配置Pod 删除若 NodePodProbe 中不再包含该 Pod 的其他探针配置则删除对应条目。4.1 NodePodProbe 资源结构NodePodProbe 是一个集群级Cluster scope自定义资源以节点名命名每节点一个定义见 apis/apps/v1alpha1/node_pod_probe_types.gospec.podProbes[]每个条目对应一个 Pod含name、namespace、uid、IP其probes[]描述该 Pod 内需要探测的容器spec.podProbes[].probes[].probe即ContainerProbeSpec包含exec/httpGet/tcpSocket等探针动作及failureThreshold、initialDelaySeconds、periodSeconds、successThreshold、timeoutSeconds参数status.podProbeStatuses[]记录探测结果state取值Succeeded/Failed/Unknown并带lastProbeTime、lastTransitionTime、message。提案文档给出的 NodePodProbe 示例对应上面那个 PodapiVersion: apps.kruise.io/v1alpha1 kind: NodePodProbe metadata: name: node-test-worker uid: 973b5257-a8f7-4247-996b-f8e0fb9492db spec: podProbes: - name: clone-foo-crflxhk4hn-khlxd namespace: enhanced-livenessprobe-map-nodeprobe-klt8j probes: - containerName: app name: clone-foo-crflxhk4hn-khlxd-app probe: exec: command: - /bin/sh - -c - /healthy.sh failureThreshold: 3 initialDelaySeconds: 1000 periodSeconds: 100 successThreshold: 1 timeoutSeconds: 5 uid: 1ad8e5b3-0b0c-4367-a64b-1b3c97bf16864.2 控制器侧的维护逻辑仓库中负责维护 NodePodProbe 资源生命周期的控制器位于 pkg/controller/nodepodprobe/node_pod_probe_controller.go它同时 Watch NodePodProbe、Pod、Node 三类对象node_pod_probe_controller.go当节点对应的 NodePodProbe 不存在时创建之当 Node 被删除或处于删除中时删除对应 NodePodProbesyncPodFromNodePodProbe按npp.Spec.PodProbes反查 Pod过滤掉已不存在、非活跃或 UID 不匹配的条目回收与 Pod 生命周期绑定的探针配置探测结果会由该控制器回写到 Pod 的 Condition 与 Labels/Annotations。五、EnhancedLivenessProbeController集群级决策与韧性保护这是方案的核心决策单元。它监听配置了 livenessProbe 的 Pod 所关联的 NodePodProbe 状态变化一旦发现探针失败立即判断是否通过CRRContainerRecreateRequestKruise 自定义资源执行容器重启逻辑。5.1 决策前的应用可用性保护为兼顾应用高可用与服务保护该控制器的架构设计与 Kruise 的PodUnavailableBudget功能以及一系列异常检测算法全局开关、黑名单、全局限流规则等协同在执行容器重启前先做可用性保护避免因批量重启导致无可用服务创建 CRR 时PodUnavailableBudget 控制器会考虑 maxUnavailable 保护策略——部分 Pod 可能因 CRR 处理而暂时不可用当请求违反 maxUnavailable 保护策略时PodUnavailableBudget Webhook 会拒绝 CRR 的创建典型风险场景因网络或探针配置错误等意外原因导致所有容器探测全部失败。5.2 通过 CRR 完成容器重建当决策通过保护策略后EnhancedLivenessProbeController 创建 CRR 资源。提案文档给出的 CRR 示例apiVersion: apps.kruise.io/v1alpha1 kind: ContainerRecreateRequest metadata: labels: crr.apps.kruise.io/node-name: pod-node-name crr.apps.kruise.io/pod-name: clone-foo-crflxhk4hn-khlxd crr.apps.kruise.io/pod-uid: 1ad8e5b3-0b0c-4367-a64b-1b3c97bf1686 name: clone-foo-crflxhk4hn-khlxd-b1e8901771bc namespace: enhanced-livenessprobe-map-nodeprobe-klt8j spec: containers: - name: app statusContext: containerID: docker://e92a39jhg9ddk8k6f8321and45723daf1ac5fe restartCount: 1 podName: clone-foo-crflxhk4hn-khlxd strategy: failurePolicy: Fail terminationGracePeriodSeconds: 1CRR 的类型定义见 apis/apps/v1alpha1/containerrecreaterequest_types.go关键语义包括spec.podNamespec.containers[]指明要重建哪个 Pod 的哪些容器statusContext由系统在创建时从真实 Pod 状态同步strategy.failurePolicyFail任一容器重建失败即标记失败或Ignorestrategy.terminationGracePeriodSeconds优雅终止等待时长为 nil 时默认取pod.Spec.TerminationGracePeriodSeconds标签crr.apps.kruise.io/node-name/pod-name/pod-uid分别标注目标节点与 Pod 身份常量见 containerrecreaterequest_types.gocrr.apps.kruise.io/active标记 CRR 是否活跃。CRR 的实际执行发生在 kruise-daemon 侧daemon 内的容器重建控制器 Watch 本节点上activetrue的 CRRpkg/daemon/containerrecreate/crr_daemon_controller.go对目标容器调用运行时管理器的KillContainer完成旁路杀掉随后由 kubelet 依据 Pod 的restartPolicy: Always尽快拉起容器。被重建容器重启后其容器 ID 变化探针 worker 会重新进入正常探测周期。5.3 全局流控令牌桶限制重启频率EnhancedLivenessProbeController 中实现了全局流控逻辑其基本框架是一个令牌桶算法用于控制探测失败 Pod 的应用重启频率当令牌被允许时算法取出队列中的 nodePodProbe 元素为其创建 CRR 以重启失败容器该算法保证每个失败的 livenessProbe Pod 只创建一个 CRR当同一 Pod 内存在多个失败容器时算法会按顺序为该 Pod 的容器逐个创建 CRR通过这一机制确保失败的 NodePodProbes 不会被同时处理避免同 Pod 内多个容器同时重启。对于本控制器创建的 CRR 垃圾回收EnhancedLivenessProbeController 会周期性检查现有 CRR 与相关 NodePodProbe 的映射关系删除已完成succeeded/failed/completed状态的 CRR 资源。六、LivenessProbeDetectorkruise-daemon 中的节点探针执行器在节点组件中探针检测器是 Kruise-daemon 内的 NodePodProbe 控制器支持TCP / HTTP / EXEC探测提案文档还提到 RPC。该设计绕过了原生 kubelet 的探测能力改为检查自定义的 NodePodProbe 资源配置并周期性回报状态从而避免「kubelet 探测失败后直接重启容器」这一激进行为。6.1 执行器与结果上报相关实现位于 pkg/daemon/podprobe/pod_probe_controller.go每个节点上的 daemon 通过metadata.namenodeName的 FieldSelector 只 Watch 本节点的 NodePodProbepod_probe_controller.gosync根据spec.podProbes为每个「Pod-容器-探针」组合创建独立的 workerpod_probe_controller.go探针配置变化时热更新 worker条目消失时停止 worker探测结果由结果管理器汇总写回 NodePodProbe 的status.podProbeStatuses并向 Pod 发出KruiseProbeSucceeded/KruiseProbeFailed事件pod_probe_controller.go。6.2 三种探测动作的实现探针执行核心在 pkg/daemon/podprobe/prober.goExec通过 CRI 的ExecSync在容器内执行命令prober.goHTTPGet基于 Pod IP 与端口构造 HTTP GET 请求User-Agent、Accept等头按 kubelet 语义补齐prober.goTCPSocket按podIP:port做 TCP 连通性探测prober.go。worker 的探测循环pkg/daemon/podprobe/worker.go实现了与 kubelet 一致的语义periodSeconds控制探测周期、initialDelaySeconds内不探测、failureThreshold/successThreshold决定状态翻转阈值worker.go从而保证增强方案与原生探针行为在判定结果上等价。提案中提到的 RPCgRPC探测在 prober.go 标注为 TODO当前实现以 Exec/HTTP/TCP 为主。节点侧执行链路整体如下图所示最终EnhancedLivenessProbeController 决定用 CRR 而非 kubelet 来重启容器决策结果反馈到 Pod 注解LivenessProbeDetector 解析指令并做出响应形成闭环。七、端到端流程五个关键问题的答案提案文档通过 FAQ 形式明确了整个方案的运转逻辑梳理如下Q1标准 livenessProbe 配置如何转换进本方案Webhook 把标准 livenessProbe 转为 Pod 注解中的专用字段见API Definition一节及架构图同时由 LivenessNodeProbeController 创建对应的 NodePodProbe 自定义资源。Q2如何接管探针探测原生 livenessProbe 配置被移除后kubelet 探测不再生效对已配置探针的 PodWebhook 准入时移除原生探针并存入注解对其他 Pod可直接用本方案注解进行配置。Q3如何执行 livenessProbe 探测由 kruise-daemon 组件中的 NodePodProbe 探测控制器负责执行 EXEC/HTTP/TCP/RPC 探测并回报结果状态。Q4如何重启探测失败的容器触发机制是什么EnhancedLivenessProbeController 使用 CRRKruise 中的容器重建请求能力重启 Pod 内探测失败的容器被杀容器随后由 kubelet 依据 PodrestartPolicy: Always尽快重新拉起。Q5如何彻底保护应用/服务免遭重启侵害决策单元基于工作负载内置韧性保护全局开关、黑名单、全局限流规则等与 maxUnavailable 保护原生 PodDisruptionBudget 或 Kruise PodUnavailableBudget可在 Pod 上设置开关紧急情况下关闭探测。八、API 定义如何启用增强版 livenessProbe启用入口是 Pod 上的注解提案文档API DefinitionapiVersion: v1 kind: Pod metadata: annotations: ... # [user defined] 使用增强版 livenessProbe否则走原生检查 apps.kruise.io/using-enhanced-liveness: true ... labels: ... spec: ... livenessProbe: failureThreshold: 3 httpGet: path: /health port: 7002 scheme: HTTP initialDelaySeconds: 3000 periodSeconds: 100 successThreshold: 1 timeoutSeconds: 5同时需要在部署时开启名为EnhancedLivenessProbe的 FeatureGate。仓库中的定义见 pkg/features/kruise_features.goEnhancedLivenessProbe默认关闭Default: falsePreRelease 级别为 Alphakruise_features.go它依赖PodWebhook与KruiseDaemon两个默认开启的 FeatureGate若PodWebhook关闭EnhancedLivenessProbeGate会被联动关闭若KruiseDaemon关闭同样联动关闭kruise_features.go。也就是说使用该能力的前提是集群中已部署 Kruise-manager 与 kruise-daemon且开启EnhancedLivenessProbe、PodWebhook、KruiseDaemon三个 FeatureGate。九、与原生方案的对比提案文档Functional Assessment给出如下对比维度增强版本方案原生社区方案架构模式集群内「指定组件探测kruise-daemon NodePodProbe 控制器 全局组件决策kruise-manager EnhancedLivenessProbeController」单机探测 单机决策全部在 kubelet 内探测能力kruiseDaemon/ProbeDetector 旁路探测启用扩展性强无保护策略具备应用全局视角支持 maxUnavailable 保护策略与韧性保护系统能力建设无可扩展性架构易扩展不侵入式修改原生组件适配不同场景伸缩性强强耦合可扩展性差十、适用边界与实施计划10.1 适用边界与注意事项无 OwnerReference 的 Pod 同样生效由于探测由 kruise-daemon 的 NodePodProbe 控制器实现对于没有 OwnerReference 的 Pod本方案在 livenessProbe 失败时同样能提供容器重启的增强能力覆盖社区逻辑原生 livenessProbe 配置与本方案配置会同时存在于处理流程中原生配置被移除并备份到注解二者语义在链路中并存前提限制当前仓库实现中探针动作以 Exec/HTTP/TCP 为主RPCgRPC探测在代码中标注为 TODO方案整体依赖 NodePodProbe CRD 与 PodProbeMarker 相关基础设施PodProbeMarkerGate默认开启是 NodePodProbe 控制器注册的前置条件之一见 node_pod_probe_controller.go。10.2 实施计划来自提案文档kruise-daemon 的 NodePodProbe 控制器除 EXEC 外支持 TCP/HTTPGET/RPC 探测首先开发 EnhancedLivenessProbeWebhook将标准 livenessProbe 配置转换到 Pod 注解中的专用字段开发 LivenessNodeProbeController将探针配置转换为 Kruise 的 NodePodProbe 自定义资源开发 EnhancedLivenessProbeController对失败的 NodePodProbe 状态执行容器重启该控制器基于工作负载的全局决策单元含韧性保护、maxUnavailable 保护等做出判断。十一、深入阅读方案提案docs/proposals/20240327-enhancedlivenessprobe.mdWebhook 转换实现pkg/webhook/pod/mutating/enhancedlivenessprobe_handler.go、pkg/webhook/pod/mutating/pod_create_update_handler.goWebhook 单元测试pkg/webhook/pod/mutating/enhancedlivenessprobe_handler_test.go注解常量定义apis/apps/v1alpha1/well_know_annotations.goFeatureGate 定义pkg/features/kruise_features.goNodePodProbe CRD 类型apis/apps/v1alpha1/node_pod_probe_types.goNodePodProbe 控制器pkg/controller/nodepodprobe/node_pod_probe_controller.godaemon 探针执行器pkg/daemon/podprobe/pod_probe_controller.go、pkg/daemon/podprobe/prober.go、pkg/daemon/podprobe/worker.goCRR 类型与执行apis/apps/v1alpha1/containerrecreaterequest_types.go、pkg/daemon/containerrecreate/crr_daemon_controller.go赞分享云原生容器编排微服务运维【免费下载链接】kruiseAutomated management of large-scale applications on Kubernetes (incubating project under CNCF)项目地址https://gitcode.com/gh_mirrors/kr/kruise点击查看免费下载相关推荐OBS Studio高可用架构从单机到集群的直播可靠性解决方案OBS Studio高可用架构从单机到集群的直播可靠性解决方案 痛点与解决方案概述 你是否曾经历过直播中断导致观众流失是否担心单服务器故障影响重要活动直播音视频直播屏幕录制桌面应用视频OpenKruise 级联删除保护Cascading Deletion Protection深度解析用 policy.kruise.io/delete-protection 守护集群关键资源OpenKruise 级联删除保护Cascading Deletion Protection深度解析用 policy.kruise.io/delete p云原生容器编排微服务运维企业级Syncthing虚拟机部署从单机到高可用集群的完整方案企业级Syncthing虚拟机部署从单机到高可用集群的完整方案 引言虚拟环境下的文件同步痛点与解决方案 你是否还在为跨虚拟机文件同步烦恼虚拟机快照恢复后同网络通信存储上一篇push.js代码规范ESLint与Prettier配置实践下一篇JNA社区贡献者资源学习与成长的机会创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考