Change:
Set the value of the `replicas` field to 2. | Set the value of the `replicas` field to `2`. {{< /table >}} <ins> ## Referring to Kubernetes API resources This section talks about how we reference API resources in the documentation. ### Clarification about "resource" Kubernetes uses the word "resource" to refer to API resources, such as `pod`, `deployment`, and so on. We also use "resource" to talk about CPU and memory requests and limits. Always refer to API resources as "API resources" to avoid confusion with CPU and memory resources. ### When to use Kubernetes API terminologies The different Kubernetes API terminologies are: - Resource type: the name used in the API URL (such as `pods`, `namespaces`) - Resource: a single instance of a resource type (such as `pod`, `secret`) - Object: a resource that serves as a "record of intent". An object is a desired state for a specific part of your cluster, which the Kubernetes control plane tries to maintain. Always use "resource" or "object" when referring to an API resource in docs. For example, use "a `Secret` object" over just "a `Secret`". ### API resource names Always format API resource names using [UpperCamelCase](https://en.wikipedia.org/wiki/Camel_case), also known as PascalCase, and code formatting. For inline code in an HTML document, use the `<code>` tag. In a Markdown document, use the backtick (`` ` ``). Don't split an API object name into separate words. For example, use `PodTemplateList`, not Pod Template List. For more information about PascalCase and code formatting, please review the related guidance on [Use upper camel case for API objects](/docs/contribute/style/style-guide/#use-upper-camel-case-for-api-objects) and [Use code style for inline code, commands, and API objects](/docs/contribute/style/style-guide/#code-style-inline-code). For more information about Kubernetes API terminologies, please review the related guidance on [Kubernetes API terminology](/docs/reference/using-api/api-concepts/#standard-api-terminology). </ins> ## Code snippet formatting ### Don't include the command prompt

Discussion:
Kubernetes uses the word "resource" to refer to API resources, such as , , and so on. We also use "resource" to talk about CPU and memory requests and limits. Update the with a new section to clarify how we talk about API resources in our documentation. [ ] Add a new section under Documentation formatting standards called "Referring to Kubernetes API resources" (or similar). [ ] In your new section, add guidance for the following (use a combination of paragraphs and bulleted lists): Differentiate between an HTTP API resource and a CPU/memory resource (you can use the first line of this issue description) Differentiate between Kubernetes API terminology and when to use: Resource type: the name used in the API URL (such as , ) Resource: a single instance of a resource type (such as , ) Object: a resource that serves as a "record of intent". An object is a desired state for a specific part of your cluster, which the Kubernetes control plane tries to maintain. Add a rule to always mention "resource" or "object" when referring to an API resource in docs. For example, use "a object" over just "a ". Add a rule to always format API resource names with PascalCase and . (link users to and for full guidance) [ ] Review other API sections on the page to remove duplicate content or conflicting guidance. For example, has the following, which can be moved and merged into your new section: [ ] Link to for more information at the end of the section. /sig docs /help-wanted /cc
/language en /triage accepted
I could take this up /assign
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command.

<detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
have you completely solved this issue?
Yes, the pointers mentioned in the issue description have been addressed in the linked PR above. Kindly pick up another . Thanks for showing your interest