Advertisement
Advertisement

More Related Content

Advertisement

Recently uploaded(20)

Debug Your Kubernetes Network

  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 南北向其他架構
  10. Kubernetes 東⻄向簡易畫法
  11. Kubernetes 的網路流量 • 沒有⼀個萬解的網路架構 • 所有網路問題都要根據⽬標環境攤開來講 • 前述所有的圖都只是非常粗略不講細節的流向圖 • 架構為主,不探討實作 • 實務上除錯與維運則需要把實作給考慮進來
  12. Kubernetes 的網路元件 • 基本上可以分成四類 • 底層基礎建設 • 內建 • CNI • 第三⽅功能 • 這些網路元件互相整合才使得叢集有基本的網路功能 • 只要⼀個出錯,就會造成網路功能不如預期
  13. Kubernetes 的網路元件 • 底層基礎建設 • 雲端使⽤者 • 就是滿滿的 VPC + Firewall + Routing • 地端維運⼈員 • 節點與節點之間的連線,同時基本的 IP 發放 • 中間是否牽扯 Router/Switch,是否跨機櫃等 • 問你家網管
  14. 底層基礎建設
  15. Kubernetes 的網路元件 • 內建 • Kubernetes Service • Kube-Proxy • Iptables/ipvs • Kubernetes Ingress • 取決於你⽤哪⼀套 Ingress,不同套的實作細節不同 • CoreDNS • HostNetwork (跳脫 CNI,繼承節點網路) • Network Policy • 取決於 CNI 設定
  16. Kubernetes 的網路元件 • CNI 很深 • Calico -> BGP/IPIP • Flannel -> VXLAN • Cilium -> eBPF • OVS -> OpenFlow • Cloud-Provider speci fi ed • AWS/Azure
  17. CNI
  18. Kubernetes 的網路元件 • 第三⽅功能 • Service Mesh • Cluster Federation • ... • 這些功能都必須要建立於 Kubernetes 之上,同時疊加更多更複雜的功能來處理 網路封包 • 基礎功不夠,就只能當 YAML ⼯程師
  19. Kubernetes 的除錯思路 • 網路非常複雜,也是最難除錯的 • 遇到問題第⼀步都是釐清 • ⽅向性 • 到底是南北向問題還是東⻄向問題 • 問題點 • 基礎建設? K8s? CNI? 第三⽅整合?
  20. Kubernetes 的除錯思路 • 網路問題極度不推薦⽤嘴除錯 • 推薦做法 • 畫出整個系統架構圖 • 標⽰出你的網路情境(從誰想要透過何種⽅式存取誰) • 將⾃⼰想像成⼀個封包,於架構圖上解釋你認為封包會怎麼流動 • 這個步驟沒有辦法就代表你對於整體網路還是有不熟的地⽅ • 以上述過程的流動⽅式為基準開始除錯,透過測試的⽅式來逐漸縮⼩範圍
  21. Kubernetes 的除錯思路
  22. Kubernetes 的除錯思路
  23. Kubernetes 的除錯思路 • 假設你聽到有⼈描述「我的 Pod 不能存取某個 Service 耶?」 • 你聽到會有什麼反應? • 你期望對⽅告訴你什麼?
  24. Kubernetes 的除錯思路 • 我通常會反問對⽅ • 你做過哪些測試? • 你⽬前排除過哪些問題點? • 這也是⼀個良好的合作⽅式,不要當無腦伸⼿牌 • 問問題請同時敘述⾃⼰做過什麼嘗試,⾃⼰⽬前認為卡關在哪裡
  25. 思路範例 • 「我的 Pod 不能存取某個 Service 耶?」 • 跟 DNS 解析有無問題? 直接使⽤ ClusterIP 試試看 • 跟 Service 轉換是否有關? 直接打 Pod IP 試試看? • 跟節點是否有關係? 從同節點上的 Pod 打看看? • 從節點直接打看看? • 是否有 Network Policy?
  26. 思路範例 • 「我的 Pod 不能存取某個 Service 耶?」 • 縮⼩範圍後如果還是不能釐清問題點,嘗試錄製封包 • 封包流向 • Server 沒收到 • Server 有收到,沒有回 • Server 有收到,也有回,但是 Client 沒有收到
  27. 思路範例 • 「我的 Pod 不能存取某個 Service 耶?」 • 錄製的封包是否可以看出問題? • 可能封包不如預期,被 Kernel 丟掉? • 封包錄製不到? • 問題發⽣於底層架構,請求其他⼈幫忙
  28. 擷取封包 • 當現存⼯具都沒有辦法幫忙釐清為什麼網路不會通,這時候就可以借助抓取封 包的⽅式來判斷 • 問題要有辦法重現搭配擷取封包才好處理,否則事情已經發⽣,錯誤的封包已 經消失這時候其實也沒有辦法擷取分析 • 常⾒問題有 • 要⽤什麼⼯具擷取分析? • 要如何從茫茫封包中找到⽬標封包?
  29. 什麼⼯具 • 常⾒⼯具如 wireshark/tcpdump/tshark • ⼤部分⼈環境不⼀定有 GUI 可以⽤,所以純 CLI ⼯具要優先熟悉 • 有了⼯具下⼀個就是誰要去運⾏這些⼯具來錄製封包? • 節點: • 管理上容易,要安裝⼯具也相對容易 • Pod 本⾝: • 取決於運⾏容器,不⼀定有想要的除錯⼯具
  30. 什麼⼯具 - 解決⽅式 • 節點: ⾃⼰安裝 • Pod 本⾝: • 可以透過 ksni ff 這套⼯具,該套⼯具可獨立使⽤也可以掛到 kubectl plugin 使 ⽤ • 透過 kubectl 上傳⼀個事先編譯好的 tcpdump binary 到⽬標 Pod,並且將節 果給傳回到執⾏端 • 執⾏端如果有 wireshark,會打開變成串流模式
  31. 尋找封包 • 假設今天是⼀個叢集內的東⻄向請求,該請求封包實際上會經過的落點非常多 • 不同發⽣點錄製的封包數量完全不⼀樣 • 完美情況是只要錄製跟⽬標有關的封包 • 最壞情況下就是錄製⼀⼤堆封包,然後嘗試從這些封包中找到⽬標封包
  32. 尋找封包(精簡圖)
  33. 尋找封包 • 從節點出發錄製封包往往遇到的第⼀個問題是,我要監聽哪⼀個網卡? • 以 tcpdump 為範例 • -i any -> 監聽所有網卡,資料量最多,過濾最⿇煩 • -i xxxx -> 可以直接找到⽬標網卡的話,資料最精準 • CNI 的實作⽅式不同會使得這個網卡的⽅式不同 • 有⼀些 CNI 還會把封包進⾏⼆次封裝,如 vxlan, ipip 等,這些都會使得你收到的 封包不是你真的想要看到的封包
  34. 其他雜錄 • 除了 Kubernetes 內的基本概念外, Linux 本⾝的概念也要有 • 常⽤⼯具 • ip/tcpdump • Conntrack • 系統有上限,超過就會出現連線問題 • Iptables/ipvs • 網卡資訊與控制 • Ethtool • rp_ fi lter/routing/NAT ...etc
  35. Q&A
Advertisement