Kubernetes-贡献者峰会-US-2024-笔记-全-

Kubernetes 贡献者峰会 US 2024 笔记（全）

001：奖项与表彰 🏆

在本节课中，我们将学习Kubernetes 2024北美贡献者峰会的奖项颁发环节。我们将了解项目如何感谢核心组织者，并表彰在过去一年中为各个特别兴趣小组做出杰出贡献的开发者们。

特别致谢 🙏

在开始颁发奖项之前，我们首先要感谢一位特别的人物，她多年来在组织历届贡献者峰会方面提供了巨大帮助。

感谢来自CNCF（云原生计算基金会）的Pri Prine。她负责从CNCF的角度组织所有这些活动，并耐心处理我们所有的疑问和请求。虽然她未来将不再属于Kubernetes核心团队，因为她将在Linux基金会承担其他职责，但我们仍想为她过去组织的所有活动表达谢意。

Josh特意准备了一份礼物。这是一个特别的Kubernetes纪念杯，你无法在其他地方获得，只能从George这里得到。同时，还有一个需要你自己组装的、由550块乐高积木构成的Kubernetes标志。我们期待看到成品。

杰出贡献者表彰 🎉

现在，我们将继续表彰那些多年来，尤其是过去一年中，在Kubernetes项目中做出杰出贡献的人们。我们将从SIG API Machinery开始。

以下是获得表彰的贡献者名单，我们对可能读错的姓名表示歉意。

SIG API Machinery

Lucas：感谢你的工作。
Stephen Heyward：感谢你所做的一切。这掌声是给你的。

SIG CLI

Ma Zuk

SIG Cluster Lifecycle

Fan Boa Bofa
Christian Schlaughter
Max Gotier

SIG Contributor Experience

Arvin Parek
Jason Bragen Brugenza
Mario
Noah Kviitz
Cip Kennabar
S arm We it

SIG Docs

Abigail McCarthy
Tipesh Gt

SIG Auth

Ivonne Valdeez

SIG Architecture

Can Sang
Weiffu

SIG Instrumentation

Katherine Fang
Man Ruger

SIG Intro

Ricky Zowsky
Marco Binch

SIG Multicluster

Mike Morris

SIG Network

Chuan Tian
Damen awar
Maade
Dave Prataovsky

SIG Node

Peter Hunt
Francesco Romanmani

SIG Release

Meha Belodia
Wayom Yaov

SIG Scalability

Harsh Kuna
Praique Georgia
Justin Santa Barbara

SIG Scheduling

Shengchn

SIG Security

And Chaman Chapathy
Ayla Dbury

SIG Storage

Bafathanan
Rawa Shah

SIG Windows

Ratiika Gupta

本节课中，我们一起学习了Kubernetes贡献者峰会的表彰环节。我们看到了项目对核心组织者的衷心感谢，也认识了许多在API Machinery、CLI、集群生命周期、文档、安全、网络等各个特别兴趣小组中辛勤付出的杰出贡献者。正是这些社区成员的共同努力，驱动着Kubernetes项目不断向前发展。

002：CNCF问答环节

在本节课程中，我们将一起回顾2024年Kubernetes北美贡献者峰会上，CNCF（云原生计算基金会）核心成员与社区进行的问答交流。内容涵盖了项目维护、社区发展、活动规划等多个方面，旨在帮助初学者了解CNCF的运作和社区关心的核心议题。

自我介绍

首先，让我们认识一下参与本次问答的CNCF核心成员。

Jeffrey Sica (Gfi)：CNCF项目负责人。自2018年起成为Kubernetes贡献者，并曾负责运营贡献者峰会数年。他的工作是确保CNCF旗下的各个项目顺利运行、感到满意。
Taylor Dolezal：CNCF生态系统负责人。他的工作重点是服务最终用户，即那些将CNCF项目应用于自身业务平台的企业（如Adobe、Apple），了解他们的独特需求。
Angela Brown：Linux基金会活动高级副总裁兼总经理。她的团队负责管理与CNCF项目相关的各类活动，包括KubeCon等大型会议。

核心议题讨论

上一节我们认识了CNCF的团队成员，本节中我们来看看社区提出的具体问题以及官方的回应。

如何修复不同项目间的维护者信息同步问题？

这是一个关于项目治理的基础问题。核心挑战在于“维护者”的定义在不同项目间不统一（例如，有些项目将所有贡献者列为维护者并赋予投票权，而Kubernetes则严格限定），导致CNCF内部在管理权限（如邮件列表、投票权）时遇到困难。

可能的解决方案探讨：

要求每个项目在其社区仓库中维护一个标准化的 YAML 文件来定义维护者。
利用 LFX（Linux基金会身份平台） 来关联GitHub账号和邮箱，从而同步信息，但此方案可能略显笨重。
未来可能引入基于项目成熟度（毕业、孵化、沙箱）的加权投票机制，让像Kubernetes这样的大型项目在集体决策中拥有相应权重。

TOC（技术监督委员会）的任命机制会优化吗？

简短的回答是：是的，有计划。TOC正在讨论优化方案，目标是增加由社区选举产生的TOC成员比例，减少由GB（理事会）直接任命的成员数量。具体方案将由TOC自行公布。

2025年，在支持项目和维护者方面，最令人期待的计划是什么？

团队成员分享了他们关注的重点：

举办维护者峰会：尽管存在不同意见，但这对项目与社区健康有益。
展示社区健康与投资回报率（ROI）：通过数据量化开源项目的价值，帮助企业决策者理解并增加对开源的投入。公式可简单理解为：ROI = (项目产生的价值) / (投入的成本)。
利用LFX洞察数据：更好地获取和分析社区数据，了解不同终端用户的需求差异。
活动拓展与支持：包括将KubeDay Japan升级为KubeCon Japan、继续举办KubeCon China和KubeCon India、并加大对KCD（Kubernetes社区日）的财务与组织支持。

如何让Kubernetes贡献者社区与最终用户（End Users）更好地协作？

与最终用户协作的主要挑战是时间，因为他们主要精力在其主营业务上。以下是改进方向：

降低参与门槛：项目维护者应思考如何更清晰地展示新功能（Alpha/Beta/GA），让终端用户能轻松评估和升级。
加强双向反馈：终端用户团体计划在2025年加强与项目的直接沟通，与TOC合作，建立有效的反馈闭环。
关注重要公告：在KubeCon主题演讲中可能会有相关进展发布。

2025年所有的KubeCon都会举办维护者峰会吗？

是的。但规模会因地区而异。例如，KubeCon India可能只有一个与大会同期举行的单轨峰会，而KubeCon Europe则计划设立包括Kubernetes专属轨道在内的多个轨道。

能否在KubeCon参会者胸牌上直接打印GitHub账号？

可以。这是一个被多次提及的需求。由于欧洲KubeCon的注册尚未开放，可以直接将此需求反馈给活动团队以添加该字段。

是否有计划将CNCF会员资格与为项目提供开发资源绑定？

这个问题已被讨论过，但目前没有具体计划。这属于CNCF理事会（GB）的决策范畴，需要由GB代表提出并投票决定，而非CNCF工作人员能直接推动。

对于考虑申请CNCF沙箱的项目，有指导计划吗？

目前没有正式的导师计划，但正在积极筹备中。

现有支持：

项目可以直接联系CNCF项目团队（如Jeffrey, Daniel, Bob）进行咨询。
TOC计划在未来的维护者峰会和项目展馆中举办研讨会，指导项目如何晋级以及申请沙箱的注意事项。

寻求帮助：如果您有维护者峰会相关的问题，也可以联系峰会主席或在Slack中提问。

如果想在韩国举办KubeCon，如何启动？

举办大型活动需要评估市场需求和财务可持续性。

当前步骤：

市场测试：2025年将在韩国举办一场包含CNCF轨道的开源峰会（Open Source Summit），以测试当地社区的参与度和公司支持意愿。
社区与资金：通常需要本地社区的热情参与以及本地公司（或潜在会员）在赞助、派遣参会者等方面的支持。
已有基础：2025年韩国也将举办KCD（Kubernetes社区日），这是培育本地社区的重要一步。

历史参考：像KubeCon Japan的成立，就离不开本地社区贡献和会员公司的大力支持。

CNCF是否有计划解决项目及Kubernetes中的维护者流失问题？

这是一个复杂的问题，没有单一的解决方案，需要多管齐下。

现有及计划中的举措：

导师计划：如LFX Mentorship、Google Summer of Code，旨在吸引新人。
终端用户引入：举办工作坊，引导终端用户公司的员工参与贡献。
项目自身努力：项目需要审视自身，改善文档、设立“影子”项目等，降低新人参与门槛。
社群支持：建立同期学员社群，让新人在学习过程中能相互支持。
寻求导师：鼓励现有维护者担任导师，这是扩大维护者队伍的关键。
社区重建：CNCF有专员（如George）帮助陷入困境的项目重建社区和成长路径。

数据参考：过去的“新贡献者工作坊”后期效果不佳，部分原因是有人仅为获取免费参会资格而注册。而线上贡献者导向和LFX导师计划数据显示，约40-50%的学员在项目结束后会继续贡献，长期来看有助于培养新的维护者。

开源项目为何总是在经济下行时首当其冲被削减预算？CNCF能做什么？

这确实是一个令人疲惫的循环。核心在于向企业决策者证明开源项目的价值（ROI）。

CNCF的努力方向：

量化与沟通价值：通过收集数据和案例，更有效地向企业传达开源技术的商业价值。
分享成功故事：通过“Humans of Cloud Native”等项目， spotlight展示开源如何改变个人和组织。
提供弹药：鼓励社区分享在内部说服财务团队时遇到的困难，CNCF可以协助提供相应的数据或报告。
互助网络：CNCF内部存在非正式的“职位推荐网络”，会尽力帮助失业的维护者寻找新机会。
利用行业报告：建议参考Linux基金会研究部门（LF Research） 发布的报告，其中包含基于大量调查的数据，可用于内部游说。

总结

本节课中我们一起学习了CNCF在2024年Kubernetes贡献者峰会上与社区交流的核心内容。我们了解到CNCF正在积极应对项目治理、社区增长、活动全球化以及维护者可持续发展等多方面的挑战。关键要点包括：通过标准化和工具（如LFX）改善项目管理；通过数据量化ROI来保障开源投入；通过多元化的活动（KubeCon, KCD）和项目（导师计划、工作坊）来培育全球社区；并始终强调社区成员与CNCF团队保持开放沟通的重要性。对于初学者而言，这是一个了解大型开源基金会如何运作以及社区如何共同解决问题的绝佳窗口。

