Change:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be describes a bug in Kubernetes where YAML 1.2 documents are not parsed (Kubernetes does not have good support for YAML 1.1), but then also Kubernetes does incorrectly parse completely valid YAML 1.1 the way that the specification defines. Why is this needed The bug makes it hard for some people, using conformant libraries, to make YAML documents that Kubernetes accepts. We should document the bug so that readers are aware of the shortcomings here. Comments /wg api-expression /language en /priority backlog
/triage accepted
i can help you because I'm new to it so if i can tag along i will be able to learn a lot
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
would you add this as a warning note in ?
/assign

Discussion:
- Put object descriptions in annotations, to allow better introspection. <ins> {{< note >}} There is a breaking change introduced in the [YAML 1.2](https://yaml.org/spec/1.2.0/#id2602744) boolean values specification with respect to [YAML 1.1](https://yaml.org/spec/1.1/#id864510). This is a known [issue](https://github.com/kubernetes/kubernetes/issues/34146) in Kubernetes. YAML 1.2 only recognizes **true** and **false** as valid booleans, while YAML 1.1 also accepts **yes**, **no**, **on**, and  **off** as booleans. However, Kubernetes uses YAML [parsers](https://github.com/kubernetes/kubernetes/issues/34146#issuecomment-252692024) that are mostly compatible with YAML 1.1, which means that using **yes** or **no** instead of **true** or **false** in a YAML manifest may cause unexpected errors or behaviors. To avoid this issue, it is recommended to always use **true** or **false** for boolean values in YAML manifests, and to quote any strings that may be confused with booleans, such as **"yes"** or **"no"**. Besides booleans, there are additional specifications changes between YAML versions. Please refer to the [YAML Specification Changes](https://spec.yaml.io/main/spec/1.2.2/ext/changes) documentation for a comprehensive list. {{< /note >}} </ins> ## "Naked" Pods versus ReplicaSets, Deployments, and Jobs {#naked-pods-vs-replicasets-deployments-and-jobs} - Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or

Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.

Different kinds of object can also have different `.status`; again, the API reference pages detail the structure of that `.status` field, and its content for each different type of object. <ins> {{< note >}} See [Configuration Best Practices](/docs/concepts/configuration/overview/) for additional information on writing YAML configuration files. {{< /note >}} </ins> ## Server side field validation Starting with Kubernetes v1.25, the API server offers server side