kubernetes pod 如何獲取 IP 而不是容器而不是它，因為 CNI 插件在容器級別工作

Question

當 CNI 插件在容器級別工作時，kubernetes pod 如何獲取 IP 而不是容器而不是它？

同一個 pod 的所有容器如何共享同一個網絡堆棧？

Answer 1

容器使用內核中稱為虛擬網絡接口的功能，創建虛擬網絡接口（讓其命名為veth0 ）然后分配給命名空間，當創建容器時，也分配給命名空間，當創建多個容器時在同一個命名空間中，只會創建一個網絡接口 veth0。

POD 只是用於指定一組資源和功能的術語，其中之一是命名空間和在其中運行的容器。

當您說 POD 獲得 IP 時，實際上獲得 IP 的是 veth0 接口，容器應用程序看到 veth0 的方式與容器外的應用程序看到服務器上的單個物理網卡的方式相同。

CNI 只是關於如何在不更改平台的情況下使多個網絡插件工作的技術規范。 上面的過程應該對所有網絡插件都是一樣的。

這篇博文中有一個很好的解釋

Answer 2

它是使一切正常的 kubeproxy。 一個 Pod 有一個代理，它通過一個 IP 為其余容器轉換所有端口。 只有在特定情況下，才會說您希望在同一個 Pod 中擁有多個容器。 它不是首選，但它可能。 這就是為什么他們稱之為“緊密”耦合。 請參考： https : //kubernetes.io/docs/concepts/cluster-administration/proxies/

Answer 3

首先，讓我們深入研究 CNI 方面。 在生產系統中，工作負載/pod（工作負載可以被認為是一個或多個用於實現特定功能的容器化應用程序）網絡隔離是一級安全要求。 此外，根據基礎設施的設置方式，路由平面可能還需要是工作負載（kubectl 代理）、主機級代理（kube 代理）或中央路由平面（apiserver 代理）的屬性主機級代理為其公開網關。

對於服務發現和實際從工作負載/pod 發送請求，您不希望個別應用程序開發人員與 apiserver 代理交談，因為這可能會產生開銷。 相反，您希望它們通過 kubectl 或 kube 代理與其他應用程序通信，這些層負責知道何時以及如何與 apiserver 平面通信。

因此，當啟動一個新的工作負載時，kubelet 可以傳遞--network-plugin=cni和一個配置路徑，告訴 kubelet 如何為這個工作負載/pod 設置虛擬網絡接口。

例如，如果您不希望 pod 中的應用程序容器能夠直接與主機級 kube 代理通信，因為您想要進行一些特定於基礎設施的監控，您的 CNI 和工作負載配置將是：

• 最外層容器監控
• 最外層容器為 pod 中的每個其他容器創建虛擬網絡接口
• 最外面的容器位於橋接接口（也是一個私有虛擬網絡接口）上，可以與主機上的 kube 代理通信

Pod 獲得的 IP 是允許其他工作負載通過其橋接接口向該 Pod 發送字節 - 因為從根本上說，其他人應該與 Pod 交談，而不是 Pod 內的單個工作單元。

Answer 4

有一個稱為“暫停容器”的特殊容器，用於保存 pod 的網絡命名空間。 它什么都不做，它的容器進程只是進入睡眠狀態。

Kubernetes 為每個 Pod 創建一個暫停容器，以獲取相應 Pod 的 IP 地址並為屬於特定 Pod 的所有其他容器設置網絡命名空間。 Pod 中的所有容器都可以使用 localhost 相互訪問。

這意味着您的“應用程序”容器可能會死掉，然后恢復生機，並且所有網絡設置仍將完好無損。