这篇文章已过一年以上。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes v1.9 发布了对 Windows Server 容器的 Beta 支持

作者：Michael Michael (Apprenda) |

在发布时，Michael Michael 是作为 SIG-Windows 的负责人撰写的。

随着 Kubernetes v1.9 的发布，我们确保 Kubernetes 在任何地方和为每个人都能良好运行的使命向前迈进了一大步。我们已将对 Windows Server 的支持推进到 beta 版，同时在 Kubernetes 和 Windows 平台上继续进行功能和功能改进。自 2016 年 3 月以来，SIG-Windows 一直在努力为许多特定于 Windows 的应用程序和工作负载在 Kubernetes 上运行打开大门，从而显着扩展了 Kubernetes 的实现场景和企业覆盖范围。

各种规模的企业都在 .NET 和基于 Windows 的应用程序上进行了大量投资。许多企业组合今天都包含 .NET 和 Windows，Gartner 声称 80% 的企业应用程序在 Windows 上运行。根据 StackOverflow Insights，40% 的专业开发人员使用 .NET 编程语言（包括 .NET Core）。

但是为什么所有这些信息都很重要呢？这意味着企业既有遗留应用程序，也有在云端诞生的（微服务）应用程序，它们使用各种编程框架。业界正在大力推动将现有/遗留应用程序现代化为容器，使用类似于“迁移和转移”的方法。将现有应用程序现代化为容器还为在其他 Windows 或 Linux 容器中引入新功能提供了更大的灵活性。容器正在成为打包、部署和管理现有应用程序和微服务应用程序的事实标准。IT 组织正在寻找一种更简单、更统一的方式来编排和管理其 Linux 和 Windows 环境中的容器。Kubernetes v1.9 现在提供对 Windows Server 容器的 beta 支持，使其成为编排任何类型容器的明确选择。

功能

Kubernetes 中对 Windows Server 容器的 Alpha 支持对于概念验证项目和可视化 Kubernetes 中支持 Windows 的路线图非常有用。然而，alpha 版本存在明显的缺点，并且缺乏许多功能，尤其是在网络方面。SIG-Windows、Microsoft、Cloudbase Solutions、Apprenda 和其他社区成员齐心协力创建了一个全面的 beta 版本，使 Kubernetes 用户能够开始评估和使用 Windows。

Kubernetes 上 Windows Server 容器的一些主要功能改进包括

  • 改进了对 Pod 的支持！Pod 中的多个 Windows Server 容器现在可以使用 Windows Server 中的网络隔离共享网络命名空间。此功能使 Pod 的概念与基于 Linux 的容器保持一致
  • 通过为每个 Pod 使用单个网络端点来降低网络复杂性
  • 使用虚拟过滤平台 (VFP) Hyper-v 交换机扩展进行基于内核的负载平衡（类似于 Linux iptables）
  • 容器运行时接口 (CRI) Pod 和节点级统计信息。现在可以使用从 Pod 和节点收集的性能指标对 Windows Server 容器进行水平 Pod 自动缩放配置
  • 支持使用 kubeadm 命令将 Windows Server 节点添加到 Kubernetes 环境。Kubeadm 简化了 Kubernetes 集群的配置，并且在支持 Windows Server 的情况下，您可以使用单个工具在您的基础架构中部署 Kubernetes
  • 支持 ConfigMaps、Secrets 和 Volumes。这些是关键功能，使您可以分离（在某些情况下是保护）容器的配置与实现。然而，Kubernetes 1.9 Windows 支持的皇冠上的宝石是网络增强功能。随着 Windows Server 1709 的发布，Microsoft 在操作系统和 Windows 主机网络服务 (HNS) 中启用了关键的网络功能，为生成许多可与 Kubernetes 中的 Windows Server 容器一起使用的 CNI 插件铺平了道路。Kubernetes 1.9 支持的第 3 层路由和网络覆盖插件如下所示
  1. 上游 L3 路由 - 在上游 ToR 中配置的 IP 路由
  2. 主机网关 - 在每个主机上配置的 IP 路由
  3. 带有覆盖的 Open vSwitch (OVS) 和 Open Virtual Network (OVN) - 支持 STT 和 Geneve 隧道类型，您可以阅读有关其 配置、设置和运行时功能的更多信息，以便为 Kubernetes 中的网络堆栈做出明智的选择。

即使您必须继续在 Linux 中运行 Kubernetes 控制平面和主组件，您现在也可以将 Windows Server 作为 Kubernetes 中的节点引入。作为一个社区，这是一个巨大的里程碑和成就。我们现在将开始在 Kubernetes 中看到 .NET、.NET Core、ASP.NET、IIS、Windows 服务、Windows 可执行文件和更多基于 Windows 的应用程序。

下一步是什么

此 beta 版本投入了大量工作，但社区意识到，在我们发布 Windows 支持作为生产工作负载的 GA（正式发布）之前，还需要在更多领域进行投资。2018 年前两个季度的重点领域包括

  1. 继续在网络领域取得进展。其他 CNI 插件正在开发中，即将完成
  • 覆盖 - win-overlay（使用 Flannel 的 vxlan 或 IP-in-IP 封装）
  • Win-l2bridge（主机网关）
  • 使用云网络的 OVN - 没有覆盖
  • 支持 ovn-kubernetes 中的 Kubernetes 网络策略
  • 支持 Hyper-V 隔离
  • 支持有状态应用程序的 StatefulSet 功能
  • 生成可在任何基础设施以及 Microsoft Azure、Google Cloud 和 Amazon AWS 等许多公共云提供商上使用的安装工件和文档
  • SIG-Windows 的持续集成/持续交付 (CI/CD) 基础设施
  • 可扩展性和性能测试，即使我们尚未承诺 GA 的时间表，SIG-Windows 估计 2018 年上半年将发布 GA 版本。

参与其中

随着我们在 Kubernetes 中向此功能的正式发布迈进，我们欢迎您参与其中、贡献代码、提供反馈、将 Windows Server 容器部署到您的 Kubernetes 集群，或者只是加入我们的社区。