• author

第70节 Kubernetes 社区规范

⬆️上一节🔗 ⬇️下一节🔗

❤️💕💕新时代拥抱云原生，云原生具有环境统一、按需付费、即开即用、稳定性强特点。Myblog:http://nsddd.top

---

[TOC]

前言

一个顶级的社区，必然有着最全面和最规范的章程值得我们学习和借鉴，对于 Kubernetes 来说也是如此，如果想要做好一个顶级的社区，Kubernetes 必然值得我们去借鉴的。

用官方的一句话来描述：Kubernetes builds upon a decade and a half of experience at Google running production workloads at scale using a system called Borg, combined with best-of-breed ideas and practices from the community.

Community

Community 的地址在 https://github.com/kubernetes/community 。很多社区的社区都是这样设计的。

Kubernetes具有以下类型的官方支持的组（greps）：

• Committees：委员会是一批被授权处理敏感话题的人。鼓励该小组在完成其使命时尽可能开放，但由于所讨论主题的性质，允许私下交流。委员会的例子包括指导委员会和安全或行为准则等。

• Special Interest Groups (SIGs) 特殊兴趣小组（SIG）是专注于项目某个部分的持续性开放小组。特别政府必须有公开和透明的程序。欢迎任何人参与和贡献，只要他们遵守Kubernetes行为准则。SIG的目的是拥有和开发一组子项目。

  子项目每个SIG可以有一组子项目。这些是可以独立工作的小团体。一些子项目将是Kubernetes主要交付成果的一部分，而其他子项目则更具推测性，位于 kubernetes-sigs github org 中（例如 kind 和 kubebuilder 就是在这里）。

• Working Groups 工作组是为解决跨越SIG边界的问题而成立的临时小组。工作组不拥有任何代码或其他长期工件。工作组可以通过参与的SIG进行汇报和采取行动。

• User Groups 用户组是用于促进交流和发现与Kubernetes大用户组具有长期相关性的主题相关的信息的组。他们没有Kubernetes代码库的部分所有权。

SIG可以有自己的贡献策略（在此存储库的SIG文件夹中的 README 或 CONTRIBUTING 文件中描述）（例如sig-cli/CONTRIBUTING.md），以及自己的邮件列表、空闲通道等。

所以是独立出去的，不过依旧是为 kubernetes 服务的。

Kubernetes-sig 社区提供了 Kubernetes 的开发学习实验，在 https://github.com/kubernetes/community/blob/master/contributors/devel/development.md 中

告诉了我们如何构建出一个开发环境，并且需要哪些工具。其实和我们在前面二进制搭建是差不多类似的。

Kubernetes 为贡献 git CICD 流程有一个帮助文档在这里: https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md

要测试Kubernetes，你需要安装最新版本的etcd，这是一个一致且高度可用的键值存储。要安装本地版本的etcd，请在Kubernetes工作目录中运行以下命令。

./hack/install-etcd.sh

此脚本将指示你对 PATH 进行更改。要使其永久化，请将其添加到你的 .bashrc 或登录脚本中：

export PATH="$GOPATH/src/k8s.io/kubernetes/third_party/etcd:${PATH}"

Makefile

我们即使知道了对于一个开发者来说，一个 Makefile 文档带来的帮助是巨大的。

要构建Kubernetes的特定部分，请使用 WHAT 环境变量。在Kubernetes项目目录 $GOPATH/src/k8s.io/kubernetes/ 中，运行以下命令：

make WHAT=cmd/<subsystem>

将 <subsystem> 替换为 cmd/ 目录下的命令文件夹之一。例如，要构建 kubectl CLI，请运行以下命令：

make WHAT=cmd/kubectl

如果此命令成功，你现在将在Kubernetes项目目录的 _output/bin/kubectl 处拥有一个可执行文件。

要构建整个Kubernetes项目，请运行以下命令：

make all

注意：你可以省略 all ，只运行 make 。

