为上游 Kubernetes 代码贡献
此页面展示了如何为上游的 kubernetes/kubernetes 项目贡献。你可以修复 Kubernetes API 文档中发现的 bug，或者修复 Kubernetes 组件（如 kubeadm、kube-apiserver 和 kube-controller-manager）的内容。
如果你想从上游代码重新生成 Kubernetes API 或 kube-* 组件的参考文档，请参阅以下说明
准备工作
您需要安装以下工具
你的
GOPATH环境变量必须已设置，并且etcd的位置必须在你的PATH环境变量中。你需要知道如何向 GitHub 仓库创建 pull request。通常，这涉及到创建仓库的 fork。更多信息，请参阅 创建 Pull Request 和 GitHub 标准 Fork & Pull Request 工作流程。
整体概览
Kubernetes API 和 kube-* 组件（如 kube-apiserver、kube-controller-manager）的参考文档是从 上游 Kubernetes 的源代码自动生成的。
当你发现生成文档中的 bug 时，你可能想考虑创建一个 patch 来在项目上游修复它。
克隆 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 规范自动生成的，而 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
输出显示你当前在 master 分支，并且 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 规范和相关文件的生成结果。保持这两个提交分开。也就是说，不要 squashing 你的提交。
将你的更改作为 pull request 提交到 kubernetes/kubernetes 仓库的 master 分支。监控你的 pull request，并根据需要响应审阅者的评论。继续监控你的 pull request，直到它被合并。
PR 57758 是一个修复 Kubernetes 源代码中拼写错误的 pull request 示例。
注意
确定要修改的正确源文件可能会很棘手。在前面的示例中，权威源文件位于kubernetes/kubernetes 仓库的 staging 目录中。但在你的情况下，staging 目录可能不是查找权威源的地方。有关指导，请查看 kubernetes/kubernetes 仓库以及相关仓库（如 kubernetes/apiserver）中的 README 文件。将你的提交 cherry-pick 到 release 分支
在上一节中，你编辑了一个 master 分支中的文件，然后运行脚本生成了 OpenAPI 规范和相关文件。然后，你将更改提交到了 kubernetes/kubernetes 仓库的 master 分支的 pull request。现在假设你想将你的更改 backport 到一个 release 分支。例如，假设 master 分支正用于开发 Kubernetes 1.34 版本，而你想将你的更改 backport 到 release-1.33 分支。
回想一下，你的 pull request 有两个提交：一个用于编辑 types.go，另一个用于运行脚本生成的文件。下一步是提议将你的第一个提交 cherry-pick 到 release-1.33 分支。这个想法是 cherry-pick 编辑了 types.go 的提交，但不是包含运行脚本结果的提交。有关说明，请参阅 提议 Cherry Pick。
注意
提议 cherry-pick 需要你有权限在你的 pull request 中设置标签和里程碑。如果你没有这些权限，你需要与拥有这些权限的人合作。当你有一个用于将你的一个提交 cherry-pick 到 release-1.33 分支的 pull request 时，下一步是在你的本地环境的 release-1.33 分支中运行这些脚本。
./hack/update-codegen.sh
./hack/update-openapi-spec.sh
现在，将包含最近生成的 OpenAPI 规范和相关文件的提交添加到你的 cherry-pick pull request 中。监控你的 pull request，直到它被合并到 release-1.33 分支。
此时，master 分支和 release-1.33 分支都拥有你更新的 types.go 文件以及反映你对 types.go 所做更改的一组生成文件。请注意，release-1.33 分支中的生成 OpenAPI 规范和其他生成文件不一定与 master 分支中的生成文件相同。release-1.33 分支中的生成文件仅包含 Kubernetes 1.33 的 API 元素。master 分支中的生成文件可能包含不属于 1.33 但正在为 1.34 开发的 API 元素。
生成已发布的参考文档
前面的部分展示了如何编辑源文件，然后生成几个文件，包括 kubernetes/kubernetes 仓库中的 api/openapi-spec/swagger.json。swagger.json 文件是用于生成 API 参考文档的 OpenAPI 定义文件。
你现在可以遵循 生成 Kubernetes API 参考文档 指南，来生成 已发布的 Kubernetes API 参考文档。