Kubernetes中的Windows网络-Kubernetes中文教程(二)

当前位置:　首页>> 技术小册>> Kubernetes中文教程(二)

Kubernetes 支持运行 Linux 或 Windows 节点。
你可以在统一集群内混布这两种节点。
本页提供了特定于 Windows 操作系统的网络概述。

## Windows 容器网络

Windows 容器网络通过 [CNI 插件]暴露。
Windows 容器网络的工作方式与虚拟机类似。
每个容器都有一个连接到 Hyper-V 虚拟交换机（vSwitch）的虚拟网络适配器（vNIC）。
主机网络服务（Host Networking Service，HNS）和主机计算服务（Host Comute Service，HCS）
协同创建容器并将容器 vNIC 挂接到网络。
HCS 负责管理容器，而 HNS 负责管理以下网络资源：

* 虚拟网络（包括创建 vSwitch）
* Endpoint / 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 、Transparent 和 NAT。
在 Windows 和 Linux 工作节点组成的异构集群中，你需要选择一个同时兼容 Windows 和 Linux 的网络方案。
下表列出了 Windows 支持的树外插件，并给出了何时使用每种 CNI 的建议：

| 网络驱动 | 描述 | 容器数据包修改 | 网络插件 | 网络插件特点 |
| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
| L2bridge       | 容器挂接到一个外部 vSwitch。容器挂接到下层网络，但物理网络不需要了解容器的 MAC，因为这些 MAC 在入站/出站时被重写。 | MAC 被重写为主机 MAC，可使用 HNS OutboundNAT 策略将 IP 重写为主机 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 | 容器被赋予一个 vNIC，连接到外部 vSwitch。每个上层网络都有自己的 IP 子网，由自定义 IP 前缀进行定义。该上层网络驱动使用 VXLAN 封装。 | 用外部头进行封装。 | [win-overlay]、Flannel VXLAN（使用 win-overlay） | 当需要将虚拟容器网络与主机的下层隔离时（例如出于安全原因），应使用 win-overlay。如果你的数据中心的 IP 个数有限，可以将 IP 在不同的上层网络中重用（带有不同的 VNID 标记）。在 Windows Server 2019 上这个选项需要 [KB4489899]。 |
| Transparent（[ovn-kubernetes] 的特殊用例） | 需要一个外部 vSwitch。容器挂接到一个外部 vSwitch，由后者通过逻辑网络（逻辑交换机和路由器）实现 Pod 内通信。 | 数据包通过 [GENEVE] 或 [STT] 隧道进行封装，以到达其它主机上的 Pod。  <br/> 数据包基于 OVN 网络控制器提供的隧道元数据信息被转发或丢弃。<br/>南北向通信使用 NAT。 | [ovn-kubernetes] | [通过 ansible 部署]。通过 Kubernetes 策略可以实施分布式 ACL。支持 IPAM。无需 kube-proxy 即可实现负载均衡。无需 iptables/netsh 即可进行 NAT。 |
| NAT（**Kubernetes 中未使用**） | 容器被赋予一个 vNIC，连接到内部 vSwitch。DNS/DHCP 是使用一个名为 [WinNAT 的内部组件]实现的 | MAC 和 IP 重写为主机 MAC/IP。 | [nat] | 放在此处保持完整性。 |

如上所述，Windows 通过 [VXLAN 网络后端]（**Beta 支持**；委派给 win-overlay）
和 [host-gateway 网络后端]（稳定支持；委派给 win-bridge）
也[支持] [Flannel] 的 [CNI 插件]。

此插件支持委派给参考 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）
* Node → Pod
* Pod → Node

## IP 地址管理（IPAM）

Windows 支持以下 IPAM 选项：

* [host-local]
* [azure-vnet-ipam]（仅适用于 azure-cni）
* [Windows Server IPAM]（未设置 IPAM 时的回滚选项）

## 负载均衡和 Service

Kubernetes  是一种抽象：定义了逻辑上的一组 Pod 和一种通过网络访问这些 Pod 的方式。
在包含 Windows 节点的集群中，你可以使用以下类别的 Service：

* `NodePort`
* `ClusterIP`
* `LoadBalancer`
* `ExternalName`

Windows 容器网络与 Linux 网络有着很重要的差异。
更多细节和背景信息，参考 [Microsoft Windows 容器网络文档]。

在 Windows 上，你可以使用以下设置来配置 Service 和负载均衡行为：

