當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

追踪 Kubernetes 中的网络流量

發布時間：2024/8/23 编程问答 45 豆豆

生活随笔收集整理的這篇文章主要介紹了追踪 Kubernetes 中的网络流量小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

作者 | Addo Zhang

來源 |?云原生指北

譯者注：

這篇文章很全面的羅列出了 Kubernetes 中涉及的網絡知識，從 Linux 內核的網絡內容，到容器、Kubernetes，一一進行了詳細的說明。

文章篇幅有點長，不得不說，網絡是很復雜很麻煩的一層，但恰恰這層多年來變化不大。希望翻譯的內容對大家能有所幫助，有誤的地方，也歡迎大家指正。

本文翻譯獲得?Learnk8s 的授權，原文?Tracing the path of network traffic in Kubernetes^[1]?作者?Kristijan Mitevski。

TL;DR：?本文將代理了解 Kubernetes 集群內外的數據流轉。從最初的 Web 請求開始，一直到托管應用程序的容器。

Kubernetes 網絡要求
Linux 網絡命名空間如果在 pod 中工作
Pause 容器創建 Pod 中的網絡命名空間
為 Pod 分配了 IP 地址
檢查集群中 pod 到 pod 的流量
Pod 命名空間連接到以太網橋接器
跟蹤同一節點上 pod 間的流量
跟蹤不同節點上 pod 間的通信
- 位運算的工作原理
容器網絡接口 - CNI
檢查 pod 到服務的流量
使用 Netfilter 和 Iptables 攔截和重寫流量
檢查服務的響應
回顧

Kubernetes 網絡要求

在深入了解 Kubernetes 中的數據流轉之前，讓我們先澄清下 Kubernetes 網絡的要求。

Kubernetes 網絡模型定義了一套基本規則：

集群中的 pod 應該能夠與任何其他 pod 自由通信，而無需使用網絡地址轉換（NAT）。
在不使用 NAT 的情況下，集群節點上運行的任意程序都應該能夠與同一節點上的任意 pod 通信。
每個 pod 都有自己的 IP 地址（IP-per Pod），其他 pod 都可以使用同一個地址進行訪問。

這些要求不會將實現限制在單一方案上。

相反，他們概括了集群網絡的特性。

在滿足這些限制時，必須解決如下挑戰^[2]：

如何保證同一 pod 中的容器間的訪問就像在同一主機上一樣？

Pod 能否訪問集群中的其他 pod？

Pod 能否訪問服務（service）？以及服務可以負載均衡請求嗎？

Pod 可以接收來自集群外的流量嗎？

本文將專注于前三點，從 pod 內部網絡或者容器間的通信說起。

Linux 網絡命名空間如果在 pod 中工作

我們想象下，有一個承載應用程序的主容器和另一個與它一起運行的容器。

在示例 Pod 中有一個 Nginx 容器和 busybox 容器：

apiVersion:?v1 kind:?Pod metadata:name:?multi-container-pod spec:containers:-?name:?container-1image:?busyboxcommand:?['/bin/sh',?'-c',?'sleep?1d']-?name:?container-2image:?nginx

在部署時，會出現如下情況：

Pod 在節點上得到自己的網絡命名空間。

Pod?分配到一個 IP 地址，兩個容器間共享端口。

兩個容器共享同一個網絡命名空間，在本地互相可見。

網絡配置在后臺很快完成。

然后，我們退后一步，是這理解為什么上面是容器運行所必須的。

在 Linux 中，網絡命名空間是獨立的、隔離的邏輯空間。^[3]

可以將網絡命名空間堪稱將物理網絡接口分割成更小的獨立部分。

每部分都可以單獨配置，并使用自己的網絡規則和資源。

這些可以包括防火墻規則、接口（虛擬或物理）、路由和其他所有與網絡相關的內容。

物理接口持有根命名空間。

可以使用 Linux 網絡命名空間創建隔離的網絡。每個網絡都是獨立的，除非進行配置否則不會與其他命名空間通信。

