Contribute to Kubernetes docs

Kubernetes v1.16 documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.

Edit This Page

Generating Reference Pages for Kubernetes Components and Tools

This page shows how to use the update-imported-docs tool to generate reference documentation for tools and components in the Kubernetes repository.

Before you begin

  • You need a machine that is running Linux or macOS.

  • Install the following:

  • The Go binary must be in your path. The update-imported-docs tool sets your GOPATH.

  • You need to know how to create a pull request to a GitHub repository. This involves creating your own fork of the repository. For more information, see Work from a local clone.

Getting the repository

Make sure your website fork is up-to-date with the kubernetes/website master and then clone your website fork.

git clone<your_github_username>/website.git

Determine the base directory of your clone. For example, if you followed the preceding step to get the repository, your base directory is The remaining steps refer to your base directory as <web-base>.

The update-imported-docs tool generates the reference documentation for the Kubernetes components from the Kubernetes source code. The tool automatically clones the kubernetes/kubernetes repository. If you want to change the reference documentation, please follow this guide.

Overview of update-imported-docs

The update-imported-docs tool is located in the kubernetes/website/update-imported-docs/ directory. The tool consists of a Python script that reads a YAML configuration file and performs the following steps:

  1. Clones the related repositories specified in a configuration file. For the purpose of generating reference docs, the repository that is cloned by default is kubernetes-sigs/reference-docs.
  2. Runs commands under the cloned repositories to prepare the docs generator and then generates the Markdown files.
  3. Copies the generated Markdown files to a local clone of the kubernetes/website repository under locations specified in the configuration file.
  4. Updates kubectl command links from to the kubectl command reference.

When the Markdown files are in your local clone of the kubernetes/website repository, you can submit them in a pull request to kubernetes/website.

Configuration file format

Each config file may contain multiple repos that will be imported together. When necessary, you can customize the configuration file by manually editing it. You may create new config files for importing other groups of documents. Imported documents must follow these guidelines:

  1. Adhere to the Documentation Style Guide.

  2. Have title defined in the front matter. For example:

    title: Title Displayed in Table of Contents
    Rest of the .md file...
  3. Be listed in the kubernetes/website/data/reference.yml file

The following is an example of the YAML configuration file:

- name: community
  branch: master
  - src: contributors/devel/
    dst: docs/imported/community/
  - src: contributors/guide/
    dst: docs/imported/community/

Note: generate-command is an optional entry, which can be used to run a given command or a short script to generate the docs from within a repo.

Customizing the reference.yml config file

Open <web-base>/update-imported-docs/reference.yml for editing. Do not change the content for the generate-command entry unless you understand what it is doing and need to change the specified release branch.

- name: reference-docs
  # This and the generate-command below needs a change when reference-docs has
  # branches properly defined
  branch: master
  generate-command: |
    cd $GOPATH
    git clone src/
    cd src/
    git checkout release-1.16
    make generated_files
    cp -L -R vendor $GOPATH/src
    rm -r vendor
    cd $GOPATH
    go get -v
    cd src/
    make comp

In reference.yml, the files field is a list of src and dst fields. The src field specifies the location of a generated Markdown file, and the dst field specifies where to copy this file in the cloned kubernetes/website repository. For example:

- name: reference-docs
  - src: gen-compdocs/build/
    dst: content/en/docs/reference/command-line-tools-reference/

Note that when there are many files to be copied from the same source directory to the same destination directory, you can use wildcards in the value given to src and you can just provide the directory name as the value for dst. For example:

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

Running the update-imported-docs tool

After having reviewed and/or customized the reference.yaml file, you can run the update-imported-docs tool:

cd <web-base>/update-imported-docs
./update-imported-docs reference.yml

To fix relative links within your imported files, set the repo config’s gen-absolute-links property to true. You can find an example of this in release.yml.

Adding and committing changes in kubernetes/website

List the files that were generated and copied to the kubernetes/website repository:

cd <web-base>
git status

The output shows the new and modified files. For example, the output might look like this:


    modified:   content/en/docs/reference/command-line-tools-reference/
    modified:   content/en/docs/reference/command-line-tools-reference/
    modified:   content/en/docs/reference/command-line-tools-reference/
    modified:   content/en/docs/reference/command-line-tools-reference/
    modified:   content/en/docs/reference/command-line-tools-reference/
    modified:   content/en/docs/reference/setup-tools/kubeadm/generated/
    modified:   content/en/docs/reference/kubectl/

Run git add and git commit to commit the files.

Creating a pull request

Create a pull request to the kubernetes/website repository. Monitor your pull request, and respond to review comments as needed. Continue to monitor your pull request until it is merged.

A few minutes after your pull request is merged, your updated reference topics will be visible in the published documentation.

What's next