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

返回本页常规视图.

参考文档概述

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

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

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

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

Before you begin

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

基本说明

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 源代码中的拼写错误的拉取请求的示例。

将你的提交 Cherrypick 到发布分支

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

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

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

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.23 分支中为止。

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

生成已发布的参考文档

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

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

What's next

2 - 快速入门

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

Before you begin

需求

  • 你的 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> 用来指代你的根目录。

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 执行以下步骤：

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

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

在 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.24/index.html
static/docs/reference/generated/kubernetes-api/v1.24/js/navData.js
static/docs/reference/generated/kubernetes-api/v1.24/js/scroll.js
static/docs/reference/generated/kubernetes-api/v1.24/js/query.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.24/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.24/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.24/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.24/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.woff2

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

创建拉取请求

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

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

What's next

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

3 - 为 Kubernetes API 生成参考文档

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

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

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

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

Before you begin

需求

  • 你的 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.24/css/bootstrap.min.css
static/docs/reference/generated/kubernetes-api/v1.24/css/font-awesome.min.css
static/docs/reference/generated/kubernetes-api/v1.24/css/stylesheet.css
static/docs/reference/generated/kubernetes-api/v1.24/fonts/FontAwesome.otf
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.eot
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.svg
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.ttf
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.woff
static/docs/reference/generated/kubernetes-api/v1.24/fonts/fontawesome-webfont.woff2
static/docs/reference/generated/kubernetes-api/v1.24/index.html
static/docs/reference/generated/kubernetes-api/v1.24/js/jquery.scrollTo.min.js
static/docs/reference/generated/kubernetes-api/v1.24/js/navData.js
static/docs/reference/generated/kubernetes-api/v1.24/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，直到合并为止。

What's next

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

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

Before you begin

需求

  • 你的 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.23.0 的文档，可以使用以下命令：

cd <k8s-base>
git checkout v1.23.0
git pull https://github.com/kubernetes/kubernetes 1.23.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.24 版本， 而你希望将修改合入到 release-1.23 版本分支。 相关的操作指南，请参见 提议一个 cherry-pick。

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

设置构建变量

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

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

例如：

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

创建版本目录

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

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

cd <rdocs-base>
make createversiondirs

从 kubernetes/kubernetes 检出一个分支

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

cd <k8s-base>
git checkout v1.23.0
git pull https://github.com/kubernetes/kubernetes v1.23.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 合入的几分钟后，你更新的参考主题将出现在已发布文档中。

What's next

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

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

Before you begin

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

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

What's next

6 -

需求

  • 你的 PATH 环境变量必须包含所需要的构建工具，例如 Go 程序和 python。

  • 你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。 这牵涉到创建仓库的派生（fork）副本。 有关信息可进一步查看基于本地副本开展工作。