[kubernetes] Support Kubernetes v1.32.0

[mzaian]

What type of PR is this?

/kind feature

What this PR does / why we need it:
Upgrade kubernetes versions
Add hashes for kubernetes 1.32.0
Make kubernetes v1.32.0 default
Set minimum required version to Kubernetes v1.30.x
Cleanup old hashes

Which issue(s) this PR fixes:

Fixes #11856

Does this PR introduce a user-facing change?:

Make kubernetes v1.32.0 default

[mzaian]

/ok-to-test

[yankay]

ref to kubernetes/kubernetes#129462

[yankay]

Since AlmaLinux OS 8 is still under maintenance (refer to: https://endoflife.date/almalinux), I have an idea to work around this issue.

We can add kubeadm_ignore_preflight_errors in the CI to ignore the kernel version issue. Additionally, we should update the documentation at https://github.com/kubernetes-sigs/kubespray/blob/master/docs/operating_systems/centos.md#centos-8 to include instructions on how to add the configuration parameter to bypass kubeadm checks.

[VannTen]

I don't think that's a good idea (to add SystemVerification to the ignored errors) ; this is not recommended by kubeadm maintainer.

Furthermore, I don't think long-term we will be able to support RHEL 8 derivatives for the up until their full EOL (which is in 2029). cgroupv1 is already in maintenance mode in Kubernetes, and kubernetes upstream will assume a newer kernel (and this might happen for other components such as systemd, network utilies like nftables, etc ?)

IMO we might want to discuss a timeline to deprecate RHEL8 + derivatives before 2029 (which might mean several things, maybe as the same time we deprecate k8s 1.31, so 2.29 for us ?)

Maybe this particular issue is worth taking the input of a broader audience like other sig-cluster-lifecycle projects ?

[tico88612]

I'd like to add a note about the reasons for deprecating RHEL 8. The reason we can't upgrade Ansible to 10 now is to support RHEL 8 because the Python version that comes with the system is too old. Especially since Ansible 9 has been EOL for a while now (30 Nov 2024), which is not good for this project.

FYI: #11519

[VannTen]

Ansible-core 2.16 is supported for as long as RHEL 8, though, right ? (At some point we should transition to a collection first approach, when that happens we'll drop Ansible deps and depends on core directly, + collections in galaxy.yml)

[tico88612]

Ansible-core 2.16 is supported for as long as RHEL 8, though, right ? (At some point we should transition to a collection first approach, when that happens we'll drop Ansible deps and depends on core directly, + collections in galaxy.yml)

No, ansible-core 2.16 is only supported until 01 May 2025.
FYI: https://endoflife.date/ansible-core

[VannTen]

Ok, no idea where I thought I had read that, thanks 👍

[yankay]

Supporting Kubernetes 1.32 does not necessarily hinge on the discussions in Issue #11872. While Kubernetes recommends using a kernel version of at least 4.19, this does not prohibit using RHEL 8 family distributions.

These can indeed be considered as two separate issues. The choice to support certain distributions could be evaluated independently from the kernel version requirements. This allows for more flexibility in maintaining compatibility with various environments while adhering to the recommended standards.

[VannTen]

I don't think it's independent per se, but you're right that we can move forward with 1.32 support with the current state, and keep the dicussion on support on the related issue. => that will need a small documentation blurb and updating the CI with kubeadm_ignore_preflight_errors for relevant distros.

[yankay]

I don't think it's independent per se, but you're right that we can move forward with 1.32 support with the current state, and keep the dicussion on support on the related issue. => that will need a small documentation blurb and updating the CI with kubeadm_ignore_preflight_errors for relevant distros.

Thanks @VannTen

We can keep the discus RedHat 8 and support the Kubernetes 1.32.0.
It's welcome to review the new PR #11885 with RHEL8 workaround,

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mzaian

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment