对Windows的支持-Kubernetes-树叶云kubernetes教程 (对WINDOWS 7中文件文件夹操作包括)

Kubernetes对Windows的支持

在很多组织中，其服务和应用的很大比例是Windows应用。Windows容器提供了一种对进程和包依赖关系进行封装的现代方式，这使得用户更容易采用DevOps实践，令Windows应用同样遵从云原生模式。Kubernetes已经成为事实上的标准容器编排器，Kubernetes1.14发行版本中包含了将Windows容器调度到Kubernetes集群中Windows节点上的生产级支持，从而使得巨大的Windows应用生态圈能够充分利用Kubernetes的能力。对于同时投入基于Windows应用和Linux应用的组织而言，他们不必寻找不同的编排系统来管理其工作负载，其跨部署的运维效率得以大幅提升，而不必关心所用操作系统。

kubernetes中的Windows容器

若要在Kubernetes中启用对Windows容器的编排，可以在现有的Linux集群中包含Windows节点。在Kubernetes上调度Pods中的Windows容器与调用基于Linux的容器类似。

为了运行Windows容器，你的Kubernetes集群必须包含多个操作系统，控制面节点运行Linux，工作节点则可以根据负载需要运行Windows或Linux。WindowsServer2019是唯一被支持的Windows操作系统，在Windows上启用Kubernetes节点支持（包括kubelet,容器运行时、以及kube-proxy）。关于Windows发行版渠道的详细讨论，可参见 Microsoft文档。

支持的功能与局限性

支持的功能

Windows操作系统版本支持

参考下面的表格，了解Kubernetes中支持的Windows操作系统。同一个异构的Kubernetes集群中可以同时包含Windows和Linux工作节点。Windows容器仅能调度到Windows节点，Linux容器则只能调度到Linux节点。

Kubernetes 版本	Windows Server LTSC 版本	Windows Server SAC 版本
Kubernetes v1.20	Windows Server 2019	Windows Server ver 1909, Windows Server ver 2004
Kubernetes v1.21	Windows Server 2019	Windows Server ver 2004, Windows Server ver 20H2
Kubernetes v1.22	Windows Server 2019	Windows Server ver 2004, Windows Server ver 20H2

关于不同的WindowsServer版本的服务渠道，包括其支持模式等相关信息可以在WindowsServerservicingchannels找到。

我们并不指望所有Windows客户都为其应用频繁地更新操作系统。对应用的更新是向集群中引入新代码的根本原因。对于想要更新运行于Kubernetes之上的容器中操作系统的客户，我们会在添加对新操作系统版本的支持时提供指南和分步的操作指令。该指南会包含与集群节点一起来升级用户应用的建议升级步骤。Windows节点遵从Kubernetes版本偏差策略（节点到控制面的版本控制），与Linux节点的现行策略相同。

WindowsServer主机操作系统会受WindowsServer授权策略控制。Windows容器镜像则遵从Windows容器的补充授权条款约定。

带进程隔离的Windows容器受一些严格的兼容性规则约束，其中宿主OS版本必须与容器基准镜像的OS版本相同。一旦我们在Kubernetes中支持带Hyper-V隔离的Windows容器，这一约束和兼容性规则也会发生改变。

Pause镜像

Kubernetes维护着一个多体系结构镜像，其中包括对Windows的支持。对于Kubernetesv1.22，推荐的pause镜像是​ k8s.gcr.io/pause:3.5 ​。源代码可在GitHub上找到。

Microsoft维护了一个支持Linux和Windowsamd64的多体系结构镜像：​ mcr.microsoft.com/oss/kubernetes/pause:3.5 ​。此镜像与Kubernetes维护的镜像是从同一来源构建，但所有Windows二进制文件均由Microsoft签名。当生产环境需要被签名的二进制文件时，建议使用Microsoft维护的镜像。

计算

从API和kubectl的角度，Windows容器的表现在很大程度上与基于Linux的容器是相同的。不过也有一些与关键功能相关的差别值得注意，这些差别列举于局限性小节中。