Kubernetes构建系统默认将报告的Go编译器错误数量限制为10。如果你想删除此限制，请在命令行中添加 GOGCFLAGS="-e" 。

make WHAT="cmd/kubectl" GOGCFLAGS="-e"

如果你需要在已编译的Kubernetes可执行文件上使用调试检查工具，请设置DBG=1。例如：

make WHAT="cmd/kubectl" DBG=1

要为所有平台交叉编译Kubernetes，请运行以下命令：

make cross

要为特定平台构建二进制文件，请添加 KUBE_BUILD_PLATFORMS=<os>/<arch> 。例如：

make cross KUBE_BUILD_PLATFORMS=windows/amd64

要运行所有提交前验证测试，请使用以下命令：

make verify

如果某个特定的验证测试失败，可能会有一个更新脚本来帮助解决问题。它们位于 hack/update-*.sh 。例如， hack/update-gofmt.sh 确保所有源代码文件的格式正确。向项目中添加新文件时通常需要此选项。

可以使用此命令运行所有更新脚本：

make update

ull request需要通过所有单元测试。要运行每个单元测试，请使用以下命令：

make test

你还可以使用 WHAT 选项来控制要测试的包和子系统，并使用 GOFLAGS 来更改测试的运行方式。例如，要对一个包详细运行单元测试，请使用以下命令：

make test WHAT=./pkg/apis/core/helper GOFLAGS=-v

要运行集成测试，请使用以下命令：

make test-integration

Kubernetes增强建议（KEP）

Kubernetes Enhancement Proposals (KEPs)

Kubernetes增强提案（KEP）是一种为Kubernetes项目提出，沟通和协调新工作的方式。你可以在KEP-0000中阅读该项目的全部细节。

什么是 KEP？

提出了Kubernetes的标准化开发流程，以便：

• 为Kubernetes的变更建议提供一个通用的结构

• 确保变更的动机明确

• 允许列举稳定性里程碑和稳定性分级标准

• 在版本控制系统（VCS）中持久保存项目信息，以便将来使用Kubernetes

• 支持创建面向用户的高价值信息，例如：

  • 总体项目开发路线图
  • 有影响力的面向用户的变更的动机

• 保留GitHub问题用于跟踪正在进行的工作，而不是创建 "umbrella" issues

• 确保社区参与者能够成功地推动一个或多个版本的变更完成，同时在整个过程中充分代表利益相关者

这个过程由一个名为 Kubernetes Enhancement Proposals (KEPs) 或KEP的工作单元支持。KEP尝试将以下方面结合起来

• 功能和工作跟踪文档
• 产品需求文档
• 设计文件

一个文件，该文件是与一个或多个特殊兴趣组（SIG）协作逐步创建的。

第一次参与 Kubernetes

• 这篇文档告诉了我们贡献的一些方法

以下是你今天可以做的一些事情，以开始贡献：

• 帮助改进Kubernetes文档
• 阐明可以重命名或注释的代码、变量或函数
• 写测试覆盖率
• 帮助分类问题（并不一定需要权限，而是通过命令和机器人）

如果上面的建议对你没有吸引力，你可以浏览被标记为 好的第一个问题 的问题，看看谁在寻求帮助。那些有兴趣在不编写代码的情况下进行贡献的人也可以在非代码贡献指南中找到想法。

修改自己的 kubectl fork

确保你准备好立即开始之前，你声称任何一块的工作。

• 设置开发环境。
• 熟悉代码：
  • kubernetes/cmd/kubectl is the entry point
  • kubernetes/pkg/kubectl is the implementation
  • Look at how some of the other commands are implemented
  • Codebase Tour
• 尝试添加一个新命令来执行一些简单的操作：
  • 添加 kubectl hello-world ：打印“Hello World”
  • 添加 kubectl hello-kubernetes -f file ：打印 Hello<kind of resource><name of resource>
  • 添加 kubectl hello-kubernetes type/name ：打印 Hello<kind of resource><name of resource><creation time>

