这是本节的多页打印视图。点击此处打印.

更新参考文档

1: 参考文档快速入门
2: 为上游 Kubernetes 代码库做出贡献
3: 为 Kubernetes API 生成参考文档
4: 为 kubectl 命令集生成参考文档
5: 为 Kubernetes 组件和工具生成参考文档
6:

本节的主题是描述如何生成 Kubernetes 参考指南。要生成参考文档，请参考下面的指南：

生成参考文档快速入门

1 - 参考文档快速入门

本页讨论如何使用 update-imported-docs.py 脚本来生成 Kubernetes 参考文档。此脚本将构建的配置过程自动化，并为某个发行版本生成参考文档。

准备开始

需求

你需要一台 Linux 或 macOS 机器。
你需要安装以下工具：
- Python v3.7.x
- Git
- Golang 1.13+ 版本
- 用来安装 PyYAML 的 Pip
- PyYAML v5.1.2
- make
- gcc compiler/linker
- Docker （仅用于 kubectl 命令参考）

你的 PATH 环境变量必须包含所需要的构建工具，例如 Go 程序和 python。
你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。这牵涉到创建仓库的派生（fork）副本。有关信息可进一步查看基于本地副本开展工作。

获取文档仓库

确保你的 website 派生仓库与 GitHub 上的 kubernetes/website 远程仓库（main 分支）保持同步，并克隆你的派生仓库。

mkdir github.com
cd github.com
git clone git@github.com:<your_github_username>/website.git

确定你的克隆副本的根目录。例如，如果你按照前面的步骤获取了仓库，你的根目录会是 github.com/website。接下来的步骤中，<web-base> 用来指代你的根目录。

说明：

如果你希望更改构建工具和 API 参考资料，可以阅读上游贡献指南。

update-imported-docs 的概述

脚本 update-imported-docs.py 位于 <web-base>/update-imported-docs/ 目录下，能够生成以下参考文档：

Kubernetes 组件和工具的参考页面
kubectl 命令参考文档
Kubernetes API 参考文档

脚本 update-imported-docs.py 基于 Kubernetes 源代码生成参考文档。过程中会在你的机器的 /tmp 目录下创建临时目录，克隆所需要的仓库 kubernetes/kubernetes 和 kubernetes-sigs/reference-docs 到此临时目录。脚本会将 GOPATH 环境变量设置为指向此临时目录。此外，脚本会设置三个环境变量：

K8S_RELEASE
K8S_ROOT
K8S_WEBROOT

脚本需要两个参数才能成功运行：

一个 YAML 配置文件（reference.yml）
一个发行版本字符串，例如：1.17

配置文件中包含 generate-command 字段，其中定义了一系列来自于 kubernetes-sigs/reference-docs/Makefile 的构建指令。变量 K8S_RELEASE 用来确定所针对的发行版本。

脚本 update-imported-docs.py 执行以下步骤：

克隆配置文件中所指定的相关仓库。就生成参考文档这一目的而言，要克隆的仓库默认为 kubernetes-sigs/reference-docs。
在所克隆的仓库下运行命令，准备文档生成器，之后生成 HTML 和 Markdown 文件。
将所生成的 HTML 和 Markdown 文件复制到 <web-base> 本地克隆副本中，放在配置文件中所指定的目录下。
更新 kubectl.md 文件中对 kubectl 命令文档的链接，使之指向 kubectl 命令参考中对应的节区。

当所生成的文件已经被放到 <web-base> 目录下，你就可以将其提交到你的派生副本中，并基于所作提交发起拉取请求（PR）到 kubernetes/website 仓库。

配置文件格式

每个配置文件可以包含多个被导入的仓库。当必要时，你可以通过手工编辑此文件进行定制。你也可以通过创建新的配置文件来导入其他文档集合。下面是 YAML 配置文件的一个例子：

repos:
- name: community
  remote: https://github.com/kubernetes/community.git
  branch: master
  files:
  - src: contributors/devel/README.md
    dst: docs/imported/community/devel.md
  - src: contributors/guide/README.md
    dst: docs/imported/community/guide.md

通过工具导入的单页面的 Markdown 文档必须遵从文档样式指南。

