Kubernetes 不健康容器平滑漂移与重组的核心是构建可编程外部探针系统，通过多维信号采集、HealthAdaptorController 转译健康语义、分阶段标记-驱逐-重建、状态续传与拓扑约束保障，实现无中断、可追溯、闭环验证的自愈流程。
要实现不健康容器的平滑漂移与重组，核心不是单纯依赖 kubernetes 原生 liveness/readiness 探针，而是引入可编程、可观测、可干预的外部探针系统，配合调度器与控制器协同工作。
外部探针需具备主动诊断能力
原生探针是被动、单点、黑盒式的（如 HTTP GET 或 exec），而外部探针应能跨组件采集多维信号：容器内业务指标（如请求成功率、队列积压）、宿主机资源（CPU throttling、内存 pressure）、网络连通性（服务间 ping/traceroute）、甚至上游依赖健康状态（如数据库连接池耗尽）。这些数据统一上报至中央可观测平台（如 Prometheus + Alertmanager + 自定义 receiver）。
- 用轻量级 DaemonSet 部署探针 Agent，避免干扰业务容器生命周期
- 探针输出结构化事件（如
{"pod": "svc-abc-123", "reason": "db-timeout-90s", "severity": "critical"}），而非仅返回 true/false - 支持动态配置：不同服务可绑定不同探测策略（如支付服务启用 DB+缓存双校验，日志服务只检磁盘 inode）
健康状态需映射为可调度语义
Kubernetes 调度器不理解“业务不健康”，只响应 PodCondition 或 NodeCondition。因此需构建中间层——一个自定义控制器（如 HealthAdaptorController），将外部探针事件转化为 Pod 的 condition 或打上特定 label/taint。
- 当探针判定 pod 不健康但尚未崩溃时，控制器为其添加
health.k8s.io/unready: "true"condition，并触发readinessGates关闭流量入口 - 若持续异常超阈值（如 2 分钟），控制器自动给该 pod 打上
drain-scheduled=truelabel，并向 kube-scheduler 发送优先级提示（通过 SchedulingGates 或 PodTopologySpreadConstraints 引导新副本避开同节点） - 避免直接删除 pod：先标记、再驱逐、最后重建，确保 service endpoint 逐步更新，无连接中断
漂移过程必须保留上下文一致性
平滑漂移 ≠ 简单重启。关键在于维持会话、状态和拓扑约束。需结合 StatefulSet 控制器行为与 Operator 拓展逻辑：
- 对有状态服务（如 Kafka broker、Redis cluster node），漂移前调用 preStop hook 触发优雅下线（如迁移 partition leader、flush buffer）
- 新 pod 启动后，由 InitContainer 拉取前序实例的 checkpoint 或 WAL 日志，实现状态续传
- 利用 topologySpreadConstraints + podAntiAffinity，确保漂移后副本分散在不同 failure domain（可用区/机架），同时满足亲和性要求（如与某 configmap 共节点）
重组阶段依赖闭环反馈机制
漂移完成不代表问题终结。需建立“探测→决策→执行→验证”闭环，防止震荡或误判：
- 新 pod 上线后，外部探针立即启动专项校验（如模拟真实业务请求链路），结果反馈给 HealthAdaptorController
- 若验证失败，控制器暂停后续漂移，触发告警并保留旧实例（设置 maxUnavailable=0 临时冻结 rollout）
- 所有动作记录到审计日志，并关联 traceID，便于回溯：谁触发了漂移？依据哪条探针规则？是否影响 SLI？