注意：考虑将你的命令发布到一个fork上，这样维护人员就可以查看它。

Find a good first topic

Kubernetes组织中有多个存储库。每个存储库都有初学者友好的问题，这是开始你的贡献者之旅的好地方。例如，kubernetes/kubernetes对于不需要高级Kubernetes知识来贡献的问题有help wanted和 good first issue标签。 good first issue 标签还表示Kubernetes成员已承诺为新贡献者提供额外帮助。另一种开始的方法是找到一个文档改进，比如一个丢失/断开的链接，这将给予你接触到代码提交/审查过程，而不会增加技术深度的复杂性。

Github中的问题分配

Issue Assignment in Github

当你发现一个问题要解决时，你可以将它分配给自己。

• 就你希望解决的问题回复 /assign 或 /assign @yourself
• K8s-ci-robot 会自动将问题分配给你。
• 你的姓名将列在 Assignees 下。

选择合适的 sig

Find a SIG that is related to your contribution

为你的贡献找到合适的SIG并添加SIG标签将有助于你在正确的位置提出问题，并给予你的贡献具有更高的可见性和更快的社区响应。

对于合并请求，自动分配的审阅者将添加SIG标签（如果你尚未添加）。

对于问题，请注意，社区正在开发一个更加自动化的工作流程。由于SIG不直接映射到Kubernetes子存储库，因此可能很难找到你的贡献属于哪个SIG。查看 SIG列表 以确定哪个SIG最有可能与你的贡献相关。

例如：如果你正在提交一个CNI问题（即容器网络接口），你将选择网络SIG。在GitHub上的新评论中添加SIG标签，方法是键入以下内容：

/sig network

按照SIG名称列中的链接访问每个SIG的README。

大多数SIG都有一组GitHub团队，这些团队的标签可以在问题评论和拉取请求中提及，以获得更高的可见性。如果你不确定问题的正确SIG，可以尝试 SIG-contributor-experience, or ask in Slack。

SIG专用贡献指南

一些SIG有自己的 CONTRIBUTING.md 文件，其中可能包含除了这些一般信息或指南之外的额外信息或指南。这些位于SIG特定的社区目录中：

• /sig-apps/CONTRIBUTING.md
• /sig-cli/CONTRIBUTING.md
• /sig-multicluster/CONTRIBUTING.md
• /sig-storage/CONTRIBUTING.md
• /sig-windows/CONTRIBUTING.md

Kubernetes 分类指南

• https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md

Issue triage是一个SIG接收和审查新的GitHub问题和请求的过程，并将其组织起来，由自己的成员或其他SIG采取行动。

分类涉及根据优先级/紧急程度、问题的SIG所有权和问题类型（错误、功能等）等因素对问题和拉取请求进行分类。

权限和机器人

所有贡献者都可以打开新问题并对其他人的问题发表评论。但是，分配特定标签（如 triage ）、更改里程碑或关闭其他贡献者问题的权限仅授予问题的作者、受让人和组织成员。出于这个原因，我们使用机器人来管理标签和分类。有关bot的命令和权限的完整列表，请参阅Prow命令参考页面。

• https://prow.k8s.io/command-help

除了机器人，Kubernetes 还有一个特别有意思的工具，可以显示你当前哪些pull requests正在等待你的反馈，哪些PR正在等待贡献者响应。请注意，Gubernator只显示pull requests。你将看不到分配给你的问题。

• https://gubernator.k8s.io/pr/cubxxw

标签分类

对于 Kubernetes 来说，标签分类很复杂，但是确实很有必要，能够帮助 member 快速的去定位和解决问题。

在 Kubernetes 中的标签列表定义在 ：https://github.com/kubernetes/kubernetes/labels

新问题将自动分配 needs-triage 标签，指示这些问题当前正在等待分类。在对问题进行分类后，拥有SIG的问题将使用bot命令 /triage accepted 。此命令删除 needs-triage 标签并添加 triage/accepted 标签。