003：单元、集成与端到端测试的统一框架

在本节课中，我们将探讨 Kubernetes 测试框架的现状，并深入了解一个旨在统一单元测试、集成测试和端到端测试编写体验的新项目：KTesting。我们将分析现有框架的差异，介绍 KTesting 的设计理念与核心功能，并讨论其潜在价值与面临的挑战。

概述：为何需要统一的测试框架？

我的名字是 Patrick Oh。我在英特尔工作，负责 Kubernetes 的多个领域。其中之一是尝试在测试框架方面为 SIG Testing 提供帮助，主要围绕端到端测试。Kubernetes 中还有其他需要维护的测试辅助工具，我是负责这部分 Kubernetes 代码的维护者之一。

我反复问自己的一个问题是：为什么我们没有为 Kubernetes 中的所有测试提供一个统一的框架？我们有单元测试，用于测试底层的独立包。我们有集成测试，处理与 API 服务器交互的事务。我们还有用于完整集群的端到端测试。为什么所有这些测试都使用不同的框架？

历史背景与现状

当我进行一些调查时，我发现了端到端测试框架原作者 Daniel Smith 的一条九年前的评论。他说：“最终目标是将此（端到端框架）与集成测试框架合并。” 然而，自那以后，什么也没有发生。

乍一看，合并是有道理的。因为端到端测试和集成测试非常相似。在这两种情况下，我们都有客户端连接到 API 服务器，进行一些更改，检查预期结果是否发生，然后将其视为测试成功。那么，为什么我们要为编写这些非常相似的测试准备不同的代码片段？我们能为此做些什么吗？是否有技术原因导致此事未完成？或许是因为没有人关心？在这次分享中，我试图与大家一起探讨我们是否可以改变这一现状。

第一个答案很简单：它们之所以不同，是因为历史原因。单元测试和集成测试基于 Go 语言的 go test 基础设施。一个大型的 Go 测试单元也用于集成测试，只是我们有一些启动 API 服务器的样板代码，但归根结底，它是普通的 go test。而对于端到端测试，当时决定需要更复杂的东西，因此引入了 Ginkgo 作为编写端到端测试的框架。

这导致了我们今天仍然面临的情况：对于做同样的事情，我们拥有不同的 API，具体取决于它是集成测试还是端到端测试。因此我的想法是：如果我们为两者提供相同的 API，只是后台实现不同，会怎样？我们能否改变所有辅助包，让它们使用这个通用 API，并在两种场景下工作？KTesting 正是为此而生。它是一个抽象层。

框架对比：Ginkgo 与 Go Test

为了理解 KTesting 需要做什么，我们首先比较 Ginkgo 和 go test。记住，我们讨论的是框架，这可能是一个非常有争议的话题。让我们保持友好，专注于解决问题。

以下是两种框架在关键特性上的对比：

测试注册与发现

两种测试框架都需要一种方式来找出应该测试什么，即哪些测试存在。

Ginkgo：使用 Context 和 It 等 API 调用来分组和定义测试。
Go Test：依赖编译器的内置支持。你只需定义一个以 Test 开头的特定签名的函数。在函数内部，你可以有子测试。

一个相关的区别是，我们可以在 Ginkgo 中标记测试，并广泛使用它来选择测试。在 go test 中我们没有这样的机制。我们只能测试整个包，但无法在特定场景下运行特定测试。

构建与并行性

Ginkgo：一个目录定义整个测试二进制文件，并引入包含测试定义的其他包。最终结果是一个单一的二进制文件。并行性通过多个进程实现，每个进程在任何时候都运行一个测试。
Go Test：必须为每个包分发多个不同的测试二进制文件。并行性通过多个 Goroutine 实现，它们可能并行运行。

日志输出

这对于每个测试的日志记录至关重要。

Ginkgo：标准输出/标准错误中的输出可以被捕获为每个测试的输出。这通过 GinkgoWriter 等 API 实现。
Go Test：标准输出/标准错误在所有当前运行的测试之间共享。我们没有一个内置的机制来获取每个测试的输出。我们有一个自定义的 T.Logf 函数用于每个测试输出，但你必须使用这个特定的调用。

失败报告

报告失败的方式也不同。

Ginkgo：有一个 Fail 调用，接收一个字符串（可以是多行），它被捕获为当前运行测试的失败原因，并立即中止测试。Ginkgo 中没有记录多个测试失败的概念。
Go Test：Error 或 Fatal 与记录某些内容然后中止测试没有太大区别。测试作者有责任确保失败原因在更大的测试输出中显而易见。

超时处理

Ginkgo：非常复杂。可以设置套件超时、每个测试的超时。运行的测试会获得一个关联了超时的 context.Context。
Go Test：我们基本上必须自己编写超时逻辑。我们可以获得每个套件的超时，但如果超时触发，它会终止整个进程。

延迟清理

Ginkgo：有 DeferCleanup。即使测试本身失败，它也能确保清理代码运行，并且清理操作有独立的超时。
Go Test：有 T.Cleanup API。但重要的区别是，如果套件超时或手动中止，它不会运行。

其他特性

两者都支持特性，但 API 不同：

堆栈跟踪：Ginkgo 将堆栈跟踪附加到失败信息中；go test 你只得到一行。
标记辅助函数：两者都允许将辅助函数标记为 Helper，以便在回溯堆栈时跳过它们。
进度报告（Ginkgo 特有）：一个非常有用的功能。如果你向端到端测试二进制文件发送 SIGUSR1 信号，它将触发进度报告，显示当前正在运行的测试、它在轮询什么等信息。这对于本地调试非常有用。

引入 KTesting

上一节我们比较了现有框架的差异，本节我们来看看旨在统一这些差异的解决方案：KTesting。

KTesting 最初是为了解决每个测试的日志记录问题而开始的。作为 SIG Instrumentation 中上下文日志记录工作的一部分，其价值主张之一是我们可以拥有一个与上下文关联的记录器。在集成测试的上下文中，当 klog 查看该上下文时，它会提取记录器，并且该记录器可以通过我之前介绍的 T.Logf 函数输出。

KTesting 正是这样做的。它实现了一个记录器，接收我们在 Kubernetes 中进行的正常日志调用，并以更接近 klog 的格式输出。它旨在相当灵活，但你必须自己设置和配置命令行参数。

在 Kubernetes 内部，我们在 kubernetes/test/utils/ktesting 下有一个更“固执己见”的变体。它自动添加了常见的 -v、-vmodule 命令行标志。另一个好处是它修改了 Gomega 如何格式化对象，使其输出更易读。

KTesting 的统一 API

KTesting 有趣的部分在于它如何扩展以实现统一的 API。这部分更具实验性。

我设定的目标是：

编写一个辅助包和抽象 API，以便我们可以在端到端测试和集成测试中重用所有其他代码。
为集成测试实现 Ginkgo 中已有的进度报告、超时处理等优秀功能。

我不想改变测试的注册方式。集成测试将继续使用 go test，端到端测试将继续使用 Ginkgo。我们只是为编写测试逻辑提供一个统一的抽象层。

当前状态是，对于集成测试，这些功能已经合并到 Kubernetes 中。对于 Ginkgo，有一个待处理的 PR。

核心概念：TContext 接口

KTesting 统一 API 的核心是 TContext 接口。我对此感到恼火，因为当我处理一个集成测试时，我不得不通过多层函数传递 4 或 5 个参数，最终才能做某事。这促使我决定需要一个单一的测试上下文参数来代表所有这些事物。

TContext 是一个抽象接口。它同时实现了 context.Context 接口和类似于 Go 定义的 testing.T 接口的东西。你可以在测试开始时通过调用 ktesting.Init 设置它一次。然后，你可以像使用 testing.T 实例一样使用它，也可以从中获取记录器、进行上下文日志记录等。

它抽象了清理操作，结合了 Ginkgo 的 DeferCleanup 和 Go 的 T.Cleanup。你获得一个新的、专为清理操作构建的上下文，并具有关联的超时。

它还为集成测试添加了信号处理。如果你中止测试，KTesting 会捕获它，取消当前正在进行的上下文，但仍会运行清理，不会留下混乱。

对于超时，它考虑了 testing.T 中的截止时间，并自动取消。如果测试返回，它会自动取消该上下文。

在输出方面，除了每个测试的日志记录，我还试图让失败原因更明显。例如，调用 Error 时会添加一个错误前缀。

关于断言，KTesting 的一个决定是它不打算取代 Testify 或 Gomega。它只内置了一个断言函数：ExpectNoError，因为这在我们的整个代码库中太常见了。

进度报告也已实现。它使用与 Ginkgo 相同的 SIGUSR1 信号。如果你在集成测试中使用 Gomega 的 Eventually，它会给你相同的信息。

讨论：挑战与未来方向

我们已经介绍了 KTesting 的技术实现，本节我们来探讨围绕它的一些讨论、挑战以及可能的未来发展路径。

设计决策与不确定性

有些概念我还不确定。例如 WithStep，它用于检测你的源代码，以便你知道测试的执行路径。这需要测试作者主动使用，他们可能会忘记。我的想法是，这很有用，因为当失败发生在调用链深处时，你会确切知道是如何到达那里的。

另一个讨论点是错误处理模式。传统上，我们编写通用的、可重用的函数，这些函数返回一个错误，然后在顶层的测试中检查错误。但有了 KTesting，我们可以在底层（在辅助函数内部）直接中止，因为 KTesting 可以创建一个记录失败但不立即中止的测试上下文，然后调用者可以检查是否记录了任何失败。这是一种不同的编写测试的方式，我不确定哪种更好。

潜在优势与实施顾虑

如果我们就此向前推进，我们可以做几件事：

减少重叠代码：为创建对象、等待 Pod 等常见操作提供一个统一的辅助包，减少 Kubernetes 中的整体代码量。
将 KTesting 移至 staging 仓库：目前它位于内部包中，无法被 staging 仓库中的集成测试使用。移至 staging 意味着更强烈的维护承诺。
改善开发者体验：统一的 API 和良好的辅助包将使为 Kubernetes 编写新功能测试的新贡献者更容易上手。

然而，也存在反对这样做的理由：