物理接口必須處理最后的所有真實數據包，因此所有的虛擬接口都是從中創建的。

網絡命名空間可以通過?`ip-netns` 管理工具^[4]?來管理，可以使用?ip netns list?列出主機上的命名空間。

請注意，創建的網絡命名空間將會出現在?/var/run/netns?目錄下，但?Docker 并沒有遵循這一點^[5]。

例如，下面是 Kubernetes 節點的命名空間：

$?ip?netns?list cni-0f226515-e28b-df13-9f16-dd79456825ac?(id:?3) cni-4e4dfaac-89a6-2034-6098-dd8b2ee51dcd?(id:?4) cni-7e94f0cc-9ee8-6a46-178a-55c73ce58f2e?(id:?2) cni-7619c818-5b66-5d45-91c1-1c516f559291?(id:?1) cni-3004ec2c-9ac2-2928-b556-82c7fb37a4d8?(id:?0)

注意?cni-?前綴意味著命名空間的創建由 CNI 來完成。

當創建 pod 并分配給節點時，CNI^[6]?會：

為其創建網絡命名空間。

分配 IP 地址。

將容器連接到網絡。

如果 pod 像上面的示例一樣包含多個容器，則所有容器都被置于同一個命名空間中。

創建 pod 時，CNI 為容器創建網絡命名空間

然后分配 IP 地址

最后將容器連接到網絡的其余部分

那么當列出節點上的容器時會看到什么？

可以 SSH 到 Kubernetes 節點來查看命名空間：

$?lsns?-t?netNS?TYPE?NPROCS???PID?USER?????NETNSID?NSFS???????????????????????????COMMAND 4026531992?net?????171?????1?root??unassigned?/run/docker/netns/default??????/sbin/init?noembed?norestore 4026532286?net???????2??4808?65535??????????0?/run/docker/netns/56c020051c3b?/pause 4026532414?net???????5??5489?65535??????????1?/run/docker/netns/7db647b9b187?/pause

lsns?命令會列出主機上所有的命名空間。

記住 Linux 中有多種命名空間類型^[7]。

Nginx 容器在哪？

那么?pause?容器又是什么？

Pause 容器創建 Pod 中的網絡命名空間

從節點上的所有進程中找出 Nginx 容器：

$?lsnsNS?TYPE???NPROCS???PID?USER????????????COMMAND #?truncated?output 4026532414?net?????????5??5489?65535???????????/pause 4026532513?mnt?????????1??5599?root????????????sleep?1d 4026532514?uts?????????1??5599?root????????????sleep?1d 4026532515?pid?????????1??5599?root????????????sleep?1d 4026532516?mnt?????????3??5777?root????????????nginx:?master?process?nginx?-g?daemon?off; 4026532517?uts?????????3??5777?root????????????nginx:?master?process?nginx?-g?daemon?off; 4026532518?pid?????????3??5777?root????????????nginx:?master?process?nginx?-g?daemon?off;

該容器出現在了掛在（mount?mnt）、Unix 分時系統（Unix time-sharing?uts）和 PID（pid）命名空間中，但是并不在網絡命名空間（net）中。

不幸的是，lsns?只顯示了每個進程最低的 PID，不過可以根據進程 ID 進一步過濾。

可以通過以下內容檢索Nginx 容器的所有命名空間：

$?sudo?lsns?-p?5777NS?TYPE???NPROCS???PID?USER??COMMAND 4026531835?cgroup????178?????1?root??/sbin/init?noembed?norestore 4026531837?user??????178?????1?root??/sbin/init?noembed?norestore 4026532411?ipc?????????5??5489?65535?/pause 4026532414?net?????????5??5489?65535?/pause 4026532516?mnt?????????3??5777?root??nginx:?master?process?nginx?-g?daemon?off; 4026532517?uts?????????3??5777?root??nginx:?master?process?nginx?-g?daemon?off; 4026532518?pid?????????3??5777?root??nginx:?master?process?nginx?-g?daemon?off;

pause?進程再次出現，這次它劫持了網絡命名空間。

那是什么？

集群中的每個 pod 都有一個在后臺運行的隱藏容器，被稱為?pause。

列出節點上的所有容器并過濾出 pause 容器：

$?docker?ps?|?grep?pause fa9666c1d9c6???k8s.gcr.io/pause:3.4.1??"/pause"??k8s_POD_kube-dns-599484b884-sv2js… 44218e010aeb???k8s.gcr.io/pause:3.4.1??"/pause"??k8s_POD_blackbox-exporter-55c457d… 5fb4b5942c66???k8s.gcr.io/pause:3.4.1??"/pause"??k8s_POD_kube-dns-599484b884-cq99x… 8007db79dcf2???k8s.gcr.io/pause:3.4.1??"/pause"??k8s_POD_konnectivity-agent-84f87c…

將看到對于節點分配到的每個 pod，都有一個匹配的?pause?容器。

該?pause?容器負責創建和維持網絡命名空間。

它包含的代碼極少，部署后立即進入睡眠狀態。

然而，它在 Kubernetes 生態中的首當其沖，發揮著至關重要的作用。^[8]。

創建 pod 時，CNI 會創建一個帶有睡眠容器的網絡命名空間

Pod 中的所有容器都會加入到它創建的網絡命名空間中

此時 CNI 分配 IP 地址并將容器連接到網絡

進入睡眠狀態的容器有什么用？

要了解它的實用性，我們可以想象下如示例一樣有兩個容器的 pod，但沒有?pause?容器。

容器啟動，CNI：

為 Nginx 容器創建一個網絡命名空間。

把 busybox 容器加入到前面創建的網絡命名空間中。

為 pod 分配 IP 地址。

將容器連接到網絡。

假如 Nginx 容器崩潰了會發生什么？

CNI 將不得不再次完成所有流程，兩個容器的網絡都會中斷。

由于?sleep?容器不太可能有任何 bug，因此創建網絡命名空間通常是一個更保險、更健壯的選擇。

如果 pod 中的一個容器崩潰，其余的仍可以處理網絡請求。

為 Pod 分配了 IP 地址

前面提到 pod 和所有容器獲得了同樣的 IP。

這是怎么配置的？

在 pod 網絡命名空間中，創建一個接口并分配 IP 地址。

我們來驗證下。

首先，找到 pod 的 IP 地址：

$?kubectl?get?pod?multi-container-pod?-o?jsonpath={.status.podIP} 10.244.4.40

接下來，找到相關的網絡命名空間。

由于網絡命名空間是從物理接口創建的，需要訪問集群節點。

如果你運行的是 minikube，可以通過?minikube ssh?訪問節點。如果在云提供商中運行，應該有某種方法通過 SSH 訪問節點。

進入后，可以找到創建的最新的網絡命名空間：

$?ls?-lt?/var/run/netns total?0 -r--r--r--?1?root?root?0?Sep?25?13:34?cni-0f226515-e28b-df13-9f16-dd79456825ac -r--r--r--?1?root?root?0?Sep?24?09:39?cni-4e4dfaac-89a6-2034-6098-dd8b2ee51dcd -r--r--r--?1?root?root?0?Sep?24?09:39?cni-7e94f0cc-9ee8-6a46-178a-55c73ce58f2e -r--r--r--?1?root?root?0?Sep?24?09:39?cni-7619c818-5b66-5d45-91c1-1c516f559291 -r--r--r--?1?root?root?0?Sep?24?09:39?cni-3004ec2c-9ac2-2928-b556-82c7fb37a4d8

本示例中，它是?cni-0f226515-e28b-df13-9f16-dd79456825ac。此時，可以在該命名空間總執行?exec命令：

$?ip?netns?exec?cni-0f226515-e28b-df13-9f16-dd79456825ac?ip?a #?output?truncated 3:?eth0@if12:?<BROADCAST,MULTICAST,UP,LOWER_UP>?mtu?1450?qdisc?noqueue?state?UP?group?defaultlink/ether?16:a4:f8:4f:56:77?brd?ff:ff:ff:ff:ff:ff?link-netnsid?0inet?10.244.4.40/32?brd?10.244.4.40?scope?global?eth0valid_lft?forever?preferred_lft?foreverinet6?fe80::14a4:f8ff:fe4f:5677/64?scope?linkvalid_lft?forever?preferred_lft?forever

10.244.4.40?就是 pod 的 IP 地址。

通過查找?@if12?中的?12?找到網絡接口。

$?ip?link?|?grep?-A1?^12 12:?vethweplb3f36a0@if16:?mtu?1376?qdisc?noqueue?master?weave?state?UP?mode?DEFAULT?group?defaultlink/ether?72:1c:73:d9:d9:f6?brd?ff:ff:ff:ff:ff:ff?link-netnsid?1

還可以驗證 Nginx 容器是否從該命名空間中監聽 HTTP 流量：

$?ip?netns?exec?cni-0f226515-e28b-df13-9f16-dd79456825ac?netstat?-lnp Active?Internet?connections?(only?servers) Proto?Recv-Q?Send-Q?Local?Address???????????Foreign?Address?????????State???????PID/Program?name tcp????????0??????0?0.0.0.0:80??????????????0.0.0.0:*???????????????LISTEN??????692698/nginx:?master tcp6???????0??????0?:::80???????????????????:::*????????????????????LISTEN??????692698/nginx:?master

如果無法通過 SSH 訪問集群的節點，可以試試?kubectl exec?進入到 busybox 容器，然后使用?ip?和?netstat?命令。

太棒了！

現在我們已經介紹了容器間的通信，接下來看看 Pod 與 Pod 直接如何建立通信。

檢查集群中 pod 到 pod 的流量

當說起 pod 間通信時，會有兩種可能：

Pod 流量流向同一節點上的 pod。

Pod 流量流量另一個節點上的 pod。

為了使整個設置正常工作，我們需要之前討論過的虛擬接口和以太網橋接。

在繼續之前，我們先討論下他們的功能以及為什么他們時必需的。

要完成 pod 與其他 pod 的通信，它必須先訪問節點的根命名空間。

這是使用連接 pod 和根命名空間的虛擬以太網對來實現的。

這些虛擬接口設備^[9]（veth?中的?v）連接并充當兩個命名空間間的隧道。

使用此?veth?設備，將一端連接到 pod 的命名空間，另一端連接到根命名空間。

這些 CNI 可以替你做，也可以手動操作：

$?ip?link?add?veth1?netns?pod-namespace?type?veth?peer?veth2?netns?root

現在 pod 的命名空間有了可以訪問根命名空間的隧道。

節點上每個新建的 pod 都會設置如下所示的 veth 對。

創建接口對時其中一部分。

其他的就是為以太網設備分配地址，并創建默認路由。

來看下如何在 pod 的命名空間中設置?veth1?接口：

$?ip?netns?exec?cni-0f226515-e28b-df13-9f16-dd79456825ac?ip?addr?add?10.244.4.40/24?dev?veth1 $?ip?netns?exec?cni-0f226515-e28b-df13-9f16-dd79456825ac?ip?link?set?veth1?up $?ip?netns?exec?cni-0f226515-e28b-df13-9f16-dd79456825ac?ip?route?add?default?via?10.244.4.40

在節點側，我們創建另一個?veth2?對：

$?ip?addr?add?169.254.132.141/16?dev?veth2 $?ip?link?set?veth2?up

可以像以前一樣檢查現有的?veth?對。

在 pod 的命名空間中，檢查?eth0?接口的后綴。

$?ip?netns?exec?cni-0f226515-e28b-df13-9f16-dd79456825ac?ip?link?show?type?veth 3:?eth0@if12:?<BROADCAST,MULTICAST,UP,LOWER_UP>?mtu?1450?qdisc?noqueue?state?UP?mode?DEFAULT?group?defaultlink/ether?16:a4:f8:4f:56:77?brd?ff:ff:ff:ff:ff:ff?link-netnsid?0

這種情況下可以使用?grep -A1 ^12?進行查找（或者滾動到目標所在）：

$?ip?link?show?type?veth #?output?truncated 12:?cali97e50e215bd@if3:?<BROADCAST,MULTICAST,UP,LOWER_UP>?mtu?1450?qdisc?noqueue?state?UP?mode?DEFAULT?group?defaultlink/ether?ee:ee:ee:ee:ee:ee?brd?ff:ff:ff:ff:ff:ff?link-netns?cni-0f226515-e28b-df13-9f16-dd79456825ac

也可以使用?ip -n cni-0f226515-e28b-df13-9f16-dd79456825ac link show type veth命令。

注意?3: eth0@if12?和?12: cali97e50e215bd@if3?接口上的符號。

在 pod 命名空間中，eth0?接口連接到根命名空間中編號為?12?的接口。因此是?@if12。

在?veth?對的另一端，根命名空間連接到 pod 命名空間的?3?號接口。

接下來是連接?veth?對兩端的橋接器（bridge）。

Pod 命名空間連接到以太網橋接器

橋接器將位于根命名空間中的虛擬接口的每一端“綁定”。

該橋接器將允許流量在虛擬對之間流動，并通過公共根命名空間。

理論時間。

以太網橋接器位于OSI 網絡模型^[10]的第二層。

可以將橋接器看作一個虛擬交換機，接受來自不同命名空間和接口的連接。^[11]

以太網橋接器允許連接同一個節點上的多個可用網絡。

因此，可以使用該設置連接兩個接口：從 pod 命名空間的?veth?連接到同一節點上另一個 pod 的?veth。

我們繼續看下以太網橋接器和 veth 對的作用。

跟蹤同一節點上 pod 間的流量

假設同一個節點上有兩個 pod，Pod-A 想向 Pod-B 發送消息。

由于目標不是同命名空間的容器，Pod-A 向其默認接口?eth0?發送數據包。這個接口與?veth?對的一端綁定，作為隧道。因此數據包將被轉發到節點的根命名空間。

以太網橋接器作為虛擬交換機，必須以某種方式將目標 pod IP（Pod-B）解析為其 MAC 地址。

輪到ARP 協議上場了。當幀到達橋接器時，會向所有連接的設備發送 ARP 廣播。橋接器喊道誰有 Pod-B 的 IP 地址。

收到帶有連接 Pod-B 接口的 MAC 地址的回復，然后此信息存儲在橋接器 ARP 緩存（查找表）中。

IP 和 MAC 地址的映射存儲完成后，橋接器在表中查找，并將數據包轉發到正確的短點。數據包到達根命名空間中 Pod- B 的?veth，然后從那快速到達 Pod-B 命名空間內的?eth0?接口。

有了這個，Pod-A 和 Pod-B 之間的通信取得了成功。

跟蹤不同節點上 pod 間的通信

對于需要跨不同節點通信的 pod，需要額外的通信跳轉。

前幾個步驟保持不變，直到數據包到達根命名空間并需要發送到 Pod- B。

當目標地址不在本地網絡中，數據包將被轉發到本節點的默認網關。節點上退出或默認網關通常位于?eth0?接口上 -- 將節點連接到網絡的物理接口。

這次并不會發生 ARP 解析，因為源和目標 IP 在不同網絡上。

檢查使用位運算（Bitwise）操作完成。

當目標 IP 不在當前網絡上時，數據包將被轉發到節點的默認網關。

位運算的工作原理

在確定數據包的轉發位置時，源節點必須執行位運算。

這也被稱為與操作。^[12]

作為復習，位與操作產生如下結果：

0?AND?0?=?0 0?AND?1?=?0 1?AND?0?=?0 1?AND?1?=?1

除了 1 與 1 以外的都是 false。

