Windows 上的網路
Kubernetes 支援在 Linux 或 Windows 上執行節點。你可以在單個叢集中混合使用這兩種節點。本頁面概述了 Windows 作業系統特有的網路功能。
Windows 上的容器網路
Windows 容器的網路透過CNI 外掛暴露。Windows 容器在網路方面與虛擬機器功能相似。每個容器都有一個虛擬網路介面卡 (vNIC)，連線到 Hyper-V 虛擬交換機 (vSwitch)。主機網路服務 (HNS) 和主機計算服務 (HCS) 協同工作以建立容器並將容器 vNIC 附加到網路。HCS 負責容器管理，而 HNS 負責網路資源管理，例如：
- 虛擬網路（包括 vSwitch 的建立）
- 端點/vNIC
- 名稱空間
- 策略，包括資料包封裝、負載均衡規則、ACL 和 NAT 規則。
Windows HNS 和 vSwitch 實現了名稱空間，並可以根據需要為 Pod 或容器建立虛擬 NIC。但是，許多配置，如 DNS、路由和指標，儲存在 Windows 登錄檔資料庫中，而不是像 Linux 那樣儲存在 /etc 中的檔案中。容器的 Windows 登錄檔與主機的登錄檔是分開的，因此像將主機上的 /etc/resolv.conf 對映到容器中這樣的概念，不會產生與在 Linux 上相同的效果。這些必須使用在容器上下文中執行的 Windows API 進行配置。因此，CNI 實現需要呼叫 HNS，而不是依賴檔案對映將網路詳細資訊傳遞到 Pod 或容器中。
網路模式
Windows 支援五種不同的網路驅動程式/模式：L2bridge、L2tunnel、Overlay (Beta)、Transparent 和 NAT。在一個同時包含 Windows 和 Linux 工作節點的異構叢集中，你需要選擇一個在 Windows 和 Linux 上都相容的網路解決方案。下表列出了 Windows 上支援的樹外外掛，並就何時使用每個 CNI 提供了建議。
| 網路驅動程式 | 描述 | 容器資料包修改 | 網路外掛 | 網路外掛特性 |
|---|---|---|---|---|
| L2bridge | 容器連線到外部 vSwitch。容器連線到底層網路，儘管物理網路不需要學習容器 MAC，因為它們在入口/出口時會被重寫。 | MAC 被重寫為主機 MAC，IP 可能會使用 HNS OutboundNAT 策略重寫為主機 IP。 | win-bridge，Azure-CNI，Flannel host-gateway 使用 win-bridge | win-bridge 使用 L2bridge 網路模式，將容器連線到主機的底層網路，提供最佳效能。需要使用者定義的路由 (UDR) 來實現節點間連線。 |
| L2Tunnel | 這是 L2bridge 的一個特殊情況，但僅在 Azure 上使用。所有資料包都發送到應用 SDN 策略的虛擬化主機。 | MAC 重寫，IP 在底層網路上可見 | Azure-CNI | Azure-CNI 允許容器與 Azure vNET 整合，並允許它們利用 Azure 虛擬網路提供的一系列功能。例如，安全連線到 Azure 服務或使用 Azure NSG。請參閱 azure-cni 獲取一些示例 |
| Overlay | 容器被賦予一個連線到外部 vSwitch 的 vNIC。每個 Overlay 網路都有自己的 IP 子網，由自定義 IP 字首定義。Overlay 網路驅動程式使用 VXLAN 封裝。 | 用外部頭部封裝。 | win-overlay，Flannel VXLAN (使用 win-overlay) | 當希望虛擬容器網路與主機底層隔離時（例如出於安全原因），應使用 win-overlay。如果資料中心 IP 受限，它允許對不同的 Overlay 網路（具有不同的 VNID 標籤）重用 IP。此選項需要 Windows Server 2019 上的 KB4489899。 |
| Transparent（ovn-kubernetes 的特殊用例） | 需要外部 vSwitch。容器連線到外部 vSwitch，透過邏輯網路（邏輯交換機和路由器）實現 Pod 內部通訊。 | 資料包透過 GENEVE 或 STT 隧道封裝，以到達不在同一主機上的 Pod。 資料包透過 ovn 網路控制器提供的隧道元資料資訊進行轉發或丟棄。 進行南北向通訊的 NAT。 | ovn-kubernetes | 透過 Ansible 部署。可以透過 Kubernetes 策略應用分散式 ACL。支援 IPAM。無需 kube-proxy 即可實現負載均衡。無需使用 iptables/netsh 即可進行 NAT。 |
| NAT (Kubernetes 中不使用) | 容器被賦予一個連線到內部 vSwitch 的 vNIC。DNS/DHCP 透過名為 WinNAT 的內部元件提供。 | MAC 和 IP 被重寫為主機 MAC/IP。 | nat | 此處列出僅為完整性 |
如上所述，Flannel CNI 外掛也透過 VXLAN 網路後端（Beta 支援；委託給 win-overlay）和 host-gateway 網路後端（穩定支援；委託給 win-bridge）在 Windows 上受支援。
該外掛支援委託給其中一個參考 CNI 外掛（win-overlay、win-bridge），與 Windows 上的 Flannel 守護程式 (Flanneld) 協同工作，用於自動節點子網租約分配和 HNS 網路建立。該外掛讀取其自己的配置檔案 (cni.conf)，並將其與 FlannelD 生成的 subnet.env 檔案中的環境變數聚合。然後，它委託給其中一個參考 CNI 外掛進行網路佈線，並將包含節點分配子網的正確配置傳送給 IPAM 外掛（例如：host-local）。
對於 Node、Pod 和 Service 物件，以下網路流支援 TCP/UDP 流量
- Pod → Pod (IP)
- Pod → Pod (名稱)
- Pod → Service (叢集 IP)
- Pod → Service (PQDN，但僅當不包含 “.” 時)
- Pod → Service (FQDN)
- Pod → 外部 (IP)
- Pod → 外部 (DNS)
- 節點 → Pod
- Pod → 節點
IP 地址管理 (IPAM)
Windows 支援以下 IPAM 選項
- host-local
- azure-vnet-ipam (僅適用於 azure-cni)
- Windows Server IPAM (如果未設定 IPAM，則為備用選項)
直接伺服器返回 (DSR)
Kubernetes v1.34 [穩定] (預設啟用：true)負載均衡模式，其中 IP 地址修復和 LBNAT 直接發生在容器 vSwitch 埠上；服務流量以源 IP 設定為原始 Pod IP 的方式到達。這透過允許透過負載均衡器路由的返回流量繞過負載均衡器並直接響應客戶端來提供效能最佳化；從而減少負載均衡器的負載並減少總體延遲。有關更多資訊，請閱讀直接伺服器返回 (DSR) 簡介。
負載均衡和服務
Kubernetes Service 是一種抽象，它定義了一組邏輯 Pod 和透過網路訪問它們的方式。在包含 Windows 節點的叢集中，你可以使用以下型別的 Service
NodePortClusterIPLoadBalancerExternalName
Windows 容器網路在某些重要方面與 Linux 網路不同。Microsoft 的 Windows 容器網路文件提供了更多詳細資訊和背景。
在 Windows 上，你可以使用以下設定來配置 Service 和負載均衡行為
| 特性 | 描述 | 支援的最低 Windows 作業系統版本 | 如何啟用 |
|---|---|---|---|
| 會話親和性 | 確保來自特定客戶端的連線每次都傳遞給同一個 Pod。 | Windows Server 2022 | 將 service.spec.sessionAffinity 設定為 "ClientIP" |
| 直接伺服器返回 (DSR) | 請參閱上面的 DSR 說明。 | Windows Server 2019 | 設定以下命令列引數（假設版本為 1.34）：--enable-dsr=true |
| 保留目的地址 | 跳過服務流量的 DNAT，從而保留到達後端 Pod 的資料包中目標服務的虛擬 IP。同時停用節點間轉發。 | Windows Server 版本 1903 | 在服務註解中設定 "preserve-destination": "true" 並在 kube-proxy 中啟用 DSR。 |
| IPv4/IPv6 雙棧網路 | 叢集內部、出入叢集的 IPv4-to-IPv4 與 IPv6-to-IPv6 通訊並行進行 | Windows Server 2019 | 參閱 IPv4/IPv6 雙棧 |
| 客戶端 IP 保留 | 確保傳入入口流量的源 IP 被保留。同時停用節點間轉發。 | Windows Server 2019 | 將 service.spec.externalTrafficPolicy 設定為 "Local" 並在 kube-proxy 中啟用 DSR |
限制
Windows 節點不支援以下網路功能
- 主機網路模式
- 節點本身的本地 NodePort 訪問（適用於其他節點或外部客戶端）
- 單個 Service 的後端 Pod 數量（或唯一目標地址）超過 64 個
- 連線到 Overlay 網路的 Windows Pod 之間的 IPv6 通訊
- 非 DSR 模式下的本地流量策略
- 使用
win-overlay、win-bridge或 Azure-CNI 外掛透過 ICMP 協議進行出站通訊。具體來說，Windows 資料平面 (VFP) 不支援 ICMP 資料包轉換，這意味著：- 指向同一網路內目的地的 ICMP 資料包（例如 Pod 之間透過 ping 進行通訊）按預期工作；
- TCP/UDP 資料包按預期工作；
- 指向透過遠端網路（例如 Pod 到外部網際網路透過 ping 進行通訊）的 ICMP 資料包無法轉換，因此不會路由回其源；
- 由於 TCP/UDP 資料包仍然可以轉換，因此在除錯與外部世界的連線時，可以用
curl <destination>替代ping <destination>。
其他限制
- Windows 參考網路外掛 win-bridge 和 win-overlay 由於缺少
CHECK實現，未實現 CNI 規範 v0.4.0。 - Flannel VXLAN CNI 外掛在 Windows 上有以下限制
- 節點-Pod 連線僅適用於 Flannel v0.12.0（或更高版本）的本地 Pod。
- Flannel 僅限於使用 VNI 4096 和 UDP 埠 4789。有關這些引數的更多詳細資訊，請參閱官方的 Flannel VXLAN 後端文件。