Disable settings.k8s.io/v1alpha1 for 3.6

[mfojtik]

Possible solutions:

• Use RuntimeConfig and parse the strings (nobody wants this ;-)
• Keep the API enabled and restrict access with policy
• Other options?

[mfojtik]

@deads2k lets kick the discussions... i'm fine with 2)

[mfojtik]

@soltysh we have to figure out what to do with "/apis/batch/v2alpha1" and @DirectXMan12 what to do with "/apis/autoscaling/v2alpha1" :-)

[deads2k]

@mfojtik I think I may have found a clever-ish spot to wire this in. Mind including a snippet of your extended args?

[mfojtik]

kubernetesMasterConfig:
  admissionConfig:
    pluginConfig: null
  apiLevels: null
  apiServerArguments:
    runtime-config:
    - apis/settings.k8s.io/v1alpha1=true

[DirectXMan12]

For autoscaling/v2alpha1 is there a reason not to just leave it enabled? All the functionality is available via annotations in v1 due the the round-trip requirements, so it's not like we're actually preventing anything from being used...

[deads2k]

For autoscaling/v2alpha1 is there a reason not to just leave it enabled? All the functionality is available via annotations in v1 due the the round-trip requirements, so it's not like we're actually preventing anything from being used...

Part of the concern is the possibility of adding other types to the version later on. If we enable it now and have to disable it later, we are not being helpful.

[deads2k]

@mfojtik alright, I think I found a way to plumb it in here: #14941 if you want to pick that commit and build out from it.

[soltysh]

@soltysh we have to figure out what to do with "/apis/batch/v2alpha1"

We need to leave it enabled, otherwise we'll break existing clusters. On by default, with option to disable it.

[deads2k]

@DirectXMan12 is there a backwards compatibility concern or a critical feature in v2alph1 we need?

[DirectXMan12]

@deads2k no, there's no backwards compat concern, since v2alpha1 is new this release. It should be fine to disable it by default and then people can enable it if they want.