Download as PDF, PPTX
Uploaded byHungWei Chiu
Debug Your Kubernetes Network
本文探讨了Kubernetes网络调试的复杂性和必要性，重点介绍了网络流量的南北向和东西向流动，以及常用的网络组件和调试思路。通过系统架构图和封包捕获工具，作者提供了实际的调试方法和常见问题的解决方案。文章强调理解网络架构的重要性和在调试过程中应采取的有效步骤。
Debug Your Kubernetes Network
- 1. HungWei Chiu 09/01/2022LINE 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.
- 8.
- 9.
- 13.
- 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.
- 23. Kubernetes 的網路元件 • 第三⽅功能 •Service Mesh • Cluster Federation • ... • 這些功能都必須要建立於 Kubernetes 之上，同時疊加更多更複雜的功能來處理 網路封包 • 基礎功不夠，就只能當 YAML ⼯程師
- 25. Kubernetes 的除錯思路 • 網路非常複雜，也是最難除錯的 •遇到問題第⼀步都是釐清 • ⽅向性 • 到底是南北向問題還是東⻄向問題 • 問題點 • 基礎建設？ K8s? CNI? 第三⽅整合?
- 26. Kubernetes 的除錯思路 • 網路問題極度不推薦⽤嘴除錯 •推薦做法 • 畫出整個系統架構圖 • 標⽰出你的網路情境(從誰想要透過何種⽅式存取誰) • 將⾃⼰想像成⼀個封包，於架構圖上解釋你認為封包會怎麼流動 • 這個步驟沒有辦法就代表你對於整體網路還是有不熟的地⽅ • 以上述過程的流動⽅式為基準開始除錯，透過測試的⽅式來逐漸縮⼩範圍
- 27.
- 28.
- 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.