Reviewed-by: Gergo-Bence Lorincz <a200452876@noreply.gitea.eco.tsi-dev.otc-service.com> Co-authored-by: qiujiandong1 <qiujiandong1@huawei.com> Co-committed-by: qiujiandong1 <qiujiandong1@huawei.com>
17 KiB
Compatibility Risks
Check Items
Read the version compatibility differences and ensure that they are not affected. The patch upgrade does not involve version compatibility differences.
Version Compatibility
Upgrade Path |
Version Difference |
Self-Check |
|---|---|---|
All upgrade scenarios |
Pay attention to Kubernetes API changes. For details, see Deprecated APIs. |
Check the API version used in the cluster. Do not use a deprecated API version. Change the API version to the one recommended in Deprecated APIs. |
v1.28 to v1.29 or v1.31 |
In Kubernetes 1.29, the startup behavior of kube-proxy has been modified. This update allows kube-proxy to use a value smaller than the node sysctl setting. For example, if the kernel value of nf_conntrack_max on a node is set to 1000000, but kube-proxy calculates a value of 131072, the value 131072 calculated by kube-proxy will be used. Community PR: https://github.com/kubernetes/kubernetes/pull/120448 |
This issue may occur on nodes that generate a large number of connections, such as gateway nodes. Check whether the value of nf_conntrack_max has been changed to a large value (for example, 4294967295 or 1000000) using sysctl. After a node is upgraded, the value calculated by kube-proxy is used, and the parameter is overwritten with a smaller value (100,000+ or 200,000+), which affects traffic during peak hours. Configure conntrack-min using kube-proxy of the node pool instead of modifying the OS kernel parameter nf_conntrack_max. For details, see Managing Node Pool Configurations. |
v1.23 or v1.25 to v1.27 |
Docker is no longer recommended. Use containerd instead. For details, see Container Engines. |
This item has been included in the pre-upgrade check. |
v1.23 to v1.25 |
Since Kubernetes v1.25, PodSecurityPolicy has been replaced by pod Security Admission. For details, see Configuring Pod Security Admission. |
|
v1.19 to v1.21 |
The bug of exec probe timeouts is fixed in Kubernetes v1.21. Before this bug is fixed, the exec probe does not consider the timeoutSeconds field. Instead, the probe will run indefinitely, even beyond its configured deadline. It will stop until the result is returned. If this field is not specified, the default value 1 is used. This field takes effect after the upgrade. If the probe runs over 1 second, the application health check may fail and the application may restart frequently. |
Before the upgrade, check whether the timeout is properly set for the exec probe. |
kube-apiserver of CCE v1.19 or later requires that the Subject Alternative Names (SANs) field be configured for the certificate of your webhook server. Otherwise, kube-apiserver fails to call the webhook server after the upgrade, and containers cannot be started properly. Root cause: X.509 CommonName is discarded in Go v1.15. kube-apiserver of CCE v1.19 is compiled using Go v1.15. If your webhook certificate does not have SANs, kube-apiserver does not process the CommonName field of the X.509 certificate as the host name by default. As a result, the authentication fails. |
Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server.
|
Init Container (Calculated Based on spec.initContainers) |
Service Container (Calculated Based on spec.containers) |
Pod (Calculated Based on spec.containers and spec.initContainers) |
Impacted or Not |
|---|---|---|---|
Guaranteed |
BestEffort |
Burstable |
Yes |
Guaranteed |
Burstable |
Burstable |
No |
Guaranteed |
Guaranteed |
Guaranteed |
No |
BestEffort |
BestEffort |
BestEffort |
No |
BestEffort |
Burstable |
Burstable |
No |
BestEffort |
Guaranteed |
Burstable |
Yes |
Burstable |
BestEffort |
Burstable |
Yes |
Burstable |
Burstable |
Burstable |
No |
Burstable |
Guaranteed |
Burstable |
Yes |