### What happened?

We have a cluster with 3 master and 2 worker nodes. One the master node went through RHEL OS upgrade from 7.9V to 9.3V. after this upgrade of OS the kubelet packages got upgrade to 1.28.15 automatically and resulted in Node failure for which we had to downgrade the kubelet and kubeadm packages to 1.22.15 which is our current version of kubernetes. On doing so we had the node back in ready state. but after this the KUBE-SYSTEM pods running on this server are failing with crashloopback. 

### What did you expect to happen?

After the downgrade of the Kubelet and Kubeadm packages we expected the kube-system pods to run fine. 

### How can we reproduce it (as minimally and precisely as possible)?

1. Run kubernetes 1.22.15 on a RHEL server 7.9v 
2. Upgrade the OS to 9.3 RHEL version
3. You can see the Kubelet and kubeadm along with other kubenetes packages will be upgraded to 1.28V
4. now donwgrade the related k8S packages to 1.22.15V
5. now you can reproduce that Kube-system pods running this particular servers wont come up.
6. You can leave the other2 master nodes running on 1.22.15v of k8s on RHEl 7.9V

### Anything else we need to know?

I wanted to know if we can get a list of kubernetes packages or its needed dependency packages which can be avoid during the OS upgrade of RHEL from 7.9 to 9.3V.

I believe if you can give the list of packages that will get affected during the RHEL OS upgrade, would be of great help. 

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
``` Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.15", GitCommit:"1d79bc3bcccfba7466c44cc2055d6e7442e140ea", GitTreeState:"clean", BuildDate:"2022-09-21T12:18:10Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}
The connection to the server localhost:8080 was refused - did you specify the right host or port?


</details>


### Cloud provider

<details>

</details>
NA

### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```
NAME="Red Hat Enterprise Linux"
VERSION="9.3 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.3 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
BUG_REPORT_URL="https://issues.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_BUGZILLA_PRODUCT_VERSION=9.3
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.3"

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

Kube-system pods are in crashlookbackup state when the OS is upgraded from RHEL 7.9 to 9.3.
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : Kube-system pods are in crashlookbackup state when the OS is upgraded from RHEL 7.9 to 9.3.
Issue date:

--- start body ---
### What happened?

We have a cluster with 3 master and 2 worker nodes. One the master node went through RHEL OS upgrade from 7.9V to 9.3V. after this upgrade of OS the kubelet packages got upgrade to 1.28.15 automatically and resulted in Node failure for which we had to downgrade the kubelet and kubeadm packages to 1.22.15 which is our current version of kubernetes. On doing so we had the node back in ready state. but after this the KUBE-SYSTEM pods running on this server are failing with crashloopback. 

### What did you expect to happen?

After the downgrade of the Kubelet and Kubeadm packages we expected the kube-system pods to run fine. 

### How can we reproduce it (as minimally and precisely as possible)?

1. Run kubernetes 1.22.15 on a RHEL server 7.9v 
2. Upgrade the OS to 9.3 RHEL version
3. You can see the Kubelet and kubeadm along with other kubenetes packages will be upgraded to 1.28V
4. now donwgrade the related k8S packages to 1.22.15V
5. now you can reproduce that Kube-system pods running this particular servers wont come up.
6. You can leave the other2 master nodes running on 1.22.15v of k8s on RHEl 7.9V

### Anything else we need to know?

I wanted to know if we can get a list of kubernetes packages or its needed dependency packages which can be avoid during the OS upgrade of RHEL from 7.9 to 9.3V.

I believe if you can give the list of packages that will get affected during the RHEL OS upgrade, would be of great help. 

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
``` Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.15", GitCommit:"1d79bc3bcccfba7466c44cc2055d6e7442e140ea", GitTreeState:"clean", BuildDate:"2022-09-21T12:18:10Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}
The connection to the server localhost:8080 was refused - did you specify the right host or port?


</details>


### Cloud provider

<details>

</details>
NA

### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```
NAME="Red Hat Enterprise Linux"
VERSION="9.3 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.3 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
BUG_REPORT_URL="https://issues.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_BUGZILLA_PRODUCT_VERSION=9.3
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.3"

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

--- end body ---