代码变动：重写现有测试会引入风险，可能会在未注意到的情况下破坏测试。
维护负担：就像修复 Lint 问题一样，大规模重写测试的审查成本和潜在风险可能超过其收益。现有的测试是有效的，重写它们更多是“锦上添花”而非必需。
采用与教育：需要确保所有 SIG 的评审者和批准者都理解并执行新的测试编写规则，否则新贡献者可能会复制旧的模式。

扩展功能设想

我们可以基于 KTesting 构建更强大的辅助功能，例如：

从 YAML 创建对象：这是非常常见的操作。
测试失败时的对象转储：在清理过程中，将相关对象（如 Pod、节点状态）转储到日志文件，以便于调试。
事件收集：连接和收集事件。
快照测试：这可能有助于迁移旧测试，通过比较快照来确保行为不变。

要实现这些，很可能需要成立一个包含不同用户的工作组，而不仅仅是 SIG Testing 内部的项目，以确保其设计能满足广泛需求并被采纳。

总结与行动呼吁

本节课中，我们一起探讨了 Kubernetes 中测试框架割裂的历史与现状，深入了解了旨在提供统一 API 的 KTesting 项目。我们比较了 Ginkgo 和 go test 的差异，介绍了 KTesting 的核心设计——特别是 TContext 接口，并讨论了统一测试框架带来的潜在好处（如代码复用、体验改善）与面临的挑战（如代码变动、教育成本）。

KTesting 在集成测试方面的一些改进（如上下文日志记录、更好的输出）已经可用。是否要更广泛地推进统一 API 和重写辅助包，需要社区更广泛的讨论和共识。

如果你对此感兴趣并愿意参与，请通过 Slack 或电子邮件联系我。我需要与 SIG Testing 沟通，获得他们的支持。如果有足够的鼓励和帮助，我可以尝试推动建立相关的工作组或合作机制。最终目标是让编写 Kubernetes 测试对所有人来说都变得更好、更简单。

004：在 Kubernetes 中实现事务

概述

在本节课中，我们将探讨为何当前的 Kubernetes 架构难以支持事务和批量写入操作。我们将从 Kubernetes 的核心协议——List-Watch 协议入手，分析其设计约束，并讨论这些约束如何阻碍了事务功能的实现。最后，我们会探索一些潜在的解决方案和变通方法。

历史背景与协议约束

上一节我们介绍了课程主题，本节中我们来看看 Kubernetes 独特的设计背景。Kubernetes 与大多数数据库或存储系统不同，它优化了控制器查看和响应集群状态的能力。这导致了独特的访问模式，需要使用不同的协议，即 List-Watch 协议。

该协议的核心是，控制器无需持续列出（List）资源来感知变化，而是可以先获取当前状态快照，然后订阅（Watch）后续的所有变更历史。这个设计对系统能力施加了许多约束。

让我们具体看看 Watch 协议。在 Kubernetes 中，Watch 总是从一个 List 请求开始。你可以请求单个对象、某个命名空间或整个资源类型。响应中将包含一个状态快照，以及一个附加的资源版本。

这个资源版本代表了生成响应时最新的数据版本。随后，你可以使用这个资源版本来开启一个 Watch 流，接收一系列事件（创建、更新、删除等），每个事件也会附带一个资源版本，以便你了解进度。

出于性能考虑，Kubernetes 支持所谓的“书签”事件，它可以在没有实际变更时提供进度更新，这样在连接中断后，你不必从头开始重新同步。

这个协议本身并不复杂，也非 Kubernetes 独有。例如，在 etcd 中，其工作方式有细微差别：

使用 Range 请求替代 List，这要求 Kubernetes 中所有可列出的对象必须处于一个连续的键范围内。
返回的是 revision 而非 resource version，Kubernetes 的 resource version 与 etcd 的 revision 是一一映射的。
Watch 响应可以包含多个事件的批次，而 Kubernetes 每个响应只包含一个事件。
使用进度通知而非书签。

以下是两者在批处理支持上的关键差异：

在 etcd 中，它完全支持多对象事务。你可以一次性更新多个对象（如果支持子键，甚至可以是同一个对象的不同部分），并将它们作为一个原子事务提交到磁盘，从而获得成倍的吞吐量提升。其 Watch 响应可以包含共享同一 revision 的多个对象变更。

然而，在 Kubernetes 中，不存在原子性。虽然它提供了一些批处理支持（如删除集合），但这只是一个“承诺”或“假象”，底层实际上是通过多个独立的事务处理的。Kubernetes 的批处理操作会产生多个拥有不同资源版本的对象。

为何 Kubernetes Watch 协议排斥原子批处理

上一节我们对比了协议差异，本节中我们来看看这为何成为实现事务的根本障碍。关键在于 Kubernetes Watch 事件的格式。

在 Kubernetes 中，每个 Watch 事件只能包含一个对象。这一点并非广为人知，但它直接导致我们无法让多个对象共享同一个资源版本，否则会破坏协议的有效性。

我们可以通过反证法来证明这一点：

假设：我们可以让多个对象共享同一个资源版本（即实现了原子批写入）。
场景：有 5 个对象在一次批处理中被创建，它们共享同一个 RV。一个控制器正在通过 Watch 流观察这些事件。
问题：控制器收到了第一个对象的创建事件，然后网络连接断开。
协议行为：根据协议，控制器会使用最后观察到的 RV 重新初始化 Watch。API 服务器内部会将这个 RV 解析并加 1，然后从新的位置开始推送事件。
矛盾：由于 5 个对象共享同一个 RV，API 服务器加 1 后，会直接跳过剩下的 4 个对象。控制器将永远无法观察到它们，导致状态不一致，协议失效。

因此，最初的假设不成立。Kubernetes 在设计 Watch 事件时，将其限制为单个对象，这在标准 API 设计中可能是一个失误（本应使用列表结构），导致我们现在被“卡住”了。

探索潜在的解决方案：操作资源版本

既然无法轻易改变协议，我们能否找到一些“漏洞”或变通方法呢？本节中我们来看看资源版本这个关键字段的潜力。

官方的立场是：资源版本应该被视为不透明的字符串。客户端不应假设其格式或顺序，只需将它最后看到的 RV 原样传回即可。这为我们在底层进行修改留下了空间。

实际上，RV 目前是 etcd revision 的直通，是一个 64 位整数。在 etcd 中，客户端负责递增 revision。Kubernetes 社区将其声明为“不透明”，正是为了保留未来安全地修改其格式的权利。

那么，我们可以如何修改 RV 来支持批处理呢？以下是一些设想：

添加批次索引：给定一个基础 RV，我们可以为批处理中的每个对象附加一个索引。
- 公式：RV_final = BaseRV + Index
- 这样，每个对象都有唯一的 RV，避免了“加 1 跳过”的问题。
位分割：将 RV 的二进制位分割，一部分存储基础版本，一部分存储索引。
- 公式：RV_final = (BaseRV << N) | Index
- 同样能保证唯一性和顺序。
结构化字符串：采用更灵活的、版本化的字符串格式。
- 代码示例："v2:<base_revision>:<index>:<checksum>"
- 这为未来添加更多元数据提供了扩展性。

引入新 RV 格式的挑战：

需要非常谨慎地引入，因为会存在新旧两种 RV 格式。
可以采用渐进式方案：在多个 Kubernetes 版本中同时支持读取新旧格式，然后逐步切换到只写入新格式。

然而，仅仅修改 RV 格式并不足以实现 10 倍的写入吞吐量提升，因为我们仍然在写入完整的对象数据。要获得显著性能提升，可能还需要考虑将对象的 spec、status 和 metadata 作为独立部分存储到 etcd 中。

总结与问答环节

本节课中我们一起学习了 Kubernetes 难以实现事务和原子批处理的核心原因。根本障碍在于 List-Watch 协议中每个事件只包含单个对象的设计，这导致多个对象无法共享同一资源版本，从而无法实现原子性。

我们探讨了通过修改“不透明”的资源版本格式来绕过此限制的可能性，例如添加批次索引。但这仅是解决方案的一部分，要大幅提升写入吞吐量，可能还需要结合对象数据拆分等优化。

核心结论：Kubernetes 目前可能不需要完整的事务支持，但批量写入无疑是未来值得追求的特性。

听众问答精选

以下是现场听众提出的一些问题及讲者的回答：

问题1：你提到的批量写入需求，主要是为了优化控制器同时创建大量 Pod 的场景吗？

这涉及两个方面：一是原子性需求，确保一组操作要么全部成功要么全部失败；二是提升吞吐量。要提升吞吐量，就需要减小写入对象的大小，并能够批量写入。此外，我们可能还需要更高效的 Watch 响应，例如流式传输差异而非完整对象。

问题2：能否将 RV 的灵活字符串格式用作向量时钟，以聚合多个 API 服务器的响应？

你描述的场景更像一个构建在 Kubernetes 之上的多集群概念或读穿透代理。这可能需要专门的控制器来实现，并非 Kubernetes 内部直接支持的功能。

问题3：如果我们不把 RV 声明为不透明字符串，而是明确它是一个整数，会不会让事情更简单？

如果 RV 是明确的整数，我们就失去了灵活修改它的能力，会被完全绑定到 etcd 的全局 revision 上。将其声明为不透明字符串的初衷，正是为了保留这种未来变更的灵活性。对于像存储版本迁移器这类我们完全控制代码的内部组件，我们可以处理更结构化的 RV。

问题4：为什么 API 服务器内部一定要对 RV “加 1”？为什么不直接使用给定的 RV，即使可能返回重复事件，至少能保证不跳过任何事件？

这涉及到协议保证。当前协议保证 Watch 流中没有重复事件。如果取消“加 1”逻辑，允许返回重复 RV，那么每个客户端都必须自己处理去重，这相当于改变了协议约定。要求每个客户端都实现去重逻辑，可能比在服务器端维持“加 1”逻辑更复杂且容易出错。可以说，最初保证“无重复”本身可能就是一个设计上的权衡。

005：Kubernetes 流式 API 深度解析 🚀

在本节课中，我们将深入探讨 Kubernetes 中的流式 API。我们将了解它们是什么、为什么需要它们、它们与标准 HTTP REST API 的区别，以及 Kubernetes 社区如何从传统的 SPDY 协议迁移到更现代的 WebSocket 协议。通过具体的命令演示和原理剖析，你将理解 kubectl exec 和 kubectl port-forward 等命令背后的工作机制。

我是 Sean Sullivan。

