本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
SIG-Windows 聚焦
这篇文章讲述了 Kubernetes 贡献者如何协作，以提供一个适用于 Linux 和 Windows 的容器编排器。
大多数熟悉 Kubernetes 的人可能习惯于将其与 Linux 联系起来。这种联系是有道理的，因为 Kubernetes 从一开始就运行在 Linux 上。然而，许多致力于采用 Kubernetes 的团队和组织需要能够在 Windows 上编排容器。自从 Docker 发布以及容器普及以来，社区和微软自身都在努力使容器技术在 Windows 系统中像在 Linux 系统中一样易于访问。
在 Kubernetes 社区中，那些热衷于使 Kubernetes 可供 Windows 社区使用的人可以在 Windows 特别兴趣小组中找到归宿。为了更多地了解 SIG-Windows 以及 Kubernetes 在 Windows 上的未来，我与联合主席 Mark Rossetti 和 Michael Michael 讨论了 SIG 的目标以及其他人如何贡献。
Windows 容器和 Kubernetes 简介
Kubernetes 是用于编排容器工作负载的最流行的工具，因此要了解 Kubernetes 项目中的 Windows 特别兴趣小组 (SIG)，首先了解我们谈论在 Windows 上运行容器时的含义非常重要。
SIG（特别兴趣小组）联合主席 Mark Rossetti 和 Michael Michael 说：“在研究 Kubernetes 中的 Windows 支持时，许多人开始将 Linux 容器进行比较。尽管一些突出限制的比较是公平的，但区分 Windows 和 Linux 操作系统之间的操作限制和差异非常重要。Windows 容器运行 Windows 操作系统，而 Linux 容器运行 Linux。”
本质上，任何“容器”都只是在其主机操作系统上运行的进程，其中有一些关键工具到位，可以将该进程及其依赖项与环境的其余部分隔离。目标是使正在运行的进程安全隔离，同时从系统占用最少的资源来执行隔离。在 Linux 上，用于隔离进程以创建“容器”的工具通常归结为 cgroups 和命名空间（以及其他一些），它们本身就是内置于 Linux 内核的工具。
如果狗是进程：容器化就像使用 cgroups 给每只狗自己的资源（如玩具和食物），并使用命名空间隔离麻烦的狗。
原生 Windows 进程是在 Windows 操作系统上运行或必须运行的进程。这使得它们与在 Linux 操作系统上运行的进程根本不同。由于 Linux 容器是 Linux 进程，由 Linux 内核工具（称为 cgroups 和命名空间）隔离，因此容器化原生 Windows 进程意味着在 Windows 内核本身中实现类似的隔离工具。因此，“Windows 容器”和“Linux 容器”是根本不同的技术，即使它们具有相同的目标（隔离进程）并且在某些方面工作方式相似（使用内核级容器化）。
因此，在 Windows 上运行容器时，实际上有两个非常重要的概念需要考虑
- 作为原生 Windows Server 样式容器运行的原生 Windows 进程，
- 以及在 Linux 内核上运行的传统 Linux 容器，通常托管在轻量级 Hyper-V 虚拟机上。
您可以在微软的此 教程 中了解更多关于 Linux 和 Windows 容器的信息。
Windows 上的 Kubernetes
Kubernetes 最初是考虑到 Linux 容器而设计的，并且本身也被设计为在 Linux 系统上运行。因此，Kubernetes 的许多功能都涉及独特的 Linux 功能。特定于 Linux 的工作是有意为之的——我们都希望 Kubernetes 在 Linux 上以最佳方式运行——但对 Windows 服务器的类似优化需求正在增长。对于用户需要在 Windows 上进行容器编排的情况，Kubernetes 贡献者社区 SIG-Windows 已经为 Windows 特定的用例整合了功能。
“我们经常会问到的一个问题是，我是否可以拥有一个仅限 Windows 的集群。答案是否定的。Kubernetes 控制平面组件将继续基于 Linux，而 SIG-Windows 则专注于在 Kubernetes 集群中拥有 Windows 工作节点的用户体验。”
SIG-Windows 社区不是将“Windows Kubernetes”和“Linux Kubernetes”的概念分开，而是致力于向主要的 Kubernetes 项目添加功能，使其能够处理 Windows 的用例。这些 Windows 功能镜像了 Kubernetes 自 2014 年发布以来一直在服务的 Linux 用例，在某些情况下还添加了独特的功能（想要了解更多历史？请浏览此 原始设计文档）。
SIG-Windows 做什么？
“SIG-Windows 实际上是 Kubernetes 中所有 Windows 事物的中心，” SIG 主席 Mark 和 Michael 说，“我们主要关注计算方面的事情，但实际上，任何与在 Windows 上运行 Kubernetes 相关的事情都在 SIG-Windows 的范围内。”
为了最好地为用户服务，SIG-Windows 致力于使 Windows 和 Linux 用户在 Kubernetes 中的用户体验尽可能保持一致。然而，某些用例只适用于一种操作系统，因此，SIG-Windows 小组也致力于创建仅适用于 Windows 工作负载的功能。
Kubernetes 中的许多 SIG（“特别兴趣小组”）都有狭窄的重点，允许成员深入研究技术的某个方面。虽然欢迎特定的专业知识，但对 SIG-Windows 感兴趣的人会发现它是一个建立对 Kubernetes 许多重点领域广泛理解的绝佳社区。“我们 SIG 的成员与 Kubernetes 中的存储、网络、测试、集群生命周期和其他小组进行交互。”
SIG-Windows 的用户是谁？
了解一个小组制造的技术的最好方法通常是了解他们的客户或用户是谁。
SIG 主席分享说：“我们互动过的大多数用户都在 Windows 上运行着多年开发的业务关键型基础设施，并且由于各种原因（成本、时间、合规性等）无法将这些工作负载迁移到 Linux。” “通过将这些工作负载传输到 Windows 容器并在 Kubernetes 中运行它们，他们能够快速实现基础设施的现代化，并帮助将其迁移到云端。”
正如 Kubernetes 领域的任何人都证明的那样，世界各地许多不同行业的公司都将 Kubernetes 视为他们实现基础设施现代化的途径。这通常涉及重新架构甚至彻底重新发明他们开展业务的许多方式。目标是使他们的系统更具可扩展性、更强大，并为未来可能带来的任何事情做好准备。但并非每个应用程序或工作负载都可以或应该更改其运行的核心操作系统，因此许多团队需要能够在 Windows 或 Linux 或两者上大规模运行容器的能力。
“有时驱动 Windows 容器的是现代化工作，有时是因为当前操作系统的硬件保修到期或支持周期结束。我们在 SIG-Windows 中的努力使 Windows 开发人员能够利用云原生工具和 Kubernetes 更快地构建和部署分布式应用程序。这令人兴奋！本质上，用户可以在降低成本的同时保留应用程序可用性的好处。”
谁是 SIG-Windows？
是谁在为 Kubernetes 启用 Windows 工作负载的贡献者？可能就是你！
与其他 Kubernetes SIG 一样，SIG-Windows 的贡献者可以是来自许多不同公司的独立爱好者，也可以是专业人士。他们来自世界各地，并带来了许多不同的技能组合。
SIG 联合主席 Michael Michael 和 Mark Rosetti 解释说：“像大多数其他 Kubernetes SIG 一样，我们是一个非常受欢迎和开放的社区。”
成为贡献者
对于任何有兴趣入门的人，联合主席补充说：“新的贡献者可以在 GitHub 上查看旧的社区会议（我们记录了过去三年的每一次会议），阅读我们的文档，参加新的社区会议，亲自或在 Slack 上提问，并在 Github 上提交一些问题。我们还参加所有的 KubeCon 会议，并举办 1-2 次会议、贡献者会议以及与维护者会面的办公时间。”
联合主席还分享了成为 SIG-Windows 社区成员的途径。
“我们鼓励新的贡献者最初只是加入我们的社区并倾听，然后开始提出一些问题并学习 Kubernetes 中的 Windows 相关知识。当他们感到舒适时，他们可以逐步开始改进我们的文档、提交一些错误/问题，最终他们可以通过修复一些错误成为代码贡献者。如果他们对 Windows 有长期和持续的大量贡献，他们可以成为 SIG-Windows 的技术负责人或主席。除非你开始行动，否则你不会知道你是否喜欢这个领域 :) 要开始，请访问此入门页面。这是一个一站式商店，其中包含与 Kubernetes 中 SIG-Windows 相关的所有内容的链接。”
当被问及新贡献者需要哪些有用的技能时，联合主席表示：
“我们一直在寻找在 Go、网络和存储方面的专业知识，以及对 Windows 的热情。这些是非常重要的技能。但是，我们不要求具备这些技能，我们欢迎任何和所有具有不同技能的贡献者。如果你不了解某些东西，我们会帮助你掌握它。”
你可以通过他们的 Slack 频道与 SIG-Windows 的成员取得联系，或参加他们定期举行的会议 - 目前是每周二美国东部时间下午 12:30 举行的 30 分钟会议！你可以在 GitHub 上的 SIG-Windows README 中找到他们定期会议的链接，以及过去的会议记录和录像。
作为来自 SIG-Windows 的结束语：