| 网络驱动 | -描述 | -容器报文更改 | -网络插件 | -网络插件特点 | -
|---|---|---|---|---|
| L2bridge | -- 容器挂接到外部 vSwitch 上。容器挂接到下层网络之上，但由于容器的 MAC - 地址在入站和出站时被重写，物理网络不需要这些地址。 - | -- - MAC 地址被重写为宿主系统的 MAC 地址，IP 地址也可能依据 HNS OutboundNAT - 策略重写为宿主的 IP 地址。 - | -- win-bridge、 - Azure-CNI、 - - Flannel 宿主网关（host-gateway）使用 win-bridge - | -- - win-bridge 使用二层桥接（L2bridge）网络模式，将容器连接到下层宿主系统上， - 从而提供最佳性能。需要用户定义的路由（User-Defined Routes，UDR）才能 - 实现节点间的连接。 - | -
| L2Tunnel | -- - 这是二层桥接的一种特殊情形，但仅被用于 Azure 上。 - 所有报文都被发送到虚拟化环境中的宿主机上并根据 SDN 策略进行处理。 - | -- - MAC 地址被改写，IP 地址在下层网络上可见。 - | -- Azure-CNI - | -- - Azure-CNI 使得容器能够与 Azure vNET 集成，并允许容器利用 - [Azure 虚拟网络](https://azure.microsoft.com/en-us/services/virtual-network/) - 所提供的功能特性集合。例如，可以安全地连接到 Azure 服务上或者使用 Azure NSG。 - 你可以参考 - [azure-cni](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) - 所提供的一些示例。 - | -
| 覆盖网络（Kubernetes 中为 Windows 提供的覆盖网络支持处于 *alpha* 阶段） | -- - 每个容器会获得一个连接到外部 vSwitch 的虚拟网卡（vNIC）。 - 每个覆盖网络都有自己的、通过定制 IP 前缀来定义的 IP 子网。 - 覆盖网络驱动使用 VxLAN 封装。 - | -- - 封装于外层包头内。 - | -- Win-overlay、 - Flannel VXLAN（使用 win-overlay） - | -- - 当（比如出于安全原因）期望虚拟容器网络与下层宿主网络隔离时， - 应该使用 win-overlay。如果你的数据中心可用 IP 地址受限， - 覆盖网络允许你在不同的网络中复用 IP 地址（每个覆盖网络有不同的 VNID 标签）。 - 这一选项要求在 Windows Server 2009 上安装 - [KB4489899](https://support.microsoft.com/help/4489899) 补丁。 - | -
| - - 透明网络（[ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) 的特殊用例） - | -- - 需要一个外部 vSwitch。容器挂接到某外部 vSwitch 上，该 vSwitch - 通过逻辑网络（逻辑交换机和路由器）允许 Pod 间通信。 - | -
-
- 报文或者通过 [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) 来封装，
- 或者通过 [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) 隧道来封装，
- 以便能够到达不在同一宿主系统上的每个 Pod。 - 报文通过 OVN 网络控制器所提供的隧道元数据信息来判定是转发还是丢弃。 - 北-南向通信通过 NAT 网络地址转译来实现。 - |
- - ovn-kubernetes - | -- - [通过 Ansible 来部署](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)。 - 所发布的 ACL 可以通过 Kubernetes 策略来应用实施。支持 IPAM 。 - 负载均衡能力不依赖 kube-proxy。 - 网络地址转译（NAT）也不需要 iptables 或 netsh。 - | -
| NAT（未在 Kubernetes 中使用） | -- - 容器获得一个连接到某内部 vSwitch 的 vNIC 接口。 - DNS/DHCP 服务通过名为 - [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) - 的内部组件来提供。 - | -- - MAC 地址和 IP 地址都被重写为宿主系统的 MAC 地址和 IP 地址。 - | -- nat - | -- - 列在此表中仅出于完整性考虑 - | -
| 功能特性 | -描述 | -所支持的 Kubernetes 版本 | -所支持的 Windows OS 版本 | -如何启用 | -
|---|---|---|---|---|
| 会话亲和性 | -- - 确保来自特定客户的连接每次都被交给同一 Pod。 - | -v1.20+ | -- - [Windows Server vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) - 或更高版本 - | -
-
- 将 service.spec.sessionAffinitys 设置为 "ClientIP"
- |
-
| 直接服务器返回（DSR） | -- - 这是一种负载均衡模式，IP 地址的修正和负载均衡地址转译（LBNAT） - 直接在容器的 vSwitch 端口上处理；服务流量到达时，其源端 IP 地址 - 设置为来源 Pod 的 IP。 - | -v1.20+ | -- Windows Server 2019 - | -- - 为 kube-proxy 设置标志：`--feature-gates="WinDSR=true" --enable-dsr=true` - | -
| 保留目标地址 | -- - 对服务流量略过 DNAT 步骤，这样就可以在到达后端 Pod 的报文中保留目标服务的 - 虚拟 IP 地址。还要禁止节点之间的转发。 - | -v1.20+ | -Windows Server 1903 或更高版本 | -- - 在服务注解中设置 `"preserve-destination": "true"` 并启用 - kube-proxy 中的 DSR 标志。 - | -
| IPv4/IPv6 双栈网络 | -- - 在集群内外同时支持原生的 IPv4-到-IPv4 和 IPv6-到-IPv6 通信。 - | -v1.19+ | -Windows Server 2004 或更高版本 | -- - 参见 [IPv4/IPv6 双栈网络](#ipv4ipv6-dual-stack) - | -
| 保留客户端 IP | -- - 确保入站流量的源 IP 地址被保留。同样要禁止节点之间的转发。 - | -v1.20+ | -Windows Server 2019 或更高版本 | -
-
- 将 service.spec.externalTrafficPolicy 设置为 "Local"，
- 并在 kube-proxy 上启用 DSR。
- |
-
IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; "
- nodeSelector:
- kubernetes.io/os: windows
-```
-
-
-{{< note >}}
-端口映射也是支持的，但为简单起见，在此示例中容器端口 80 直接暴露给服务。
-{{< /note >}}
-
-
-1. 检查所有节点是否健康：
-
- ```bash
- kubectl get nodes
- ```
-
-1. 部署服务并观察 pod 更新：
-
- ```bash
- kubectl apply -f win-webserver.yaml
- kubectl get pods -o wide -w
- ```
-
- 正确部署服务后，两个 Pod 都标记为 “Ready”。要退出 watch 命令，请按 Ctrl + C。
-
-1. 检查部署是否成功。验证：
-
- * Windows 节点上每个 Pod 有两个容器，使用 `docker ps`
- * Linux 控制平面节点列出两个 Pod，使用 `kubectl get pods`
- * 跨网络的节点到 Pod 通信，从 Linux 控制平面节点 `curl` 你的 pod IPs 的端口 80，以检查 Web 服务器响应
- * Pod 到 Pod 的通信，使用 docker exec 或 kubectl exec 在 Pod 之间
- （以及跨主机，如果你有多个 Windows 节点）进行 ping 操作
- * 服务到 Pod 的通信，从 Linux 控制平面节点和各个 Pod 中 `curl` 虚拟服务 IP
- （在 `kubectl get services` 下可见）
- * 服务发现，使用 Kubernetes `curl` 服务名称
- [默认 DNS 后缀](/zh/docs/concepts/services-networking/dns-pod-service/#services)
- * 入站连接，从 Linux 控制平面节点或集群外部的计算机 `curl` NodePort
- * 出站连接，使用 kubectl exec 从 Pod 内部 curl 外部 IP
-
-
-{{< note >}}
-由于当前平台对 Windows 网络堆栈的限制，Windows 容器主机无法访问在其上调度的服务的 IP。只有 Windows pods 才能访问服务 IP。
-{{< /note >}}
-
-
-## 可观测性 {#observability}
-
-### 抓取来自工作负载的日志 {#capturing-logs-from-workloads}
-
-
-日志是可观测性的重要一环；使用日志用户可以获得对负载运行状况的洞察，
-因而日志是故障排查的一个重要手法。
-因为 Windows 容器中的 Windows 容器和负载与 Linux 容器的行为不同，
-用户很难收集日志，因此运行状态的可见性很受限。
-例如，Windows 工作负载通常被配置为将日志输出到 Windows 事件跟踪
-（Event Tracing for Windows，ETW），或者将日志条目推送到应用的事件日志中。
-[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)
-是 Microsoft 提供的一个开源工具，是监视 Windows 容器中所配置的日志源
-的推荐方式。
-LogMonitor 支持监视时间日志、ETW 提供者模块以及自定义的应用日志，
-并使用管道的方式将其输出到标准输出（stdout），以便 `kubectl logs