<p>We recently started upgrading our EKS clusters from 1.18 version to 1.19. One change that we did was to change our HPA manifest files to have apiVersion as autoscaling/v2beta2.
I can see all three api versions are available in my cluster</p>
<pre><code>kubectl api-versions | grep autoscaling
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
</code></pre>
<p>once the HPA file is applied autoscaling/v2beta2 is changed to autoscaling/v1. In the annotation block, I see the last applied changes showing, apiversion as autoscaling/v2beta2. Autoscaling is working fine and I don't see any errors in events. I am getting edgy to see the apiversion getting changed automatically and don't see any document explaining why is this happening and if this is expected behavior. Any inputs or explanation of this will be appreciated</p>

<p>This command show which versions are supported by your cluster</p>
<pre><code>kubectl api-versions | grep autoscaling
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
</code></pre>
<p>however, we mainly focus on which ApiVersion is getting stored in etcd database.</p>
<p>Based on my understanding, there could be chances kubectl get the resource using one <strong>ApiVersion: autoscaling/v1</strong> but you have created the resource with <code>autoscaling/v1</code> in that case if you are getting your resource using <strong>kubectl</strong> CLI, it will show the change in API version.</p>
<p><code>kubectl get</code> uses the <strong>server prefer API</strong> version, you can check it out using :</p>
<pre><code>kubectl explain hpa

KIND:     HorizontalPodAutoscaler
VERSION:  autoscaling/v1
</code></pre>
<blockquote>
<p>The differences between API versions are things like default values
and field names. Because API versions are round-trippable, you can
safely get the same deployment object with different API version
endpoints.</p>
</blockquote>