定制 reference.yml

打开 <web-base>/update-imported-docs/reference.yml 文件进行编辑。在不了解参考文档构造命令的情况下，不要更改 generate-command 字段的内容。你一般不需要更新 reference.yml 文件。不过也有时候上游的源代码发生变化，导致需要对配置文件进行更改（例如：Golang 版本依赖或者第三方库发生变化）。如果你遇到类似问题，请在 Kubernetes Slack 的 #sig-docs 频道联系 SIG-Docs 团队。

说明：

注意，generate-command 是一个可选项，用来运行指定命令或者短脚本以在仓库内生成文档。

在 reference.yml 文件中，files 属性包含了一组 src 和 dst 字段。 src 字段给出在所克隆的 kubernetes-sigs/reference-docs 构造目录中生成的 Markdown 文件的位置，而 dst 字段则给出了对应文件要复制到的、所克隆的 kubernetes/website 仓库中的位置。例如：

repos:
- name: reference-docs
  remote: https://github.com/kubernetes-sigs/reference-docs.git
  files:
  - src: gen-compdocs/build/kube-apiserver.md
    dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
  ...

注意，如果从同一源目录中有很多文件要复制到目标目录，你可以在为 src 所设置的值中使用通配符。这时，为 dst 所设置的值必须是目录名称。例如：

  files:
  - src: gen-compdocs/build/kubeadm*.md
    dst: content/en/docs/reference/setup-tools/kubeadm/generated/

运行 update-imported-docs 工具

你可以用如下方式运行 update-imported-docs.py 工具：

cd <web-base>/update-imported-docs
./update-imported-docs.py <configuration-file.yml> <release-version>

例如：

./update-imported-docs.py reference.yml 1.17

修复链接

配置文件 release.yml 中包含用来修复相对链接的指令。若要修复导入文件中的相对链接，将 gen-absolute-links 属性设置为 true。你可以在 release.yml 文件中找到示例。

添加并提交 kubernetes/website 中的变更

枚举新生成并复制到 <web-base> 的文件：

cd <web-base>
git status

输出显示新生成和已修改的文件。取决于上游源代码的修改多少，所生成的输出也会不同。

生成的 Kubernetes 组件文档

content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
content/en/docs/reference/command-line-tools-reference/kube-proxy.md
content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md
content/en/docs/reference/kubectl/kubectl.md

生成的 kubectl 命令参考文件

static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js
static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/css/font-awesome.min.css

生成的 Kubernetes API 参考目录与文件

static/docs/reference/generated/kubernetes-api/v1.26/index.html
static/docs/reference/generated/kubernetes-api/v1.26/js/navData.js
static/docs/reference/generated/kubernetes-api/v1.26/js/scroll.js
static/docs/reference/generated/kubernetes-api/v1.26/js/query.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.26/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.26/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.26/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.26/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.woff2

运行 git add 和 git commit 提交文件。

创建拉取请求

接下来创建一个对 kubernetes/website 仓库的拉取请求（PR）。监视所创建的 PR，并根据需要对评阅意见给出反馈。继续监视该 PR 直到其被合并为止。

当你的 PR 被合并几分钟之后，你所做的对参考文档的变更就会出现发布的文档上。

接下来

要手动设置所需的构造仓库，执行构建目标，以生成各个参考文档，可参考下面的指南：

2 - 为上游 Kubernetes 代码库做出贡献

此页面描述如何为上游 kubernetes/kubernetes 项目做出贡献，如修复 Kubernetes API 文档或 Kubernetes 组件（例如 kubeadm、kube-apiserver、kube-controller-manager 等）中发现的错误。

如果你仅想从上游代码重新生成 Kubernetes API 或 kube-* 组件的参考文档。请参考以下说明：

准备开始

你需要安装以下工具：
- Git
- Golang 的 1.13 版本或更高
- Docker
- etcd
- make
- gcc compiler/linker

你必须设置 GOPATH 环境变量，并且 etcd 的位置必须在 PATH 环境变量中。

