全职工作者如何为 Kubernetes 做贡献

开源社

发布于 2020-06-24 16:34:13

7820

发布于 2020-06-24 16:34:13

文章被收录于专栏：开源社开源社

| 作者：Tara Gu

| 编辑：王皓月

| 设计：朱亿钦

| 翻译：Rudy Steiner

| 审稿：颖颖子，PuPaul_II_

你甚至可以在业余时间参与最大的开源项目之一的内部工作。

我是从 2018年10月开始为 Kubernetes (K8s) 做贡献的。那时我在 IBM 的产品安全事件响应团队工作，被分布式系统所吸引，但日常工作中接触不到，于是我导师 Lin Sun 建议我在空闲时间为开源的分布式系统做贡献。自此，我开始对 K8s 产生兴趣，再也没有回头。

我主要在 Kubernetes 特别兴趣小组工作，参与测试、存储和发布的工作。我最为人所知的代码贡献是在 Saad Ali 的带领下实现了插件管理器。插件管理器是一个管理插件注册/注销的控制器。在注册插件（如容器存储接口或设备插件）失败场景下，它给 Kubelet 插件注册添加了重试和指数退避逻辑。

2019年1月，我成为 K8s 组织成员，并于2019年7月加入 IBM 开放技术组，成为一名开源贡献和开发技术推广工程师。目前我正在为 Knative，一个基于 Kubernetes 的无服务器负载部署和管理平台，做出贡献。

现在 Kubernetes 非常欢迎贡献者，如果你想跟着我的足迹，在空闲时间开始贡献，请继续阅读。

开始为Kubernetes做贡献所需要的技能

任意的版本控制系统(如 git,svn)

K8s 的源代码托管在 GitHub，了解如何使用 Git 或者其它版本控制系统是非常重要的。首先，请熟悉这些常见命令。

Golang

我有 C/C++ 的使用背景，但在开始前我并不了解 Golang。如果你熟悉面向对象的编程，Golang 应该相当容易上手。我建议在学习 K8s 代码库的同时学习Go。我的同事 Wei Huang 向我介绍了 Ultimate Go 编程系列视频，这极大地帮助了我。

其它要求

在你的提交可以被合并到 K8s 代码库之前，必须签署贡献者许可协议（CLA）。还要注意社区准则、编码准则、如何设置你的开发环境以及 Kubernetes 的 Github 仓库“开始贡献之前”中所述的相关事项。

如何选取你的第一个 Kubernetes 问题

在 Kubernetes 中找事做的首要的方法是查看开放问题列表。你可以用标签过滤问题列表，例如 “good first issue”，“help wanted”，这些标签表明这个问题对新手非常友好。偶尔问题会被打上错误标签；也许问题的技术难度被低估了，并被错误的标记为 “good first issue”。所以一个 “good first issue” 比你预料的要复杂也不必惊讶。

第二个找事做的方法是搜索代码库里的 “TODO”。TODO 里面有数百个低优先级需改进的待办事项。这是学习代码库的好办法，同时还可以从别人的 “TODO” 列表中划掉一个待办事项 -- 双赢！

如何处理一个问题（issue）

阅读任何链接的问题（issue）或拉取请求（PRs）来帮助你理解问题的背景和要解决的难题。如果某个问题描述不清楚，在投入时间之前，一定要联系问题的创建者以获得更清晰的理解。如果它是一个 bug，就要验证你是否能复现这个 bug。请注意这可能需要投入大量时间；我就花了很多时间去设置环境以尝试复现 bug。

一旦你有解决方案的想法，最好在提交 PR 之前，在 Slack 上联系问题（issue）的创建者来验证你的方法。如果你在一周之内没有收到反馈，直接提交 PR ，问题创建者会用具体方案进行审查。

起初，我感到困惑的是，在认领一个 issue 之后应该多快提交 PR。因为我只能在全职工作以外的时间为K8s 做贡献，我也想知道这会如何影响我的工作与生活的平衡。在浏览了 issues 和其它 PR 之后，我发现我需要在至少两周内提交 PR 或者提供状态更新。在我看来，如果你有一个还没有做测试的初始实现（initial implementation），提交初步的 PR 是可以的，这样可以尽快得到是否反馈，了解自己的方向是否正确。