如果源節點的 IP 為 192.168.1.1，子網掩碼為 /24，目標 IP 為 172.16.1.1/16，則按位與操作將確認他們不在同一網絡上。

這意味著目標 IP 與數據包的源在不同的網絡上，因此數據包將在默認網關中轉發。

數學時間。

我們必須從二進制文件中的 32 位地址執行與操作開始。

先找出源和目標 IP 的網絡。

|?Type?????????????|?Binary??????????????????????????????|?Converted??????????| |?----------------?|?-----------------------------------?|?------------------?| |?Src.?IP?Address??|?11000000.10101000.00000001.00000001?|?192.168.1.1????????| |?Src.?Subnet?Mask?|?11111111.11111111.11111111.00000000?|?255.255.255.0(/24)?| |?Src.?Network?????|?11000000.10101000.00000001.00000000?|?192.168.1.0????????| |??????????????????|?????????????????????????????????????|????????????????????| |?Dst.?IP?Address??|?10101100.00010000.00000001.00000001?|?172.16.1.1?????????| |?Dst.?Subnet?Mask?|?11111111.11111111.00000000.00000000?|?255.255.0.0(/16)???| |?Dst.?Network?????|?10101100.00010000.00000000.00000000?|?172.16.0.0?????????|

位運算操作后，需要將目標 IP 與數據包源節點的子網進行比較。

進行位比較后，ARP 會檢查其查詢表來查找默認網關的 MAC 地址。

如果有條目，將立即轉發數據包。

否則，先進行廣播以確定網關的 MAC 地址。

數據包現在路由到另一個節點的默認接口，我們叫它 Node-B。

以相反的順序。數據包現在位與 Node-B 的根命名空間，并到達橋接器，這里會進行 ARP 解析。

收到帶有連接 Pod-B 的接口 MAC地址的回復。

這次橋接器通過 Pod-B 的?veth?設備將幀轉發，并到達 Pod-B 自己的命名空間。

此時應該已經熟悉了 pod 之間的流量如何流轉，接下來再探索下 CNI 如何創建上述內容。

容器網絡接口 - CNI

容器網絡接口（CNI）關注當前節點的網絡。^[13]

可以將 CNI 看作網絡插件在解決 Kubernetes?某些?需求時要遵循的一套規則。

然而，它不僅僅與 Kubernetes 或者特定網絡插件關聯。

可以使用如下 CNI：

Calico^[14]
Cilium^[15]
Flannel^[16]
Weave Net^[17]
其他網絡插件^[18]

他們都實現相同的 CNI 標準。

如果沒有 CNI，你需要手動完成如下操作：

創建 pod（容器）的網絡命名空間
創建接口
創建 veth 對
設置命名空間網絡
設置靜態路由
配置以太網橋接器
分配 IP 地址
創建 NAT 規則

還有太多其他需要手動完成的工作。

更不用說刪除或重新啟動 pod 時刪除或調整上述所有內容了。

CNI 必須支持四個不同的操作^[19]：

ADD?- 將容器添加到網絡
DEL?- 從網絡中刪除容器
CHECK?- 如果容器的網絡出現問題，則返回錯誤
VERSION?- 顯示插件的版本

讓我們在實踐中看看它是如何工作的。

當 pod 分配到特定節點時，kubelet 本身不會初始化網絡。

相反，它將任務交給了 CNI。

然后，它指定了配置，并以 JSON 格式將其發送給 CNI 插件。

可以在節點的?/etc/cni/net.d?目錄中，找到當前 CNI 的配置文件：

$?cat?10-calico.conflist {"name":?"k8s-pod-network","cniVersion":?"0.3.1","plugins":?[{"type":?"calico","datastore_type":?"kubernetes","mtu":?0,"nodename_file_optional":?false,"log_level":?"Info","log_file_path":?"/var/log/calico/cni/cni.log","ipam":?{?"type":?"calico-ipam",?"assign_ipv4"?:?"true",?"assign_ipv6"?:?"false"},"container_settings":?{"allow_ip_forwarding":?false},"policy":?{"type":?"k8s"},"kubernetes":?{"k8s_api_root":"https://10.96.0.1:443","kubeconfig":?"/etc/cni/net.d/calico-kubeconfig"}},{"type":?"bandwidth","capabilities":?{"bandwidth":?true}},{"type":?"portmap",?"snat":?true,?"capabilities":?{"portMappings":?true}}] }

