Documentation for Kubernetes v1.4 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


Continue your edit

Click the below link to edit the page you were just on. When you are done, press "Commit Changes" at the bottom of the screen. This will create a copy of our site on your GitHub account called a "fork." You can make other changes in your fork after it is created, if you want. When you are ready to send us all your changes, go to the index page for your fork and click "New Pull Request" to let us know about it.

Edit our site in the cloud

Click the below button to visit the repo for our site. You can then click the "Fork" button in the upper-right area of the screen to create a copy of our site on your GitHub account called a "fork." Make any changes you want in your fork, and when you are ready to send those changes to us, go to the index page for your fork and click "New Pull Request" to let us know about it.

Browse this site's source code

Instructions for Contributing to the Docs/Website

Welcome! We are very pleased you want to contribute to the documentation and/or website for Kubernetes.

You can click the “Fork” button in the upper-right area of the screen to create a copy of our site on your GitHub account called a “fork.” Make any changes you want in your fork, and when you are ready to send those changes to us, go to the index page for your fork and click “New Pull Request” to let us know about it.

For more information about contributing to the Kubernetes documentation, see:

Automatic Staging for Pull Requests

When you create a pull request (either against master or the upcoming release), your changes are staged in a custom subdomain on Netlify so that you can see your changes in rendered form before the PR is merged. You can use this to verify that everything is correct before the PR gets merged. To view your changes:

Branch structure and staging

The current version of the website is served out of the master branch. To make changes to the live docs, such as bug fixes, broken links, typos, etc, target your pull request to the master branch

The release-1.x branch stores changes for upcoming releases of Kubernetes. For example, the release-1.5 branch has changes for the 1.5 release. These changes target branches (and not master) to avoid publishing documentation updates prior to the release for which they’re relevant. If you have a change for an upcoming release of Kubernetes, target your pull request to the appropriate release branch.

The staging site for the next upcoming Kubernetes release is here: The staging site reflects the current state of what’s been merged in the release branch, or in other words, what the docs will look like for the next upcoming release. It’s automatically updated as new PRs get merged.

Staging the site locally (using Docker)

Don’t like installing stuff? Download and run a local staging server with a single docker run command.

git clone
docker run -ti --rm -v "$PWD":/k8sdocs -p 4000:4000

Then visit http://localhost:4000 to see our site. Any changes you make on your local machine will be automatically staged.

If you’re interested you can view the Dockerfile for this image.

Staging the site locally (from scratch setup)

The below commands to setup your environment for running GitHub pages locally. Then, any edits you make will be viewable on a lightweight webserver that runs on your local machine.

This will typically be the fastest way (by far) to iterate on docs changes and see them staged, once you get this set up, but it does involve several install steps that take awhile to complete, and makes system-wide modifications.

Install Ruby 2.2 or higher. If you’re on Linux, run these commands:

apt-get install software-properties-common
apt-add-repository ppa:brightbox/ruby-ng
apt-get install ruby2.2
apt-get install ruby2.2-dev

The remainder of the steps should work the same across operating systems.

To confirm you’ve installed Ruby correctly, at the command prompt run gem --version and you should get a response with your version number. Likewise you can confirm you have Git installed properly by running git --version, which will respond with your version of Git.

Install the GitHub Pages package, which includes Jekyll:

gem install github-pages

Clone our site:

git clone

Make any changes you want. Then, to see your changes locally:

jekyll serve

Your copy of the site will then be viewable at: http://localhost:4000 (or wherever Jekyll tells you).

GitHub help

If you’re a bit rusty with git/GitHub, you might want to read this for a refresher.

Common Tasks

Edit Page Titles or Change the Left Navigation

Edit the yaml files in /_data/ for the Guides, Reference, Samples, or Support areas.

You may have to exit and jekyll clean before restarting the jekyll serve to get changes to files in /_data/ to show up.

Add Images

Put the new image in /images/docs/ if it’s for the documentation, and just /images/ if it’s for the website.

For diagrams, we greatly prefer SVG files!

Include code from another file

To include a file that is hosted on this GitHub repo, insert this code:

{% include code.html language="<LEXERVALUE>" file="<RELATIVEPATH>" ghlink="<PATHFROMROOT>" %}

To include a file that is hosted in the external, main Kubernetes repo, make sure it’s added to /, and run it so that the file gets downloaded, then enter:

{% include code.html language="<LEXERVALUE>" file="<RELATIVEPATH>" k8slink="<PATHFROMK8SROOT>" %}

Using tabs for multi-language examples

By specifying some inline CSV in a varable called tabspec, you can include a file called tabs.html that generates tabs showing code examples in multiple langauges.

{% capture tabspec %}servicesample
YAML,yaml,service-sample.yaml,/docs/user-guide/services/service-sample.yaml{% endcapture %}
{% include tabs.html %}

In English, this would read: “Create a set of tabs with the alias servicesample, and have tabs visually labeled “JSON” and “YAML” that use json and yaml Rouge syntax highlighting, which display the contents of service-sample.{extension} on the page, and link to the file in GitHub at (full path).”

Example file: Pods: Multi-Container.

Use a global variable

The /_config.yml file defines some useful variables you can use when editing docs.

This keeps the docs you’re editing aligned with the Kubernetes version you’re talking about. For example, if you define a link like so, you’ll never have to worry about it going stale in future doc branches:

View the README [here]({{page.githubbranch}}/cluster/addons/

That, of course, will send users to:

(Or whatever Kubernetes release that docs branch is associated with.)

Config yaml guidelines

Guidelines for config yamls that are included in the site docs. These are the yaml or json files that contain Kubernetes object configuration to be used with kubectl create -f Config yamls should be:

Don’t assume the reader has this repository checked out, use kubectl create -f https://github... in example commands. For Docker images used in config yamls, try to use an image from an existing Kubernetes example. If creating an image for a doc, follow the example guidelines section on “Docker images” from the Kubernetes repository.


Kubernetes partners refers to the companies who contribute to the Kubernetes core codebase, extend their platform to support Kubernetes or provide managed services to users centered around the Kubernetes platform. Partners can get their services and offerings added to the partner page by completing and submitting the partner request form. Once the information and assets are verified, the partner product/services will be listed in the partner page. This would typically take 7-10 days.

Thank you!

Kubernetes thrives on community participation and we really appreciate your contributions to our site and our documentation!


Create an Issue Edit this Page