本文发布时间已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已过时或不再准确。
SIG-Windows 聚焦
这篇文章讲述了 Kubernetes 贡献者如何共同努力提供一个既适用于 Linux 又适用于 Windows 的容器编排器。
大多数熟悉 Kubernetes 的人可能习惯于将其与 Linux 联系起来。这种关联是有道理的，因为 Kubernetes 从一开始就运行在 Linux 上。然而，许多正在采用 Kubernetes 的团队和组织需要能够在 Windows 上编排容器。自 Docker 发布和容器流行以来，社区和微软本身都在努力使容器技术在 Windows 系统中像在 Linux 系统中一样易于使用。
在 Kubernetes 社区内部，热衷于让 Windows 社区更容易接触 Kubernetes 的人可以在 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 和 namespaces（还有一些其他工具），这些工具本身就内置于 Linux 内核中。
如果把狗比作进程：容器化就像使用 cgroups 为每只狗提供自己的玩具和食物等资源，并使用 namespaces 隔离那些麻烦的狗。
本地 Windows 进程是必须或只能在 Windows 操作系统上运行的进程。这使得它们与在 Linux 操作系统上运行的进程有着根本的区别。由于 Linux 容器是 Linux 进程，由 Linux 内核工具 cgroups 和 namespaces 进行隔离，容器化本地 Windows 进程意味着在 Windows 内核本身内部实现类似的隔离工具。因此，“Windows 容器”和“Linux 容器”是根本上不同的技术，即使它们的目标相同（隔离进程），并且在某些方面工作方式类似（使用内核级别容器化）。
因此，当谈到在 Windows 上运行容器时，实际上有两个非常重要的概念需要考虑
- 以本地 Windows Server 风格容器运行的本地 Windows 进程，
- 以及通常托管在轻量级 Hyper-V 虚拟机上，在 Linux 内核上运行的传统 Linux 容器。
您可以通过微软提供的这篇教程了解更多关于 Linux 和 Windows 容器的信息。
Windows 上的 Kubernetes
Kubernetes 最初设计时考虑的是 Linux 容器，其本身也是设计用来运行在 Linux 系统上。正因如此，Kubernetes 的许多功能都涉及独特的 Linux 功能。针对 Linux 的工作是故意的——我们都希望 Kubernetes 在 Linux 上最优地运行——但对 Windows 服务器进行类似优化的需求正在增长。对于用户需要在 Windows 上进行容器编排的场景，SIG-Windows 的 Kubernetes 贡献者社区已经整合了针对 Windows 特定用例的功能。
“我们经常被问到的一个问题是，我能否拥有一个纯 Windows 集群。答案是否定的。Kubernetes 控制平面组件将继续基于 Linux，而 SIG-Windows 正专注于在 Kubernetes 集群中拥有 Windows Worker 节点的用户体验。”
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 的贡献者可以是任何人，从独立的业余爱好者到在许多不同公司工作的专业人士。他们来自世界各地，带来了许多不同的技能。
SIG 联合主席 Michael Michael 和 Mark Rosetti 解释说：“像大多数其他 Kubernetes SIG 一样，我们是一个非常热情和开放的社区。”
成为贡献者
对于任何有兴趣入门的人，联合主席补充道：“新贡献者可以在 GitHub 上查看以前的社区会议（我们记录了过去三年的每一次会议），阅读我们的文档，参加新的社区会议，当面或在 Slack 上提问，并在 Github 上提交一些议题 (issues)。我们还会参加所有的 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 的结语