本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
聚焦 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 上运行容器时所指的含义。
“在关注 Kubernetes 中的 Windows 支持时，”SIG（特别兴趣小组）联合主席 Mark Rossetti 和 Michael Michael 说，“许多人开始将其与 Linux 容器进行比较。尽管一些突出限制的比较是公平的，但区分操作限制以及 Windows 和 Linux 操作系统之间的差异非常重要。Windows 容器运行 Windows 操作系统，Linux 容器运行 Linux。”
本质上，任何“容器”都只是在其宿主操作系统上运行的一个进程，并带有一些关键工具来隔离该进程及其依赖项与环境的其余部分。目标是使该运行中的进程安全隔离，同时占用系统最少的资源来执行该隔离。在 Linux 上，用于隔离进程以创建“容器”的工具通常归结为 cgroups 和命名空间（以及其他一些工具），它们本身就是内置于 Linux 内核中的工具。
如果狗是进程：容器化就像使用 cgroups 为每只狗提供自己的玩具和食物等资源，并使用命名空间隔离麻烦的狗。
原生 Windows 进程是必须在 Windows 操作系统上运行的进程。这使得它们与在 Linux 操作系统上运行的进程有着根本的区别。由于 Linux 容器是 Linux 内核工具（cgroups 和命名空间）隔离的 Linux 进程，因此容器化原生 Windows 进程意味着在 Windows 内核本身中实现类似的隔离工具。因此，“Windows 容器”和“Linux 容器”是根本不同的技术，尽管它们具有相同的目标（隔离进程）并且在某些方面工作方式相似（使用内核级容器化）。
因此，在 Windows 上运行容器时，实际上有两个非常重要的概念需要考虑
- 作为原生 Windows Server 风格容器运行的原生 Windows 进程，
- 以及在 Linux 内核上运行的传统 Linux 容器，通常托管在轻量级 Hyper-V 虚拟机上。
您可以在微软的这份教程中了解更多关于 Linux 和 Windows 容器的信息。
Kubernetes on Windows
Kubernetes 最初设计时就考虑到了 Linux 容器，并且本身就是为了在 Linux 系统上运行而设计的。正因为如此，Kubernetes 的大部分功能都涉及到独特的 Linux 功能。Linux 特定的工作是故意的——我们都希望 Kubernetes 在 Linux 上运行得最佳——但对 Windows 服务器进行类似优化的需求正在增长。对于用户需要在 Windows 上进行容器编排的情况，SIG-Windows 的 Kubernetes 贡献者社区已经为 Windows 特定用例整合了功能。
“我们经常遇到的一个问题是，我能否拥有一个纯 Windows 集群。答案是否定的。Kubernetes 控制平面组件将继续基于 Linux，而 SIG-Windows 正在专注于在 Kubernetes 集群中拥有 Windows 工作节点的用户体验。”
SIG-Windows 社区并没有将“Windows Kubernetes”和“Linux Kubernetes”的概念区分开来，而是致力于为主 Kubernetes 项目添加功能，使其能够处理 Windows 的用例。这些 Windows 功能反映了 Kubernetes 自 2014 年发布以来所服务的 Linux 用例，并在某些情况下为其添加了独特的功能（想了解更多历史？请滚动查阅这份原始设计文档）。
SIG-Windows 的职责是什么？
SIG 主席 Mark 和 Michael 表示，“SIG-Windows 确实是 Kubernetes 中所有 Windows 相关事务的中心。” “我们主要关注计算方面，但实际上，任何与在 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 的贡献者可以是任何独立爱好者，也可以是来自不同公司的专业人士。他们来自世界各地，带来各种不同的技能。
“与大多数其他 Kubernetes SIG 一样，我们是一个非常热情和开放的社区，”SIG 联席主席 Michael Michael 和 Mark Rosetti 解释道。
成为贡献者
对于任何有兴趣入门的人，联合主席补充道：“新贡献者可以在 GitHub 上查看过去的社区会议（我们记录了过去三年来的每一次会议），阅读我们的文档，参加新的社区会议，在现场或 Slack 上提问，并在 GitHub 上提交一些问题。我们还参加所有的 KubeCon 大会，并主持 1-2 场会议、一次贡献者会议以及与维护者会面办公时间。”
联席主席还分享了成为 SIG-Windows 社区成员的途径概览。
“我们鼓励新贡献者最初只加入我们的社区并倾听，然后开始提问并了解 Kubernetes 中的 Windows。当他们感到舒适时，他们可以提升到改进我们的文档、提交一些 bug/问题，最终他们可以通过修复一些 bug 成为代码贡献者。如果他们对 Windows 做出长期和持续的重大贡献，他们可以成为 SIG-Windows 的技术负责人或主席。除非您开始，否则您不会知道自己是否喜欢这个领域 :) 要开始，请访问此入门页面。这是一个一站式商店，其中包含与 Kubernetes 中的 SIG-Windows 相关的所有链接。”
当被问及新贡献者是否有任何有用的技能时，联合主席说，
“我们一直在寻找 Go、网络和存储方面的专业知识，以及对 Windows 的热情。这些都是非常重要的技能。然而，我们不要求具备这些技能，我们欢迎任何和所有具有不同技能组合的贡献者。如果您不了解某些东西，我们会帮助您掌握它。”
您可以通过他们的 Slack 频道与 SIG-Windows 的成员联系，或者参加他们定期举行的会议——目前每周二美国东部时间下午 12:30 举行 30 分钟！您可以在 GitHub 上的 SIG-Windows README 中找到他们定期会议的链接，以及过去的会议记录和录音。
来自 SIG-Windows 的最后信息