Skip to content

Audit code for Kubernetes-version specific handling #8190

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
14 tasks
sbueringer opened this issue Feb 27, 2023 · 4 comments
Open
14 tasks

Audit code for Kubernetes-version specific handling #8190

sbueringer opened this issue Feb 27, 2023 · 4 comments
Assignees
Labels
kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@sbueringer
Copy link
Member

sbueringer commented Feb 27, 2023

Goal of this issue is to audit all code in core Cluster API for Kubernetes version-specific handling and come up with an overview with which Kubernetes (and estimated Cluster API) version we can drop which code.

Tasks:

  • Audit code and write overview
    • Overview should be structured by provider and Kubernetes (and estimated Cluster API) version
  • This should include:
    • the remaining tasks of Rename references to "node-role.kubernetes.io/master" #3279 (kubeadm label & annotation migration)
      • Remove handling for nodeRoleOldControlPlane in test/framework
    • CRS controller should wait for the 'kubernetes' service ready before reconciling CRS objects #7804 (comment)
    • CRS: drop ensureKubernetesServiceCreated
    • KCP
      • Can we drop the cgroup driver override? 🌱 KCP: remove code handling Kubernetes <= v1.21 #11146 (comment)
      • Webhook validation code for 1.19:
        // Check if we're trying to upgrade to Kubernetes v1.19.0, which is not supported.
        //
        // See https://github.com/kubernetes-sigs/cluster-api/issues/3564
        if fromVersion.NE(toVersion) && toVersion.Equals(semver.MustParse("1.19.0")) {
        allErrs = append(allErrs,
        field.Forbidden(
        field.NewPath("spec", "version"),
        "cannot update Kubernetes version to v1.19.0, for more information see https://github.com/kubernetes-sigs/cluster-api/issues/3564",
        ),
        )
        return allErrs
        }
      • Webhook validation code for v1.22-v1.24:
        if (newK.Spec.KubeadmConfigSpec.ClusterConfiguration == nil ||
        newK.Spec.KubeadmConfigSpec.ClusterConfiguration.ImageRepository == "") &&
        // the version changed (i.e. we have an upgrade),
        toVersion.NE(fromVersion) &&
        // the version is >= v1.22.0 and < v1.26.0
        toVersion.GTE(kubeadm.MinKubernetesVersionImageRegistryMigration) &&
        toVersion.LT(kubeadm.NextKubernetesVersionImageRegistryMigration) &&
        // and the default registry of the new Kubernetes/kubeadm version is the old default registry.
        kubeadm.GetDefaultRegistry(toVersion) == kubeadm.OldDefaultImageRepository {
        allErrs = append(allErrs,
        field.Forbidden(
        field.NewPath("spec", "version"),
        "cannot upgrade to a Kubernetes/kubeadm version which is using the old default registry. Please use a newer Kubernetes patch release which is using the new default registry (>= v1.22.17, >= v1.23.15, >= v1.24.9)",
        ),
        )
        }
  • Check test extension for Kubernetes version handling
  • [opt] consider if/how we can add this activity to the release cycle tasks
  • [opt] create separate tasks to drop code
  • Add TODO markers for versions we can drop at a certain point
  • When v1.33 or v1.34 is our min supported mgmt cluster version we should replace some of our Pattern validation with CEL (e.g. RFC 1123 label/subdomain): ⚠️ Restructure classRef field in Cluster.spec.topology #12235 (comment) (helps to avoid mistakes in the regexp patterns)

/kind cleanup

@sbueringer sbueringer added this to the v1.5 milestone Feb 27, 2023
@sbueringer sbueringer self-assigned this Feb 27, 2023
@k8s-ci-robot k8s-ci-robot added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Feb 27, 2023
@sbueringer
Copy link
Member Author

I intentionally added this to the v1.5 milestone as we won't start this activity before then and it would be good to have for v1.5

@fabriziopandini
Copy link
Member

/triage accepted
/help

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Mar 20, 2023
@sbueringer
Copy link
Member Author

/remove-help

I'll be working on this one

@k8s-ci-robot k8s-ci-robot removed the help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. label Mar 21, 2023
@sbueringer sbueringer modified the milestones: v1.5, v1.6 Jun 21, 2023
@sbueringer sbueringer removed this from the v1.6 milestone Mar 12, 2024
@fabriziopandini
Copy link
Member

/priority important-longterm

@k8s-ci-robot k8s-ci-robot added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Apr 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

3 participants