国产一区二区精品-国产一区二区精品久-国产一区二区精品久久-国产一区二区精品久久91-免费毛片播放-免费毛片基地

千鋒教育-做有情懷、有良心、有品質(zhì)的職業(yè)教育機構(gòu)

手機站
千鋒教育

千鋒學(xué)習(xí)站 | 隨時隨地免費學(xué)

千鋒教育

掃一掃進入千鋒手機站

領(lǐng)取全套視頻
千鋒教育

關(guān)注千鋒學(xué)習(xí)站小程序
隨時隨地免費學(xué)習(xí)課程

當(dāng)前位置:首頁  >  技術(shù)干貨  > Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南

來源:千鋒教育
發(fā)布人:wjy
時間: 2022-09-16 13:38:30 1663306710

  本文將引入一個思路:“在 Kubernetes 集群發(fā)生網(wǎng)絡(luò)異常時如何排查”。文章將引入 Kubernetes 集群中網(wǎng)絡(luò)排查的思路,包含網(wǎng)絡(luò)異常模型,常用工具,并且提出一些案例以供學(xué)習(xí)。

  Pod 常見網(wǎng)絡(luò)異常分類

  網(wǎng)絡(luò)排查工具

  Pod 網(wǎng)絡(luò)異常排查思路及流程模型

  CNI 網(wǎng)絡(luò)異常排查步驟

  案例學(xué)習(xí)

  Pod 網(wǎng)絡(luò)異常

  網(wǎng)絡(luò)異常大概分為如下幾類:

  網(wǎng)絡(luò)不可達:主要現(xiàn)象為 ping 不通,其可能原因為:

  源端和目的端防火墻(iptables, selinux)限制

  網(wǎng)絡(luò)路由配置不正確

  源端和目的端的系統(tǒng)負載過高,網(wǎng)絡(luò)連接數(shù)滿,網(wǎng)卡隊列滿

  網(wǎng)絡(luò)鏈路故障

  端口不可達:主要現(xiàn)象為可以 ping 通,但 telnet 端口不通,其可能原因為:

  源端和目的端防火墻限制

  源端和目的端的系統(tǒng)負載過高,網(wǎng)絡(luò)連接數(shù)滿,網(wǎng)卡隊列滿,端口耗盡

  目的端應(yīng)用未正常監(jiān)聽導(dǎo)致(應(yīng)用未啟動,或監(jiān)聽為 127.0.0.1 等)

  DNS 解析異常:主要現(xiàn)象為基礎(chǔ)網(wǎng)絡(luò)可以連通,訪問域名報錯無法解析,訪問 IP 可以正常連通。其可能原因為

  Pod 的 DNS 配置不正確

  DNS 服務(wù)異常

  pod 與 DNS 服務(wù)通訊異常

  大數(shù)據(jù)包丟包:主要現(xiàn)象為基礎(chǔ)網(wǎng)絡(luò)和端口均可以連通,小數(shù)據(jù)包收發(fā)無異常,大數(shù)據(jù)包丟包。可能原因為:

  可使用 ping -s 指定數(shù)據(jù)包大小進行測試

  數(shù)據(jù)包的大小超過了 docker、CNI 插件、或者宿主機網(wǎng)卡的 MTU 值。

  CNI 異常:主要現(xiàn)象為 Node 可以通,但 Pod 無法訪問集群地址,可能原因有:

  kube-proxy 服務(wù)異常,沒有生成 iptables 策略或者 ipvs 規(guī)則導(dǎo)致無法訪問

  CIDR 耗盡,無法為 Node 注入 PodCIDR 導(dǎo)致 CNI 插件異常

  其他 CNI 插件問題

  那么整個 Pod 網(wǎng)絡(luò)異常分類可以如下圖所示:

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南1

  總結(jié)一下,Pod 最常見的網(wǎng)絡(luò)故障有,網(wǎng)絡(luò)不可達(ping 不通);端口不可達(telnet 不通);DNS 解析異常(域名不通)與大數(shù)據(jù)包丟失(大包不通)。

  常用網(wǎng)絡(luò)排查工具

  在了解到常見的網(wǎng)絡(luò)異常后,在排查時就需要使用到一些網(wǎng)絡(luò)工具才可以很有效的定位到網(wǎng)絡(luò)故障原因,下面會介紹一些網(wǎng)絡(luò)排查工具。

  tcpdump

  tcpdump 網(wǎng)絡(luò)嗅探器,將強大和簡單結(jié)合到一個單一的命令行界面中,能夠?qū)⒕W(wǎng)絡(luò)中的報文抓取,輸出到屏幕或者記錄到文件中。

  各系統(tǒng)下的安裝

  Ubuntu/Debian: tcpdump ;apt-get install -y tcpdump

  Centos/Fedora: tcpdump ;yum install -y tcpdump

  Apline:tcpdump ;apk add tcpdump --no-cache

  查看指定接口上的所有通訊

  語法

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南2

 

  捕獲所有網(wǎng)絡(luò)接口

  tcpdump -D

  按 IP 查找流量

  最常見的查詢之一 host,可以看到來往于 1.1.1.1 的流量。

  tcpdump host 1.1.1.1

  按源 / 目的 地址過濾

  如果只想查看來自 / 向某方向流量,可以使用 src 和 dst。

  tcpdump src|dst 1.1.1.1

  通過網(wǎng)絡(luò)查找數(shù)據(jù)包

  使用 net 選項,來要查找出 / 入某個網(wǎng)絡(luò)或子網(wǎng)的數(shù)據(jù)包。

  tcpdump net 1.2.3.0/24

  使用十六進制輸出數(shù)據(jù)包內(nèi)容

  hex 可以以 16 進制輸出包的內(nèi)容

  tcpdump -c 1 -X icmp

  查看特定端口的流量

  使用 port 選項來查找特定的端口流量。

  tcpdump port 3389tcpdump src port 1025

  查找端口范圍的流量

  tcpdump portrange 21-23

  過濾包的大小

  如果需要查找特定大小的數(shù)據(jù)包,可以使用以下選項。你可以使用 less,greater。

  tcpdump less 32tcpdump greater 64tcpdump <= 128

  捕獲流量輸出為文件

  -w 可以將數(shù)據(jù)包捕獲保存到一個文件中以便將來進行分析。這些文件稱為 PCAP(PEE-cap)文件,它們可以由不同的工具處理,包括 Wireshark 。

  tcpdump port 80 -w capture_file

  組合條件

  tcpdump 也可以結(jié)合邏輯運算符進行組合條件查詢

  ANDand or &&

  ORor or ||

  EXCEPTnot or !

  tcpdump -i eth0 -nn host 220.181.57.216 and 10.0.0.1 # 主機之間的通訊tcpdump -i eth0 -nn host 220.181.57.216 or 10.0.0.1# 獲取10.0.0.1與 10.0.0.9或 10.0.0.1 與10.0.0.3之間的通訊tcpdump -i eth0 -nn host 10.0.0.1 and \(10.0.0.9 or 10.0.0.3\)

  原始輸出

  并顯示人類可讀的內(nèi)容進行輸出包(不包含內(nèi)容)。

  tcpdump -ttnnvvS -i eth0tcpdump -ttnnvvS -i eth0

  IP 到端口

  讓我們查找從某個 IP 到端口任何主機的某個端口所有流量。

  tcpdump -nnvvS src 10.5.2.3 and dst port 3389

  去除特定流量

  可以將指定的流量排除,如這顯示所有到 192.168.0.2 的 非 ICMP 的流量。

  tcpdump dst 192.168.0.2 and src net and not icmp

  來自非指定端口的流量,如,顯示來自不是 SSH 流量的主機的所有流量。

  tcpdump -vv src mars and not dst port 22

  選項分組

  在構(gòu)建復(fù)雜查詢時,必須使用單引號 '。單引號用于忽略特殊符號 () ,以便于使用其他表達式(如 host, port, net 等)進行分組。

  tcpdump 'src 10.0.2.4 and (dst port 3389 or 22)'

  過濾 TCP 標記位

  tcpdump 'tcp[13] & 4!=0'tcpdump 'tcp[tcpflags] == tcp-rst'

  TCP SYN

  tcpdump 'tcp[13] & 2!=0'tcpdump 'tcp[tcpflags] == tcp-syn'

  同時忽略 SYN 和 ACK 標志的數(shù)據(jù)包

  tcpdump 'tcp[13]=18'

  TCP URG

  tcpdump 'tcp[13] & 32!=0'tcpdump 'tcp[tcpflags] == tcp-urg'

  TCP ACK

  tcpdump 'tcp[13] & 16!=0'tcpdump 'tcp[tcpflags] == tcp-ack'

  TCP PSH

  tcpdump 'tcp[13] & 8!=0'tcpdump 'tcp[tcpflags] == tcp-push'

  TCP FIN

  tcpdump 'tcp[13] & 1!=0'tcpdump 'tcp[tcpflags] == tcp-fin'

  查找 http 包

  查找 user-agent 信息

  tcpdump -vvAls0 | grep 'User-Agent:'

  查找只是 GET 請求的流量

  tcpdump -vvAls0 | grep 'GET'

  查找 http 客戶端 IP

  tcpdump -vvAls0 | grep 'Host:'

  查詢客戶端 cookie

  tcpdump -vvAls0 | grep 'Set-Cookie|Host:|Cookie:'

  查找 DNS 流量

  tcpdump -vvAs0 port 53

  查找對應(yīng)流量的明文密碼

  tcpdump port http or port ftp or port smtp or port imap or port pop3 or port telnet -lA | egrep -i -B5 'pass=|pwd=|log=|login=|user=|username=|pw=|passw=|passwd= |password=|pass:|user:|username:|password:|login:|pass |user '

  wireshark 追蹤流

  wireshare 追蹤流可以很好的了解出在一次交互過程中都發(fā)生了那些問題。

  wireshare 選中包,右鍵選擇 “追蹤流“ 如果該包是允許的協(xié)議是可以打開該選項的

  關(guān)于抓包節(jié)點和抓包設(shè)備

  如何抓取有用的包,以及如何找到對應(yīng)的接口,有以下建議

  抓包節(jié)點:

  通常情況下會在源端和目的端兩端同時抓包,觀察數(shù)據(jù)包是否從源端正常發(fā)出,目的端是否接收到數(shù)據(jù)包并給源端回包,以及源端是否正常接收到回包。如果有丟包現(xiàn)象,則沿網(wǎng)絡(luò)鏈路上各節(jié)點抓包排查。例如,A 節(jié)點經(jīng)過 c 節(jié)點到 B 節(jié)點,先在 AB 兩端同時抓包,如果 B 節(jié)點未收到 A 節(jié)點的包,則在 c 節(jié)點同時抓包。

  抓包設(shè)備:

  對于 Kubernetes 集群中的 Pod,由于容器內(nèi)不便于抓包,通常視情況在 Pod 數(shù)據(jù)包經(jīng)過的 veth 設(shè)備,docker0 網(wǎng)橋,CNI 插件設(shè)備(如 cni0,flannel.1 etc..)及 Pod 所在節(jié)點的網(wǎng)卡設(shè)備上指定 Pod IP 進行抓包。選取的設(shè)備根據(jù)懷疑導(dǎo)致網(wǎng)絡(luò)問題的原因而定,比如范圍由大縮小,從源端逐漸靠近目的端,比如懷疑是 CNI 插件導(dǎo)致,則在 CNI 插件設(shè)備上抓包。從 pod 發(fā)出的包逐一經(jīng)過 veth 設(shè)備,cni0 設(shè)備,flannel0,宿主機網(wǎng)卡,到達對端,抓包時可按順序逐一抓包,定位問題節(jié)點。

  需要注意在不同設(shè)備上抓包時指定的源目 IP 地址需要轉(zhuǎn)換,如抓取某 Pod 時,ping {host} 的包,在 veth 和 cni0 上可以指定 Pod IP 抓包,而在宿主機網(wǎng)卡上如果仍然指定 Pod IP 會發(fā)現(xiàn)抓不到包,因為此時 Pod IP 已被轉(zhuǎn)換為宿主機網(wǎng)卡 IP。

  下圖是一個使用 VxLAN 模式的 flannel 的跨界點通訊的網(wǎng)絡(luò)模型,在抓包時需要注意對應(yīng)的網(wǎng)絡(luò)接口

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南3

  nsenter

  nsenter 是一款可以進入進程的名稱空間中。例如,如果一個容器以非 root 用戶身份運行,而使用 docker exec 進入其中后,但該容器沒有安裝 sudo 或未 netstat ,并且您想查看其當(dāng)前的網(wǎng)絡(luò)屬性,如開放端口,這種場景下將如何做到這一點?nsenter 就是用來解決這個問題的。

  nsenter (namespace enter) 可以在容器的宿主機上使用 nsenter 命令進入容器的命名空間,以容器視角使用宿主機上的相應(yīng)網(wǎng)絡(luò)命令進行操作。當(dāng)然需要擁有 root 權(quán)限

  各系統(tǒng)下的安裝

  Ubuntu/Debian: util-linux ;apt-get install -y util-linux

  Centos/Fedora: util-linux ;yum install -y util-linux

  Apline:util-linux ;apk add util-linux --no-cache

  nsenter 的 c 使用語法為,nsenter -t pid -n,-t 接 進程 ID 號,-n 表示進入名稱空間內(nèi),為執(zhí)行的命令。

  實例:如我們有一個 Pod 進程 ID 為 30858,進入該 Pod 名稱空間內(nèi)執(zhí)行 ifconfig ,如下列所示

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南4

  如何定位 Pod 名稱空間

  首先需要確定 Pod 所在的節(jié)點名稱

  $ kubectl get pods -owide |awk '{print $1,$7}'NAME NODEnetbox-85865d5556-hfg6v master-machinenetbox-85865d5556-vlgr4 node01

  如果 Pod 不在當(dāng)前節(jié)點還需要用 IP 登錄則還需要查看 IP(可選)

  $ kubectl get pods -owide |awk '{print $1,$6,$7}'NAME IP NODEnetbox-85865d5556-hfg6v 192.168.1.213 master-machinenetbox-85865d5556-vlgr4 192.168.0.4 node01

  接下來,登錄節(jié)點,獲取容器 lD,如下列所示,每個 pod 默認有一個 pause 容器,其他為用戶 yaml 文件中定義的容器,理論上所有容器共享相同的網(wǎng)絡(luò)命名空間,排查時可任選一個容器。

  $ docker ps |grep netbox-85865d5556-hfg6v6f8c58377aae f78dd05f11ff "tail -f" 45 hours ago Up 45 hours k8s_netbox_netbox-85865d5556-hfg6v_default_4a8e2da8-05d1-4c81-97a7-3d76343a323a_0b9c732ee457e registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.1 "/pause" 45 hours ago Up 45 hours k8s_POD_netbox-85865d5556-hfg6v_default_4a8e2da8-05d1-4c81-97a7-3d76343a323a_0

  接下來獲得獲取容器在節(jié)點系統(tǒng)中對應(yīng)的進程號,如下所示

  $ docker inspect --format "{{ .State.Pid }}" 6f8c58377aae30858

  最后就可以通過 nsenter 進入容器網(wǎng)絡(luò)空間執(zhí)行命令了

  paping

  paping 命令可對目標地址指定端口以 TCP 協(xié)議進行連續(xù) ping,通過這種特性可以彌補 ping ICMP 協(xié)議,以及 nmap , telnet 只能進行一次操作的的不足;通常情況下會用于測試端口連通性和丟包率

  paping download:paping

  paping 還需要安裝以下依賴,這取決于你安裝的 paping 版本

  RedHat/CentOS:yum install -y libstdc++.i686 glibc.i686

  Ubuntu/Debian:最小化安裝無需依賴

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南5

  mtr

  mtr 是一個跨平臺的網(wǎng)絡(luò)診斷工具,將 traceroute 和 ping 的功能結(jié)合到一個工具。與 traceroute 不同的是 mtr 顯示的信息比起 traceroute 更加豐富:通過 mtr 可以確定網(wǎng)絡(luò)的條數(shù),并且可以同時打印響應(yīng)百分比以及網(wǎng)絡(luò)中各跳躍點的響應(yīng)時間。

  各系統(tǒng)下的安裝

  Ubuntu/Debian: mtr ;apt-get install -y mtr

  Centos/Fedora: mtr ;yum install -y mtr

  Apline:mtr ;apk add mtr --no-cache

  簡單的使用示例

  最簡單的示例,就是后接域名或 IP,這將跟蹤整個路由

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南6

  -n 強制 mtr 打印 IP 地址而不是主機名

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南7

  -b 同時顯示 IP 地址與主機名

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南8

  -c 跟一個具體的值,這將限制 mtr ping 的次數(shù),到達次數(shù)后會退出

  $ mtr -c5 google.com

  如果需要指定次數(shù),并且在退出后保存這些數(shù)據(jù),使用 -r flag

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南9

  默認使用的是 ICMP 協(xié)議 -i ,可以指定 -u, -t 使用其他協(xié)議

  mtr --tcp google.com

  -m 指定最大的跳數(shù)

  mtr -m 35 216.58.223.78

  -s 指定包的大小

  mtr 輸出的數(shù)據(jù)

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南10

  丟包判斷

  任一節(jié)點的 Loss%(丟包率)如果不為零,則說明這一跳網(wǎng)絡(luò)可能存在問題。導(dǎo)致相應(yīng)節(jié)點丟包的原因通常有兩種。

  運營商基于安全或性能需求,人為限制了節(jié)點的 ICMP 發(fā)送速率,導(dǎo)致丟包。

  節(jié)點確實存在異常,導(dǎo)致丟包。可以結(jié)合異常節(jié)點及其后續(xù)節(jié)點的丟包情況,來判定丟包原因。

  Notes:

  如果隨后節(jié)點均沒有丟包,則通常說明異常節(jié)點丟包是由于運營商策略限制所致。可以忽略相關(guān)丟包。

  如果隨后節(jié)點也出現(xiàn)丟包,則通常說明節(jié)點確實存在網(wǎng)絡(luò)異常,導(dǎo)致丟包。對于這種情況,如果異常節(jié)點及其后續(xù)節(jié)點連續(xù)出現(xiàn)丟包,而且各節(jié)點的丟包率不同,則通常以最后幾跳的丟包率為準。如鏈路測試在第 5、6、7 跳均出現(xiàn)了丟包。最終丟包情況以第 7 跳作為參考。

  延遲判斷

  由于鏈路抖動或其它因素的影響,節(jié)點的 Best 和 Worst 值可能相差很大。而 Avg(平均值)統(tǒng)計了自鏈路測試以來所有探測的平均值,所以能更好的反應(yīng)出相應(yīng)節(jié)點的網(wǎng)絡(luò)質(zhì)量。而 StDev(標準偏差值)越高,則說明數(shù)據(jù)包在相應(yīng)節(jié)點的延時值越不相同(越離散)。所以標準偏差值可用于協(xié)助判斷 Avg 是否真實反應(yīng)了相應(yīng)節(jié)點的網(wǎng)絡(luò)質(zhì)量。例如,如果標準偏差很大,說明數(shù)據(jù)包的延遲是不確定的。可能某些數(shù)據(jù)包延遲很小(例如:25ms),而另一些延遲卻很大(例如:350ms),但最終得到的平均延遲反而可能是正常的。所以此時 Avg 并不能很好的反應(yīng)出實際的網(wǎng)絡(luò)質(zhì)量情況。

  這就需要結(jié)合如下情況進行判斷:

  如果 StDev 很高,則同步觀察相應(yīng)節(jié)點的 Best 和 wrst,來判斷相應(yīng)節(jié)點是否存在異常。

  如果 StDev 不高,則通過 Avg 來判斷相應(yīng)節(jié)點是否存在異常。

  Pod 網(wǎng)絡(luò)排查流程

  Pod 網(wǎng)絡(luò)異常時排查思路,可以按照下圖所示

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南11

  案例學(xué)習(xí)

  擴容節(jié)點訪問 service 地址不通

  測試環(huán)境 k8s 節(jié)點擴容后無法訪問集群 clusterlP 類型的 registry 服務(wù)

  環(huán)境信息:

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南12

  cni 插件:flannel vxlan

  kube-proxy 工作模式為 iptables

  registry 服務(wù)

  單實例部署在 10.61.187.48:5000

  Pod IP:10.233.65.46,

  Cluster IP:10.233.0.100 現(xiàn)象:

  所有節(jié)點之間的 pod 通信正常

  任意節(jié)點和 Pod curl registry 的 Pod 的 IP:5000 均可以連通

  新擴容節(jié)點 10.153.204.15 curl registry 服務(wù)的 Cluster lP 10.233.0.100:5000 不通,其他節(jié)點 curl 均可以連通

  分析思路:

  根據(jù)現(xiàn)象 1 可以初步判斷 CNI 插件無異常

  根據(jù)現(xiàn)象 2 可以判斷 registry 的 Pod 無異常

  根據(jù)現(xiàn)象 3 可以判斷 registry 的 service 異常的可能性不大,可能是新擴容節(jié)點訪問 registry 的 service 存在異常

  懷疑方向:

  問題節(jié)點的 kube-proxy 存在異常

  問題節(jié)點的 iptables 規(guī)則存在異常

  問題節(jié)點到 service 的網(wǎng)絡(luò)層面存在異常

  排查過程:

  排查問題節(jié)點的 kube-proxy

  執(zhí)行 kubectl get pod -owide -nkube-system l grep kube-proxy 查看 kube-proxy Pod 的狀態(tài),問題節(jié)點上的 kube-proxy Pod 為 running 狀態(tài)

  執(zhí)行 kubecti logs-nkube-system 查看問題節(jié)點 kube-proxy 的 Pod 日志,沒有異常報錯

  在問題節(jié)點操作系統(tǒng)上執(zhí)行 iptables -S -t nat 查看 iptables 規(guī)則

  排查過程:

  確認存在到 registry 服務(wù)的 Cluster lP 10.233.0.100 的 KUBE-SERVICES 鏈,跳轉(zhuǎn)至 KUBE-SVC-* 鏈做負載均衡,再跳轉(zhuǎn)至 KUBE-SEP-* 鏈通過 DNAT 替換為服務(wù)后端 Pod 的 IP 10.233.65.46。因此判斷 iptables 規(guī)則無異常執(zhí)行 route-n 查看問題節(jié)點存在訪問 10.233.65.46 所在網(wǎng)段的路由,如圖所示

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南13

  查看對端的回程路由

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南14

  以上排查證明問題原因不是 cni 插件或者 kube-proxy 異常導(dǎo)致,因此需要在訪問鏈路上抓包,判斷問題原因、問題節(jié)點執(zhí)行 curl 10.233.0.100:5000,在問題節(jié)點和后端 pod 所在節(jié)點的 flannel.1 上同時抓包發(fā)包節(jié)點一直在重傳,Cluster lP 已 DNAT 轉(zhuǎn)換為后端 Pod IP,如圖所示

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南15

  后端 Pod( registry 服務(wù))所在節(jié)點的 flannel.1 上未抓到任何數(shù)據(jù)包,如圖所示

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南16

  請求 service 的 ClusterlP 時,在兩端物理機網(wǎng)卡抓包,發(fā)包端如圖所示,封裝的源端節(jié)點 IP 是 10.153.204.15,但一直在重傳

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南17

  收包端收到了包,但未回包,如圖所示

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南18

  由此可以知道,NAT 的動作已經(jīng)完成,而只是后端 Pod( registry 服務(wù))沒有回包,接下來在問題節(jié)點執(zhí)行 curl10.233.65.46:5000,在問題節(jié)點和后端( registry 服務(wù))Pod 所在節(jié)點的 flannel.1 上同時抓包,兩節(jié)點收發(fā)正常,發(fā)包如圖所示

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南19

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南20

  接下來在兩端物理機網(wǎng)卡接口抓包,因為數(shù)據(jù)包通過物理機網(wǎng)卡會進行 vxlan 封裝,需要抓 vxlan 設(shè)備的 8472 端口,發(fā)包端如圖所示

  發(fā)現(xiàn)網(wǎng)絡(luò)鏈路連通,但封裝的 IP 不對,封裝的源端節(jié)點 IP 是 10.153.204.228,但是存在問題節(jié)點的 IP 是 10.153.204.15

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南21

  后端 Pod 所在節(jié)點的物理網(wǎng)卡上抓包,注意需要過濾其他正常節(jié)點的請求包,如圖所示;發(fā)現(xiàn)收到的數(shù)據(jù)包,源地址是 10.153.204.228,但是問題節(jié)點的 IP 是 10.153.204.15。

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南22

  此時問題以及清楚了,是一個 Pod 存在兩個 IP,導(dǎo)致發(fā)包和回包時無法通過隧道設(shè)備找到對端的接口,所以發(fā)可以收到,但不能回。

  問題節(jié)點執(zhí)行 ip addr,發(fā)現(xiàn)網(wǎng)卡 enp26s0f0 上配置了兩個 IP,如圖所示

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南23

  進一步查看網(wǎng)卡配置文件,發(fā)現(xiàn)網(wǎng)卡既配置了靜態(tài) IP,又配置了 dhcp 動態(tài)獲取 IP。如圖所示

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南24

  最終定位原因為問題節(jié)點既配置了 dhcp 獲取 IP,又配置了靜態(tài) IP,導(dǎo)致 IP 沖突,引發(fā)網(wǎng)絡(luò)異常

  解決方法:修改網(wǎng)卡配置文件 /etc/sysconfig/network-scripts/ifcfg-enp26s0f0 里 BOOTPROTO="dhcp"為 BOOTPROTO="none";重啟 docker 和 kubelet 問題解決。

  集群外云主機調(diào)用集群內(nèi)應(yīng)用超時

  問題現(xiàn)象:Kubernetes 集群外云主機以 http post 方式訪問 Kubernetes 集群應(yīng)用接口超時

  環(huán)境信息:Kubernetes 集群:calicoIP-IP 模式,應(yīng)用接口以 nodeport 方式對外提供服務(wù)

  客戶端:Kubernetes 集群之外的云主機

  排查過程:

  在云主機 telnet 應(yīng)用接口地址和端口,可以連通,證明網(wǎng)絡(luò)連通正常,如圖所示

  云主機上調(diào)用接口不通,在云主機和 Pod 所在 Kubernetes 節(jié)點同時抓包,使用 wireshark 分析數(shù)據(jù)包

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南25

  通過抓包結(jié)果分析結(jié)果為 TCP 鏈接建立沒有問題,但是在傳輸大數(shù)據(jù)的時候會一直重傳 1514 大小的第一個數(shù)據(jù)包直至超時。懷疑是鏈路兩端 MTU 大小不一致導(dǎo)致(現(xiàn)象:某一個固定大小的包一直超時的情況)。如圖所示,1514 大小的包一直在重傳。

  報文 1-3 TCP 三次握手正常

  報文 1 info 中 MSS 字段可以看到 MSS 協(xié)商為 1460,MTU=1460+20bytes(IP 包頭)+20bytes(TCP 包頭)=1500

  報文 7 k8s 主機確認了包 4 的數(shù)據(jù)包,但是后續(xù)再沒有對數(shù)據(jù)的 ACK

  報文 21-29 可以看到云主機一直在發(fā)送后面的數(shù)據(jù),但是沒有收到 k8s 節(jié)點的 ACK,結(jié)合 pod 未收到任何報文,表明是 k8s 節(jié)點和 POD 通信出現(xiàn)了問題。