你需要知道如何创建对 GitHub 代码仓库的拉取请求（Pull Request）。通常，这涉及创建代码仓库的派生副本。要获取更多的信息请参考创建 PR 和 GitHub 标准派生和 PR 工作流程。

基本说明

Kubernetes API 和 kube-* 组件（例如 kube-apiserver、kube-controller-manager）的参考文档是根据上游 Kubernetes 中的源代码自动生成的。

当你在生成的文档中看到错误时，你可能需要考虑创建一个 PR 用来在上游项目中对其进行修复。

克隆 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/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-generated-swagger-docs.sh
hack/update-openapi-spec.sh
hack/update-generated-protobuf.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 命令来提交你的更改。现在你有两个提交（commits）：一种包含编辑的 types.go 文件，另一种包含生成的 OpenAPI 规范和相关文件。将这两个提交分开独立。也就是说，不要 squash 你的提交。

将你的更改作为 PR 提交到 kubernetes/kubernetes 代码仓库的 master 分支。关注你的 PR，并根据需要回复 reviewer 的评论。继续关注你的 PR，直到 PR 被合并为止。

PR 57758 是修复 Kubernetes 源代码中的拼写错误的拉取请求的示例。

说明： 确定要更改的正确源文件可能很棘手。在前面的示例中，官方的源文件位于 kubernetes/kubernetes 代码仓库的 staging 目录中。但是根据你的情况，staging 目录可能不是找到官方源文件的地方。如果需要帮助，请阅读 kubernetes/kubernetes 代码仓库和相关代码仓库（例如 kubernetes/apiserver）中的 README 文件。

将你的提交 Cherrypick 到发布分支

在上一节中，你在 master 分支中编辑了一个文件，然后运行了脚本用来生成 OpenAPI 规范和相关文件。然后用 PR 将你的更改提交到 kubernetes/kubernetes 代码仓库的 master 分支中。现在，需要将你的更改反向移植到已经发布的分支。例如，假设 master 分支被用来开发 Kubernetes 1.30 版，并且你想将更改反向移植到 release-1.29 分支。

回想一下，你的 PR 有两个提交：一个用于编辑 types.go，一个用于由脚本生成的文件。下一步是将你的第一次提交 cherrypick 到 release-1.29 分支。这样做的原因是仅 cherrypick 编辑了 types.go 的提交，而不是具有脚本运行结果的提交。有关说明，请参见提出 Cherry Pick。

说明： 提出 Cherry Pick 要求你有权在 PR 中设置标签和里程碑。如果你没有这些权限，则需要与可以为你设置标签和里程碑的人员合作。

当你发起 PR 将你的一个提交 cherry pick 到 release-1.29 分支中时，下一步是在本地环境的 release-1.29 分支中运行如下脚本。

hack/update-generated-swagger-docs.sh
hack/update-openapi-spec.sh
hack/update-generated-protobuf.sh
hack/update-api-reference-docs.sh

现在将提交添加到你的 Cherry-Pick PR 中，该 PR 中包含最新生成的 OpenAPI 规范和相关文件。关注你的 PR，直到其合并到 release-1.29 分支中为止。

此时，master 分支和 release-1.29 分支都具有更新的 types.go 文件和一组生成的文件，这些文件反映了对 types.go 所做的更改。请注意，生成的 OpenAPI 规范和其他 release-1.29 分支中生成的文件不一定与 master 分支中生成的文件相同。 release-1.29 分支中生成的文件仅包含来自 Kubernetes 1.29 的 API 元素。 master 分支中生成的文件可能包含不在 1.29 中但正在为 1.30 开发的 API 元素。

生成已发布的参考文档

上一节显示了如何编辑源文件然后生成多个文件，包括在 kubernetes/kubernetes 代码仓库中的 api/openapi-spec/swagger.json。swagger.json 文件是 OpenAPI 定义文件，可用于生成 API 参考文档。

现在，你可以按照生成 Kubernetes API 的参考文档指南来生成已发布的 Kubernetes API 参考文档。

接下来

3 - 为 Kubernetes API 生成参考文档

本页面显示了如何更新 Kubernetes API 参考文档。

Kubernetes API 参考文档是从 Kubernetes OpenAPI 规范构建的，且使用kubernetes-sigs/reference-docs 生成代码。

