今天分享一個(gè)Kubernetes部署時(shí)很基礎(chǔ)又很容易踩的坑：網(wǎng)段規(guī)劃。

1. 故障現(xiàn)象

昨天在給社群的運(yùn)維同行答疑時(shí)，一個(gè)運(yùn)維同行說(shuō)他剛部署的Kubernetes集群的Calico顯示是 CrashLoopBackOff狀態(tài)，一直在不斷重啟。

2. 解決問(wèn)題

我開(kāi)始讓他describe看一下Pod的狀態(tài)。

看截圖是就緒檢測(cè)時(shí)失敗了，無(wú)法連接 API Server。

為了更快地解決問(wèn)題，我通過(guò)遠(yuǎn)程工具連接他的電腦進(jìn)行操作。

我一開(kāi)始看失敗的pod的日志。執(zhí)行下面命令：

kubectl logs -n kube-system calico-kube-controllers-775fd85945-bx8fk

查看到日志里的關(guān)鍵報(bào)錯(cuò)。

Get "https://10.224.0.1:443/apis/crd.projectcalico.org/v1/clusterinformations/default": dial tcp 10.224.0.1:443: i/o timeout

也就是說(shuō)Calico 控制器（calico-kube-controllers）在 啟動(dòng)時(shí)無(wú)法訪(fǎng)問(wèn) Kubernetes API Server（10.224.0.1:443）。

Calico 連不上 API Server。 這基本等同于網(wǎng)絡(luò)“斷了主干線(xiàn)”。

這時(shí)我已經(jīng)考慮可能是網(wǎng)絡(luò)的原因，檢查了防火墻，結(jié)果都是關(guān)閉的，那很可能是Kubernetes網(wǎng)絡(luò)問(wèn)題。

在群友提供的截圖還有一個(gè)pod沒(méi)有完全起來(lái)，那就是CoreDNS處于Running 但未就緒（Ready=False）狀態(tài)。

于是我順手看了下 CoreDNS 的信息：

kubectl describe po coredns-757cc6c8f8-4t6qt -n kube-system

果然，熟悉的錯(cuò)誤出現(xiàn)了：

Readiness probe failed: HTTP probe failed with statuscode: 503

這時(shí)候可以肯定，問(wèn)題不在鏡像，也不在探針。整個(gè) Pod 網(wǎng)絡(luò)已經(jīng)失聯(lián)。出現(xiàn)503狀態(tài)

接著我檢查了主機(jī)IP，找到了最根本的原因：Pod網(wǎng)絡(luò)和宿主機(jī)網(wǎng)絡(luò)沖突了

群友初始化時(shí)將Pod網(wǎng)段設(shè)置為192.168.0.0/16， 而他的宿主機(jī)的網(wǎng)卡就在 192.168.169.0/24，宿主機(jī)網(wǎng)段在Pod網(wǎng)段里。

這倆網(wǎng)段就重疊了！

3. 根本原因

最根本原因是網(wǎng)段沖突了，Pod流量被錯(cuò)誤地送進(jìn)了“虛擬網(wǎng)卡”

因?yàn)檫@次網(wǎng)段沖突，Pod 想訪(fǎng)問(wèn) API Server時(shí)，路由表判斷：“192.168？那是我 Calico 管的”，于是流量被錯(cuò)誤地送進(jìn)了虛擬網(wǎng)卡 caliXXX，然后直接丟包。

最后讓群友修改網(wǎng)段重新初始化后，Kubernetes集群所有的Pod都已正常運(yùn)行。

4. 后續(xù)正確做法

為避免這種坑，記住一個(gè)原則：Pod 網(wǎng)段、Service 網(wǎng)段、宿主機(jī)網(wǎng)段，絕對(duì)不能重疊。

Kubernetes 的網(wǎng)絡(luò)設(shè)計(jì)，本質(zhì)上有三層獨(dú)立的網(wǎng)段： 每一層都要 相互隔離、不重疊、不沖突。

5. 其他啟示

本次排查過(guò)程，還可以得出下面三個(gè)啟示：

• Calico 不停重啟 ≠ 鏡像問(wèn)題，很多時(shí)候是底層網(wǎng)絡(luò)沖突。
• 先看 CoreDNS、再查 Calico 路由表，能快速定位問(wèn)題。
• 網(wǎng)段規(guī)劃要在集群初始化前定好，別用宿主機(jī)的同一段。