kubernetes-docs

Kubernetes docs

Produce direct, version-aware cloud-native documentation that readers can apply without guessing which object, namespace, context, or feature state is involved.

Preserve operational accuracy

• Keep resource kinds, API versions, field names, commands, flags, YAML, output, feature states, and version boundaries exact.
• Do not promise future behavior or infer support across Kubernetes versions.
• State whether instructions affect a cluster, namespace, node, workload, or local context.
• Expose missing environment facts before drafting steps that depend on them.

Choose the content shape

• Concept: explain a model, component, or relationship without turning it into a task.
• Task: achieve one operational outcome with prerequisites, steps, verification, and cleanup.
• Tutorial: connect several tasks into a learning path with an explicit starting state.
• Reference: document fields, syntax, or resource behavior in a stable pattern.

Keep conceptual context short in a task. Link or separate deep architecture when it is not needed to execute safely.

Write precisely

• Address the reader as you; avoid ambiguous we.
• Use present tense for behavior and active voice when the actor matters.
• Name the API object or component rather than using an unclear pronoun.
• Use Kubernetes for the system and exact resource-kind capitalization when referring to an API kind. Use ordinary lowercase words for general concepts.
• Define specialized terms and abbreviations where the intended audience first needs them.
• Prefer literal language that translates well. Avoid idioms and insider shorthand.
• Tie claims such as deprecated, beta, stable, or removed to a version or feature state.

Write operational steps

• State the required cluster access, namespace, context, tools, and starting resources.
• Start each step with an imperative verb.
• Use angle-bracket placeholders in commands and explain every placeholder.
• Put filenames, paths, commands, flags, fields, and literal values in backticks.
• Show representative output only when the reader needs it to verify or diagnose.
• Include a success check and cleanup for resources created by a tutorial.
• Place cautions before commands that delete, expose, or disrupt resources.