Recommended
More Related Content
More from HungWei Chiu
More from HungWei Chiu (20)
Kubernetes 網路除錯所需技能大全
- 1. Kubernetes 網路除錯所需技能 大 全 HungWei Chiu, 10/26/2023, Kubernetes Summit 1
- 2. Who Am I • 邱宏瑋(HungWei Chiu) • Cloud Native Taiwan User Group 志 工 • 個 人 網站: https://www.hwchiu.com • 個 人 粉絲 頁 : 矽 谷 牛 的耕 田 筆記 • 著有書籍「矽 谷 工 程師教你 Kubernetes, 史上最全 CI/CD 中 文 應 用 指南」 • Microsoft MVP (Cloud and Data Center Management) 2 掃描獲得投影片
- 3. 網路問題 • 網路問題 大 抵上可以區分成 • 應 用 程式的問題 • 如 Server 太忙不能即時處理 Client • 網路元件造成之問題 • 不同特徵 • 永遠都不通 • 偶 而 不通，但是有辦法穩定重製 • 偶 而 不通，很隨機無法重製 3
- 4. A Chain Is Only As Strong As Its Weakest Link 4
- 7. Level 1 7
- 8. Level 2 8
- 9. Level 3 9
- 10. Level 4 10
- 11. Level 5 11
- 12. Level 6 12
- 13. Level 7 13
- 14. 14 Level 7
- 15. 15 Level 8
- 16. 16 Level 9
- 17. 如何除錯網路問題 • 排除無關之元件/環境 • 釐清問題發 生 情境 • 什麼組合才會發 生 問題 • 嘗試重製問題 • 反覆執 行 上述流程直到定位問題點 17
- 18. 排除無關之元件 • 釐清問題發 生 情境 • 排除不涉入的元件 • 使 用 合適 工 具 • 找尋錯誤 Log • 錄製封包 • 最重要還是要有網路相關知識 • Layer 3,4,7 為 大 宗 18
- 19. 釐清問題發 生 情境 • 以 Kubernetes 來說，流量常 見 可區分成東 西 流向與南北流向 • 東 西 向 • 流量於叢集中竄流 • Client/Server 屬於節點或是 Pod • 南北向 • 流量進出叢集 • Ingress • Egress 19
- 20. 情境探討(東 西 向) • 目 標與來源 • Pod to Pod • Pod to service • 範圍 • 同節點 • 跨節點 20
- 22. Pod To Pod(同節點) • 同節點上的容器互相存取(IP互打)，封包不會走出任何實體網卡 • 因此外部所有裝置都不涉獵 • 全部都是 Linux Kernel 內的資料轉移 • Pod 的網路基本上是由 CNI 幫忙處理 • 分配 IP • 建立基本路由表 • Host 上的 Kernel 進 行 轉發 22
- 23. Pod To Pod(同節點) • CNI • /etc/cni/net.d/ • CNI 相關資訊 • Pod Log • 其他除錯 工 具 • /opt/cni/bin • …/etc 23
- 24. Pod To Pod(同節點) • Pod/Host • ifcon f ig/ip a • route/ ip r • Host • Kernel Module • Overlay • br_net f ilter • … • Conntrack • ip_conntrack_max • nf_conntrack_max • Firewall • iptables/ebtables 24
- 25. Pod To Pod(同節點) • Host • Kernel parameters • bridge-nf-call-iptables • bridge-nf-call-ip6tables • TCP/IP • ip_forward • window size • … 等 • Net f ilter 25
- 26. Pod To Pod(同節點) • 錄製封包: • tcpdump • 指令好 用 ，錄製封包後可透過 wireshark 視覺化呈現與搜尋 • Pod to Node • 從容器下 手 • 容器內網卡單 一 ，但是不 一 定有相關 工 具 • 從節點下 手 • 容易安裝 工 具，但是網卡可能眾多 • Calicoxxxx • Vethxxxx • 如何知道哪張虛擬網卡對應到收送容器? • Node to Pod (與上述 一 樣) 26
- 27. Pod To Pod(同節點) • 若容器內沒有 tcpdump，可嘗試 ksniff 指令 • 該指令會動態上傳 一 個 tcpdump 的 binary，並且透過 kubectl cp 的概念傳到 容器內 • 可直接銜接 tshark/wireshark 等指令來分析內容 27 https://blog.pichuang.com.tw/20231013-remote-capture-packets-from-aks.html
- 28. Pod To Pod(同節點) • 此外 pod 有些設定會直接跳脫這些 • hostNetwork • 沒有 CNI 介入，直接共享 Host 網路 • containers.port.hostPort: • 類似 docker -p，直接從節點轉發到 Pod • 上述 用 法都可能導致封包收送不如預期 28
- 29. Pod To Pod(同節點) • 除了錄製封包外， Linux 上還有各種 工 具可以去追蹤封包 • 但是你都要有辦法 reproduce 問題才好追蹤 • 這類型的 工 具都會提供資訊讓你有機會去判別封包為什麼被 kernel 丟棄 • 必須要先理解 一 些 kernel network stack 的運作流程跟概念，不然其實看不太懂 • systemTap/dropwatch.stp • ftrace • kprobe • nettrace 29
- 31. Pod To Pod(跨節點) • 跨節點 Pod 互打(打 IP) • 封包出節點，出網卡 • 跨節點就會牽扯到 overlay + underlay 網路 31
- 32. Pod To Pod(跨節點) • Underlay Network • L2 • ARP/Switching • L3 • Routing/BGP • MTU • Firewall • 譬如 Azure 會阻擋 IPIP 封包，因此 Azure 上跑 Calico 需要調整為 VXLAN 模式 32
- 33. Pod To Pod(跨節點) • Overlay Network • 每個 CNI 做法不 一 致 • VXLAN, IPIP, Geneve…等 • 大 部分都可以系統指令去觀察節點上的設定 • ip a/ip r/ip s 等相關指令 • 若要跳脫 CNI 自 行 搭建 Overlay 則操作 又 會更複雜 • MTU 也要特別注意會不會因為 overlay network 有額外的 header 33
- 34. Pod To Pod(跨節點) • 錄製封包: • 封包走向可拆分成 • Pod to Node(與前述 一 樣) • Node to Node • 判別封包是否可以順利跨節點移動 • 由於 overlay network 的介入，你錄製封包要特別 小 心 • 你送出的封包協定都會先被 overlay 包裝，因此過濾條件如 VXLAN/IPIP 等都要設定。 • Node to Pod(與前述 一 樣) 34
- 36. Pod To Service • Service 基本上會由兩個主要元件處理 • ClusterIP/NodePort IP • 預設由 kube-proxy 接 手 • Cilium 可幫忙處理 • 解析 DNS • 由內部的 CoreDNS 處理 36
- 37. Pod To Service • ClusterIP/NodePort • 常 見 就節點上的 iptables/ipvs 處理，搭配相關 工 具 • 規則繁瑣複雜，不出錯沒事情，若出錯則很 麻 煩 • 不熟悉也不要亂改，以免弄壞其他服務 • Cilium 依賴 eBPF 動態修改，需要的除錯技能更進階 • 還要考慮 Service 是否有額外設定 • internalTraf f icPolicy: Cluster(default), Local • externalTraf f icPolicy: Cluster(default), Local 37
- 38. Pod To Service • 若採 用 Service 產 生 的 hostname，則封包會先流向 CoreDNS • Pod 內的 /etc/resolve.conf 會被修改 • 注意 fully quali f ied 與 ndots 的規則與效能 • DNS 問題還要考慮 Container Image 是否為 Alpine • 常 見 知名問題，3.18 宣稱解決所有網路問題並 支 援 DNS over TCP. • https://www.theregister.com/2023/05/16/alpine_linux_318/ • 若有採 用 NodeLocal DNSCache 的架構，還需要多考慮 一 層 38
- 39. Pod To Service • 若有導入 istio 或其他 service mesh 的 用 法，則上述提到的機制可能都會被推 翻 • 以 istio 來說，則要從 virtualService 設定以及 envoy debug message 來獲得 所有除錯可能性 • 除錯可以先排除 istio，從 Service 階層去判別問題，若 Service 層級本 身 就 有問題，通常跟 istio 無關，反之亦然 • istio 本 身 也有提供每個 sidecar 的 metrics 供檢視個服務間的流量資訊，也可 以透過 kiali 視覺化 39
- 40. 情境探討(南北向) • 目 標與來源 • WAN to Pod • Pod to WAN 40
- 41. Pod To WAN 41
- 42. Pod To WAN • 封包從節點出去後，就會依賴 underlay network 去處理 • 雲端環境都有 自 己 的 VPC 架構來把封包網外轉出 • 通常都會有所謂的 NAT Gateway，幫忙封包轉出 • SNAT (Source Network Address Translation) • 請仔細閱讀每個雲端架構元件的設定，譬如 GCP Cloud NAT • Static/Dynamic Port Allocation: 影響後端每個 VM 可以產 生 多少條對外 連線，數字太 小 會導致你的新連線被 Cloud NAT 丟棄 42
- 43. Pod To WAN • Underlay Network • K8s 管理 人 員通常沒有權限去存取 • 也不 一 定有 足 夠的網路知識去判別底下的設計與操作 • 簡化除錯 • 可以先簡化成 Node To WAN 先確認看看此步驟是否有問題，若有問題就可以請底層團隊協 助 • 排除容器等無關資訊，讓底層團隊也更好研究 • 若 Node To WAN 順利，但是 Pod To WAN 不順序 • 看看 CNI, Network Policy 以及節點上的防火牆，也可以錄製封包觀察差異 43
- 44. WAN To Pod 44
- 45. WAN To Pod • 上述的圖片實際上不夠精準，Load-Balancer 如何將封包轉送到 Kubernetes 內則有不同 方 式 • 以 AWS/Azure 為例，其 CNI 可以攤平網路 • 讓 Underlay Network 與 Overlay Network 共享網段 • Load-Balancer 可以直接存取 Pod，不需要 二 次轉換 45
- 46. WAN to Pod 46
- 47. WAN To Pod • 這類型的架構很綁定雲端，同時也會有諸多限制要處理 • AWS CNI 會根據節點等級給予限制能夠部署的容器數量 • 由於流量是 LB -> Pod 進來，這部分通常會有相關的 Controller 幫忙處理 • Pod 的變動 (更新, IP 變動) 等資訊是否即時被更新到 LB 上 • 因此若 Controller 有問題，則可能會導致 LB 的流量無法進來 47
- 48. WAN To Pod • 若不採 用 這類型的 CNI，則 大 部分都會採 用 NodePort 的 方 式來打通 • 只要流量進入到 Kubernetes，後續的流量就會分成 • Pod to Service (前述探討過) • Pod to Pod(前述探討過) • Ingress Controller/Ingress Gateway • 仰賴每個 工 具本 身 的設定與除錯 48
- 49. 網路 • 從 Client <-> Server 的簡單敘述來看，其背後有超多元件會涉入 • 就如同開頭所述般，所有的問題都是取決於最弱的那 一 環 • Timeout • Max connection number • Connection size • …等 • 因此 一 但發 生 問題時，就需要抽絲剝繭找出來當前問題發 生 點，並且逐漸縮 小 49
- 50. 總結 • 釐清當前問題情境 • 排除無關元件 • 執 行 動作進 行 除錯與排除 • 反覆執 行 前述流程直到找到問題發 生 點 • 網路技能平常 用 不到，但是發 生 問題時若不會就很 麻 煩 • 對於所有理所當然的連線保持好奇 心 ，嘗試去畫出架構圖來確保 自 己 是否理 解所有流程。 50
- 51. Thanks 51