This page gives writing style guidelines for the Kubernetes documentation. These are guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
For additional information on creating new content for the Kubernetes docs, follow the instructions on using page templates and creating a documentation pull request.
Note: Kubernetes documentation uses GitHub Flavored Markdown.
Kubernetes documentation uses US English.
When you refer to an API object, use the same uppercase and lowercase letters that are used in the actual object name. Typically, the names of API objects use camel case.
Don’t split the API object name into separate words. For example, use PodTemplateList, not Pod Template List.
Refer to API objects without saying “object,” unless omitting “object” leads to an awkward construction.
Do | Don't |
---|---|
The Pod has two Containers. | The pod has two containers. |
The Deployment is responsible for ... | The Deployment object is responsible for ... |
A PodList is a list of Pods. | A Pod List is a list of pods. |
The two ContainerPorts ... | The two ContainerPort objects ... |
The two ContainerStateTerminated objects ... | The two ContainerStateTerminateds ... |
Use angle brackets for placeholders. Tell the reader what a placeholder represents.
Display information about a pod:
kubectl describe pod <pod-name>
where <pod-name>
is the name of one of your pods.
Do | Don't |
---|---|
Click Fork. | Click "Fork". |
Select Other. | Select 'Other'. |
Do | Don't |
---|---|
A cluster is a set of nodes ... | A "cluster" is a set of nodes ... |
These components form the control plane. | These components form the control plane. |
Do | Don't |
---|---|
Open the envars.yaml file. | Open the envars.yaml file. |
Go to the /docs/tutorials directory. | Go to the /docs/tutorials directory. |
Open the /_data/concepts.yaml file. | Open the /_data/concepts.yaml file. |
Do | Don't |
---|---|
events are recorded with an associated "stage". | events are recorded with an associated "stage." |
The copy is called a "fork". | The copy is called a "fork." |
For inline code in an HTML document, use the <code>
tag. In a Markdown
document, use the backtick (`).
Do | Don't |
---|---|
The kubectl run command creates a Deployment. | The "kubectl run" command creates a Deployment. |
For declarative management, use kubectl apply . | For declarative management, use "kubectl apply". |
Do | Don't |
---|---|
Set the value of the replicas field in the configuration file. | Set the value of the "replicas" field in the configuration file. |
The value of the exec field is an ExecAction object. | The value of the "exec" field is an ExecAction object. |
For field values of type string or integer, use normal style without quotation marks.
Do | Don't |
---|---|
Set the value of imagePullPolicy to Always. | Set the value of imagePullPolicy to "Always". |
Set the value of image to nginx:1.8. | Set the value of image to nginx:1.8 . |
Set the value of the replicas field to 2. | Set the value of the replicas field to 2 . |
Do | Don't |
---|---|
kubectl get pods | $ kubectl get pods |
Verify that the pod is running on your chosen node:
kubectl get pods --output=wide
The output is similar to this:
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
Callouts help create different rhetorical appeal levels. Our documentation supports three different callouts: Note: {: .note}, Caution: {: .caution}, and Warning: {: .warning}.
Start each callout with the appropriate prefix.
Use the following syntax to apply a style:
**Note:** The prefix you use is the same text you use in the tag.
{: .note} <!-- This tag must appear on a new line. -->
The output is:
Note: The prefix you choose is the same text for the tag.
Use {: .note} to highlight a tip or a piece of information that may be helpful to know.
For example:
**Note:** You can _still_ use Markdown inside these callouts.
{: .note}
The output is:
Note: You can still use Markdown inside these callouts.
Use {: .caution} to call attention to an important piece of information to avoid pitfalls.
For example:
**Caution:** The callout style only applies to the line directly above the tag.
{: .caution}
The output is:
Caution: The callout style only applies to the line directly above the tag.
Use {: .warning} to indicate danger or a piece of information that is crucial to follow.
For example:
**Warning:** Beware.
{: .warning}
The output is:
Warning: Beware.
Callout tags must be on a new line to apply the style. Github’s Preview Changes feature further obfuscates this fact by rendering the tag on the same line, but your code must match the following syntax:
**Note:** Your text goes here.
{: .note} <!-- This tag must appear on a new line. -->
Callouts automatically span multiple lines. However, you can use <br/>
tags if you need to create multiple lines.
For example:
**Note:"** This is my note. Use `<br/>` to create multiple lines. <br/> <br/> You can still use _Markdown_ to **format** text!
{: .note}
The output is:
Note: This is my note. Use <br/>
to create multiple lines.
You can still use Markdown to format text!
Typing multiple lines does not work. The callout style only applies to the line directly above the tag.
**Note:** This is my note.
I didn't read the style guide.
{: .note}
Note: This is my note.
I didn’t read the style guide.
Callouts will interrupt numbered lists unless you indent three spaces before the notice and the tag.
For example:
1. Preheat oven to 350˚F
1. Prepare the batter, and pour into springform pan.
**Note:** Grease the pan for best results.
{: .note}
1. Bake for 20-25 minutes or until set.
The output is:
Preheat oven to 350˚F
Prepare the batter, and pour into springform pan.
Note: Grease the pan for best results.
Bake for 20-25 minutes or until set.
This section contains suggested best practices for clear, concise, and consistent content.
Do | Don't |
---|---|
This command starts a proxy. | This command will start a proxy. |
Exception: Use future or past tense if it is required to convey the correct meaning.
Do | Don't |
---|---|
You can explore the API using a browser. | The API can be explored using a browser. |
The YAML file specifies the replica count. | The replica count is specified in the YAML file. |
Exception: Use passive voice if active voice leads to an awkward construction.
Use simple and direct language. Avoid using unnecessary phrases, such as saying “please.”
Do | Don't |
---|---|
To create a ReplicaSet, ... | In order to create a ReplicaSet, ... |
See the configuration file. | Please see the configuration file. |
View the Pods. | With this next command, we'll view the Pods. |
Do | Don't |
---|---|
You can create a Deployment by ... | We'll create a Deployment by ... |
In the preceding output, you can see... | In the preceding output, we can see ... |
Prefer English terms over Latin abbreviations.
Do | Don't |
---|---|
For example, ... | e.g., ... |
That is, ... | i.e., ... |
Exception: Use “etc.” for et cetera.
Using “we” in a sentence can be confusing, because the reader might not know whether they’re part of the “we” you’re describing.
Do | Don't |
---|---|
Version 1.4 includes ... | In version 1.4, we have added ... |
Kubernetes provides a new feature for ... | We provide a new feature ... |
This page teaches you how to use pods. | In this page, we are going to learn about pods. |
Some readers speak English as a second language. Avoid jargon and idioms to help make their understanding easier.
Do | Don't |
---|---|
Internally, ... | Under the hood, ... |
Create a new cluster. | Turn up a new cluster. |
Avoid making promises or giving hints about the future. If you need to talk about an alpha feature, put the text under a heading that identifies it as alpha information.
Avoid words like “currently” and “new.” A feature that is new today might not be considered new in a few months.
Do | Don't |
---|---|
In version 1.4, ... | In the current version, ... |
The Federation feature provides ... | The new Federation feature provides ... |