Shared the basic concept of Kubernetes networking and how to have a mindset to debug your networking issue in your Kubernetes cluster.

1. HungWei Chiu 09/01/2022 LINE O
ffi
ce
Kubernetes 網路除錯⽢苦談

2. Who
• 矽⾕⽜耕⽥筆記
• CNTUG 志⼯
• 個⼈部落格
• https://hwchiu.com

3. 網路除錯之必要性與複雜性
• Kubernetes 主要三⼤⾯向
• 運算/網路/儲存
• 運算
• 基本上都基於容器為主，⼤部分使⽤者都可以藉由 Docker 等⽅式本地熟悉與學習，所以熟悉度最⾼
• 儲存
• 複雜但非必要，預設環境下不透過外部儲存也是可以正常運作
• 網路
• 複雜且必要，但是⼤部分的操作都被 Kubernetes 給抽象處理
• 不需要知道細節也可以運作，這是⼀個雙⾯刃

4. Kubernetes 的網路流量
• 以叢集為基點去觀看封包流向，⼤抵上可以分成東⻄向與南北向
• 南北向
• 流量進出叢集
• 東⻄向
• 流量於叢集中竄流

5. Kubernetes 的網路流量
• 南北向
• 外部服務如何存取叢集內的服務
• Ingress, API-Gateway, Load-Balancer 等
• 叢集內服務如何存取外部網路
• NAT(Network Address Translation)

6. Kubernetes 的網路流量
• 東⻄向
• 存取⽅向
• Pod to Service
• Pod to Pod
• 存取範圍
• 同節點
• 跨節點

7. Kubernetes 的網路流量

8. Kubernetes 南北向簡易畫法

9. Kubernetes 南北向其他架構

13. Kubernetes 東⻄向簡易畫法

15. Kubernetes 的網路流量
• 沒有⼀個萬解的網路架構
• 所有網路問題都要根據⽬標環境攤開來講
• 前述所有的圖都只是非常粗略不講細節的流向圖
• 架構為主，不探討實作
• 實務上除錯與維運則需要把實作給考慮進來

16. Kubernetes 的網路元件
• 基本上可以分成四類
• 底層基礎建設
• 內建
• CNI
• 第三⽅功能
• 這些網路元件互相整合才使得叢集有基本的網路功能
• 只要⼀個出錯，就會造成網路功能不如預期

17. Kubernetes 的網路元件
• 底層基礎建設
• 雲端使⽤者
• 就是滿滿的 VPC + Firewall + Routing
• 地端維運⼈員
• 節點與節點之間的連線，同時基本的 IP 發放
• 中間是否牽扯 Router/Switch，是否跨機櫃等
• 問你家網管

18. 底層基礎建設

19. Kubernetes 的網路元件
• 內建
• Kubernetes Service
• Kube-Proxy
• Iptables/ipvs
• Kubernetes Ingress
• 取決於你⽤哪⼀套 Ingress，不同套的實作細節不同
• CoreDNS
• HostNetwork (跳脫 CNI，繼承節點網路)
• Network Policy
• 取決於 CNI 設定

21. Kubernetes 的網路元件
• CNI 很深
• Calico -> BGP/IPIP
• Flannel -> VXLAN
• Cilium -> eBPF
• OVS -> OpenFlow
• Cloud-Provider speci
fi
ed
• AWS/Azure

22. CNI

23. Kubernetes 的網路元件
• 第三⽅功能
• Service Mesh
• Cluster Federation
• ...
• 這些功能都必須要建立於 Kubernetes 之上，同時疊加更多更複雜的功能來處理
網路封包
• 基礎功不夠，就只能當 YAML ⼯程師

25. Kubernetes 的除錯思路
• 網路非常複雜，也是最難除錯的
• 遇到問題第⼀步都是釐清
• ⽅向性
• 到底是南北向問題還是東⻄向問題
• 問題點
• 基礎建設？ K8s? CNI? 第三⽅整合?

26. Kubernetes 的除錯思路
• 網路問題極度不推薦⽤嘴除錯
• 推薦做法
• 畫出整個系統架構圖
• 標⽰出你的網路情境(從誰想要透過何種⽅式存取誰)
• 將⾃⼰想像成⼀個封包，於架構圖上解釋你認為封包會怎麼流動
• 這個步驟沒有辦法就代表你對於整體網路還是有不熟的地⽅
• 以上述過程的流動⽅式為基準開始除錯，透過測試的⽅式來逐漸縮⼩範圍