在开发解决方案时，请确保添加了单元测试或集成测试，以验证 bug 已修复或者特性和预期的一样。K8s 使用 Prow 来做持续集成/持续开发（CI/CD）系统，它会为有 /ok-to-test 标签的 PR 运行所有的单元和集成测试。如果你不是 Kubernetes 项目的成员，CI 任务就不会自动执行。这种情况下，我建议你先本地测试，然后在相关的特别兴趣组 Slack 频道找 Kubernetes Github 组织的成员去你的 PR 评论 /ok-to-test。

如何加入 Kubernetes 社区

对于日常交流，Kubernetes Slack 非常适合直接和其他贡献者联系并请教问题。我建议你加入自己最感兴趣的特别兴趣组 SIG（如客户端、存储、测试等）频道。

KubeCons 是与其他贡献者面对面交流的好地方。2019和2020年9月在北美有一次，3月/4月在欧洲有一次，7月在亚洲有一次。我强烈推荐有抱负的新手和经验丰富的贡献者参与下面的两项活动：

Kubernetes 贡献者峰会 (Kubernetes Contributor Summit)：它在 KubeCon 正式开始的前一天，一整天活动都是免费的。既有为新人也有为现有的贡献者准备的工作坊，专注于学习和发展。
交流+指导会议（Networking + Mentoring Sessions）：在这里，你可以和许多资深的开源人士会面，他们参与过众多 CNCF 项目，包括 Kubernetes。你将和其他两位参会者结对探讨技术和社区问题，甚至可以就选取的问题进行结对编程。

其他贡献方式

除了贡献代码，还有许多其它的贡献方式。审查代码很重要，因为这可以帮助审查者和维护者减轻负担并提供多样的观点。也是学习 K8s 代码库的最佳方法之一！

你还可以作为角色的影子(shadow for a role)加入发布团队，为 Kubernetes 的发布流程做出贡献。访问角色手册了解更多发布团队中的不同角色。我曾在两个版本的发布中作为测试基础架构负责人的影子，直到我们自动化了整个流程并取消了这个角色。

成为一个影子教会我很多，包括有关 CI/CD 自动化和一个高知名度的影响全世界公司的产品背后的项目管理的知识。发布团队的持续贡献使任务自动化和消除所有角色的手动任务，以获得更好的 CI/CD，这给我留下了特别深刻的印象。

如果你对成为一个影子感兴趣，请查看正式的申请流程。

如果你在空闲时间参与 K8s，一个需要注意的问题是：每周有发布团队会议，但是不要求影子所有的会议都参加。会议通常在美国太平洋时区的工作时间进行，持续半小时。幸运地是我的工作很灵活，足以让我每周预定2～3次会议室参加发布团队的会议。

全职工作时如何管理时间

设定每周用于贡献 K8s 的小时数非常有帮助，否则很容易陷入日常的开发事务中。当你的工作和生活变得忙碌的时候，暂时停止对 K8s 的贡献也非常重要。在 K8s 开发社区中，休整期通常和发布一个新版本之前的代码冻结期一致。对你来说，这是短暂休息的好时机，因为在这期间其它贡献者基本不会参与贡献。你不太可能得到有关 PR 或者 Slack 消息的回复。

让你的团队和经理了解你的新爱好是一件好事，因为知识分享是有益的。如果你的团队或者公司使用 Kubernetes（或任何容器技术），会因为你了解 K8s 的原理而受益。如果你的团队或者公司不使用 Kubernetes（或任何容器技术），分享 Kubernetes 的行业趋势、软件工程设计模式和架构设计决策也是非常棒的。考虑每月举办关于这些话题的讲座或展示你在 kubeCon 和其它会议上学到的知识。

总结

为 K8s 做贡献是我最有意义的经历之一，编程以前只是一份工作，但是现在也成了一个爱好。如果你有一份要求不是特别高的日常工作，我强烈建议你试一试。

资源