我是 LEE，老李，一个在 IT 行业摸爬滚打 17 年的技术老兵。

事件背景

某天凌晨被一个急促的电话叫醒，电话中传来了急促的声音："老李在不在，现在 Kubernetes 中 Pod 相互调用全部中断了，全盘中断了，快点起来帮忙修复下。"，吓得我一激灵从床上起来，在企微中默默看完了事情的前因后果，随后登录上故障 Kubernetes 集群上，看到 Pod 中的日志都平凡出现无法建联，无法解析域名的错误，这个时候我才意识到这个问题的严重性。

通过监控大盘，我发现 Kubernetes 集群中的 CoreDNS 服务的 ReadinessProbe 端口 8181 端口异常，导致服务无法正常启动，进而导致 Pod 之间无法相互调用，业务全盘中断。

现象获取

我登录到 Kubernetes 集群中 NetworkDebug 容器中，对运行的 CoreDNS 的 8080，8181，9153 联通性测试，发现 8080 和 9153 端口工作均正常，只有 8181 端口工作异常。

CoreDNS 运行端口功能如下表：

#	端口号	描述
1	8080	用于查询 CoreDNS 的状态
2	8181	用于检测 CoreDNS 是否正常工作
3	9153	用于 Prometheus 监控

CoreDNS Pod 都在 0/1 Running 状态。

kubectl 直接 describe CoreDNS Pod，显示 ReadinessProbe 探针异常，导致 Pod 无法正常启动。

bash 复制代码

Readiness probe failed: Get "http://x.x.x.x:8181/ready": dial tcp x.x.x.x:8181: connect: connection refused

由于 ReadinessProbe 探针主要是确认 Pod 能否进入转发列表，也就是说 Pod 的 IP 和 Port 能否成为 Service 的 Endpoint 中的一个。

如果 ReadinessProbe 探针失败，那么 Pod 就不会被加入到 Service 的 Endpoint 中，这样就会导致 Service 无法正常工作。我也对 CoreDNS 的 Service 也做了检查，发现 CoreDNS 的 Service 中的 Endpoint 为空，这就是为什么 Pod 之间无法相互调用的原因。

确认了故障触发逻辑以后，想要解决问题就简单了，只要解决 CoreDNS 的 ReadinessProbe 探针异常，恢复 CoreDNS Pod 就行了。

原理分析

为什么小伙伴完成执行变更操作，重启 CoreDNS Pod 以后，ReadinessProbe 探针依然异常呢？要能解答这个疑问，就必须要了解 CoreDNS 中 8181 这个端口是如何工作的，直接看源代码。

coredns/plugin/ready/setup.go

go 复制代码

// 注册 setup 函数， 命名为 ready
func init() { plugin.Register("ready", setup) }

func setup(c *caddy.Controller) error {
	addr, err := parse(c) // 解析 caddy 配置文件
	if err != nil {
		return plugin.Error("ready", err)
	}
	rd := &ready{Addr: addr} // 创建 ready 对象, Addr 是 8181 端口

	uniqAddr.Set(addr, rd.onStartup)
	c.OnStartup(func() error { uniqAddr.Set(addr, rd.onStartup); return nil })  // 启动一个 Http Server 相应 8181 端口的请求

	... // 省略部分代码

	return nil
}

// 解析 caddy 配置文件
func parse(c *caddy.Controller) (string, error) {
	addr := ":8181"
	i := 0
	for c.Next() {
		if i > 0 {
			return "", plugin.ErrOnce
		}
		i++
		args := c.RemainingArgs()

		switch len(args) {
		case 0:
		case 1:
			addr = args[0] // 这里可能就是应发现 8181 端口异常的原因，传入的参数是 IP:Port 的格式，但是 net.SplitHostPort 解析没有报错，导致 addr 变量的值是空的或者别的值
			if _, _, e := net.SplitHostPort(addr); e != nil {
				return "", e
			}
		default:
			return "", c.ArgErr()
		}
	}
	return addr, nil
}

coredns/plugin/ready/ready.go

go 复制代码

func (rd *ready) onStartup() error {
	ln, err := reuseport.Listen("tcp", rd.Addr)
	if err != nil {
		return err
	}

	rd.Lock()
	rd.ln = ln
	rd.mux = http.NewServeMux()
	rd.done = true
	rd.Unlock()

    // 8181 端口健康检测的处理方法，主要相应 /ready 的请求
	rd.mux.HandleFunc("/ready", func(w http.ResponseWriter, _ *http.Request) {
		rd.Lock()
		defer rd.Unlock()
		if !rd.done {
			w.WriteHeader(http.StatusServiceUnavailable)
			io.WriteString(w, "Shutting down")
			return
		}
		ok, todo := plugins.Ready() // 判断当前组件是否准备就绪
		if ok {                    // 如果准备就绪，返回 200
			w.WriteHeader(http.StatusOK)
			io.WriteString(w, http.StatusText(http.StatusOK))
			return
		}
		log.Infof("Still waiting on: %q", todo)
		w.WriteHeader(http.StatusServiceUnavailable) // 如果没有准备就绪，返回 503
		io.WriteString(w, todo)
	})

	go func() { http.Serve(rd.ln, rd.mux) }() // 启动一个 Http Server 相应 8181 端口的请求

	return nil
}

实际我看完了整个 ready 组件的代码，我也百思不得其解，因为之前我们在 CoreDNS 的 Configmap 中从来没有启动或者配置过 ready 组件，那个时候的 CoreDNS 的 ReadinessProbe 探针是正常的，为什么现在就不正常了呢？

会不会自动启动的 ready 组件一直不能进入就绪状态，导致 ReadinessProbe 探针异常？
会不会是传入的参数不正确导致的，但是为什么 net.SplitHostPort 解析没有报错呢？

各种问题在我脑袋里面翻滚，但是没有一个能够解释的通的，最后我只能通过最快和最有把握的方式来解决问题。

如果要最快的方式解决 ：我想是不是在 parse 函数让 args[0] 传入一个 :8181 的格式，也许就不会有问题了。

当然真正的问题，我们团队还在排查中，如果有结果，我会在文章中更新。

处理方法

假设 CoreDNS ready 组件自动启动有问题，那我们可不可以手动的方式启动呢？通过官方文档中的描述，我们可以在 CoreDNS 的配置文件中添加一个 ready 插件，来解决这个问题。相当通过手动设置 ready 插件的端口，来解决 ReadinessProbe 探针异常的问题。

coredns.io/plugins/rea...

具体配置如下：

yaml 复制代码

apiVersion: v1
kind: ConfigMap
metadata:
    name: coredns
    namespace: kube-system
data:
    Corefile: |
        .:53 {
            errors
            health
            kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods insecure
               fallthrough in-addr.arpa ip6.arpa
            }
            prometheus :9153
            ready :8181  ## 增加此行
            forward . /etc/resolv.conf {
              max_concurrent 1000
            }
            log
            cache 30
            loop
            reload
            loadbalance
        }

最后重启 CoreDNS Pod，问题解决。

当然后面我们通过 CoreDNS 的 Github 中 Issue 查找，发现了一个和我们类似的问题，也是 ReadinessProbe 探针异常（8181 端口），也是通过配置中添加 ready 插件解决的问题。

github.com/coredns/cor...

有兴趣的小伙伴可以自行移步查看。

最终效果

CoreDNS Pod 运行正常，ReadinessProbe 探针正常，业务恢复正常。

Kubernetes 中 CoreDNS 服务因为ReadinessProbe端口8181端口异常，导致服务大面积中断

事件背景

现象获取

原理分析

处理方法

最终效果