关键性的Kubernetes元素在Windows下与其在Linux下工作方式相同。我们在本节中讨论一些关键性的负载支撑组件及其在Windows中的映射。

Kubernetes控制器处理Pod的期望状态。Windows容器支持以下负载控制器：

KubernetesService是一种抽象对象，用来定义Pod的一个逻辑集合及用来访问这些Pod的策略。Service有时也称作微服务（Micro-service）。你可以使用服务来实现跨操作系统的连接。在Windows系统中，服务可以使用下面的类型、属性和能力：

Pods、控制器和服务是在Kubernetes上管理Windows负载的关键元素。不过，在一个动态的云原生环境中，这些元素本身还不足以用来正确管理Windows负载的生命周期。我们为此添加了如下功能特性：

容器运行时

FEATURESTATE:Kubernetesv1.14[stable]

DockerEE-basic19.03+是建议所有WindowsServer版本采用的容器运行时。该容器运行时能够与kubelet中的dockershim代码协同工作。

CRI-ContainerD

FEATURESTATE:Kubernetesv1.20[stable]

ContainerD1.4.0+也可作为WindowsKubernetes节点上的容器运行时。

持久性存储

使用Kubernetes卷，对数据持久性和Pod卷共享有需求的复杂应用也可以部署到Kubernetes上。管理与特定存储后端或协议相关的持久卷时，相关的操作包括：对卷的配备（Provisioning）、去配（De-provisioning）和调整大小，将卷挂接到Kubernetes节点或从节点上解除挂接，将卷挂载到需要持久数据的Pod中的某容器或从容器上卸载。负责实现为特定存储后端或协议实现卷管理动作的代码以Kubernetes卷插件的形式发布。Windows支持以下大类的Kubernetes卷插件：

树内卷插件

与树内卷插件（In-TreeVolumePlugin）相关的代码都作为核心Kubernetes代码基的一部分发布。树内卷插件的部署不需要安装额外的脚本，也不需要额外部署独立的容器化插件组件。这些插件可以处理：对应存储后端上存储卷的配备、去配和尺寸更改，将卷挂接到Kubernetes或从其上解挂，以及将卷挂载到Pod中各个容器上或从其上卸载。以下树内插件支持Windows节点：

FlexVolume插件

与FlexVolume插件相关的代码是作为树外（Out-of-tree）脚本或可执行文件来发布的，因此需要在宿主系统上直接部署。FlexVolume插件处理将卷挂接到Kubernetes节点或从其上解挂、将卷挂载到Pod中各个容器上或从其上卸载等操作。对于与FlexVolume插件相关联的持久卷的配备和去配操作，可以通过外部的配置程序来处理。这类配置程序通常与FlexVolume插件相分离。下面的FlexVolume 插件可以以PowerShell脚本的形式部署到宿主系统上，支持Windows节点：

CSI插件

FEATURESTATE:Kubernetesv1.22[stable]

与CSI插件相关联的代码作为树外脚本和可执行文件来发布且通常发布为容器镜像形式，并使用DaemonSet和StatefulSet这类标准的Kubernetes构造体来部署。CSI插件处理Kubernetes中的很多卷管理操作：对卷的配备、去配和调整大小，将卷挂接到Kubernetes节点或从节点上解除挂接，将卷挂载到需要持久数据的Pod中的某容器或从容器上卸载，使用快照和克隆来备份或恢复持久数据。

来支持；csi-proxy是一个社区管理的、独立的可执行文件，需要预安装在每个Windows节点之上。请参考你要部署的CSI插件的部署指南以进一步了解其细节。

CSI插件与执行本地存储操作的CSI节点插件通信。在Windows节点上，CSI节点插件通常调用处理本地存储操作的csi-proxy公开的API,csi-proxy由社区管理。

有关安装的更多详细信息，请参阅你要部署的WindowsCSI插件的环境部署指南。你也可以参考以下安装步骤。

联网

