本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Windows 網路與 Linux 在 Kubernetes 中達到同等水平

作者：Jason Messer (微軟) |

自四個月前我上次撰寫關於Kubernetes Windows 網路的部落格以來，Windows 核心網路團隊在平臺和開源 Kubernetes 專案方面都取得了巨大進展。透過這些更新，Windows 在網路方面已與 Linux 媲美。客戶現在可以在任何環境中（包括 Azure、本地和第三方雲堆疊）部署混合作業系統 Kubernetes 叢集，享受與 Linux 上相同的網路原語和拓撲，而無需任何變通方法、“技巧”或第三方交換機擴充套件。

你可能會問，“那又怎樣？”。這些平臺改進在希望執行 Kubernetes 的開發人員和運維團隊的生活中產生了實質性影響，原因涉及多個應用程式和基礎設施方面。繼續閱讀以瞭解更多資訊！

緊密耦合的通訊

這些改進實現了單個“Pod”內多個 Windows Server 容器（沒有 Hyper-V 隔離）之間的緊密耦合通訊。可以將 Pod 視為 Kubernetes 叢集的排程單元，在其中，一個或多個應用程式容器協同部署，並能夠共享儲存和網路資源。Pod 中的所有容器共享相同的 IP 地址和埠範圍，並能夠使用 localhost 相互通訊。這使得應用程式可以輕鬆利用“輔助”程式來完成監控、配置更新、日誌管理和代理等任務。另一種思考 Pod 的方式是將其視為一個計算主機，其中應用程式容器代表程序。

簡化的網路拓撲

我們還透過將每個容器（或更普遍地，每個 Pod）所需的端點數量減少到一個，簡化了 Kubernetes 叢集中 Windows 節點的網路拓撲。以前，在 Kubernetes 叢集中執行的 Windows 容器（Pod）需要兩個端點——一個用於外部（網際網路）通訊，另一個用於叢集內其他節點或 Pod 之間的通訊。這是因為從連線到具有本地範圍（即不可公開路由）的主機網路的容器進行外部通訊需要 NAT 操作，而這隻能透過主機上的 Windows NAT (WinNAT) 元件提供。叢集內通訊則要求容器透過第二個端點連線到具有“全域性”（叢集級別）範圍的獨立網路。最近的平臺改進現在可以直接在容器端點上進行 NAT 操作，該端點透過 Microsoft 虛擬過濾平臺 (VFP) Hyper-V 交換機擴充套件實現。現在，外部和叢集內流量都可以透過單個端點進行傳輸。

使用 Windows 核心中的 VFP 進行負載均衡

Kubernetes 工作節點依賴 kube-proxy 在叢集內的 Pod 之間對傳入的服務 IP 網路流量進行負載均衡。早期版本的 Windows 透過使用者空間代理實現了 Kube-proxy 的負載均衡。我們最近增加了對“代理模式：iptables”的支援，該模式使用 Windows 核心中的 VFP 實現，因此 Windows 作業系統核心可以更有效地對任何 IP 流量進行負載均衡。使用者還可以透過在服務定義中指定 externalIP 引數來配置外部負載均衡器。除了上述改進之外，我們還增加了對以下功能平臺支援：

  • 支援每個容器/Pod 的 DNS 搜尋字尾（Docker 改進 - 消除了 kube-proxy 以前為新增 DNS 字尾所做的額外工作） 
  • [平臺支援] 用於建立 ACL 的 5 元組規則（尋求社群幫助以將其與 K8s 網路策略支援整合）

現在 Windows Server 已加入 Windows Insider Program，客戶和合作夥伴可以立即利用這些新的平臺功能，這些功能將為今年晚些時候備受期待的新功能釋出和六個月後的新版本帶來價值。最新的 Windows Server Insider 版本現在包含了對所有這些平臺改進的支援。

除了 Windows 的平臺改進之外，該團隊還為 CNI、kubelet 和 kube-proxy 提交了程式碼（PRs），目標是將 Windows 支援納入 Kubernetes v1.8 版本。這些 PRs 消除了 Windows 上以前所需的變通方法，例如用於內部負載均衡的使用者模式代理、為每個 Kube-DNS 請求附加額外的 DNS 字尾，以及用於外部（網際網路）連線的單獨容器端點。

這些新的平臺功能以及對 kubelet 和 kube-proxy 的工作與 Linux 上 Kubernetes 使用的 CNI 網路模型保持一致，並簡化了 K8s 叢集的部署，無需額外的配置或自定義（Azure）資源模板。為此，我們完成了 CNI 網路和 IPAM 外掛的工作，以建立/刪除端點和管理 IP 地址。CNI 外掛透過 kubelet 呼叫 Windows 主機網路服務 (HNS) API 來建立“l2bridge”網路（類似於 Linux 上的 macvlan），該網路由 VFP 交換機擴充套件強制執行。

“l2bridge”網路驅動程式在入口和出口處重寫容器網路流量的 MAC 地址，以使用容器主機的 MAC 地址。這消除了上游網路交換機埠（容器主機連線到該埠）需要“學習”多個 MAC 地址（每個執行在主機上的容器一個）的需求。這節省了物理交換機 TCAM 表中的記憶體空間，並依賴 Hyper-V 虛擬交換機在主機中進行 MAC 地址轉換，以將流量轉發到正確的容器。IP 地址由預設的 Windows IPAM 外掛管理，該外掛要求 POD CIDR IP 取自容器主機的網路 IP 空間。

該團隊在 8 月 8 日向 SIG-Windows 小組演示了（影片連結）這些新的平臺功能和開源更新。我們正在與社群合作，合併 kubelet 和 kube-proxy PRs，以便及時將這些更改納入將於今年 9 月釋出的 Kubernetes v1.8 版本。這些功能隨後可以在當前的 Windows Server Insider 版本和Windows Server 1709 版上使用。

RTM 後不久，我們還將這些改進引入 Azure 容器服務 (ACS)，以便 Windows 工作節點和託管的容器成為 Azure VNet 的一等公民。適用於 Windows CNI 的 Azure IPAM 外掛將使這些端點能夠直接連線到 Azure VNet，其 Windows 容器的網路策略將以與 VM 相同的方式強制執行。

| 功能 | Windows Server 2016 (已上市) | 下一個 Windows Server 功能釋出，半年頻道 | Linux | | 每個 Pod 多個容器，共享網路名稱空間 (Compartment) | 每個 Pod 一個容器 | ✔ | ✔ | | 每個 Pod 單個（共享）端點 | 兩個端點：WinNAT（外部）+ 透明（叢集內） | ✔ | ✔ | | 使用者模式負載均衡 | ✔ | ✔ | ✔ | | 核心模式負載均衡 | 不支援 | ✔ | ✔ | | 支援每個 Pod 的 DNS 搜尋字尾（Docker 更新） | Kube-Proxy 為每個請求添加了多個 DNS 字尾 | ✔ | ✔ | | CNI 外掛支援 | 不支援 | ✔ | ✔ |

Kubernetes SIG Windows 小組每兩週開會一次，時間為週二上午 12:30 ET。要加入或檢視以前會議的記錄，請查閱此文件。