请注意，添加标签需要Kubernetes GitHub org成员资格。如果你不是组织成员，你应该添加你的分类结果作为评论。

进行搜索

GitHub允许你过滤出问题类型和拉取请求，这有助于你发现需要分类的项目。为方便起见，此表包括一些预定的搜索：

Search	What it sorts 它的分类
created-asc	按年龄分类的未分类问题
needs-sig	需要分配给SIG的问题
is:open is:issue	最新收到的问题
comments-desc	最繁忙的未分类问题，按评论数排序
comments-asc	需要更多关注的问题，基于评论数

我们建议你先过滤掉最老的、未标记的问题和pull requests。

按类型分类问题

使用这些 triage/ 和 kind/support 标签查找可以快速关闭的未决问题。分类工程师可以添加适当的标签。

triage/needs-information 标签表示问题需要更多信息才能继续工作;评论或关闭它。

Help Wanted/Good First Issues

为了识别专门为新贡献者准备的问题，我们使用了 help wanted and good first issue 标签。要使用这些标签，请执行以下操作：

• 如果问题满足这些准则，你可以使用 /help 命令添加 help wanted 标签。使用 /good-first-issue 命令创建 good first issue 标签。请注意，添加 good first issue 标签也会自动添加 help wanted 标签。
• 如果某个问题有这些标签，但不符合指导原则，请询问要添加到该问题的更多详细信息，或使用 /remove-help 或 /remove-good-first-issue 命令删除标签。

Kind Labels

GitHub 默认是没有 Kind 类型的，也就是说，为了方便管理， Kubernetes 对问题使用了 Kind 类型标签：

• https://github.com/kubernetes/kubernetes/labels?q=kind

通常 kind 标签由提交问题的人应用。错误的 kind 问题（例如，标记为bug的支持请求）可以由分类的人纠正;反复检查是个好办法。我们的问题模板旨在引导人们选择正确的类型。

• kind/documentation
• kind/feature
• kind/bug
• kind/support
• kind/cleanup: Categorizes issue or PR as related to cleaning up code, process, or technical debt.

Define Priority

我们使用GitHub标签进行优先级排序。如果问题缺少 priority 标签，则意味着尚未对其进行评审和优先级排序。

我们的目标是整个项目的一致性。但是，如果你发现你认为优先级不正确的问题，请留下评论，提供你的反建议，我们将对其进行评估。

找到并设置正确的SIG来拥有问题

各组成部分在特殊兴趣小组（SIG）之间进行划分。 机器人帮助找到合适的SIG来拥有问题。

如果你认为可以解决此问题，请仅使用 /assign 命令将其分配给自己。如果你由于权限相关的原因无法自行分配，请留下你想要声明的评论并开始处理PR。

如果问题已经有受理人，请不要将其分配给你自己，也不要在未与现有受理人交谈或未完成本文档中所述的后续步骤之前创建PR。当其他人已经在处理一个问题时创建PR不是一个好的做法，不鼓励这样做。

如果你发现分配了SIG标签的问题，但在30天内没有移动或讨论的证据，那么请轻轻地戳SIG关于此未决问题。另外，考虑参加他们的一次会议，提出这个问题。

当问题90天没有活动时，k8s-triage-robot会将 lifecycle/stale 标签添加到该问题。你可以通过抢先应用 /lifecycle frozen 标签来阻止bot，或者使用 /remove-lifecycle stale 命令删除标签。k8s-triage-robot在问题中添加了评论，包括其他细节。如果你不采取任何步骤，问题最终将自动关闭。

END 链接

• ⬆️上一节🔗 ️下一节🔗

• Ⓜ️回到目录🏠

• 🫵参与贡献💞❤️‍🔥💖)

• ✴️版权声明 © ：本书所有内容遵循CC-BY-SA 3.0协议（署名-相同方式共享）©