kubernetes 是否在 pod 通過目標 pod 位於同一主機上的服務與 pod 通信時使用 conntrack 兩次？

Question

據我了解，當 POD 與服務對話時，IP 表已由 CNI 提供商更新（這可能特定於某些但並非所有 CNI 提供商）。 iptables 基本上提供了一個虛擬 IP，然后循環或分發（以某種方式）到后端臨時 pod。 這些 pod 可能位於集群中的同一台主機或另一台主機上。 此時（再次基於 CNI）conntrack 用於保持 src 和 dst 的正確性，因為它將 svc-ip 重新映射到 POD 的 dest-ip。 不過，我想知道的是，如果 dest pod 在同一主機上，我不確定它是如何在返回路徑上路由的。 我仍然懷疑通過服務，然后可能使用 conntrack 作為返回路徑。

kubernetes 是否在 pod 通過目標 pod 位於同一主機上的服務與 pod 通信時使用 conntrack 兩次？

Answer 1

在嘗試解釋該主題時，我將使用 Calico 作為示例。

只有從源 pod 到服務端點需要 Conntrack。 您必須跟蹤它以將流數據包的 rest 發送到同一目標端點。 返回路徑始終只有一個選項：從目標 pod 到源 pod，這意味着即使在此處使用 conntrack，它也不會更改任何內容，因為返回路徑由 NAT 表管理。

另外值得一提的是：

對於 iptables 和 IPVS 模式，kube-proxy 的響應時間開銷與建立連接相關，而不是您在這些連接上發送的數據包或請求的數量。 這是因為 Linux 使用連接跟蹤 (conntrack) 能夠非常有效地將數據包與現有連接進行匹配。 如果一個數據包在 conntrack 中匹配，那么它不需要通過 kube-proxy 的 iptables 或 IPVS 規則 go 來確定如何處理它。

您可以使用conntrack命令行界面進行訂單搜索、列出、檢查和維護 Linux kernel 的連接跟蹤子系統。

例如：

conntrack -L將以 /proc/net/ip_conntrack 格式顯示連接跟蹤表：

 # conntrack -L
 tcp      6 431982 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34846 dport=993 packets=169 bytes=14322 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34846 packets=113 bytes=34787 [ASSURED] mark=0 secmark=0 use=1
 tcp      6 431698 ESTABLISHED src=192.168.2.100 dst=123.59.27.117 sport=34849 dport=993 packets=244 bytes=18723 src=123.59.27.117 dst=192.168.2.100 sport=993 dport=34849 packets=203 bytes=144731 [ASSURED] mark=0 secmark=0 use=1
conntrack v0.9.7 (conntrack-tools): 2 flow entries have been shown.

一個實際的例子是當您更改 Calico 的策略以禁止以前允許的流時。 Calico 只需要檢查允許流中的第一個數據包的策略（在一對 IP 地址和端口之間），然后 conntrack 會自動允許同一流中的更多數據包，而 Calico 無需重新檢查每個數據包。 如果最近在先前允許的流上交換了數據包，並且該流的 conntrack state 尚未過期，則該 conntrack state 將允許相同 ZA12A3079E14CED46E69BA52BA 之間的進一步數據包在相同的 ZA12A3079E14CED46E69BA52BA 更改地址之后。 為避免這種情況，您可以使用conntrack -D手動刪除相關的 conntrack 狀態，然后使用conntrack -E以使用新的 Calico 策略觀察連接事件。

資料來源：

• Linux Conntrack

• 連接跟蹤

• Kube 代理模式

• 包流

我希望這有幫助。