我们直接进入演示环节，通过 kubectl port-forward 和 kubectl exec 命令来展示核心内容。

演示环节

首先，我将展示客户端和服务器的版本信息，以及集群中运行的工作负载，以便了解这个特定集群的配置情况。我们的集群中运行着一个 Nginx 工作负载。

我们将查看的第一个命令是 kubectl port-forward。

当我们运行 kubectl port-forward 命令时，我们正在客户端和集群内的 Nginx 之间创建一个长久的流式连接。通过这个命令，我们将指定本地端口以及 Nginx 在集群内监听的端口。

我将以详细模式运行此命令，以便查看此命令的请求头信息。你可以看到，我们指定了感兴趣的特定子协议。客户端请求的协议是 portforward.k8s.io。然后，将与 Nginx 进程进行握手，以确定双方同意的具体子协议。如果成功，服务器将返回 101 Switching Protocols。现在，我们的本地客户端与集群中运行的 Nginx 进程之间就建立了一个长久的流式连接。

在另一个终端中，我们将运行一个 curl 命令来请求 Nginx 的主页。我们通过访问本地端口 8080 来实现，该请求将通过刚才建立的流式连接转发到 Nginx。你可以看到，我们成功从 Nginx 获取了主页。

接下来，我们继续看 exec 命令。我们先做一个非常简单的示例：在 Nginx 进程上运行 date 命令。

我设置了详细级别为 7，这样我们就能再次看到大量的头信息。这里需要指出的不仅是端点，我们还可以通过查询参数指定要运行的命令、目标容器以及我们需要的通道（标准输出和标准错误）。在请求头中，我们声明支持多个版本的子协议（这是远程命令子协议，稍后会详细说明）。响应是 101 Switching Protocols。很好，你可以在最后看到返回的标准输出中显示了日期。

下面是一个更复杂的示例，展示当我们创建这个流式命令时，可以通过标准输入通道发送数据，并在标准输出通道接收数据。我们将通过标准输入通道发送 50 MB 的 kubectl 二进制文件，在 Nginx 端简单地 cat 它，然后通过标准输出通道发送回来，最后重定向到一个临时文件中。我们将验证这个庞大的数据块是否原样返回。

现在，我们正在查看这个 kubectl exec 命令。我们必须使用 -i 标志，因为我们使用了标准输入通道，并将其输出重定向到临时目录下的 kubectl 文件。操作完成后，让我们检查一下接收到的文件，它看起来大小相同。我们再用 diff 命令确认一下发送给 Nginx 并接收回来的数据是否完全相同，结果确实相同。

最后，让我们执行一个 shell。这是一个非常有用的调试工具，我们可以通过它跳转到 Nginx Pod 本身。当我们运行 bash 时，我以什么身份运行？我是 root。我可以在那里查看错误日志、访问日志，并进行各种检查。这是一个非常有用的调试工具。

流式 API 的本质

那么，是什么让这些特定的 API 与众不同？我们刚才看到的这两个命令是流式命令。这意味着什么？它与 HTTP 有何不同？

我们大多数人都知道 Kubernetes 暴露了一个 HTTP REST API。但有些人可能不太熟悉的是，实际上有一小部分 API 最终会升级为流式连接。我们刚刚就练习了其中的几个命令。

我们都非常熟悉 HTTP。但为什么我们需要流式命令？基本上是因为 HTTP 作为一种请求-响应协议，其固有的缺陷不足以满足我们在集群中与特定工作负载上的 shell 进行交互的需求。

以下是流式协议或流式动态的一些特性，这些特性使得它在某些情况下比 HTTP REST 更有用：

低延迟与低带宽：对于 HTTP，每个请求和响应都可能带有显著的开销头信息。而在流式协议中，我们通常用很少的元数据对二进制数据进行帧封装。
双向性与任意端点发起：在流式连接中，任何一端都可以发起数据消息的传输，并且通信是双向的。

我认为最能说明这些流式 API 必要性的例子就是与容器内 shell 的交互。如果必须通过请求和响应的方式来实现这种交互，那将是不可能的。

如何建立流式连接？

我们从一个 HTTP 请求开始。这是一个尝试执行 exec 时的请求简化版。

我们有几个额外的请求头。我们会声明希望升级连接，并且我们的流式协议将是 spdy/3.1。这些是此客户端支持的特定子协议，并且是优先级顺序（例如，v4 表示我们优先选择 v4 而非 v3）。稍后我会解释什么是子协议。

握手成功后，HTTP 响应将返回 101 Switching Protocols，表示升级成功。我们发送的两个特定头信息会原样返回给我们，同时还有协商好的子协议（在这个例子中是远程命令的 v4 版本）。

什么是子协议？

子协议定义了流式消息负载中的内容。它们是版本化的。Kubernetes 定义了两个子协议：

远程命令：用于以下三个命令：kubectl exec、kubectl cp 和 kubectl attach。kubectl cp 实际上是通过 exec 端点实现的，因此它与 exec 类似。attach 是附加到一个正在运行的进程。这三个命令都利用完全相同的远程命令协议，最新版本是 v5。
端口转发：支持 kubectl port-forward 命令，最新版本是 v2。

那么，我们的远程命令子协议里具体有什么？我们正在多路复用多达五个数据通道：

标准输入、标准输出和标准错误：这很直接，要与集群中的命令交互，我们需要这三个通道。
终端调整大小事件：在后续版本中添加，用于处理 TTY 大小变化。
错误通道：在后续版本中添加，允许我们获取进程的退出代码。

这些数据通道都通过同一个已建立的流式连接进行传输，在该连接上多路复用，然后在另一端解复用，并连接到容器运行时中的进程。

对于端口转发，有一点需要在此说明：在我们的远程命令示例中，子协议里的通道数量是静态的。最多可以是 5 个，但一旦在开始时协商好，数量就固定不变，不是动态的。而对于端口转发子协议，通道数量是动态的。当我们运行 kubectl port-forward 命令建立长连接后，可能在其他终端发起 curl 连接。每个这样的转发命令都会有两个通道：一个数据通道和一个错误通道。这些并发通道的数量可以是无限的（显然受资源限制）。如果我们同时运行 1000 个 curl 命令，那么就会有 2000 个通道。这实际上带来了一些挑战，也促使我们最终为 WebSocket 协议采用了不同的处理方式，这一点我稍后会讲到。

流式连接的端到端路径

这张图旨在说明这些流式连接（流式 API）的端到端特性。它们实际上涉及集群中的许多组件：

从客户端（通常是 kubectl）开始。
客户端与 API 服务器通信，API 服务器通常只是代理这个特定的请求和升级。
API 服务器将请求代理到目标节点上的 Kubelet。
Kubelet 然后通过容器运行时接口 代理到容器运行时本身。

因此，我们从客户端开始，经过 API 服务器，到达特定节点上的 Kubelet，然后在节点上通过 Unix 套接字与容器运行时通信。当我们讨论流式 API 时，会涉及相当多的组件。

为什么我们现在要讨论这个？

这些流式 API 已经存在多年，为什么我们现在要讨论它们？因为我们最近刚刚将流式协议从 SPDY 迁移到了 WebSocket。

从 Kubernetes 1.31 版本开始，根据 KEP-4006 的定义，上述四个命令的默认流式协议现在将是 WebSocket。如果服务器或容器运行时不支持 WebSocket，它将回退到 SPDY。但默认情况下，我们将尝试建立 WebSocket 连接升级。

为什么要进行这次迁移？

这是一项相当庞大的工程，实际上始于多年前，我们最近才达到可以发布的状态。原因如下：

SPDY 已被弃用超过八年，并且从未成为标准。这导致即使我们控制了集群内的所有元素，客户端和 API 服务器之间也可能存在一些中间件（如网关、代理、负载均衡器）不理解这个过时的协议。
因此，任何使用网关的用户都可能需要使用更现代的流式协议，即 WebSocket。

然而，需要注意的是，我们只修改了从客户端到 API 服务器这一段的流式协议。我们为这两个子协议在 API 服务器中实现了代理，用于在 WebSocket 和 SPDY 之间进行转换或隧道传输。

对于远程命令，有一个流式转换器代理。
对于端口转发，由于存在动态数量的通道，为了避免拖垮 API 服务器，我们的设计需要一个隧道代理。

因此，SPDY 在集群内部仍然是通信协议。我们这样做是因为我们见过类似的动态：如果我们更改了容器运行时的协议，就必须修复所有容器运行时的实现，而历史上这曾多次失败。我们决定，如果只改变客户端到 API 服务器这一段，就能获得 99% 的收益，同时保持集群其余部分的工作方式不变。我们确实打算最终将 WebSocket 协议贯穿整个系统，但目前从客户端到 API 服务器这一段是第一步。

这张更新后的图展示了集群现在的样子，API 服务器内部的紫色部分代表了转换或隧道代理，它们将 WebSocket 转换回集群内部使用的 SPDY。

总结与资源

本节课中，我们一起学习了 Kubernetes 流式 API 的核心概念。我们了解了它们为何对于 kubectl exec 和 kubectl port-forward 等交互式命令至关重要，探讨了其双向、低开销的特性，并追溯了从 SPDY 协议迁移到 WebSocket 协议的技术演进与原因。关键点在于，这次迁移主要改善了客户端到 API 服务器之间的兼容性与现代性，而集群内部通信仍暂时保持 SPDY 以确保稳定性。

以下是一些非常有用的资源链接，如果你计划更深入地研究这个主题：

我特别想指出 Sasha Grentu 的一篇博客文章，它深入探讨了我简略提及的节点上的流式处理部分，即 Kubelet 通过容器运行时到容器之间的过程。这个过程相当复杂。
如果你真的对与节点本身相关的流式处理感兴趣，并想了解更多，Sasha 写的另一篇关于“容器运行时接口流式处理详解”的博客文章会非常有用。

看起来我们还剩大约五分钟时间。有什么问题吗？

问：我可能有个简单的问题，关于我想尝试做的事情。流式处理如何涵盖 watch？或者至少 watch 的状态。它们有何不同？
答：watch 与我们现在讨论的流式 API 无关。watch 更像是一种 HTTP 流，我们不使用 SPDY 或 WebSocket 来实现 watch。它是一个完全不同的实现，因为它是单向流而不是双向流。HTTP 确实支持流式传输，但它仍然在请求-响应的总体范式内。因此它适用于 HTTP。而如果你要与容器内的 shell 交互，那就不适合请求-响应模式，它需要双向连接。实际上，我对 watch 不是专家。watch 仍然是 HTTP，对吗？我们并没有使用……（讨论转向关于实现强一致性缓存可能需要双向流式协议，以及这可能需要像 WebSocket 这样的现代协议，而不是 SPDY）。