每個插件都使用不同類型的配置來設置網絡。

例如，Calico 使用 BGP 路由協議配對的第 3 層網絡來連接 pod。

Cilium 在第 3 到 7 層使用 eBPF 配置覆蓋網絡。

與 Calico 一起，Cilium 支持設置網絡策略來限制流量。

那該如何選擇呢？

這取決于。

CNI 主要有兩組。

第一組中，可以找到使用基本網絡設置（也稱為扁平網絡）的CNI，并將集群 IP 池中的IP 地址分配給 pod。

這可能會因為快速用盡可用的 IP 地址而成為負擔。

相反，另一種方法是使用覆蓋網絡。

簡而言之，覆蓋網絡是主（底層）網絡之上的輔助網絡。

覆蓋網絡的工作原理是封裝來自底層網絡的所有數據包，這些數據包指向另一個節點上的 pod。

覆蓋網絡的一項流行技術是?VXLAN^[20]，它允許在 L3 網絡上隧道傳輸 L2 域。

那么哪種更好？

沒有唯一的答案，通常取決于你的需求。

你是在構建一個擁有數萬個節點的大集群嗎？

可能覆蓋網絡更好。

你是否在意更簡單的設置和在嵌套網絡中不失去檢查網絡流量的能力。

扁平網絡更適合你。

現在已經討論了 CNI，讓我們繼續探索 Pod 到服務（service）的通信是如何完成的。

檢查 pod 到服務的流量

由于 Kubernetes 環境下 pod 的動態特性，分配給 pod 的 IP 地址不是靜態的。

這些 IP 地址是短暫的，每次創建或者刪除 pod 時都會發生變化。

服務解決了這個問題，為連接到一組 pod 提供了穩定的機制。

默認情況下，在 Kubernetes 中創建服務時，會為其預定并分配虛擬 IP?^[21]。

使用選擇器將服務于目標 pod 進行管理。

當刪除 pod 并添加新 pod 時會發生什么？

該服務的虛擬 IP 保持不變。

然而，無需敢于，流量將到達新創建的 pod。

換句話說，Kubernetes 中的服務類似于負載均衡器。

但他們時如何工作的？

使用 Netfilter 和 Iptables 攔截和重寫流量

Kubernetes 中的服務基于兩個 Linux 內核組件：

Netfilter

Iptables

Netfilter 是一個框架，允許配置數據包過濾、創建 NAT或端口翻譯規則，并管理網絡中的流量。

此外，它還屏蔽和阻止不請自來的連接訪問服務。

另一方面，Iptables 是一個用戶空間程序，允許你配置 Linux 內核防火墻的 IP 數據包過濾器規則。

iptables 使用不同的 Netfilter 模塊實現。

你可以使用 iptables CLI 實時更改過濾規則，并將其插入 netfilters 的掛點。

過濾器組織在不同的表中，其中包含處理網絡流量數據包的鏈。

每個協議都使用不同的內核模塊和程序。

當提到 iptables 時，通常說的是 IPV4。對于 IPV6 的規則，CLI 是 ip6tables。

Iptables 有五種類型的鏈，每種鏈都直接映射到 Netfilter 鉤子。

從 iptables 角度看是：

PRE_ROUTING
INPUT
FORWARD
OUTPUT
POST_ROUTING

對應映射到 Netfilter 鉤子：

NF_IP_PRE_ROUTING
NF_IP_LOCAL_IN
NF_IP_FORWARD
NF_IP_LOCAL_OUT
NF_IP_POST_ROUTING

