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

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

作者：Michael Michael (Apprenda) |

发布时，Michael Michael 担任 SIG-Windows 负责人。

随着 Kubernetes v1.9 的发布，我们确保 Kubernetes 在任何地方都能良好运行并为所有人服务的使命迈出了一大步。我们已将对 Windows Server 的支持提升到测试版，同时在 Kubernetes 和 Windows 平台上的功能和特性方面持续取得进展。SIG-Windows 自 2016 年 3 月以来一直致力于为许多 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 容器的测试版支持，使其成为协调各种容器的明确选择。

功能

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 容器进行 Horizontal Pod Autoscaling 的分析。
  • 支持 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 支持的 Layer-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 Services、Windows 可执行文件以及更多基于 Windows 的应用程序。

接下来是什么

这个测试版的发布投入了大量工作，但社区意识到在我们将 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 估计 GA 版本将在 2018 年上半年发布。

参与其中

随着我们继续朝着 Kubernetes 中此功能的通用可用性迈进，我们欢迎您参与进来，贡献代码，提供反馈，将 Windows Server 容器部署到您的 Kubernetes 集群，或只是加入我们的社区。