Closed Nalum closed 6 months ago
Ah I see it's coming from https://github.com/stefanprodan/kubernetes-cue-schema am I okay to create PR to add these?
Though looking at this they are explicitly being removed, maybe adding another OCI artifact that holds the beta resources and another with the alpha resources would be good? Allowing module authors to pull down the versions they want?
While digging further into this I realised the issue I have is around the migration from PodSecurityPolicy
to the newer PodSecurity
Admission Controller. So the question I have now is what approach should be taken to support both options?
From 1.25
onward I believe PodSecurityPolicy
is no longer in the schema, so to use it I'd need to get 1.24
. So I guess the thing to do is have a support matrix of what version of the module supports what version of Kubernetes?
1.24 is no longer supported upstream. Beta and Alpha APIs are no longer enabled by default in Kubernetes and no managed service supports them. The reason I kept only GA APIs is that going forward only those are officially supported upstream.
That makes sense! Thank you.
When thinking about this I should be working with this in mind? https://kubernetes.io/releases/version-skew-policy/
Kubernetes GA APIs are backwards compatible, so by keeping a module up to date with the schemas of the latest Kubernetes minor release, you will ensure that your module is compatible with all supported versions. For the APIs that are made GA in the latest release, to make use of them and not break the module on older version, you can conditionally include them. Example here: https://timoni.sh/cue/module/semver-constraints/#conditionally-enabling-features-based-on-cluster-version
Thanks Stefan, much appreciated!
Maybe I've missed it in the command
timoni mod vendor k8s
but there doesn't appear to be a way to getv1beta1
etc structure versions. Is this intentional or is there a flag for the command that should pull these too?