當數據包到達時，根據所處的階段，會“出發” Netfilter 鉤子，該鉤子應用特定的 iptables 過濾。

哎呀，看起來很復雜！

不過不需要擔心。

這就是為什么我們使用 Kubernetes，上面的所有內容都是通過使用服務來抽象的，一個簡單的 YAML 定義就可以自動完成這些規則的設置。

如果對這些 iptables 規則感興趣，可以登陸到節點并運行：

iptables-save

也可以使用可視化工具^[22]瀏覽節點上的 iptables 鏈。

記住，可能會有數百條規則。想象下手動創建的難度。

我們已經解釋了相同和不同節點上的 pod 間如何通信。

在 Pod-to-Service 中，通信的前半部分保持不變。

當 Pod-A 發出請求時，希望到達 Pod-B（這種情況下，Pod-B 位與服務之后），轉移的過程中會發生其他變化。

原始請求從 Pod-A 命名空間中的?eth0?接口出來。

從那里穿過?veth?對，到達根命名空間的以太網橋。

一旦到達橋接器，數據包立即通過默認網關轉發。

與 Pod-to-Pod 部分一樣，主機進行位比較，由于服務的 vIP 不是節點 CIDR 的一部分，數據包將立即通過默認網關轉發出去。

如果查找表中尚沒有默認網關的 MAC 地址，則會進行相同的 ARP 解析。

現在魔法發生了。

在數據包經過節點的路由處理之前，Netfilter 鉤子?NF_IP_PRE_ROUTING?被觸發并應用一條 iptables 規則。規則進行了 DNAT 轉換，重寫了 POD-A 數據包的目標 IP 地址。

原來服務 vIP 地址被重寫稱 POD-B 的IP 地址。

從那里，路由就像 Pod-to-Pod 直接通信一樣。

然而，在所有這些通信之間，使用了第三個功能。

這個功能被稱為 conntrack^[23]，或連接跟蹤。

Conntrack 將數據包與連接關聯起來，并在 Pod-B 發送回響應時跟蹤其來源。

NAT 嚴重依賴 contrack 工作。

如果沒有連接跟蹤，它將不知道將包含響應的數據包發送回哪里。

使用 conntrack 時，數據包的返回路徑可以輕松設置相同的源或目標 NAT 更改。

另一半使用相反的順序執行。

Pod-B 接收并處理了請求，現在將數據發送回 Pod-A。

此時會發生什么？

檢查服務的響應

現在 Pod-B 發送響應，將其 IP 地址設置為源地址，Pod-A IP 地址設置為目標地址。

當數據包到達 Pod-A 所在節點的接口時，就會發生另一個 NAT

這次，使用 conntrack 更改源 IP 地址，iptables 規則執行 SNAT 將 Pod-B IP 地址替換為原始服務的 VIP 地址。

從 Pod-A 來看像是服務發回的響應，而不是 Pod-B。

其他部分都一樣；一旦 SNAT 完成，數據包到達根命名空間中的以太網橋接器，并通過 veth 對轉發到 Pod-A。

回顧

讓我們來總結下你在本文中學到的東西：

容器如何在本地或 pod 內通信。
當 pod 位于相同和不同的節點上時，Pod-to- Pod 如何通信。
Pod-to-Service - 當 pod 向 Kubernetes 服務背后的 pod 發送流量時。
Kubernetes 網絡工具箱中有效通信所需的命名空間、veth、iptables、鏈、Netfilter、CNI、覆蓋網絡以及所有其他內容。

往期推薦

好難啊……一個 try-catch 問出這么多花樣

k8s集群居然可以圖形化安裝了？

惡意流量威脅新趨勢，揭秘網絡黑產3大核心本質

將 k8s 制作成 3D 射擊游戲，好玩到停不下來

點分享

點收藏

點點贊

點在看

總結

以上是生活随笔為你收集整理的追踪 Kubernetes 中的网络流量的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：产品经理教你玩转阿里云负载均衡SLB系列
下一篇： IoT日志利器：嵌入式日志客户端（C P