Review and define Kubernetes versions support policy
TBU
Current
Policy for adoption/deprecation isn't documented, but we do document which version we support here: https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/doc/installation/cloud#cloud-provider-setup-for-the-gitlab-chart which reflect the min-max versions we are testing via kubeval in CI.
Additionally in our major release notes we would specifically call out which versions our CI was running e2e tests against for the .0 release of the major line. https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/doc/releases/6_0.md#kubernetes-deployment-support
New version
No documented policy, in previous years new versions started planning around the time GKE added them to the non-rapid channel, now called the regular release channel: https://cloud.google.com/kubernetes-engine/docs/release-notes-regular . This was because at the time we only had a single GKE CI cluster, this was prior to the GKE having stable and unstable channels, and we were being notified to update the cluster by google via the console UI.
Deprecation
No documented policy, but our CI typically runs one cluster that is the oldest supported by the cloud provided, and we've left documented support for any version we are still running kubeval against and have no reason to think the default install is not working. And we have continued to accept merge requests from the community that fix support in even older versions if the change does not negatively impact the charts.
Challenge
- Speed of bringing up new clusters
- Support from a tested/recommended standpoint, vs possible to run
- Commitment and support are different, as we can only guarantee +1/-1 version support from the kubectl version we ship in our images https://gitlab.com/gitlab-org/build/CNG/-/blob/master/ci_files/variables.yml#L39 https://kubernetes.io/releases/version-skew-policy/#kubectl or N-3 for the operator https://github.com/kubernetes-sigs/kubebuilder-release-tools/blob/master/VERSIONING.md#kubernetes-version-compatibility but in practice the compatibility is often greater when possible.
Acceptance criteria
-
Discuss and confirm the policy details within this issue. -
Document the policy in https://about.gitlab.com/handbook/engineering/development/enablement/systems/distribution/workflow.html#distribution-dependency-maintenance-policy. (gitlab-com/content-sites/handbook!3027 (merged)) -
Create an issue template in gitlab-org/distribution/team-tasks used to describe all work to support a new Kubernetes release (!93 (merged)). -
Create a supported releases table for Helm charts in https://gitlab.comgitlab-org/charts/gitlab/doc/installation/cloud/index.md (gitlab-org/charts/gitlab!3589 (merged)). -
Create a supported release table for Operator in https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/master/doc/installation.md. (gitlab-org/cloud-native/gitlab-operator!737 (merged)) -
Create ADR for operator in https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/tree/master/doc/adr?ref_type=heads detailing decision to use this support policy (gitlab-org/cloud-native/gitlab-operator!776 (merged)). -
Create ADR for helm charts in https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/doc/architecture?ref_type=heads detailing decision to use this support policy (gitlab-org/charts/gitlab!3679 (merged)).