| 功能特性 | 描述 | 支持的 Windows 操作系统最低版本 | 启用方式 |
| ------- | ----------- | -------------------------- | ------------- |
| 会话亲和性 | 确保每次都将来自特定客户端的连接传递到同一个 Pod。 | Windows Server 2022 | 将 `service.spec.sessionAffinity` 设为 “ClientIP” |
| Direct Server Return  | 在负载均衡模式中 IP 地址修正和 LBNAT 直接发生在容器 vSwitch 端口；服务流量到达时源 IP 设置为原始 Pod IP。 | Windows Server 2019 | 在 kube-proxy 中设置以下标志：`--feature-gates="WinDSR=true" --enable-dsr=true` |
| 保留目标（Preserve-Destination） | 跳过服务流量的 DNAT，从而在到达后端 Pod 的数据包中保留目标服务的虚拟 IP。也会禁用节点间的转发。 | Windows Server，version 1903 | 在服务注解中设置 `"preserve-destination": "true"` 并在 kube-proxy 中启用 DSR。 |
| IPv4/IPv6 双栈网络 | 进出集群和集群内通信都支持原生的 IPv4 间与 IPv6 间流量 | Windows Server 2019 | 参考 [IPv4/IPv6 双栈]。 |
| 客户端 IP 保留 | 确保入站流量的源 IP 得到保留。也会禁用节点间转发。 |  Windows Server 2019  | 将 `service.spec.externalTrafficPolicy` 设置为 “Local” 并在 kube-proxy 中启用 DSR。 |

如果目的地节点在运行 Windows Server 2022，则上层网络的 NodePort Service 存在已知问题。
要完全避免此问题，可以使用 `externalTrafficPolicy: Local` 配置服务。

在安装了 KB5005619 的 Windows Server 2022 或更高版本上，采用 L2bridge 网络时
Pod 间连接存在已知问题。
要解决此问题并恢复 Pod 间连接，你可以在 kube-proxy 中禁用 WinDSR 功能。

这些问题需要操作系统修复。
有关更新，请参考 https://github.com/microsoft/Windows-Containers/issues/204。

## 限制

Windows 节点**不支持**以下网络功能：

* 主机网络模式
* 从节点本身访问本地 NodePort（可以从其他节点或外部客户端进行访问）
* 为同一 Service 提供 64 个以上后端 Pod（或不同目的地址）
* 在连接到上层网络的 Windows Pod 之间使用 IPv6 通信
* 非 DSR 模式中的本地流量策略（Local Traffic Policy）

* 通过 `win-overlay`、`win-bridge` 使用 ICMP 协议，或使用 Azure-CNI 插件进行出站通信。  
  具体而言，Windows 数据平面（[VFP]）不支持 ICMP 数据包转换，这意味着：
  * 指向同一网络内目的地址的 ICMP 数据包（例如 Pod 间的 ping 通信）可正常工作；
  * TCP/UDP 数据包可正常工作；
  * 通过远程网络指向其它地址的 ICMP 数据包（例如通过 ping 从 Pod 到外部公网的通信）无法被转换，
    因此无法被路由回到这些数据包的源点；
  * 由于 TCP/UDP 数据包仍可被转换，所以在调试与外界的连接时，
    你可以将 `ping <destination>` 替换为 `curl <destination>`。

其他限制：

* 由于缺少 `CHECK` 实现，Windows 参考网络插件 win-bridge 和 win-overlay 未实现
[CNI 规约] 的 v0.4.0 版本。
* Flannel VXLAN CNI 插件在 Windows 上有以下限制：
  * 使用 Flannel v0.12.0（或更高版本）时，节点到 Pod 的连接仅适用于本地 Pod。
  * Flannel 仅限于使用 VNI 4096 和 UDP 端口 4789。
  有关这些参数的更多详细信息，请参考官方的 [Flannel VXLAN] 后端文档。

该分类下的相关小册推荐：

云原生-K8S入门实战

Kubernets合辑8-权限控制

Kubernets合辑7-存储

Kubernetes合辑1-安装Kubernetes

Kubernets合辑15-持续部署

Kubernets合辑9-资源约束

Kubernets合辑4-kubernetes入门

Kubernetes中文教程(一)

Kubernets合辑5-Pod控制器

Kubernetes中文教程(五)

Kubernets合辑3-kubernetes介绍

Kubernetes中文教程(六)