贡献上游 Kubernetes 代码
此页面介绍如何为上游 kubernetes/kubernetes 项目贡献代码。您可以修复 Kubernetes API 文档或 Kubernetes 组件（例如 kubeadm、kube-apiserver 和 kube-controller-manager）的内容中发现的错误。
如果您想从上游代码重新生成 Kubernetes API 或 kube-* 组件的参考文档，请参阅以下说明
开始之前
您需要安装以下工具
您的
GOPATH环境变量必须已设置，并且etcd的位置必须在您的PATH环境变量中。您需要了解如何为 GitHub 仓库创建拉取请求。通常，这涉及创建仓库的分叉。有关更多信息，请参阅 创建拉取请求 和 GitHub 标准分叉和拉取请求工作流程。
大局观
Kubernetes API 和 kube-* 组件（例如 kube-apiserver、kube-controller-manager）的参考文档会自动从 上游 Kubernetes 中的源代码生成。
当您在生成的文档中发现错误时，您可能需要考虑创建补丁以在上游项目中修复它。
克隆 Kubernetes 仓库
如果您还没有 kubernetes/kubernetes 仓库，请立即获取它
mkdir $GOPATH/src
cd $GOPATH/src
go get github.com/kubernetes/kubernetes
确定您克隆的 kubernetes/kubernetes 仓库的基本目录。例如，如果您按照前面的步骤获取仓库，您的基本目录是 $GOPATH/src/github.com/kubernetes/kubernetes。其余步骤将您的基本目录称为 <k8s-base>。
确定您克隆的 kubernetes-sigs/reference-docs 仓库的基本目录。例如，如果您按照前面的步骤获取仓库，您的基本目录是 $GOPATH/src/github.com/kubernetes-sigs/reference-docs。其余步骤将您的基本目录称为 <rdocs-base>。
编辑 Kubernetes 源代码
Kubernetes API 参考文档会自动从 OpenAPI 规范生成，该规范是从 Kubernetes 源代码生成的。如果您想更改 API 参考文档，第一步是在 Kubernetes 源代码中更改一个或多个注释。
kube-* 组件的文档也从上游源代码生成。您必须更改与您想要修复的组件相关的代码，才能修复生成的文档。
对上游源代码进行更改
说明
以下步骤只是一个示例，不是通用过程。具体细节在您的具体情况下会有所不同。以下是一个编辑 Kubernetes 源代码中注释的示例。
在您的本地 kubernetes/kubernetes 仓库中，签出默认分支，并确保它是最新的
cd <k8s-base>
git checkout master
git pull https://github.com/kubernetes/kubernetes master
假设该默认分支中的此源代码文件包含错字“atmost”
kubernetes/kubernetes/staging/src/k8s.io/api/apps/v1/types.go
在您的本地环境中，打开 types.go，并将“atmost”更改为“at most”。
验证您已更改该文件
git status
输出显示您位于主分支上，并且 types.go 源代码已被修改
On branch master
...
modified: staging/src/k8s.io/api/apps/v1/types.go
提交您编辑的文件
运行 git add 和 git commit 以提交您到目前为止所做的更改。在下一步中，您将进行第二次提交。将您的更改分成两个提交非常重要。
生成 OpenAPI 规范和相关文件
转到 <k8s-base> 并运行这些脚本
./hack/update-codegen.sh
./hack/update-openapi-spec.sh
运行 git status 以查看生成了什么。
On branch master
...
modified: api/openapi-spec/swagger.json
modified: api/openapi-spec/v3/apis__apps__v1_openapi.json
modified: pkg/generated/openapi/zz_generated.openapi.go
modified: staging/src/k8s.io/api/apps/v1/generated.proto
modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go
查看 api/openapi-spec/swagger.json 的内容，以确保已修复错字。例如，您可以运行 git diff -a api/openapi-spec/swagger.json。这很重要，因为 swagger.json 是文档生成过程的第二阶段的输入。
运行 git add 和 git commit 以提交您的更改。现在您有两个提交：一个包含编辑后的 types.go 文件，另一个包含生成的 OpenAPI 规范和相关文件。保持这两个提交分开。也就是说，不要压缩您的提交。
将您的更改作为 拉取请求 提交到 kubernetes/kubernetes 仓库的主分支。监控您的拉取请求，并根据需要回复审阅者的评论。继续监控您的拉取请求，直到它被合并。
PR 57758 是一个修复 Kubernetes 源代码中错字的拉取请求示例。
说明
确定要更改的正确源代码文件可能很棘手。在前面的示例中，权威源代码文件位于kubernetes/kubernetes 仓库的 staging 目录中。但在您的具体情况下，staging 目录可能不是查找权威源代码的地方。有关指导，请查看 kubernetes/kubernetes 仓库和相关仓库中的 README 文件，例如 kubernetes/apiserver。将您的提交 cherry-pick 到发布分支
在上一节中，您编辑了主分支中的一个文件，然后运行脚本生成 OpenAPI 规范和相关文件。然后，您将您的更改作为拉取请求提交到 kubernetes/kubernetes 仓库的主分支。现在，假设您想将您的更改 backport 到发布分支。例如，假设主分支正在用于开发 Kubernetes 1.35 版本，并且您想将您的更改 backport 到 release-1.34 分支。
回想一下，您的拉取请求有两个提交：一个用于编辑 types.go，另一个用于脚本生成的文件的提交。下一步是提出将您的第一个提交 cherry-pick 到 release-1.34 分支。想法是 cherry-pick 编辑 types.go 的提交，但不 cherry-pick 包含脚本运行结果的提交。有关说明，请参阅 提出 Cherry Pick。
说明
提出 cherry pick 需要您具有在您的拉取请求中设置标签和里程碑的权限。如果您没有这些权限，则需要与可以设置标签和里程碑的人一起工作。当您为将您的一个提交 cherry-pick 到 release-1.34 分支准备好拉取请求时，下一步是在您的本地环境的 release-1.34 分支中运行这些脚本。
./hack/update-codegen.sh
./hack/update-openapi-spec.sh
现在，将包含最近生成的 OpenAPI 规范和相关文件的提交添加到您的 cherry-pick 拉取请求中。监控您的拉取请求，直到它合并到 release-1.34 分支。
此时，主分支和 release-1.34 分支都具有您更新的 types.go 文件和一组反映您对 types.go 所做的更改的生成文件。请注意，release-1.34 分支中的生成的 OpenAPI 规范和其他生成文件不一定与主分支中的生成文件相同。release-1.34 分支中的生成文件仅包含来自 Kubernetes 1.34 的 API 元素。主分支中的生成文件可能包含 Kubernetes 1.34 中没有但正在为 1.35 开发的 API 元素。
生成已发布的参考文档
上一节介绍了如何编辑源代码，然后生成几个文件，包括 kubernetes/kubernetes 仓库中的 api/openapi-spec/swagger.json。swagger.json 文件是用于生成 API 参考文档的 OpenAPI 定义文件。
现在您可以按照 生成 Kubernetes API 参考文档 指南生成 已发布的 Kubernetes API 参考文档。