27. Kubernetes 的除錯思路

28. Kubernetes 的除錯思路

29. Kubernetes 的除錯思路
• 假設你聽到有⼈描述「我的 Pod 不能存取某個 Service 耶?」
• 你聽到會有什麼反應？
• 你期望對⽅告訴你什麼？

30. Kubernetes 的除錯思路
• 我通常會反問對⽅
• 你做過哪些測試？
• 你⽬前排除過哪些問題點？
• 這也是⼀個良好的合作⽅式，不要當無腦伸⼿牌
• 問問題請同時敘述⾃⼰做過什麼嘗試，⾃⼰⽬前認為卡關在哪裡

31. 思路範例
• 「我的 Pod 不能存取某個 Service 耶?」
• 跟 DNS 解析有無問題？ 直接使⽤ ClusterIP 試試看
• 跟 Service 轉換是否有關？ 直接打 Pod IP 試試看？
• 跟節點是否有關係？ 從同節點上的 Pod 打看看？
• 從節點直接打看看？
• 是否有 Network Policy?

32. 思路範例
• 「我的 Pod 不能存取某個 Service 耶?」
• 縮⼩範圍後如果還是不能釐清問題點，嘗試錄製封包
• 封包流向
• Server 沒收到
• Server 有收到，沒有回
• Server 有收到，也有回，但是 Client 沒有收到

33. 思路範例
• 「我的 Pod 不能存取某個 Service 耶?」
• 錄製的封包是否可以看出問題？
• 可能封包不如預期，被 Kernel 丟掉？
• 封包錄製不到？
• 問題發⽣於底層架構，請求其他⼈幫忙

34. 擷取封包
• 當現存⼯具都沒有辦法幫忙釐清為什麼網路不會通，這時候就可以借助抓取封
包的⽅式來判斷
• 問題要有辦法重現搭配擷取封包才好處理，否則事情已經發⽣，錯誤的封包已
經消失這時候其實也沒有辦法擷取分析
• 常⾒問題有
• 要⽤什麼⼯具擷取分析？
• 要如何從茫茫封包中找到⽬標封包?

35. 什麼⼯具
• 常⾒⼯具如 wireshark/tcpdump/tshark
• ⼤部分⼈環境不⼀定有 GUI 可以⽤，所以純 CLI ⼯具要優先熟悉
• 有了⼯具下⼀個就是誰要去運⾏這些⼯具來錄製封包？
• 節點:
• 管理上容易，要安裝⼯具也相對容易
• Pod 本⾝:
• 取決於運⾏容器，不⼀定有想要的除錯⼯具

36. 什麼⼯具 - 解決⽅式
• 節點: ⾃⼰安裝
• Pod 本⾝:
• 可以透過 ksni
ff
這套⼯具，該套⼯具可獨立使⽤也可以掛到 kubectl plugin 使
⽤
• 透過 kubectl 上傳⼀個事先編譯好的 tcpdump binary 到⽬標 Pod，並且將節
果給傳回到執⾏端
• 執⾏端如果有 wireshark，會打開變成串流模式

37. 尋找封包
• 假設今天是⼀個叢集內的東⻄向請求，該請求封包實際上會經過的落點非常多
• 不同發⽣點錄製的封包數量完全不⼀樣
• 完美情況是只要錄製跟⽬標有關的封包
• 最壞情況下就是錄製⼀⼤堆封包，然後嘗試從這些封包中找到⽬標封包

38. 尋找封包(精簡圖)

39. 尋找封包
• 從節點出發錄製封包往往遇到的第⼀個問題是，我要監聽哪⼀個網卡？
• 以 tcpdump 為範例
• -i any -> 監聽所有網卡，資料量最多，過濾最⿇煩
• -i xxxx -> 可以直接找到⽬標網卡的話，資料最精準
• CNI 的實作⽅式不同會使得這個網卡的⽅式不同
• 有⼀些 CNI 還會把封包進⾏⼆次封裝，如 vxlan, ipip 等，這些都會使得你收到的
封包不是你真的想要看到的封包

40. 其他雜錄
• 除了 Kubernetes 內的基本概念外， Linux 本⾝的概念也要有
• 常⽤⼯具
• ip/tcpdump
• Conntrack
• 系統有上限，超過就會出現連線問題
• Iptables/ipvs
• 網卡資訊與控制
• Ethtool
• rp_
fi
lter/routing/NAT ...etc

41. Q&A