问：我关心的是从一个 Kubernetes 集群版本升级到另一个版本。如果我当前是 1.30 或 1.31，这个变更会强制我重新安装和迁移吗？还是可以原地升级？
答：这是个很好的问题。这对你来说应该是透明的。你可能有一个旧的 kubectl 客户端，它不会请求 WebSocket 升级，而是请求之前的 SPDY 升级，这一切都将继续工作。另一种版本偏差可能是你有一个较新的 kubectl 客户端和一个较旧的服务器。如果服务器不理解 WebSocket，客户端将回退到 SPDY。因此，升级应该是可行的。如果你有 1.30 的客户端和 1.31 的服务器，或者两者都是 1.31，那么它们都会使用 WebSocket。作为集群操作员或 kubectl 用户，你不需要做任何额外的事情。谢谢。

问：我有一个关于 TTY 调整大小通道的深入问题。为什么在远程命令中我们需要它？
答：这是因为最后一个运行 shell 的例子。如果你的客户端上的 shell 改变了大小，你可能需要将这个信息传达给进程，因为它认为自己有一个特定的终端尺寸。是的，这是一个深入的问题。这是在远程命令协议 v4 中引入的。而 v5 是我们刚刚引入的版本，我们必须引入它是因为在服务器端，我们没有正确处理标准输入。没有半关闭信号来表明标准输入通道已结束，因此会导致挂起。我们最近实现了这个半关闭信号，以表明标准输入何时完成。

006：为什么贡献如此困难？🚀

在本节课中，我们将探讨向Kubernetes项目贡献代码时面临的挑战。我们将分析当前贡献流程中的主要问题，特别是围绕CRD（自定义资源定义）和增强提案流程的难点，并讨论一些潜在的改进方向。

问题根源：扩展性的困境

上一节我们介绍了本次讨论的背景，本节中我们来看看核心问题。我们认为，Kubernetes当前面临的根本问题在于，项目在交付其所需的扩展性方面遇到了困难。

需要明确的是，这是一个普遍的计算问题，并非Kubernetes独有。目前，即使是官方功能也倾向于使用CRD来实现，而非直接集成到核心代码中。例如，Gateway API、网络策略和多网络项目都是SIG-Network内部使用CRD构建的示例。

然而，CRD目前并非一等公民的体验。它们存在技术挑战，包括生命周期管理、版本控制和升级等问题。更严重的是，管理这些CRD的责任长期以来主要落在了集群操作员身上，在最坏的情况下，甚至落在了本不应处理这些问题的最终用户身上。

作为一个项目，我们尚未能提供必要的支持和指导来妥善处理这些问题。尽管如此，对于大多数贡献者来说，使用CRD仍然是主要的、甚至是唯一的可行路径。而如果你想直接向核心代码贡献，这个过程将异常艰难且耗时漫长，对于社区新成员尤其如此。

即使你成功走完了流程，你所构建的功能也可能需要数年时间才能在集群中可用，这段时间足以让贡献者不再从事相关工作或更换工作。最终，我们看到项目，特别是通过扩展性，并未真正满足社区的需求，而社区又迫切希望实质性地参与Kubernetes的建设。

CRD API面临的具体挑战

上一节我们概述了扩展性的宏观问题，本节中我们来看看CRD API面临的具体技术和管理难题。

平台本身对管理CRD API只提供了非常有限的支持。这导致最终用户往往需要自行安装依赖CRD的项目，使得平台和用户陷入了一种“CRD的狂野西部”状态。用户可能知道需要使用某个依赖这些API的项目，但无法保证其使用的平台会支持它。

这使得项目难以依赖扩展API，进而导致用户难以依赖这些项目。另一个问题是，当多个项目尝试使用同一个扩展API时，会产生大量摩擦。例如，Linkerd和Traefik这两个CNCF项目都曾尝试使用Gateway API。由于它们无法依赖平台来处理此事，两者都尝试随项目一起发布所需的Gateway API CRD，并且发布了不兼容的版本。

这曾导致用户需要手动修改Traefik的Helm chart才能解决问题。更复杂的情况是，假设你决定不再运行Traefik和Linkerd，转而使用Envoy Gateway和Istio。当你卸载Traefik和Linkerd时，是否应该同时卸载Gateway API的CRD？如果卸载，API服务器将静默地删除基于这些CRD的所有资源，而不会发出警告或确认，这可能会破坏集群中所有用户的环境。

类似的情况也出现在平台层面，各平台不得不重复投入大量精力来管理这些CRD，有时还会被旧版本卡住。此外，实验性功能的支持也存在问题。设计和实现API的最佳方式之一是通过实验和反馈，但Kubernetes对破坏性变更的支持并不完善。

官方推荐的破坏性变更方法是使用CRD转换Webhook，但包括SIG API Machinery在内的各方都建议不要使用转换Webhook。这导致我们陷入了一种推荐的设计范式：必须成为完美的API设计者，并且永远不要更改任何东西。

增强提案流程的现状与挑战

上一节我们讨论了CRD的技术债，本节中我们来看看贡献流程本身——增强提案流程。

增强提案流程（不仅指KEP，也包括Gateway API使用的GEP等）以缓慢和痛苦著称。流程中包含大量复杂的文档和晦涩的规则，实际走完流程可能令人生畏，对于新成员更是如此。

我们对KEP进行了一些数据分析。目前，被放弃的KEP数量似乎超过了已稳定或已被拒绝的KEP数量。在这里，“放弃”意味着至少一年内看不到任何进展。将一个KEP推进到稳定状态平均需要大约一年半甚至更长时间。

有趣的是，被放弃的KEP所花费的时间似乎并不少太多，这意味着即使是将一个KEP推进到放弃状态，似乎也需要付出巨大的努力，而且最终也没有人正式宣布“我们不再研究这个了”。

当然，我们必须提到动态资源分配（DRA）。这是一个有趣的例外，它是一个试图影响核心的扩展机制，在某些情况下也会与CRD产生纠葛。人们可能认为，由于DRA需要同时触及这两个领域，它会遭受双重困难，但实际情况似乎并非如此。尽管围绕DRA流程存在一些质疑，但它实际上证明了事情是可以做成的。

子项目中的困境实例

上一节我们审视了核心流程，本节中我们来看看在具体子项目中，这些挑战是如何体现的。

我们讨论的许多问题都源于我们在Gateway API工作中的经验。然而，我们也参与并积极投身于其他遇到类似困难的子项目。

例如，SIG-Network中的多网络项目（旨在让一个Pod拥有多个网络）在通过KEP流程方面举步维艰，其KEP在近乎被放弃的状态下停留了大约两年。该项目已决定尝试另一条路线——使用CRD，但在这方面也遇到了一些困难。会议仍在进行，项目仍在推进，但过程充满挑战。

去年年底到今年，有一个名为Kubernetes网络接口（KNI，或称Kubernetes网络重构）的项目。它最初试图向Kubernetes添加原生网络API。它也经历了类似的痛苦，无法通过KEP流程，最终项目虽然没有被放弃，但基本上处于暂停状态。

此外，还有Kubernetes网络策略工作组（NPWG）。尽管其名称如此，但它并非Kubernetes内部的官方工作组，尽管它已经存在了七年。它之所以保持在外，部分原因正是由于在Kubernetes中贡献和进行实验所面临的这些挑战。在外面操作更容易。

最后，不得不提的是Kube-Proxy下一代（KPNG）项目。这个项目对我个人意义重大，我在其中结交了许多朋友，也获得了许多灵感。不幸的是，由于贡献问题和其中的摩擦，这个社区逐渐消散了。能量并未完全消失，一些人将精力转移到了SIG-Network的其他地方，但这并不是一个圆满的结局。它成为了SIG-Network第一个正式关闭的子项目。

潜在的解决方案与改进方向

上一节我们看到了问题在各个层面的体现，本节中我们来看看一些潜在的解决思路。

我们将针对之前讨论的领域（如CRD、增强流程等）来探讨解决方案。让我们从CRD开始。

一个显而易见的起点是：在CRD流程中，我们可以尝试做一件激进的事情——教导人们什么做法是有效的，以及更重要的是，什么做法是无效的。这样，当一个新项目尝试使用扩展API和CRD流程时，就不必从零开始。这项工作正在进行中，SIG-Network内部正在制定《API扩展最佳实践指南》。

另一件可以为CRD做的事情是改进CRD验证。这不是指应用CRD时发生的验证，而是指我们很容易对新的CRD版本做出会破坏现有对象的更改。我们可以自动检查这类问题，也可以自动化其他检查，以便在更改新版本的定义时，提前发现错误，避免伤害用户。

此外，OpenShift CRD模式检查器正在进行相关工作，SIG API Machinery正在考虑将其作为API服务器的插件。另外，我们认为应该做的事情是：生态系统中有Go之外的其他语言。当我们定义CRD时，通常将其定义为Go结构体，这意味着其中包含一些惯用法。对于使用Rust等其他语言的开发者来说，如果能不必从Go反向推导这些惯用法就能有效使用CRD，那将是非常好的。

构建更好的平台管理与社区流程

上一节我们探讨了CRD的技术改进，本节中我们来看看如何在平台管理和社区流程层面进行优化。

我们需要为平台提供一种有效的方式来管理扩展。目前，这取决于集群操作员，或者更糟的情况下，取决于用户。他们可能需要进行升级和管理，在最坏的情况下，还需要决定是否删除CRD。我们希望情况不是这样。

我们认为，最终需要为平台提供一种标准且一致的方式来为其用户管理这些扩展API。这将让用户能够以与核心API相同的方式依赖扩展API。重要的警告是：我们需要确保保护开发者进行实验的能力。因此，无论我们最终做什么，都需要为此创造一个安全的空间。

总结一下，鉴于我们拥有官方的扩展API（例如Gateway API就是一个官方API），我们实际上应该将它们视为官方的。我们应该托管它们、编目它们、验证它们并测试它们。也许我们可以有一个“Kubernetes扩展”目录，平台构建者可以基于此构建工具，用户在不同平台间获得一致的体验，项目也知道这些事物是如何构建的。