Kubernetes網(wǎng)絡(luò)排錯骨灰級中文指南26

  在云主機上使用 ping -s 指定數(shù)據(jù)包大小,發(fā)現(xiàn)超過 1400 大小的數(shù)據(jù)包無法正常發(fā)送。結(jié)合以上情況,定位是云主機網(wǎng)卡配置的 MTU 是 1500,tunl0 配置的 MTU 是 1440,導(dǎo)致大數(shù)據(jù)包無法發(fā)送至 tunl0 ,因此 Pod 沒有收到報文,接口調(diào)用失敗。

  解決方法:修改云主機網(wǎng)卡 MTU 值為 1440,或者修改 calico 的 MTU 值為 1500,保持鏈路兩端 MTU 值一致。

  集群 pod 訪問對象存儲超時

  環(huán)境信息:公有云環(huán)境,Kubernetes 集群節(jié)點和對象存儲在同一私有網(wǎng)絡(luò)下,網(wǎng)絡(luò)鏈路無防火墻限制 k8s 集群開啟了節(jié)點自動彈縮(CA)和 Pod 自動彈縮(HPA),通過域名訪問對象存儲,Pod 使用集群 DNS 服務(wù),集群 DNS 服務(wù)配置了用戶自建上游 DNS 服務(wù)器

  排查過程:

  使用 nsenter 工具進入 pod 容器網(wǎng)絡(luò)命名空間測試,ping 對象存儲域名不通,報錯 unknown server name,ping 對象存儲 lP 可以連通。

  telnet 對象存儲 80/443 端口可以連通。

  paping 對象存儲 80/443 端口無丟包。

  為了驗證 Pod 創(chuàng)建好以后的初始階段網(wǎng)絡(luò)連通性,將以上測試動作寫入 dockerfile,重新生成容器鏡像并創(chuàng) pod,測試結(jié)果一致。

  通過上述步驟,判斷 Pod 網(wǎng)絡(luò)連通性無異常,超時原因為域名解析失敗,懷疑問題如下:

  集群 DNS 服務(wù)存在異常

  上游 DNS 服務(wù)存在異常

  集群 DNS 服務(wù)與上游 DNS 通訊異常

  pod 訪問集群 DNS 服務(wù)異常

  根據(jù)上述方向排查,集群 DNS 服務(wù)狀態(tài)正常,無報錯。測試 Pod 分別使用集群 DNS 服務(wù)和上游 DNS 服務(wù)解析域名,前者解析失敗,后者解析成功。至此,證明上游 DNS 服務(wù)正常,并且集群 DNS 服務(wù)日志中沒有與上游 DNS 通訊超時的報錯。定位到的問題:Pod 訪問集群 DNS 服務(wù)超時

  此時發(fā)現(xiàn),出現(xiàn)問題的 Pod 集中在新彈出的 Kubernetes 節(jié)點上。這些節(jié)點的 kube-proxy Pod 狀態(tài)全部為 pending,沒有正常調(diào)度到節(jié)點上。因此導(dǎo)致該節(jié)點上其他 Pod 無法訪問包括 dns 在內(nèi)的所有 Kubernetes service。

  再進一步排查發(fā)現(xiàn) kube-proxy Pod 沒有配置 priorityclass 為最高優(yōu)先級,導(dǎo)致節(jié)點資源緊張時為了將高優(yōu)先級的應(yīng)用 Pod 調(diào)度到該節(jié)點,將原本已運行在該節(jié)點的 kube-proxy 驅(qū)逐。

  解決方法:將 kube-proxy 設(shè)置 priorityclass 值為 system-node-critical 最高優(yōu)先級,同時建議應(yīng)用 Pod 配置就緒探針,測試可以正常連通對象存儲域名后再分配任務(wù)。

