Kubernetes — 網絡流量模型

目錄

文章目錄

• Kubernetes Network 中的 IP 位址類型
• Kubernetes 的網絡流量模型
• • 同 Pod 内部的 Containers 間的通信（Container 模式）
  • 同 Node 内部的 Pods 間的通信（Host Virtual Network 模式）
  • 跨 Nodes 間的 Pods 間的通信（SDN 模式）
  • Service 的 Cluster IP 和外部網絡間的通信
  • • Service 之于叢集内部 Pods 之間的通信
    • Service 之于叢集外部與 Pod 的通信

Kubernetes Network 中的 IP 位址類型

Kubernetes 網絡中涉及以下幾種類型的 IP 位址：

1. Node IP：主控端 IP 位址。
2. Pod IP：Pod 是 Kubernetes 的最小部署單元，Pod 下可以包含若幹個 Containers，但是 Container 沒有獨立的 IP 位址，它們共享 Pod 的 IP 位址和 Ports 區間。
3. Cluster IP：這裡所述 Cluster 并非 Kubernetes Cluster，而是 Kubernetes Service 的 IP 位址。外部網絡是無法通路該位址的，隻有 Kubernetes Cluster 内部才能通路。因為 Cluster IP 是一個虛拟的 IP 位址，即：沒有網絡裝置為這個 IP 位址負責。在 Kubernetes 内部使用了 IPtables 規則來重定向到其本地端口，再均衡到後端的 Pods；
4. Public IP：因為 Cluster IP 能在 Kubernetes Cluster Internal 通路，屬于應用程式内部的層級。如果希望将這個 Service 為 Kubernetes Cluster External 的用戶端提供通路，就需要為這個 Service 提供一個 Public IP。

Pod 内部的 Containers 通過 localhost 進行通信，它們使用了同一個 Network Namespace。對 Container 而言，hostname 就是 Pod 的名稱。

Pod 内部的 Containers 共享同一個 IP 位址和端口區間，是以要為每個可以建立連接配接的 Container 配置設定不同的 Port 号。也就是說，Pod 中的 “應用” 需要自己協調端口号的配置設定和使用。

• 例如：建立一個 Pod ，包含兩個 Containers。

  

  

可以看到同一個 Pod 下屬的兩個 Containers 共享了 IP 位址。

可以看見，同一個 Pod 下屬的兩個 Containers 不能占有同一個 Port 号，因為 Port 區間也是共享的。

是以，我們可以将 Pod 了解為一個小型的 “作業系統沙盒”，兩個程序可以使用同一個作業系統 IP 位址，自然也就不可以使用同一個 Port 号了。

實作原理：同一個 Pod 内的 Containers 處于同一個 Network Namespace，是以使用了相同的 IP 位址和 Port 區間。該 Namespace 是由一個名為 Pause Container 實作的，每當一個 Pod 被建立，首先會建立一個 Pause Container。

後續所有新的普通 Containers 都通過過共享 Pause Container 的網絡棧，實作與外部 Pod 進行通信。是以，對于同 Pod 下屬的 Containers 而言，它們看到的網絡視圖是一樣的。上述我們在 Container 中看的 IP 位址，實際就是 Pause Container 的 IP 位址，通過控制 Pause Container 的網絡協定棧就可以影響所有同屬 Pod 下的 Container 的網絡協定棧了。

這種新建立的容器和已經存在的一個容器（Pause）共享一個 Network Namespace（而不是和主控端共享）的模式，就是常說的 Container 模式。

每個 Node 上的每個 Pod 都有自己專屬的 Network Namespace，由此實作 Container 模型網絡的隔離。而兩個 Pod 之間，即：兩個 Network Namespace 之間希望進行通信的話，就需要使用到 Linux 作業系統的網絡虛拟化技術 —— Veth Pair（虛拟網線）了。

但是，如果有多個 Pod 都需要兩兩建立 Veth Pair 的話，擴充性就會非常的差，假如：有 N 個 Pod，就需要建立 n(n-1)/2 個 Veth Pair。可見，除了 Veth Pair（虛拟網線）之外，我們還需要一個二層的 “集線” 裝置 —— Linux Bridge（虛拟交換機）。

舉個例子：建立位于同一個 Node 下屬的 Pod1 和 Pod2，IP 位址分别為：10.244.1.16、10.244.1.18。

檢視 Node 下的 Network Namespace：

分别查詢兩個 Network Namespace 下的 Network Interfaces：

可見，Pod1、Pod2 内部的 Veth Pair 的一端分别是

3: eth0@if7

、

3: eth0@if9

；另一端則位于 default Network Namespace，分别為

7: veth3b416eb2@if3

9: veth88cfc816@if3

。注意：interface ID 和 ifID 剛剛好是兩端對稱的，以此來進行辨識。當然了，Bridge 也同樣存在于 default Network Namespace。

這種借助于 Linux 作業系統原生的網絡虛拟化技術實作的兩個本地 Pods 之間的網絡通信方式，稱為 Host Virtual Network 模式。

總的來說，跨主機通信無非兩種方式：

• Overlay 隧道互通：Nodes 之間通過 Over the Physical 網絡互通，e.g. OvS、Flannel 和 Weave。
• Underlay 直接互通：Nodes 之間通過實體網絡互通，e.g. Calico 的 Direct 模式、macvlan。

從網絡角度對 Flannel 和 Calico 進行簡單對比。可見，對性能敏感、政策需求較高時偏向于 Calico 方案。否則，采用 Flannel 會是更好的選擇；

Pod 間可以直接通過 IP 位址通信，但前提是 Pod 知道對方的 IP。在 Kubernetes Cluster 中，Pod 可能會頻繁地銷毀和建立，也就是說 Pod 的 IP 不是固定的。為了解決這個問題，Kubernetes Service 作為通路 Pod 的上層抽象。無論後端的 Pod 如何變化，Service 都作為穩定的前端對外提供服務。同時，Service 還提供了高可用和負載均衡功能，負責将請求轉發給正确的 Pod。