CRD是我们今天试图交付内容的方式，因为这是目前向Kubernetes贡献的最佳途径。但增强流程仍然需要一些精简。即使对于最终要交付的CRD，我们仍然需要走增强流程。不幸的是，增强流程就是文档，因此改进它要从文档开始。

我们正在制定API扩展最佳实践指南，SIG-Network的相关工作旨在为新人尽可能简化流程。但最终，我们需要作为一个社区，直接教导人们如何有效地入门，并为他们取得成功做好准备。这可能不仅仅是一堵文档墙，而是需要通过社区会议或Slack等方式进行口头交流。

总结：以人为本，共同改变

在Gateway API中，我们一直在口头分享一个关于“倡导者、盟友和引导者”的概念。这基本上是将人置于流程之前。其核心理念是：不要用“去读文档吧”之类的话淹没新人，而是告诉他们一个框架，让他们可以尝试看看是否能构建一个增强功能。

倡导者是推动事物前进的角色，可以不止一人。盟友是支持它的利益相关者，他们可能不像倡导者那样冲在前面，但最终他们是任何成果的有意义的贡献者。引导者是维护者，他们需要帮助你达到目标，最终让你弄清楚所有文档，但这不应成为你入门的障碍。

如果你能做到这一点并找到盟友，你就会找到前进的道路。重要的是，如果你尝试这个过程，或者你主动联系却找不到任何人，这可能意味着现在不是推进那个增强功能的好时机，这本身也是一种有价值的反馈。

我们讨论的所有内容都是容易的部分。困难的部分是改变社区对扩展性的关注，使其成为优先事项。这需要我们所有人的共同努力，需要这里的每一个人，需要社区的每一个人。

本节课中，我们一起学习了向Kubernetes贡献时面临的主要挑战，包括CRD管理、增强流程的复杂性以及在子项目中的具体困境。我们也探讨了从技术改进、流程优化到社区文化转变等多个层面的潜在解决方案。改变是困难的，但通过社区的集体努力，我们可以让Kubernetes的贡献体验变得更好。

007：新贡献者引导计划介绍 🎯

在本节课中，我们将学习 Kubernetes 社区推出的“新贡献者引导计划”。这是一个旨在帮助新人快速了解社区结构、明确参与路径的定期线上活动。我们将详细介绍该计划的内容、运作方式、初步成效以及社区成员如何参与其中。

什么是新贡献者引导计划？🤔

上一节我们介绍了课程主题，本节中我们来看看该计划的具体定义。

新贡献者引导计划是一项由“贡献者体验特别兴趣小组”及其下属的“导师子项目”发起的新举措。其核心目标是通过为新人提供简要概述，引导他们融入社区。概述内容包括 Kubernetes 的功能、社区的组织结构以及新人如何找到自己的定位。

计划如何运作？🔄

了解了计划的目标后，本节中我们来看看它的具体运作形式。

该计划每月举办一次线上会议。会议时间固定在每月的第三个星期二，但为了照顾全球不同时区的参与者，会在两个不同时间段各举办一场：一场对欧洲、中东、非洲地区友好，另一场对美洲地区友好。每场会议时长为一小时，其中包含40分钟的演示和20分钟的问答环节。所有会议都会被录制并发布到 YouTube 上，供后续参考。

以下是会议的核心内容结构：

欢迎与介绍：会议开场。
Kubernetes 简介：讲解 Kubernetes 技术的基本功能。
社区结构：介绍特别兴趣小组、子项目、指导委员会以及 CNCF 基金会。
贡献者含义：解释在不同群体中“贡献者”的具体含义，涵盖审查者、批准者等角色以及贡献者阶梯概念。
如何开始贡献：强调融入社区、认识成员的重要性，建议通过加入 SIG 而非仅仅认领单个问题来开始。
当前工作机会：分享各 SIG 提供的活跃工作任务。
贡献常见陷阱：分享来自资深贡献者的建议，帮助新人避开起步阶段的常见问题。
问答环节：核心部分，用于解答参与者的具体疑问。

该计划并非动手实践工作坊，而是纯粹的引导性会议。演示内容基本固定，以确保信息一致性和可重复性。所有相关材料，包括演示文稿和会议主持手册，都已整理在“导师子项目”的社区仓库中。

计划进展如何？📈

前面我们介绍了计划的形式与内容，本节中我们来看看它目前的实施情况与收获。

计划已成功举办数次会议，并取得了一些积极进展和关键认知。

1. 参会情况：通过社交媒体（如 Twitter 和 LinkedIn）进行宣传能显著提升参与度。例如，经过宣传的会议有57人参加，而未宣传的会议则人数较少。
2. 关键收获：
* 多元视角的价值：邀请不同背景的贡献者在会议上分享自身经历，能更有效地解答各类问题，帮助新人找到共鸣。
* 日历邀请的可见性：需要持续优化会议日历邀请的发布渠道，确保新人能够轻松找到并加入会议。
* “良好首发问题”陷阱：许多新人认领标有 good-first-issue 的问题后，常因不熟悉 GitHub 工作流或与评审沟通受阻而无法完成，导致问题被长期占用。这需要社区层面共同寻找更好的新人参与方式。
3. 成功案例：已有参会者在会后主动帮助其他新人，或申请使用会议材料进行本地推广。更有一位参会者直接针对社区网站的一个长期遗留问题提交了具体的修复提案。

社区如何提供帮助？🤝

我们已经看到了该计划的初步成效和需求，本节将探讨社区成员，特别是各小组的领导者，如何提供支持。

计划的成功离不开整个社区的参与。以下是几种主要的帮助方式：

1. 提供“常青”任务：我们需要各 SIG 和子项目的领导者思考并提供“常青项目”。这类项目具有以下特点：
* 小组长期需要。
* 任务定义清晰。
* 新人无需深厚背景即可上手。
* 对小组有实际价值。

例如：整理会议记录、参与发布团队、为社区博客撰写文章等。

2. 参与会议：欢迎有经验的贡献者加入会议，分享你的故事，并回答与新人们兴趣领域相关的具体技术问题。

3. 主持会议：会议内容已标准化并配有详细脚本。社区成员可以学习如何主持，并直接运行会议。

4. 提供反馈：我们设有反馈表单，欢迎对计划提出改进建议。同时，我们也开放讨论如何长期追踪参与者的贡献轨迹，以评估计划效果。

总结与展望 🌟

本节课中我们一起学习了 Kubernetes 新贡献者引导计划。该计划通过固定的月度线上会议，为新人系统化地介绍社区全貌、贡献路径和潜在机会。它不是一个工作坊，而是一个低门槛的引导和问答平台。计划的成功依赖于社区的广泛参与，包括提供明确的任务、分享经验以及共同思考如何优化新人加入流程。我们鼓励所有社区成员关注并参与其中，共同降低贡献门槛，壮大 Kubernetes 社区。

008：Steering AMA 教程

概述

在本节课程中，我们将学习 Kubernetes 指导委员会（Steering Committee）的成员介绍、核心职责、面临的挑战以及对项目未来的展望。我们将通过整理 2024 年北美 Kubernetes 贡献者峰会的 AMA（Ask Me Anything）环节内容，了解指导委员会如何运作，以及他们如何与社区协作来治理这个庞大的开源项目。

章节 1：指导委员会成员介绍 👥

首先，让我们认识一下参与本次 AMA 的 Kubernetes 指导委员会成员。

以下是各位成员的自我介绍：

Benjamin Elder (Beny)：自 2017 年起全职参与 Kubernetes 项目，2015 年夏季曾参与 kube-proxy 的开发。主要活跃于 SIG Testing、Release 等小组，负责基础设施、构建等“元”项目相关工作。对项目和社区充满热情。
Patrick Woody：参与 Kubernetes 相关工作约五年，最初在 SIG Storage 社区学习如何提交 PR。后续参与了测试、日志记录等工作，并主导了“动态资源分配”功能的开发。一年前当选为指导委员会成员，致力于为新贡献者创造良好的入门体验。
Antonio Ojea：于 2019 年加入社区，与 Benjamin 一同在 kind 项目上工作。活跃于测试和网络领域，经常与测试失败相关的问题打交道。目前很高兴能在指导委员会中与大家共事。
Maciej Szulik：在社区已有约十年时间，自 2014 年底开始参与。主要活跃于与控制器相关的领域，最初在 SIG Cluster Lifecycle 贡献。去年与 Patrick、Stephen 一同当选。近期名字也出现在 PRR（生产就绪评审）批准中，已达到 approver 级别。
Stephen Augustus：工程总监，在 Kubernetes 的多个领域都有参与。喜欢横向的 SIG（特别兴趣小组），最初从 SIG Docs 开始，曾担任 SIG Azure 和 SIG PM 的联合主席，并参与了 KEP（Kubernetes 增强提案）流程的创建。目前是 SIG Release 的联合主席之一，创建了发布工程子项目，并管理发布工程工具团队。现在也花费大量时间在 Open SSF、OpenAPI 倡议等项目上。

章节 2：指导委员会的职责是什么？🎯

上一节我们介绍了委员会成员，本节中我们来看看指导委员会的核心职责。

指导委员会的主要职责是确保项目整体健康运行，并将具体领域的决策权委托给相应的特别兴趣小组。他们的工作重点在于处理那些“漏网之鱼”或需要特殊关注、权责不明确的事务。

以下是指导委员会的一些关键职责：

资源与财务监督：对项目资源拥有最终管理权，确保财务方面正常运转，项目能够持续运行。他们管理着签名密钥和文档空间。
项目声明审批：当项目需要对外发布声明时（例如在 Kubernetes 官网上显示的横幅），通常需要指导委员会批准，以确保信息与社区共识一致。
治理与架构：审查治理结构的变更，确立各个治理小组（SIG、工作组、委员会）的职责范围，并确保它们之间没有冲突。当出现新的、没有明确归属的问题时，指导委员会需要决定如何处理。
联络与代表：与 CNCF（云原生计算基金会）联络，协调项目所需的资源（如基础设施）和请求。Kubernetes 项目在 CNCF 理事会中拥有一个独特的席位，该席位由指导委员会任命，通常由现任或前任委员会成员担任，代表项目发声。
处理敏感事务：指导委员会、行为准则委员会和安全响应委员会是三个被授权处理可能无法立即公开的敏感事务的委员会。例如，处理贡献者的签证支持请求就属于这类工作。

