Kubernetes处理不健康CoreDNS Pod及lameduck配置问题

安全阿岳

2026-8-29

CoreDNS 健康检查与lameduck配置问题解答

以下代码片段取自CoreDNS的默认Corefile配置：

data:  
  Corefile: |    
  .:53 {
        errors
        health {
            lameduck 5s
        }
        ready

上述配置中，health插件用于向http://localhost:8080/health端点上报健康状态，返回200 OK即代表CoreDNS Pod处于健康状态。

问题1：健康检查返回非200 OK时Kubernetes的处理流程

是否会销毁重建Pod，完全取决于该健康端点对应的探针配置，不存在非200就必然重建的逻辑：

如果把/health端点配置为livenessProbe（存活探针，CoreDNS默认部署一般会配这个）：
1. kubelet按照periodSeconds设定的周期（默认10s）周期性请求健康端点
2. 连续失败次数达到failureThreshold阈值（默认3次）后，kubelet会直接向容器运行时发送信号，终止当前异常容器
3. 若Pod的restartPolicy为Always（Deployment管理的工作负载默认值），kubelet会按照退避规则在本地尝试重启容器，短时间内多次重启失败会逐步拉长重启间隔
4. 注意：kubelet触发的是本地容器重启，不会直接把Pod调度到其他节点，只有节点故障、Pod被驱逐时才会触发跨节点重建
如果仅把/health配置为readinessProbe（就绪探针）、或者根本没配置对应探针：kubelet不会销毁重建Pod，只会将该Pod从对应Service的后端端点列表中移除，不再转发新流量到异常实例。

Kubernetes有多层自动保障机制，但无法覆盖所有故障场景：

自动恢复相关机制：
- 流量层快速止损：就绪探针检测到异常后，立刻将实例从Service端点摘除，避免异常实例承接新的DNS请求，把故障影响面降到最低
- 实例层自愈：存活探针检测到异常后触发本地容器重启，绝大多数临时故障（进程死锁、内存泄漏导致的响应卡死、临时配置加载异常）重启后即可恢复
- 副本数保障：CoreDNS一般由Deployment管理，配置多副本+节点反亲和策略，控制器会始终维持设定的副本数。如果节点故障导致节点上的CoreDNS Pod失联，控制器会自动在其他可用节点补建新的Pod
- 节点层驱逐：节点被标记为NotReady后，节点控制器会在容忍时间到期后，将节点上的CoreDNS Pod驱逐到正常节点，保证全局可用副本数达标
无法自动恢复的场景：
比如Corefile配置错误导致进程启动即崩溃、上游DNS地址配置错误、集群底层网络插件大面积故障，这类场景下K8s只会反复重启异常实例，无法自动修复根因，必须人工介入排查日志、修正配置、恢复底层组件。

lameduck的核心作用是：CoreDNS收到退出信号后，先将健康状态改为非200，等待设定时长后再真正关闭进程，留出时间让K8s完成端点摘除、在途请求处理，避免流量丢包。

默认配置5s可以满足绝大多数节点规模<100、DNS QPS不高的集群使用，没有全场景通用的固定值，需要结合集群实际情况调整，生产环境常见配置区间为5s~15s，不建议设置超过30s，否则会拉长滚动更新周期，造成不必要的资源占用。
设置时长需要核心参考3个指标：
- 端点规则全链路传播延迟：即Pod状态变为NotReady后，所有节点上的kube-proxy/CNI插件完成iptables/ipvs/eBPF规则更新，将异常PodIP从CoreDNS Service后端移除的最长耗时。小规模集群一般在1~3s，500节点以上的大集群可能达到10s以上，lameduck时长必须大于这个值，否则规则未更新完成进程就退出，会出现请求超时
- 在途请求排空耗时：即CoreDNS峰值QPS下，处理完所有已接收请求的最长耗时，默认配置下一般不超过2s，如果启用了大量自定义插件（日志、审计、外部DNS转发等）可以适当放宽
- 探针检测间隔：lameduck时长不要小于就绪探针的检测间隔+1~2s冗余，保证kubelet至少能检测到1次健康状态异常，触发端点摘除流程。

内容的提问来源于stack exchange，提问作者anonymous user