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

Windows 網路功能與 Linux 達到同等水平，適用於 Kubernetes

作者：Jason Messer (Microsoft) | 2017 年 9 月 8 日星期五

自從我四個月前發表了關於 Windows 版 Kubernetes 網路功能的部落格文章以來，Windows 核心網路團隊在平台和開放原始碼 Kubernetes 專案上都取得了巨大的進展。透過這些更新，Windows 在網路功能方面現在與 Linux 並駕齊驅。客戶現在可以在任何環境中部署混合作業系統的 Kubernetes 叢集，包括 Azure、內部部署和協力廠商雲端堆疊，並使用與 Linux 上相同的網路基本元素和拓撲，而無需任何變通方案、「駭客」或協力廠商交換器擴充功能。

「所以呢？」您可能會問。這些平台改進之所以對想要運行 Kubernetes 的開發人員和營運團隊的生活產生重大影響，有多個與應用程式和基礎架構相關的原因。請繼續閱讀以了解更多資訊！

緊密耦合的通訊

這些改進功能可在單一「Pod」內的多個 Windows Server 容器（不含 Hyper-V 隔離）之間實現緊密耦合的通訊。將 Pod 視為 Kubernetes 叢集的排程單位，在其中，一個或多個應用程式容器共置，並且能夠共享儲存和網路資源。Pod 內的所有容器共享相同的 IP 位址和連接埠範圍，並且能夠使用 localhost 相互通訊。這使應用程式能夠輕鬆利用「輔助」程式來執行監控、組態更新、記錄管理和 Proxy 等任務。思考 Pod 的另一種方式是將其視為運算主機，而應用程式容器則代表程序。

簡化的網路拓撲

我們也簡化了 Kubernetes 叢集中 Windows 節點上的網路拓撲，方法是將每個容器（或更廣泛地說，每個 Pod）所需的端點數量減少到一個。先前，在 Kubernetes 叢集中運行的 Windows 容器 (Pod) 需要兩個端點 - 一個用於外部（網際網路）通訊，另一個用於叢集中其他節點或 Pod 之間的叢集內通訊。這是因為從連接到具有本機範圍（即不可公開路由）的主機網路的容器進行外部通訊需要 NAT 作業，而 NAT 作業只能透過主機上的 Windows NAT (WinNAT) 组件提供。叢集內通訊需要容器透過第二個端點連接到具有「全域」（叢集層級）範圍的獨立網路。最近的平台改進現在使 NAT 能夠直接在容器端點上發生，這是透過 Microsoft 虛擬篩選平台 (VFP) Hyper-V 交換器擴充功能實現的。現在，外部和叢集內流量都可以透過單一端點流動。

在 Windows 核心中使用 VFP 進行負載平衡

Kubernetes 工作節點依賴 kube-proxy 在叢集中 Pod 之間對 Service IP 的傳入網路流量進行負載平衡。先前版本的 Windows 透過使用者空間 Proxy 實作 Kube-proxy 的負載平衡。我們最近新增了對「Proxy 模式：iptables」的支援，該模式是使用 Windows 核心中的 VFP 實作的，以便 Windows 作業系統核心可以更有效率地對任何 IP 流量進行負載平衡。使用者也可以透過在服務定義中指定 externalIP 參數來組態外部負載平衡器。除了上述改進之外，我們還新增了對以下功能的平台支援

支援每個容器/Pod 的 DNS 搜尋後綴 (Docker 改進 - 移除先前由 kube-proxy 完成的附加 DNS 後綴的額外工作)
[平台支援] 用於建立 ACL 的 5 元組規則 (正在尋求社群的協助，以將其與對 K8s 網路政策的支援整合)

現在 Windows Server 已加入 Windows 測試人員計畫，客戶和合作夥伴可以立即利用這些新的平台功能，這些功能將為今年稍後備受期待的新功能發布和六個月後的新組建累積價值。最新的 Windows Server 測試人員組建現在包含對所有這些平台改進的支援。

除了 Windows 的平台改進之外，團隊還為 CNI、kubelet 和 kube-proxy 提交了程式碼 (PR)，目標是將 Windows 支援主線化到 Kubernetes v1.8 版本中。這些 PR 移除了先前在 Windows 上針對諸如內部負載平衡的使用者模式 Proxy、將額外的 DNS 後綴附加到每個 Kube-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 PR，以便在今年 9 月發布的 Kubernetes v1.8 版本及時主線化這些變更。然後可以在目前的 Windows Server 測試人員組建和 Windows Server 1709 版上使用這些功能。

在 RTM 之後不久，我們也將把這些改進功能引入 Azure 容器服務 (ACS)，以便 Windows 工作節點和託管的容器成為一流的 Azure VNet 成員。適用於 Windows CNI 的 Azure IPAM 外掛程式將使這些端點能夠直接連接到 Azure VNet，並且針對 Windows 容器的網路政策的強制方式與 VM 相同。

| 功能 | Windows Server 2016 (上市版本) | 下一個 Windows Server 功能發行版本，半年通道 | Linux | | 每個 Pod 的多個容器，具有共用網路命名空間 (區隔) | 每個 Pod 一個容器 | ✔ | ✔ | | 每個 Pod 的單一 (共用) 端點 | 兩個端點：WinNAT (外部) + 透明 (叢集內) | ✔ | ✔ | | 使用者模式、負載平衡 | ✔ | ✔ | ✔ | | 核心模式、負載平衡 | 不支援 | ✔ | ✔ | | 每個 Pod 的 DNS 搜尋後綴支援 (Docker 更新) | Kube-Proxy 為每個請求新增多個 DNS 後綴 | ✔ | ✔ | | CNI 外掛程式支援 | 不支援 | ✔ | ✔ |

Kubernetes SIG Windows 小組每週二美國東部時間下午 12:30 舉行雙週會議。若要加入或檢視先前會議的記錄，請查看此文件。