一个具体的例子是创建 SIG K8s-infra。过去，项目通过一个名为 kubernetes/funding 的仓库接收基础设施相关的资金请求。指导委员会发现这类请求越来越多，且大多与基础设施相关，因此决定成立一个专门的治理小组（即 SIG K8s-infra）来管理基础设施请求和成本。

章节 3：项目采纳与治理框架 🔄

上一节我们了解了指导委员会的日常职责，本节中我们来看看他们如何处理项目生态中的治理问题，特别是如何采纳外部项目。

社区有一个既定的流程，用于处理新项目捐赠到 Kubernetes 旗下。然而，对于现有成熟项目的采纳（如 etcd），情况则更为特殊，需要与项目现有维护者进行大量沟通。

以 SIG etcd 的成立为例，这是一个非常独特的案例。etcd 作为 Kubernetes 的“大脑”，其健康状况对整个生态系统至关重要。指导委员会与 etcd 的维护者进行了深入沟通，最终决定以成立一个独立 SIG 的方式将其纳入，这既给予了 etcd 一定的自治权，又使其能获得 Kubernetes 项目内部的支持结构。

对于大多数情况，项目通常会被提名由某个现有的 SIG 赞助，作为其子项目。没有一个放之四海而皆准的完整框架来应对所有现有项目的采纳问题。

对于社区成员的建议：如果你认为某个项目应该被 Kubernetes 采纳，最佳路径是：

首先与相关领域的 SIG 讨论。SIG 最了解该领域，也通常知晓生态中的其他项目。
向 SIG 介绍项目，阐述利弊以及采纳的提议。
只有在与 SIG 沟通遇到障碍时，才需要将问题升级到指导委员会。

指导委员会在审查所有治理小组的章程时，通常能对项目归属有一个初步判断。当前的一个挑战是，如何让新来者更容易地找到正确的沟通路径（即“我应该去找哪个 SIG？”）。简化这个信息收集流程是未来可以改进的方向。

同时，社区也需要考虑项目的可持续性。SIG 的维护者已经非常繁忙，不能无条件地接纳所有新项目。必须确保新项目有明确的维护计划和社区支持，避免产生无人维护的“僵尸项目”。

章节 4：如何成为指导委员会成员？ 🏃

上一节讨论了项目治理，本节我们关注个人发展：如何准备并参选指导委员会成员。

指导委员会成员不能公开支持或提名特定候选人。但是，他们以及所有社区成员都可以为潜在候选人提供建议和支持。

给潜在候选人的建议：

主动沟通：如果你对角色有疑问（如职责、时间投入、要求），最好的方式是直接联系任何一位现任指导委员会成员。他们通常愿意通过 Slack、Zoom 等方式进行私下交流。
借鉴历史经验：与往届指导委员会成员交流同样宝贵。他们能提供关于角色挑战和所需准备的不同视角。
积累跨领域经验：参与横向的、跨项目的 SIG（如 SIG Contributor Experience、SIG Release、SIG Testing）是极佳的准备方式。在这些小组中，你会与来自项目各个部分的人合作，处理影响整个社区的问题，这不仅能为你积累经验，也能提升你在社区中的知名度。
解决跨领域问题：不要只专注于自己工作相关的特性开发。尝试去发现并解决那些影响多个 SIG 的“大而多汁”的跨领域问题。这种经历能极大地锻炼你的全局观和领导力。
建立广泛连接：努力认识社区中不同 SIG 的人。广泛的人脉和跨 SIG 的沟通对于理解整个项目和未来担任领导角色至关重要。

现任成员指出，近年来，来自 SIG Contributor Experience 和 SIG Release 的成员在指导委员会中占有相当比例，这可能是因为这些小组在引导新人、建立贡献者阶梯方面做得非常出色。

章节 5：2024年的挑战与未来展望 🔮

上一节我们探讨了个人成长路径，本节我们将目光投向项目整体，看看指导委员会在2024年面临的主要挑战以及对未来的思考。

2024年已解决/进行中的挑战：

选举时间冲突：指导委员会选举和《行为准则》委员会选举时间过于接近，导致有人可能同时参选或需要退出一个以加入另一个。解决方案是将《行为准则》委员会选举推迟到2025年2月，让新当选的指导委员有时间熟悉工作。
维护者名单与TOC投票权：Kubernetes 在 CNCF 技术监督委员会（TOC）的开发者代表席位投票权目前仅限指导委员会成员。为了增加 Kubernetes 在 TOC 中的代表性，正在推动将所有 SIG 的主席和技术负责人添加为 CNCF 官方认可的“维护者”，从而获得投票权。这需要收集并提交这些领导者的联系信息。
年度报告：简化后的年度报告流程仍有部分 SIG 和工作组未能按时完成。这些数据对于展示项目工作和贡献者成果非常重要，需要各小组领导积极配合。

Kubernetes 的未来：
指导委员会更关注项目和社区的可持续性，而非具体的技术方向（技术方向由各 SIG 主导）。

未来的核心挑战与目标包括：

以人为本：项目成功的关键在于人。需要关注维护者倦怠、知识传承、人员流动（如换工作）对领导力的影响。鼓励维护者尽可能记录上下文，制定贡献者阶梯和继任计划。
平衡稳定与创新：用户既要求“稳定、可升级”，又希望引入新功能（如 AI/加速器支持、非统一内存访问调度）。项目需要在引入严格的流程（如 KEP、PRR）以确保稳定性的同时，避免流程过于繁琐而吓退贡献者。目标是找到既能保证质量又不制造过多摩擦的平衡点。
应对技术演进：需要适应硬件和软件世界的变化，例如 AI 工作负载、新型处理器等，同时确保核心体验的稳定。
成本控制：项目基础设施成本（主要来自云服务商捐赠）高达数百万美元/年，且持续增长。社区需要更审慎地评估新需求，优化现有工作负载和测试效率（如减少“flake”测试），确保长期财务可持续性。
处理“弃用”项目：随着时间推移，一些兄弟项目可能变得无人维护。社区需要思考如何在不“大包大揽”的情况下为这些项目提供支持，或者制定项目“失败”或归档的计划。SIG Architecture 旗下的代码组织小组正在积极研究相关课题。

关于 .io 域名可能被移除的问题，指导委员会认为这不是迫在眉睫的危机，但有预案，例如将用户流量逐步迁移到备用的 .dev 域名上。

总结

本节课中，我们一起学习了 Kubernetes 指导委员会在 2024 年贡献者峰会 AMA 环节分享的核心内容。我们认识了委员会成员，了解了他们作为项目“守门人”和“协调者”的职责，包括资源管理、治理架构维护和敏感事务处理。我们探讨了社区采纳外部项目的复杂性和最佳实践，以及个人如何通过积累跨领域经验、解决全局性问题来为参选指导委员会做准备。最后，我们审视了项目当前在可持续性、成本控制、平衡稳定与创新方面面临的挑战，并展望了 Kubernetes 未来需要以“人”为本，持续适应技术生态变化的发展方向。指导委员会的工作重心在于确保这个由人驱动的庞大开源项目能够健康、稳定地持续运行。

009：开幕式教程

在本教程中，我们将学习2024年北美Kubernetes贡献者峰会开幕式的核心内容。我们将了解活动的基本规则、日程安排、重要公告以及一个具有里程碑意义的社区成就。

欢迎与行为准则

欢迎来到2024年在盐湖城举行的Kubernetes贡献者峰会。

最重要的一点是，请注意我们有一套行为准则，要求每个人彼此友好相待。

我们不希望发生任何不愉快的事情。如果确实发生了问题，可以联系我们的行为准则团队。

我们也有CNCF办公室，即CNCF行为准则办公室。如果您需要联系他们，可以前往大厅这一侧的房间252B。

如果出现任何问题，请直接联系我们中的任何一位，或直接前往行为准则办公室。

特殊日期与志愿者致谢

今天是一个特殊的日子。特别是对于身处美国的各位，如果您还不知道，今天是美国的退伍军人节。

我们向那些做出牺牲的人们致敬，不仅是在美国，也包括其他地方的人们，感谢他们为保障安全所做的贡献。感谢你们的付出。

在活动期间，如果您需要任何帮助或有任何问题，请寻找戴着这些帽子的人员。

同时，感谢所有的志愿者和峰会工作人员，因为没有他们，这次活动就不可能举办。谢谢大家。

日程安排与社交活动

以下是日程安排。如果有人错过了，非会议环节将在255房间举行，沿着大厅走然后在左边。我们还有一个单独的Dock Print房间，位置会稍远一点，同样在左侧。

今晚我们有社交活动。社交活动将于下午6点在Fllanker举行。

根据我的方向感，它是在那个方向，我认为是西北方向。无论如何，请查看地图或使用谷歌地图。它离得不远，但需要走一小段路。天气会有点凉，请确保带上保暖衣物。

这一点非常重要：请携带年龄身份证明文件。

特别是对于非美国公民，只有护照簿有效。请带上您的护照簿。他们会检查，如果您没带，将无法入场。请带上您的护照，不是我的，是您的。

餐饮与后续环节更新

还有一个更新是，所有的食品和饮料将在255B房间供应。

在房间的后部。您需要去找一下，但它就在那里。

此外，在这之后，我们将进行指导委员会问答环节。

我们将进行“求助呼喊”环节。因为我们错过了一些需要呼喊的人，我们将基本按照去年在芝加哥的方式进行，所以请排好队，上前说出您的项目是否需要帮助或支持。

下午在这个房间将有CNCF问答环节。

下午同样在这个房间还将举行颁奖典礼，并且我们会拍摄合影。

我们可能会在这个斜坡上拍摄合影。当您出去时，在左侧的这个斜坡上，我们将在那里拍照。

但由于我们都会参加颁奖典礼，我们会在之后带大家一起去拍照。

重要通告与反馈收集

别忘了，还将有Kub见面会。

这次见面会将于周四午餐时间在项目展馆举行。

我们非常高兴尽可能多的各位能加入我们，以便有可能招募到新的贡献者。

同时，衷心感谢今年提交的所有T恤设计，以及所有参与设计的人员。我们只选择了一件，因为我们只能印制一件T恤。

您也会在255房间看到它，那里陈列了所有的T恤设计。

我们也希望收集一些关于贡献者峰会的反馈，也许你们中的一些人还没有听说。我们将继续举办贡献者峰会，但这将成为维护者峰会的一部分，今年将从印度开始，然后继续在伦敦举办。