如果你在生成的文档中发现错误，则需要在上游修复。

如果你只需要从 OpenAPI 规范中重新生成参考文档，请继续阅读此页。

准备开始

需求

你需要一台 Linux 或 macOS 机器。
你需要安装以下工具：
- Python v3.7.x
- Git
- Golang 1.13+ 版本
- 用来安装 PyYAML 的 Pip
- PyYAML v5.1.2
- make
- gcc compiler/linker
- Docker （仅用于 kubectl 命令参考）

你的 PATH 环境变量必须包含所需要的构建工具，例如 Go 程序和 python。
你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。这牵涉到创建仓库的派生（fork）副本。有关信息可进一步查看基于本地副本开展工作。

配置本地仓库

创建本地工作区并设置你的 GOPATH。

mkdir -p $HOME/<workspace>
export GOPATH=$HOME/<workspace>

获取以下仓库的本地克隆：

go get -u github.com/kubernetes-sigs/reference-docs

go get -u github.com/go-openapi/loads
go get -u github.com/go-openapi/spec

如果你还没有下载过 kubernetes/website 仓库，现在下载：

git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website

克隆 kubernetes/kubernetes 仓库作为 k8s.io/kubernetes：

git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes

kubernetes/kubernetes 仓库克隆后的根目录为 $GOPATH/src/k8s.io/kubernetes。后续步骤将此目录称为 <k8s-base>。
kubernetes/website 仓库克隆后的根目录为 $GOPATH/src/github.com/<your username>/website。后续步骤将此目录称为 <web-base>。
kubernetes-sigs/reference-docs 仓库克隆后的基本目录为 $GOPATH/src/github.com/kubernetes-sigs/reference-docs.。后续步骤将此目录称为 <rdocs-base>。

生成 API 参考文档

本节说明如何生成已发布的 Kubernetes API 参考文档。

设置构建变量

设置 K8S_ROOT 为 <k8s-base>.
设置 K8S_WEBROOT 为 <web-base>.
设置 K8S_RELEASE 为要构建的文档的版本。例如，如果你想为 Kubernetes 1.17.0 构建文档，请将 K8S_RELEASE 设置为 1.17.0。

例如：

export K8S_WEBROOT=${GOPATH}/src/github.com/<your-username>/website
export K8S_ROOT=${GOPATH}/src/k8s.io/kubernetes
export K8S_RELEASE=1.17.0

创建版本目录并复制 OpenAPI 规范

构建目标 updateapispec 负责创建版本化的构建目录。目录创建了之后，从 <k8s-base> 仓库取回 OpenAPI 规范文件。这些步骤确保配置文件的版本和 Kubernetes OpenAPI 规范的版本与发行版本匹配。版本化目录的名称形式为 v<major>_<minor>。

在 <rdocs-base> 目录中，运行以下命令来构建：

cd <rdocs-base>
make updateapispec

构建 API 参考文档

构建目标 copyapi 会生成 API 参考文档并将所生成文件复制到 <web-base 中的目录下。在 <rdocs-base> 目录中运行以下命令：

cd <rdocs-base>
make copyapi

验证是否已生成这两个文件：

