<p>The k8s documentation <a href="https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/" rel="nofollow noreferrer">Versions in CustomResourceDefinitions</a> talks about how to upgrade CRD schema and CRD objects from one version to another.</p>
<p>However, what will happen when I update/change a CRD schema WITHOUT updating its version?</p>
<p>Fr example, I have a CRD schema <code>v1/Foo</code> and two field <code>A,B</code> (written in go):</p>
<pre class="lang-golang prettyprint-override"><code>// api version: v1
type FOOSpec struct {
    A int `json:&quot;a&quot;`
    B int `json:&quot;b&quot;`
}
</code></pre>
<p>I use kubebuilder to generate the CRD manifest and apply it in the k8s cluster. After that, The field A is deleted.</p>
<pre class="lang-golang prettyprint-override"><code>// still api version: v1
type FOOSpec struct {
    B int `json:&quot;b&quot;`
}
</code></pre>
<p>Again I generate the CRD manifest and apply it in the k8s cluster. Surprisingly k8s simply accept the updated CRD schema and no warning is reported.</p>
<p>Why is that? What if I create a Foo1 object of the first schema and then create a Foo2 object in the second schema. The two object has same version (v1) but the different schema.</p>
<p>I expect k8s to report an error when updating the CRD version without upgrading the version.</p>

Owe u.
<p>You've mostly answered your own question.</p>
<p>Custom Resource <strong>Definitions</strong> (CRDs) <strong>define</strong> Kubernetes resource types in the Kubernetes API.</p>
<p>In most schema evolutions, it is developers' responsibility to version such changes correctly. Kubernetes can't challenge the developer on the definition of schemas; it must accept the developers' intent (even if problematic).</p>
<p>The issue as you've observed, it that changing the definition of a Group<em>Version</em>Kind is problematic and therefore discouraged (in production).</p>
<p>If you create Resources against CRDs, then revise the CRD (without revising its Version) and create more Resources, you've introduced inconsistency:</p>
<ul>
<li>Removed fields are not accessible in <strong>any</strong> of the CRD's Resources</li>
<li>Added|Changed fields aren't present in pre-change CRD's Resources</li>
</ul>
<p>Errors will not arise until an operation (CRUD) is attempted (by the Kubernetes API server) against the Resource.</p>
<p>Kubernetes Kinds aren't SemVer versioned but follow a limited set of enumerations eg. v1alpha1, v1beta1, v1, v2 ... (see e.g. <a href="https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#version-priority" rel="nofollow noreferrer">Version priority</a>). During development I tend to use e.g. v1alpha1, make changes without bumping the version and manage the house-keeping. Once you publish a CRD, it's important to bump versions so that you do not break your users.</p>