因此我们也会询问，如果您对伦敦的维护者峰会有任何特殊要求或想法，希望我们如何安排，请告诉我们。这对我们来说变化不大，但会减轻我们的压力，因为我们不再需要单独运营这个活动了。

说到注册，印度维护者峰会的注册已经开放。如果您计划参加在印度举行的KubeCon，您就有资格在那里注册并参加维护者峰会。

同样，伦敦KubeCon维护者峰会的提案征集也已开放。

好消息是，如果您被选为维护者峰会的演讲者，您将获得一张完整的KubeCon通行证。

里程碑成就：API Snoop测试覆盖率

现在，我想请Rihan上台，因为我们有一个特别的环节。

我想大多数人都注意到了。这就是API Snoop，这是我们一致性测试的测试覆盖率情况。

如您所见，我们有497个端点，其中496个已通过测试。我们希望使其达到100%。

能够站在这里是一种荣幸。看看我们的图表，过去10年里这个社区取得的惊人进展。

抱歉，我有点激动了。这真的非常令人兴奋。

非常感谢所有为此付出努力的人。我特别想提到最后那个PR的所有者，Stephen Howardwood，感谢他所做的出色工作，还有II团队、Bpiakker、China Woodman，以及Kubernetes安全架构中所有帮助合并这些PR的人们。

感谢你们在我不断“骚扰”你们时的耐心。

那么，让我们开始吧。让我们倒计时。3…2…1…

好的，众所周知，这不会只花五分钟。所以希望到今晚活动时，我们将看到一个覆盖率达到100%的API Snoop。

本节课总结

在本节课中，我们一起学习了2024年Kubernetes贡献者峰会开幕式的要点。我们了解了活动的行为准则、日程安排、餐饮位置和重要的社交活动注意事项。会议还宣布了贡献者峰会未来将并入维护者峰会的计划，并鼓励社区提供反馈。最后，我们共同见证并庆祝了Kubernetes API一致性测试覆盖率接近100%这一社区努力的重大里程碑，体现了协作与持续改进的精神。

010：Kubernetes贡献者峰会（2024北美）-p10-贡献者招募与公告

在本节课中，我们将学习Kubernetes社区中多个特别兴趣小组（SIG）和子项目的当前状况与贡献机会。多个项目维护者将介绍他们急需帮助的领域，从代码开发、文档本地化到社区运营和安全响应等。无论你是经验丰富的贡献者还是希望入门的新手，都能找到参与的方式。

贡献者招募：各项目急需帮助的领域

以下是来自不同SIG和子项目代表的发言，他们各自阐述了项目当前面临的挑战和急需帮助的具体方面。

SIG Testing - Pro项目

我们目前在资金和运营方面取得了很大成功，但项目工具本身的代码，即我们运行所有CI的载体，主要由一位非常活跃的维护者支撑，其他贡献者几乎都已离开。SIG Testing的其他成员手头也有很多事情。我们迫切需要更多人积极参与这个项目，特别是来自Kubernetes项目的成员。虽然有一些来自Kubernetes外部用途的用户参与，但我们缺乏足够多的、来自Kubernetes社区并思考Kubernetes如何使用该项目的代表，以确保我们为运行CI而孵化的项目仍能满足我们自身的需求。如果你感兴趣，请在会后或SIG会议间歇与我交流。

SIG Contributor Experience - 新贡献者引导与社区运营

我是SIG Contributor Experience的Kasn，我们有一个新的贡献者引导计划，本次峰会之后我们有一个专门的会议来介绍它。我和Mario将告诉你这个计划是什么，以及你们所有人如何提供帮助。我们特别需要SIG负责人、维护者以及任何能够帮助新贡献者融入社区的贡献者的帮助，我们将在会议上详细介绍更多信息。

此外，在社区运营子项目中，我们希望在明年开展一些社交媒体方面的工作。我们现在有很多社交媒体账号，我们正在努力确保我们有可持续的策略和工作，以及学习如何开展这项工作的人员。请来帮助我们运营社交媒体。如果你曾想尝试博客写作，我们也有相关计划。在导师计划方面，我们有一位新的导师子项目负责人。如果你想通过担任导师来帮助新贡献者参与，请参与导师子项目正在进行的工作。

SIG Architecture - 代码组织与评审

我是SIG Architecture的John。我们非常需要帮助的方面包括代码组织、生产就绪性评审和API评审。我们在Bridget（她之前在这里）的带领下有一个影子计划，她已承诺参与下一个周期。我们还有其他一些人参与。这是一个了解整个项目全貌的好方法。你会与很多人交流，虽然他们可能不喜欢你，但你至少能接触到社区。实际上，你能学到项目中正在发生的很多事情。我们这个小团队会审视整个发布周期中的所有增强功能，这非常酷。

此外，我也参与了设备管理工作组。我们有很多人参与其中，稍后我们有一个线下会议，如果你想了解更多关于我们在那里做什么的信息，可以参加。我们在那个领域有太多工作要做，绝对需要更多人加入并做出贡献。

SIG Docs - 文档本地化

我是SIG Docs的Soco，目前是SIG Docs本地化子项目的负责人之一。我在此呼吁为Kubernetes文档的本地化提供一些帮助。我们实际上有许多本地化团队来领导每种语言的本地化工作，目前有超过10个团队。但我们需要更多贡献者为每种语言提供帮助，以及能够领导团队本身的人。如果你对文档本地化感兴趣，请来找我，或者你可以分享给你的朋友，如果他们也对本地化文档以及为Kubernetes做贡献感兴趣的话。我认为本地化项目和这些团队是开启他们首次贡献的绝佳场所。作为SIG本地化项目的负责人，我努力将新贡献者带入我们的Kubernetes社区，并推动他们进入其他SIG，使他们能够成为我们整个Kubernetes社区的新贡献者。

SIG Network - Gateway API

我是Gateway API子项目和SIG Network的Shane。我们在去年的KubeCon芝加哥大会上宣布了正式发布（GA），但我们仍处于一个相当大的增长期，我们需要帮助和反馈。特别是我们目前在Slack的SIG Network Gateway API频道中有一项正在进行的调查，我们希望人们填写。我们对用户体验以及介于其间的所有事情的反馈特别感兴趣。所以，如果你一直在考虑使用Gateway API，或者已经在使用它，你的反馈将非常有帮助。

API评审

我没有数据支持，但我还是要断言：阻碍你的增强提案（CAP）被合并的首要障碍是API评审。有多少人提交过CAP并遇到了“哦，我需要找一位API评审员，我需要获得他们的时间”这种情况？今天在座的API评审员有多少？有资格进行API评审的人。1，2，3。Michelle之前在这里。有4位，因为只有我们4个人。所以，如果你的CAP需要API评审，你必须通过我们中的一位才能让它进入。让我告诉你，过去几周有点疯狂。所以这是我的恳求。如果你是项目的成员，并且已经参与了一段时间，你见过API，使用过API，并且可能想帮助评审其他人的API设计，我们确实需要帮助。我们越能分散这项工作，情况就会越好。这有点像一段旅程。所以，如果你感兴趣，来和我们中的一位谈谈，我们会很乐意帮助你入门。

SIG Release - 发布工程

大家好，我以SIG Release联合主席的身份再次发言。很多人认为SIG Release只是发布团队，我们实际上有两个子项目。其中之一是发布工程，该项目负责处理所有发布工程工具，这些工具实际上在每个周期点击按钮来发布Kubernetes。我们正在积极寻找对开发这些工具感兴趣的人。有一群人拥有Kubernetes发布经理的头衔，我们一直在努力构建更多的贡献者阶梯。所以，如果你有发布工程背景，如果你曾是SRE、生产工程、DevOps等，并且对发布Kubernetes感兴趣，请来和我们谈谈。

SIG Testing - Hyrophone项目

我是Hyrophone项目的维护者Ricky，我们是SIG Testing下的一个较新的项目子项目。我们正在努力使Kubernetes的合规性和测试变得更加容易。我们正在寻找更广泛的采用以及在你们平台上的测试，以帮助我们找出差距和可以改进的地方。任何反馈都非常欢迎。

kubectl插件管理器

大家好。你们知道kubectl有一个插件管理器吗？好的。猜猜那个插件管理器上分发了多少个插件？800？5？太多了。好的。实际上是275个。我认为开源中有很多插件。猜猜有多少人在评审这些插件及其更新？是的，只有一个人。那就是我。我真的忙不过来。所以我们正在尝试围绕插件管理建立一些流程。我们也在尝试做v1版本。你知道，如果我们能做到的话。同样的旧代码已经运行了很多年，运行得很好。但我们想要一个稳定、愉快的API。我们想要，你知道，让项目处于一个成功的状态。所以，是的，时间。

安全响应委员会

嘿，大家好。你们知道Kubernetes有CVE吗？不是我们，对吧，我们是完美的。所以，是的，我们有一个安全响应委员会，目前大约有8名成员，大多来自不同的公司，许多是社区的资深成员，我们正在寻求帮助。就像其他待命一样，我们也有待命安排。因此，我们委员会的每个人都有每周的待命任务。所以我们正在寻找对CVE充满热情并愿意与社区（如其他SIG的维护者）以及SIG Release合作，以分类安全漏洞的人。所以请来加入我们。

Ingress NGINX与Gateway API实现

大家好。我的名字是James Strong。我是Ingress NGINX的维护者之一，这是每个人最喜欢的Ingress控制器。我将开始做一些事情，这会让我的公司变得更有趣。有多少人有机会从头开始做一些事情？有多少人想要这个机会？没有，有几个，谢谢Tim。对于Ingress NGINX，我们实际上要开始Gateway API的实现。我为此感谢所有在那里的支持者。所以我们即将开始那个实现。下周开始，所以如果你想开始参与，我们已经与SIG Network和Gateway API社区进行了很多讨论。所以，是的，我们需要帮助来完成这件事，并且是从头开始。我们将进行很多对话，编写很多代码，并尝试修复那些CVE和安全问题。但要努力避免重蹈过去的覆辙。总之，谢谢。

本节课中我们一起学习了Kubernetes社区中多个关键领域对贡献者的迫切需求。从核心的测试框架、API设计评审、发布工程，到社区运营、文档本地化、插件生态和安全响应，每个环节都欢迎并需要社区的参与。无论你的专长是编码、文档、运营还是安全，都能在Kubernetes找到贡献力量、提升技能并影响项目发展的机会。

posted @ 2026-03-29 09:18 绝不原创的飞龙阅读(1) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