tags:
聲明:本站稿件版權(quán)均屬千鋒教育所有,未經(jīng)許可不得擅自轉(zhuǎn)載。
10年以上業(yè)內(nèi)強師集結(jié),手把手帶你蛻變精英
請您保持通訊暢通,專屬學(xué)習(xí)老師24小時內(nèi)將與您1V1溝通
免費領(lǐng)取
今日已有369人領(lǐng)取成功
劉同學(xué) 138****2860 剛剛成功領(lǐng)取
王同學(xué) 131****2015 剛剛成功領(lǐng)取
張同學(xué) 133****4652 剛剛成功領(lǐng)取
李同學(xué) 135****8607 剛剛成功領(lǐng)取
楊同學(xué) 132****5667 剛剛成功領(lǐng)取
岳同學(xué) 134****6652 剛剛成功領(lǐng)取
梁同學(xué) 157****2950 剛剛成功領(lǐng)取
劉同學(xué) 189****1015 剛剛成功領(lǐng)取
張同學(xué) 155****4678 剛剛成功領(lǐng)取
鄒同學(xué) 139****2907 剛剛成功領(lǐng)取
董同學(xué) 138****2867 剛剛成功領(lǐng)取
周同學(xué) 136****3602 剛剛成功領(lǐng)取
相關(guān)推薦HOT
抖店入駐收費多少?開抖店費用是多少?