Windows容器的联网是通过CNI插件来暴露出来的。Windows容器的联网行为与虚拟机的联网行为类似。每个容器有一块虚拟的网络适配器（vNIC）连接到Hyper-V的虚拟交换机（vSwitch）。宿主的联网服务（HostNetworkingService，HNS）和宿主计算服务（HostComputeService，HCS）协同工作，创建容器并将容器的虚拟网卡连接到网络上。HCS负责管理容器，HNS则负责管理网络资源，例如：

支持的服务规约类型如下：

网络模式

Windows支持五种不同的网络驱动/模式：二层桥接（L2bridge）、二层隧道（L2tunnel）、覆盖网络（Overlay）、透明网络（Transparent）和网络地址转译（NAT）。在一个包含Windows和Linux工作节点的异构集群中，你需要选择一种对Windows和Linux兼容的联网方案。下面是Windows上支持的一些树外插件及何时使用某种CNI插件的建议：

网络驱动	描述	容器报文更改	网络插件	网络插件特点
容器挂接到外部 vSwitch 上。容器挂接到下层网络之上，但由于容器的 MAC 地址在入站和出站时被重写，物理网络不需要这些地址。	MAC 地址被重写为宿主系统的 MAC 地址，IP 地址也可能依据 HNS OutboundNAT 策略重写为宿主的 IP 地址。	win-bridge、Azure-CNI、 Flannel 宿主网关（host-gateway）使用 win-bridge	win-bridge 使用二层桥接（L2bridge）网络模式，将容器连接到下层宿主系统上， 从而提供最佳性能。需要用户定义的路由（User-Defined Routes，UDR）才能 实现节点间的连接。
这是二层桥接的一种特殊情形，但仅被用于 Azure 上。 所有报文都被发送到虚拟化环境中的宿主机上并根据 SDN 策略进行处理。	MAC 地址被改写，IP 地址在下层网络上可见。	Azure-CNI 使得容器能够与 Azure vNET 集成，并允许容器利用 [Azure 虚拟网络](所提供的功能特性集合。例如，可以安全地连接到 Azure 服务上或者使用 Azure NSG。 你可以参考 [azure-cni](所提供的一些示例。
覆盖网络（Kubernetes 中为 Windows 提供的覆盖网络支持处于 *alpha* 阶段）	每个容器会获得一个连接到外部 vSwitch 的虚拟网卡（vNIC）。 每个覆盖网络都有自己的、通过定制 IP 前缀来定义的 IP 子网。 覆盖网络驱动使用 VxLAN 封装。	封装于外层包头内。	Win-overlay、 Flannel VXLAN（使用 win-overlay）	当（比如出于安全原因）期望虚拟容器网络与下层宿主网络隔离时， 应该使用 win-overlay。如果你的数据中心可用 IP 地址受限， 覆盖网络允许你在不同的网络中复用 IP 地址（每个覆盖网络有不同的 VNID 标签）。 这一选项要求在 Windows Server 2009 上安装 [KB4489899](补丁。
透明网络（[ovn-kubernetes](的特殊用例）	需要一个外部 vSwitch。容器挂接到某外部 vSwitch 上，该 vSwitch 通过逻辑网络（逻辑交换机和路由器）允许 Pod 间通信。	报文或者通过 [GENEVE](来封装， 或者通过 [STT](隧道来封装， 以便能够到达不在同一宿主系统上的每个 Pod。报文通过 OVN 网络控制器所提供的隧道元数据信息来判定是转发还是丢弃。北-南向通信通过 NAT 网络地址转译来实现。	ovn-kubernetes	[通过 Ansible 来部署](。 所发布的 ACL 可以通过 Kubernetes 策略来应用实施。支持 IPAM 。 负载均衡能力不依赖 kube-proxy。 网络地址转译（NAT）也不需要 iptables 或 netsh。
NAT（ 未在 Kubernetes 中使用 ）	容器获得一个连接到某内部 vSwitch 的 vNIC 接口。 DNS/DHCP 服务通过名为 [WinNAT](的内部组件来提供。	MAC 地址和 IP 地址都被重写为宿主系统的 MAC 地址和 IP 地址。	列在此表中仅出于完整性考虑

如前所述，FlannelCNImeta插件在Windows上也是被支持的，方法是通过VXLAN网络后端（alpha阶段：委托给win-overlay）和主机-网关（host-gateway）网络后端（稳定版本；委托给win-bridge实现）。此插件支持将操作委托给所引用的CNI插件（win-overlay、win-bridge）之一，从而能够与Windows上的Flannel守护进程（Flanneld）一同工作，自动为节点分配子网租期，创建HNS网络。该插件读入其自身的配置文件（cni.conf），并将其与FlannelD所生成的subnet.env文件中的环境变量整合，之后将其操作委托给所引用的CNI插件之一以完成网络发现，并将包含节点所被分配的子网信息的正确配置发送给IPAM插件（例如host-local）。

对于节点、Pod和服务对象，可针对TCP/UDP流量支持以下网络数据流：

IP地址管理（IPAM）

Windows上支持以下IPAM选项：

负载均衡与服务

在Windows系统上，你可以使用以下配置来设定服务和负载均衡行为：

功能特性	描述	所支持的 Kubernetes 版本	所支持的 Windows OS 版本	如何启用
会话亲和性	确保来自特定客户的连接每次都被交给同一 Pod。	[Windows Server vNext Insider Preview Build 19551](或更高版本	将 service.spec.sessionAffinitys 设置为 “ClientIP”
直接 服务器 返回（DSR）	Windows Server 2019	为 kube-proxy 设置标志：`–feature-gates=”WinDSR=true” –enable-dsr=true`
保留目标地址	对服务流量略过 DNAT 步骤，这样就可以在到达后端 Pod 的报文中保留目标服务的 虚拟 IP 地址。还要禁止节点之间的转发。	Windows Server 1903 或更高版本	在服务注解中设置 `”preserve-destination”: “true”` 并启用 kube-proxy 中的 DSR 标志。
IPv4/IPv6 双栈网络	在集群内外同时支持原生的 IPv4-到-IPv4 和 IPv6-到-IPv6 通信。	Windows Server 2004 或更高版本	参见 [IPv4/IPv6 双栈网络](#ipv4ipv6-dual-stack)
保留客户端 IP	确保入站流量的源 IP 地址被保留。同样要禁止节点之间的转发。	Windows Server 2019 或更高版本	将 service.spec.externalTrafficPolicy 设置为 “Local”， 并在 kube-proxy 上启用 DSR。

IPv4/IPv6双栈支持

你可以通过使用​ IPv6DualStack ​特性门控来为​​网络启用IPv4/IPv6双栈联网支持。

对Windows而言，在Kubernetes中使用IPv6需要WindowsServer2004（内核版本10.0.19041.610）或更高版本。

目前Windows上的覆盖网络（VXLAN）还不支持双协议栈联网。

局限性

在Kubernetes架构和节点阵列中仅支持将Windows作为工作节点使用。这意味着Kubernetes集群必须总是包含Linux主控节点，零个或者多个Linux工作节点以及零个或者多个Windows工作节点。

资源处理

Linux上使用Linux控制组（CGroups）作为Pod的边界，以实现资源控制。容器都创建于这一边界之内，从而实现网络、进程和文件系统的隔离。控制组CGroupsAPI可用来收集CPU、I/O和内存的统计信息。与此相比，Windows为每个容器创建一个带有系统名字空间过滤设置的Job对象，以容纳容器中的所有进程并提供其与宿主系统间的逻辑隔离。没有现成的名字空间过滤设置是无法运行Windows容器的。这也意味着，系统特权无法在宿主环境中评估，因而Windows上也就不存在特权容器。归咎于独立存在的安全账号管理器（SecurityAccountManager，SAM），容器也不能获得宿主系统上的任何身份标识。

资源预留

内存预留

Windows不像Linux一样有一个内存耗尽（Out-of-memory）进程杀手（ProcessKiller）机制。Windows总是将用户态的内存分配视为虚拟请求，页面文件（Pagefile）是必需的。这一差异的直接结果是Windows不会像Linux那样出现内存耗尽的状况，系统会将进程内存页面写入磁盘而不会因内存耗尽而终止进程。当内存被过量使用且所有物理内存都被用光时，系统的换页行为会导致性能下降。

使用kubelet参数​ --kubelet-reserve ​与/或​ -system-reserve ​可以统计节点上的内存用量（各容器之外），进而可能将内存用量限制在一个合理的范围，。这样做会减少节点可分配内存。

在你部署工作负载时，对容器使用资源限制（必须仅设置limits或者让limits等于requests值）。这也会从NodeAllocatable中耗掉部分内存量，从而避免在节点负荷已满时调度器继续向节点添加Pods。

避免过量分配的最佳实践是为kubelet配置至少2GB的系统预留内存，以供Windows、Docker和Kubernetes进程使用。

CPU预留

为了统计Windows、Docker和其他Kubernetes宿主进程的CPU用量，建议预留一定比例的CPU，以便对事件作出相应。此值需要根据Windows节点上CPU核的个数来调整，要确定此百分比值，用户需要为其所有节点确定Pod密度的上线，并监控系统服务的CPU用量，从而选择一个符合其负载需求的值。

使用kubelet参数​ --kubelet-reserve ​与/或​ -system-reserve ​可以统计节点上的CPU用量（各容器之外），进而可能将CPU用量限制在一个合理的范围，。这样做会减少节点可分配CPU。

功能特性限制

与Linux相比参数行为的差别

以下kubelet参数的行为在Windows节点上有些不同，描述如下：

存储

Windows上包含一个分层的文件系统来挂载容器的分层，并会基于NTFS来创建一个拷贝文件系统。容器中的所有文件路径都仅在该容器的上下文内完成解析。

因此，Windows节点上不支持以下存储功能特性：

联网

Windows容器联网与Linux联网有着非常重要的差别。MicrosoftdocumentationforWindowsContainerNetworking中包含额外的细节和背景信息。

Windows宿主联网服务和虚拟交换机实现了名字空间隔离，可以根据需要为Pod或容器创建虚拟的网络接口（NICs）。不过，很多类似DNS、路由、度量值之类的配置数据都保存在Windows注册表数据库中而不是像Linux一样保存在​​文件中。Windows为容器提供的注册表与宿主系统的注册表是分离的，因此类似于将/etc/resolv.conf文件从宿主系统映射到容器中的做法不会产生与Linux系统相同的效果。这些信息必须在容器内部使用WindowsAPI来配置。因此，CNI实现需要调用HNS，而不是依赖文件映射来将网络细节传递到Pod或容器中。

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

Kubernetesv1.15中添加了以下功能特性：

CNI插件

Windows上的Kubernetes不支持单协议栈的“只用IPv6”联网选项。不过，系统支持在IPv4/IPv6双协议栈的Pod和节点上运行单协议家族的服务。

会话亲和性

不支持使用​ service.spec.sessionAffinityConfig.clientIP.timeoutSeconds ​来为Windows服务设置最大会话粘滞时间。

安全性

Secret以明文形式写入节点的卷中（而不是像Linux那样写入内存或tmpfs中）。这意味着客户必须做以下两件事：

用户可以为WindowsPods或Container设置​ runAsUserName ​以便以非节点默认用户来执行容器中的进程。这大致等价于设置​​。

不支持特定于Linux的Pod安全上下文特权，例如SELinux、AppArmor、Seccomp、权能字（POSIX权能字）等等。

此外，如前所述，Windows不支持特权容器。

对Windows而言，大多数KubernetesAPI的工作方式没有变化。一些不易察觉的差别通常体现在OS和容器运行时上的不同。在某些场合，负载API（如Pod或Container）的某些属性在设计时假定其在Linux上实现，因此会无法在Windows上运行。

在较高层面，不同的OS概念有：

退出代码遵从相同的习惯，0表示成功，非0值表示失败。特定的错误代码在Windows和Linux上可能会不同。不过，从Kubernetes组件（kubelet、kube-proxy）所返回的退出代码是没有变化的。

V1.PodSecurityContext

PodSecurityContext的所有选项在Windows上都无法工作。这些选项列在下面仅供参考。

操作系统版本限制

Windows有着严格的兼容性规则，宿主OS的版本必须与容器基准镜像OS的版本匹配。目前仅支持容器操作系统为WindowsServer2019的Windows容器。对于容器的Hyper-V隔离、允许一定程度上的Windows容器镜像版本向后兼容性等等，都是将来版本计划的一部分。

获取帮助和故障排查

Kubernetes中日志是故障排查的一个重要元素。确保你在尝试从其他贡献者那里获得故障排查帮助时提供日志信息。你可以按照SIG-Windows贡献指南和收集日志所给的指令来操作。

若以上所引用的脚本不适合，你可以使用下面的例子手动配置​​。

注册flanneld.exe：

nssm install flanneld C:\flannel\flanneld.exenssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1nssm set flanneld AppEnvironmentExtra NODE_NAME=nssm set flanneld AppDirectory C:\flannelnssm start flanneld

注册kubelet.exe：

nssm install kubelet C:\k\kubelet.exenssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=k8s.gcr.io/pause:3.5 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false--log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\confignssm set kubelet AppDirectory C:\knssm start kubelet

注册kube-proxy.exe（二层网桥模式和主机网关模式）

nssm install kube-proxy C:\k\kube-proxy.exenssm set kube-proxy AppDirectory c:\knssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=falsenssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0nssm set kube-proxy DependOnService kubeletnssm start kube-proxy

注册kube-proxy.exe（覆盖网络模式或VxLAN模式）

nssm install kube-proxy C:\k\kube-proxy.exenssm set kube-proxy AppDirectory c:\knssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=falsenssm set kube-proxy DependOnService kubeletnssm start kube-proxy

作为初始的故障排查操作，你可以使用在nssm.exe中使用下面的标志以便将标准输出和标准错误输出重定向到一个输出文件：

nssm set <服务名称> AppStdout C:\k\mysvc.lognssm set <服务名称> AppStderr C:\k\mysvc.log

要了解更多的细节，可参见官方的nssm用法文档。

如果你在使用虚拟机，请确保VM网络适配器均已开启MAC侦听（Spoofing）。

WindowsPods目前没有为ICMP协议提供出站规则。不过TCP/UDP是支持的。尝试与集群外资源连接时，可以将​​命令替换为对应的​​命令。

如果你还遇到问题，很可能你在cni.conf中的网络配置值得额外的注意。你总是可以编辑这一静态文件。配置的更新会应用到所有新创建的Kubernetes资源上。

Kubernetes网络的需求之一是集群内部无需网络地址转译（NAT）即可实现通信。为了符合这一要求，对所有我们不希望出站时发生NAT的通信都存在一个ExceptionList。然而这也意味着你需要将你要查询的外部IP从ExceptionList中移除。只有这时，从你的WindowsPod发起的网络请求才会被正确地通过SNAT转换以接收到来自外部世界的响应。就此而言，你在​​中的​ ExceptionList ​应该看起来像这样：

"ExceptionList": ["10.244.0.0/16",# 集群子网"10.96.0.0/12",# 服务子网"10.127.130.0/24" # 管理（主机）子网]

从节点自身发起的本地NodePort请求会失败。这是一个已知的局限。NodePort服务的访问从其他节点或者外部客户端都可正常进行。

这一问题可能因为​ hostname-override ​参数未能传递给kube-proxy而导致。解决这一问题时，用户需要按如下方式将主机名传递给kube-proxy：

C:\k\kube-proxy.exe --hostname-override=$(hostname)

无论何时，当一个之前被删除的节点被重新添加到集群时，flannelD都会将为节点分配一个新的Pod子网。用户需要将将下面路径中的老的Pod子网配置文件删除：

Remove-Item C:\k\SourceVip.jsonRemove-Item C:\k\SourceVipRequest.json

关于这一问题有很多的报告；最可能的一种原因是关于何时设置Flannel网络的管理IP的时间问题。一种解决办法是重新启动​​或者按如下方式手动重启之：

[Environment]::SetEnvironmentVariable("NODE_NAME", "")C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1

这表明Flannel网络未能正确启动。你可以尝试重启flanneld.exe或者将文件手动地从Kubernetes主控节点的​ /run/flannel/subnet.env ​路径复制到Windows工作节点的​ C:\run\flannel\subnet.env ​路径，并将​ FLANNEL_SUBNET ​行改为一个不同的数值。例如，如果期望节点子网为​ 10.244.4.1/24 ​：

FLANNEL_NETWORK=10.244.0.0/16FLANNEL_SUBNET=10.244.4.1/24FLANNEL_MTU=1500FLANNEL_IPMASQ=true

这是Windows上当前网络协议栈的一个已知的限制。WindowsPods能够访问服务IP。

Windows网络堆栈需要一个虚拟的适配器，这样Kubernetes网络才能工作。如果下面的命令（在管理员Shell中）没有任何返回结果，证明虚拟网络创建（kubelet正常工作的必要前提之一）失败了：

Get-HnsNetwork | ? Name -ieq "cbr0"Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"

当宿主系统的网络适配器名称不是“Ethernet”时，通常值得更改​​脚本中的InterfaceName参数来重试。否则可以查验​ start-kubelet.ps1 ​的输出，看看是否在虚拟网络创建过程中报告了其他错误。

检查你的pause镜像是与你的OS版本兼容的。 如果你安装的是更新版本的Windows，比如说某个Insider构造版本，你需要相应地调整要使用的镜像。请参照Microsoft的Docker仓库了解镜像。不管怎样，pause镜像的Dockerfile和示例服务都期望镜像的标签为​​。

此功能是在Kubernetesv1.15中实现的，pause基础设施容器​ mcr.microsoft.com/oss/kubernetes/pause:3.4.1 ​中包含了wincat.exe。请确保你使用的是这些版本或者更新版本。如果你想要自行构造你自己的pause基础设施容器，要确保其中包含了wincat

Windows的端口转发支持需要在pause基础设施容器中提供wincat.exe。确保你使用的是与你的Windows操作系统版本兼容的受支持镜像。如果你想构建自己的pause基础架构容器，请确保包含wincat。

如果你处于防火墙之后，那么必须定义如下PowerShell环境变量：

[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)

在一个KubernetesPod中，一个基础设施容器，或称“pause”容器，会被首先创建出来，用以托管容器端点。属于同一Pod的容器，包括基础设施容器和工作容器，会共享相同的网络名字空间和端点（相同的IP和端口空间）。我们需要pause容器来工作容器崩溃或重启的状况，以确保不会丢失任何网络配置。

进一步探究

如果以上步骤未能解决你遇到的问题，你可以通过以下方式获得在Kubernetes中的Windows节点上运行Windows容器的帮助：

报告问题和功能需求

如果你遇到看起来像是软件缺陷的问题，或者你想要提起某种功能需求，请使用GitHub问题跟踪系统。你可以在GitHub上发起Issue并将其指派给SIG-Windows。你应该首先搜索Issue列表，看看是否该Issue以前曾经被报告过，以评论形式将你在该Issue上的体验追加进去，并附上额外的日志信息。SIG-WindowsSlack频道也是一个获得初步支持的好渠道，可以在生成新的Ticket之前对一些想法进行故障分析。

在登记软件缺陷时，请给出如何重现该问题的详细信息，例如：

---

杀毒软件的共享版和破译版有什么不同

共享版有使用限制，比如使用时间上或者功能上受限制，属于正版软件；破解版就是破解该软件的注册环节，使其不用注册即可使用全部功能．

系统脚本文件杀毒杀掉怎么修复

出现此问题是因为该网页的 HTML 源代码不能使用客户端脚本（如 Microsoft JScript 或 Visual basic 脚本）正确工作。 发生此问题可能是因为以下原因之一： • 网页的 HTML 源代码中有问题。 • 您的计算机或网络上阻止了活动脚本、ActiveX 控件或 Java 小程序。 Internet Explorer 或另外一种程序（如防病毒程序或防火墙）可以配置为阻止活动脚本、ActiveX 控件或 Java 小程序• 防病毒软件配置为扫描您的“临时 Internet 文件”或“已下载的程序文件”文件夹。 • 您计算机上的脚本引擎损坏或过时。 • 您计算机上的 Internet 相关文件夹损坏。 • 您的视频卡驱动程序已损坏或者已过时。 • 您计算机上的 DirectX 组件损坏或过时。 注意：服务器端脚本 -- 如 Active Server pages (ASp) 中的 Visual basic 脚本 -- 运行在 Web 服务器上。 因服务器端脚本故障而发生的脚本错误不在 Internet Explorer 中生成错误消息，但也可能会创建一个不能正确显示或工作的网页。 本文中的故障排除信息适用于服务器端脚本错误。 如果您怀疑服务器端脚本有问题，请与 Web 服务器的管理员联系。 解决方案使用本文中的故障排除方法时要按它们出现的顺序进行。 在您完成一个故障排除部分后，请进行测试以确定是否仍发生此脚本错误。 如果问题已解决，则不必继续下一部分。 如果问题未解决，则继续执行下一部分。 从另一个用户帐户、另一个浏览器和另一台计算机测试网页如果问题只在您查看一个或两个网页时发生，则从另一个用户帐户、另一个浏览器或另一台计算机查看这些网页，以确定问题是否依然存在。 如果脚本错误依然存在，则可能是网页的编写有问题。 请与网站管理员或内容开发者联系，告诉他们网页存在的问题。 如果从另一个用户帐户使用网页时脚本错误未发生，则问题可能是您的用户配置文件的文件或设置造成的。 如果在从另一个浏览器或另一台计算机使用网页时脚本错误未发生，则继续进行故障排除操作。 确认活动脚本、ActiveX 和 Java 未被阻止确认您计算机上的 Internet Explorer 或另外一种程序（如防病毒程序或防火墙）未配置为阻止活动脚本、ActiveX 控件或 Java 小程序。 在 Internet Explorer 的“高”安全级别，活动脚本、ActiveX 控件和 Java 小程序被关闭。 默认情况下，Internet Explorer 6 和某些 Internet Explorer 5.x 版本针对受限站点区域使用“高”安全级别。 默认情况下，Microsoft Windows Server 2003 针对受限站点区域和 Internet 区域使用“高”安全级别。 如要为当前网页重置 Internet Explorer 安全设置，请按照下列步骤操作：1. 启动 Internet Explorer。 2. 在“工具”菜单上，单击“Internet 选项”。 3. 在“Internet 选项”对话框中，单击“安全”。 4. 单击“默认级别”。 5. 单击“确定”。 请参见您使用的防病毒程序或防火墙的文档资料，以确定如何打开脚本、ActiveX 和 Java 小程序。 确认您的防病毒程序未设置为扫描“临时 Internet 文件”或“已下载的程序文件”文件夹请参见您使用的防病毒程序的文档资料，以确定如何防止该程序扫描“临时 Internet 文件”或“已下载的程序文件”文件夹。 删除所有临时的 Internet 相关文件从您的计算机中删除所有临时的 Internet 相关文件。 为此，请按照下列步骤操作：1. 启动 Internet Explorer。 2. 在“工具”菜单上，单击“Internet 选项”。 3. 单击“常规”选项卡。 4. 在“Internet 临时文件”下，单击“设置”。 5. 单击“删除文件”。 6. 单击“确定”。 7. 单击“删除 Cookies”。 8. 单击“确定”。 9. 在“历史记录”下，单击“清除历史记录”，然后单击“是”。 10. 单击“确定”。

关于木马程序？

误报吧，bat 是一种批处理文件，不可能是木马。