[ -e "<rdocs-base>/gen-apidocs/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-apidocs/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"

进入本地 <web-base> 目录，检查哪些文件被更改：

cd <web-base>
git status

输出类似于：

static/docs/reference/generated/kubernetes-api/v1.26/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.26/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.26/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.26/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.26/fonts/fontawesome-webfont.woff2
static/docs/reference/generated/kubernetes-api/v1.26/index.html
static/docs/reference/generated/kubernetes-api/v1.26/js/jquery.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.26/js/navData.js
static/docs/reference/generated/kubernetes-api/v1.26/js/scroll.js

更新 API 参考索引页面

在为新发行版本生成参考文档时，需要更新下面的文件，使之包含新的版本号： <web-base>/content/en/docs/reference/kubernetes-api/api-index.md。

打开并编辑 <web-base>/content/en/docs/reference/kubernetes-api/api-index.md， API 参考的版本号。例如：
```
title: v1.17
[Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/)
```

打开编辑 <web-base>/content/en/docs/reference/_index.md，添加指向最新 API 参考的链接，删除最老的 API 版本。通常保留最近的五个版本的 API 参考的链接。

在本地测试 API 参考

发布 API 参考的本地版本。检查本地预览。

cd <web-base>
git submodule update --init --recursive --depth 1 # if not already done
make container-serve

提交更改

在 <web-base> 中运行 git add 和 git commit 来提交更改。

基于你所生成的更改创建 PR，提交到 kubernetes/website 仓库。监视你提交的 PR，并根据需要回复 reviewer 的评论。继续监视你的 PR，直到合并为止。

接下来

4 - 为 kubectl 命令集生成参考文档

本页面描述了如何生成 kubectl 命令参考。

说明： 本主题描述了如何为 kubectl 命令生成参考文档，如 kubectl apply 和 kubectl taint。本主题没有讨论如何生成 kubectl 组件选项的参考页面。相关说明请参见为 Kubernetes 组件和工具生成参考页面。

准备开始

需求

你需要一台 Linux 或 macOS 机器。
你需要安装以下工具：
- Python v3.7.x
- Git
- Golang 1.13+ 版本
- 用来安装 PyYAML 的 Pip
- PyYAML v5.1.2
- make
- gcc compiler/linker
- Docker （仅用于 kubectl 命令参考）

你的 PATH 环境变量必须包含所需要的构建工具，例如 Go 程序和 python。
你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。这牵涉到创建仓库的派生（fork）副本。有关信息可进一步查看基于本地副本开展工作。

配置本地仓库

创建本地工作区并设置你的 GOPATH。

mkdir -p $HOME/<workspace>
export GOPATH=$HOME/<workspace>

获取以下仓库的本地克隆：

go get -u github.com/spf13/pflag
go get -u github.com/spf13/cobra
go get -u gopkg.in/yaml.v2
go get -u kubernetes-incubator/reference-docs

如果你还没有获取过 kubernetes/website 仓库，现在获取之：

git clone https://github.com/<your-username>/website $GOPATH/src/github.com/<your-username>/website

克隆 kubernetes/kubernetes 仓库作为 k8s.io/kubernetes：

git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes

从 $GOPATH/src/k8s.io/kubernetes/vendor/github.com 中移除 spf13 软件包。

rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13

kubernetes/kubernetes 仓库提供对 kubectl 和 kustomize 源代码的访问。

确定 kubernetes/kubernetes 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 $GOPATH/src/k8s.io/kubernetes.。下文将该目录称为 <k8s-base>。

确定 kubernetes/website 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 $GOPATH/src/github.com/<your-username>/website。下文将该目录称为 <web-base>。

确定 kubernetes-sigs/reference-docs 仓库的本地主目录。例如，如果按照前面的步骤来获取该仓库，则主目录是 $GOPATH/src/github.com/kubernetes-sigs/reference-docs。下文将该目录称为 <rdocs-base>。

在本地的 k8s.io/kubernetes 仓库中，检出感兴趣的分支并确保它是最新的。例如，如果你想要生成 Kubernetes 1.29.0 的文档，可以使用以下命令：

cd <k8s-base>
git checkout v1.29.0
git pull https://github.com/kubernetes/kubernetes 1.29.0

如果不需要编辑 kubectl 源码，请按照说明配置构建变量。

编辑 kubectl 源码

kubectl 命令的参考文档是基于 kubectl 源码自动生成的。如果想要修改参考文档，可以从修改 kubectl 源码中的一个或多个注释开始。在本地 kubernetes/kubernetes 仓库中进行修改，然后向 github.com/kubernetes/kubernetes 的 master 分支提交 PR。

PR 56673 是一个对 kubectl 源码中的笔误进行修复的 PR 示例。

跟踪你的 PR，并回应评审人的评论。继续跟踪你的 PR，直到它合入到 kubernetes/kubernetes 仓库的目标分支中。

以 cherry-pick 方式将你的修改合入已发布分支

你的修改已合入 master 分支中，该分支用于开发下一个 Kubernetes 版本。如果你希望修改部分出现在已发布的 Kubernetes 版本文档中，则需要提议将它们以 cherry-pick 方式合入已发布分支。

例如，假设 master 分支正用于开发 Kubernetes 1.26 版本，而你希望将修改合入到 release-1.29 版本分支。相关的操作指南，请参见提议一个 cherry-pick。

跟踪你的 cherry-pick PR，直到它合入到已发布分支中。

说明： 提议一个 cherry-pick 需要你有在 PR 中设置标签和里程碑的权限。如果你没有，你需要与有权限为你设置标签和里程碑的人合作完成。

设置构建变量

进入 <rdocs-base> 目录, 打开 Makefile 进行编辑：

设置 K8S_ROOT 为 <k8s-base>。
设置 K8S_WEBROOT 为 <web-base>。
设置 K8S_RELEASE 为要构建文档的版本。例如，如果你想为 Kubernetes 1.29 构建文档，请将 K8S_RELEASE 设置为 1.29。

例如：

export K8S_WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes
export K8S_RELEASE=1.29

创建版本目录

构建目标 createversiondirs 会生成一个版本目录并将 kubectl 参考配置文件复制到该目录中。版本目录的名字模式为 v<major>_<minor>。

在 <rdocs-base> 目录下，执行下面的命令：

cd <rdocs-base>
make createversiondirs

从 kubernetes/kubernetes 检出一个分支

在本地 <k8s-base> 仓库中，检出你想要生成文档的、包含 Kubernetes 版本的分支。例如，如果希望为 Kubernetes 1.29.0 版本生成文档，请检出 v1.29 标记。确保本地分支是最新的。

cd <k8s-base>
git checkout v1.29.0
git pull https://github.com/kubernetes/kubernetes v1.29.0

运行文档生成代码

在本地的 <rdocs-base> 目录下，运行 copycli 构建目标。此命令以 root 账号运行：

cd <rdocs-base>
make copycli

copycli 命令将清理暂存目录，生成 kubectl 命令文件，并将整理后的 kubectl 参考 HTML 页面和文件复制到 <web-base>。

找到生成的文件

验证是否已生成以下两个文件：

[ -e "<rdocs-base>/gen-kubectldocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html"
[ -e "<rdocs-base>/gen-kubectldocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"

找到复制的文件

确认所有生成的文件都已复制到你的 <web-base>：

cd <web-base>
git status

输出应包括修改后的文件：

static/docs/reference/generated/kubectl/kubectl-commands.html
static/docs/reference/generated/kubectl/navData.js

此外，输出可能还包含：

static/docs/reference/generated/kubectl/scroll.js
static/docs/reference/generated/kubectl/stylesheet.css
static/docs/reference/generated/kubectl/tabvisibility.js
static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
static/docs/reference/generated/kubectl/node_modules/font-awesome/css/font-awesome.min.css

在本地测试文档

在本地 <web-base> 中构建 Kubernetes 文档。

cd <web-base>
git submodule update --init --recursive --depth 1 # if not already done
make container-serve

查看本地预览。

在 kubernetes/website 中添加和提交更改

运行 git add 和 git commit 提交修改文件。

创建 PR

对 kubernetes/website 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。继续跟踪你的 PR，直到它被合入。

在 PR 合入的几分钟后，你更新的参考主题将出现在已发布文档中。

接下来

5 - 为 Kubernetes 组件和工具生成参考文档

本页面描述如何构造 Kubernetes 组件和工具的参考文档。

准备开始

阅读参考文档快速入门指南中的准备工作节。

按照参考文档快速入门指引，生成 Kubernetes 组件和工具的参考文档。

接下来

6 -

需求

你需要一台 Linux 或 macOS 机器。
你需要安装以下工具：
- Python v3.7.x
- Git
- Golang 1.13+ 版本
- 用来安装 PyYAML 的 Pip
- PyYAML v5.1.2
- make
- gcc compiler/linker
- Docker （仅用于 kubectl 命令参考）

你的 PATH 环境变量必须包含所需要的构建工具，例如 Go 程序和 python。
你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。这牵涉到创建仓库的派生（fork）副本。有关信息可进一步查看基于本地副本开展工作。