如果要開通抖音小店,需要先把抖音賬號開通商品櫥窗功能。入駐之后,可以選擇頭條賬號、抖音賬號、火山賬號任一類型注冊或登錄。那開個抖店要多...詳情>>

2023-09-19 07:50:26
想做直播帶貨的貨源哪里來?怎么找貨源?

現(xiàn)如今直播推廣的方式是非常火的,有著非常多的賣家都是利用直播推廣店鋪產(chǎn)品,效果也是非常不錯。但很多賣家想要了解現(xiàn)在直播帶貨的話什么產(chǎn)品...詳情>>

2023-09-19 07:47:16
適合三農(nóng)領(lǐng)域的名字?有何技巧?

現(xiàn)在在抖音上很多博主會選擇直播來賺取更多的流量以及利潤,直播間的東西也有很多讓消費者信任并且喜歡的,而且隨著越來越多人直播,很多農(nóng)產(chǎn)品...詳情>>

2023-09-19 07:06:05
抖店商品發(fā)布違規(guī)怎么申訴?有何規(guī)則?

抖店服務(wù)市場服務(wù)商發(fā)布違禁信息如何處理?情節(jié)嚴重程度判定原則:違規(guī)嚴重等級主要通過服務(wù)商違規(guī)次數(shù)、造成后果的嚴重程度、獲利或?qū)е聯(lián)p失的...詳情>>

2023-09-19 06:59:55
“泛垂直起號”可能是2023年最高效的起號方式

這可能是明年最好用的旗號方式了,今天教大家一個很野,但是可以讓你三天漲1000粉的偏方。去年前年啊,每個人都教你,誰知七號對著自己的產(chǎn)品拍...詳情>>

2023-09-19 06:37:38
開班信息
北京校區(qū)
  • 北京校區(qū)
  • 大連校區(qū)
  • 廣州校區(qū)
  • 成都校區(qū)
  • 杭州校區(qū)
  • 長沙校區(qū)
  • 合肥校區(qū)
  • 南京校區(qū)
  • 上海校區(qū)
  • 深圳校區(qū)
  • 武漢校區(qū)
  • 鄭州校區(qū)
  • 西安校區(qū)
  • 青島校區(qū)
  • 重慶校區(qū)
  • 太原校區(qū)
  • 沈陽校區(qū)
  • 南昌校區(qū)
  • 哈爾濱校區(qū)