Updated on 2024-01-26 GMT+08:00

Before You Start

Before the upgrade, you can check whether your cluster can be upgraded and which versions are available on the CCE console. For details, see Upgrade Overview.

Precautions

Before upgrading a cluster, pay attention to the following points:

  • Upgrading a cluster cannot be rolled back. Perform an upgrade at a proper time to minimize the impact on your services. To ensure data security, you back up your data before an upgrade.
  • Before upgrading a cluster, ensure that no high-risk operations are performed in the cluster. Otherwise, the cluster upgrade may fail or the configuration may be lost after the upgrade. Common high-risk operations include modifying cluster node configurations locally and modifying the configurations of the listeners managed by CCE on the ELB console. Instead, modify configurations on the CCE console so that the modifications can be automatically inherited during the upgrade.
  • Before upgrading a cluster, ensure the cluster is working properly.
  • Before upgrading a cluster, learn about the features and differences of each cluster version in Kubernetes Release Notes to prevent exceptions due to the use of an incompatible cluster version. For example, check whether any APIs deprecated in the target version are used in the cluster. Otherwise, calling the APIs may fail after the upgrade. For details, see Deprecated APIs.

During a cluster upgrade, pay attention to the following points that may affect your services:

  • During a cluster upgrade, do not perform any operation on the cluster. Do not stop, restart, or delete nodes during cluster upgrade. Otherwise, the upgrade will fail.
  • During a cluster upgrade, the running workloads will not be interrupted, but access to the API server will be temporarily interrupted.
  • During a cluster upgrade, the node.kubernetes.io/upgrade taint (equivalent to NoSchedule) will be added to the nodes in the cluster. The taint will be removed after the cluster is upgraded. Do not add taints with the same key name on a node. Even if the taints have different effects, they may be deleted by the system by mistake after the upgrade.

Constraints

  • CCE clusters with VM nodes can be upgraded.
  • If there are any nodes created using a private image, the cluster cannot be upgraded.
  • After the cluster is upgraded, if the containerd vulnerability of the container engine is fixed in Kubernetes Release Notes, manually restart containerd for the upgrade to take effect. The same applies to the existing pods.
  • If you mount the docker.sock file on a node to a pod using the hostPath mode, that is, the Docker in Docker scenario, Docker will restart during the upgrade, but the docker.sock file does not change. As a result, your services may malfunction. You are advised to mount the docker.sock file by mounting the directory.
  • When clusters using the tunnel network model are upgraded to v1.19.16-r4, v1.21.7-r0, v1.23.5-r0, v1.25.1-r0, or later, the SNAT rule whose destination address is the container CIDR block but the source address is not the container CIDR block will be removed. If you have configured VPC routes to directly access all pods outside the cluster, only the pods on the corresponding nodes can be directly accessed after the upgrade.

Deprecated APIs

With the evolution of Kubernetes APIs, APIs are periodically reorganized or upgraded, and old APIs are deprecated and finally deleted. The following tables list the deprecated APIs in each Kubernetes community version. For details about more deprecated APIs, see Deprecated API Migration Guide.

When an API is deprecated, the existing resources are not affected. However, when you create or edit the resources, the API version will be intercepted.

Table 1 Deprecated APIs in Kubernetes v1.25

Resource Name

Deprecated API Version

Substitute API Version

Change Description

CronJob

batch/v1beta1

batch/v1

(This API is available since v1.21.)

None

EndpointSlice

discovery.k8s.io/v1beta1

discovery.k8s.io/v1

(This API is available since v1.21.)

Pay attention to the following changes:

  • In each endpoint, the topology["kubernetes.io/hostname"] field has been deprecated. Replace it with the nodeName field.
  • In each endpoint, the topology["kubernetes.io/zone"] field has been deprecated. Replace it with the zone field.
  • The topology field is replaced with deprecatedTopology and cannot be written in v1.

Event

events.k8s.io/v1beta1

events.k8s.io/v1

(This API is available since v1.19.)

Pay attention to the following changes:

  • The type field can only be set to Normal or Warning.
  • The involvedObject field is renamed regarding.
  • The action, reason, reportingController, and reportingInstance fields are mandatory for creating a new events.k8s.io/v1 event.
  • Use eventTime instead of the deprecated firstTimestamp field (this field has been renamed deprecatedFirstTimestamp and is not allowed to appear in the new events.k8s.io/v1 event object).
  • Use series.lastObservedTime instead of the deprecated lastTimestamp field (this field has been renamed deprecatedLastTimestamp and is not allowed to appear in the new events.k8s.io/v1 event object).
  • Use series.count instead of the deprecated count field (this field has been renamed deprecatedCount and is not allowed to appear in the new events.k8s.io/v1 event object).
  • Use reportingController instead of the deprecated source.component field (this field has been renamed deprecatedSource.component and is not allowed to appear in the new events.k8s.io/v1 event object).
  • Use reportingInstance instead of the deprecated source.host field (this field has been renamed deprecatedSource.host and is not allowed to appear in the new events.k8s.io/v1 event object).

HorizontalPodAutoscaler

autoscaling/v2beta1

autoscaling/v2

(This API is available since v1.23.)

None

PodDisruptionBudget

policy/v1beta1

policy/v1

(This API is available since v1.21.)

If spec.selector is set to null ({}) in PodDisruptionBudget of policy/v1, all pods in the namespace are selected. (In policy/v1beta1, an empty spec.selector means that no pod will be selected.) If spec.selector is not specified, pod will be selected in neither API version.

PodSecurityPolicy

policy/v1beta1

None

Since v1.25, the PodSecurityPolicy resource no longer provides APIs of the policy/v1beta1 version, and the PodSecurityPolicy access controller is deleted.

Replace it with Configuring Pod Security Admission.

RuntimeClass

node.k8s.io/v1beta1

node.k8s.io/v1 (This API is available since v1.20.)

None

Table 2 Deprecated APIs in Kubernetes v1.22

Resource Name

Deprecated API Version

Substitute API Version

Change Description

MutatingWebhookConfiguration

ValidatingWebhookConfiguration

admissionregistration.k8s.io/v1beta1

admissionregistration.k8s.io/v1

(This API is available since v1.16.)

  • The default value of webhooks[*].failurePolicy is changed from Ignore to Fail in v1.
  • The default value of webhooks[*].matchPolicy is changed from Exact to Equivalent in v1.
  • The default value of webhooks[*].timeoutSeconds is changed from 30s to 10s in v1.
  • The default value of webhooks[*].sideEffects is deleted, and this field must be specified. In v1, the value can only be None or NoneOnDryRun.
  • The default value of webhooks[*].admissionReviewVersions is deleted. In v1, this field must be specified. (AdmissionReview v1 and v1beta1 are supported.)
  • webhooks[*].name must be unique in the list of objects created through admissionregistration.k8s.io/v1.

CustomResourceDefinition

apiextensions.k8s.io/v1beta1

apiextensions/v1

(This API is available since v1.16.)

  • The default value of spec.scope is no longer Namespaced. This field must be explicitly specified.
  • spec.version is deleted from v1. Use spec.versions instead.
  • spec.validation is deleted from v1. Use spec.versions[*].schema instead.
  • spec.subresources is deleted from v1. Use spec.versions[*].subresources instead.
  • spec.additionalPrinterColumns is deleted from v1. Use spec.versions[*].additionalPrinterColumns instead.
  • spec.conversion.webhookClientConfig is moved to spec.conversion.webhook.clientConfig in v1.
  • spec.conversion.conversionReviewVersions is moved to spec.conversion.webhook.conversionReviewVersions in v1.
  • spec.versions[*].schema.openAPIV3Schema becomes a mandatory field when the CustomResourceDefinition object of the v1 version is created, and its value must be a structural schema.
  • spec.preserveUnknownFields: true cannot be specified when the CustomResourceDefinition object of the v1 version is created. This configuration must be specified using x-kubernetes-preserve-unknown-fields: true in the schema definition.
  • In v1, the JSONPath field in the additionalPrinterColumns entry is renamed jsonPath (patch #66531).

APIService

apiregistration/v1beta1

apiregistration.k8s.io/v1

(This API is available since v1.10.)

None

TokenReview

authentication.k8s.io/v1beta1

authentication.k8s.io/v1

(This API is available since v1.6.)

None

LocalSubjectAccessReview

SelfSubjectAccessReview

SubjectAccessReview

SelfSubjectRulesReview

authorization.k8s.io/v1beta1

authorization.k8s.io/v1

(This API is available since v1.16.)

spec.group was renamed spec.groups in v1 (patch #32709).

CertificateSigningRequest

certificates.k8s.io/v1beta1

certificates.k8s.io/v1

(This API is available since v1.19.)

Pay attention to the following changes in certificates.k8s.io/v1:
  • For an API client that requests a certificate:
    • spec.signerName becomes a mandatory field (see Known Kubernetes Signers). In addition, the certificates.k8s.io/v1 API cannot be used to create requests whose signer is kubernetes.io/legacy-unknown.
    • spec.usages now becomes a mandatory field, which cannot contain duplicate string values and can contain only known usage strings.
  • For an API client that needs to approve or sign a certificate:
    • status.conditions cannot contain duplicate types.
    • The status.conditions[*].status field is now mandatory.
    • The status.certificate must be PEM-encoded and can contain only the CERTIFICATE data block.

Lease

coordination.k8s.io/v1beta1

coordination.k8s.io/v1

(This API is available since v1.14.)

None

Ingress

networking.k8s.io/v1beta1

extensions/v1beta1

networking.k8s.io/v1

(This API is available since v1.19.)

  • The spec.backend field is renamed spec.defaultBackend.
  • The serviceName field of the backend is renamed service.name.
  • The backend servicePort field represented by a number is renamed service.port.number.
  • The backend servicePort field represented by a string is renamed service.port.name.
  • The pathType field is mandatory for all paths to be specified. The options are Prefix, Exact, and ImplementationSpecific. To match the behavior of not defining the path type in v1beta1, use ImplementationSpecific.

IngressClass

networking.k8s.io/v1beta1

networking.k8s.io/v1

(This API is available since v1.19.)

None

ClusterRole

ClusterRoleBinding

Role

RoleBinding

rbac.authorization.k8s.io/v1beta1

rbac.authorization.k8s.io/v1

(This API is available since v1.8.)

None

PriorityClass

scheduling.k8s.io/v1beta1

scheduling.k8s.io/v1

(This API is available since v1.14.)

None

CSIDriver

CSINode

StorageClass

VolumeAttachment

storage.k8s.io/v1beta1

storage.k8s.io/v1

  • CSIDriver is available in storage.k8s.io/v1 since v1.19.
  • CSINode is available in storage.k8s.io/v1 since v1.17.
  • StorageClass is available in storage.k8s.io/v1 since v1.6.
  • VolumeAttachment is available in storage.k8s.io/v1 since v1.13.
Table 3 Deprecated APIs in Kubernetes v1.16

Resource Name

Deprecated API Version

Substitute API Version

Change Description

NetworkPolicy

extensions/v1beta1

networking.k8s.io/v1

(This API is available since v1.8.)

None

DaemonSet

extensions/v1beta1

apps/v1beta2

apps/v1

(This API is available since v1.9.)

  • The spec.templateGeneration field is deleted.
  • spec.selector is now a mandatory field and cannot be changed after the object is created. The label of an existing template can be used as a selector for seamless migration.
  • The default value of spec.updateStrategy.type is changed to RollingUpdate (the default value in the extensions/v1beta1 API version is OnDelete).

Deployment

extensions/v1beta1

apps/v1beta1

apps/v1beta2

apps/v1

(This API is available since v1.9.)

  • The spec.rollbackTo field is deleted.
  • spec.selector is now a mandatory field and cannot be changed after the Deployment is created. The label of an existing template can be used as a selector for seamless migration.
  • The default value of spec.progressDeadlineSeconds is changed to 600 seconds (the default value in extensions/v1beta1 is unlimited).
  • The default value of spec.revisionHistoryLimit is changed to 10. (In the apps/v1beta1 API version, the default value of this field is 2. In the extensions/v1beta1 API version, all historical records are retained by default.)
  • The default values of maxSurge and maxUnavailable are changed to 25%. (In the extensions/v1beta1 API version, these fields default to 1.)

StatefulSet

apps/v1beta1

apps/v1beta2

apps/v1

(This API is available since v1.9.)

  • spec.selector is now a mandatory field and cannot be changed after the StatefulSet is created. The label of an existing template can be used as a selector for seamless migration.
  • The default value of spec.updateStrategy.type is changed to RollingUpdate (the default value in the apps/v1beta1 API version is OnDelete).

ReplicaSet

extensions/v1beta1

apps/v1beta1

apps/v1beta2

apps/v1

(This API is available since v1.9.)

spec.selector is now a mandatory field and cannot be changed after the object is created. The label of an existing template can be used as a selector for seamless migration.

PodSecurityPolicy

extensions/v1beta1

policy/v1beta1

(This API is available since v1.10.)

PodSecurityPolicy for the policy/v1beta1 API version will be removed in v1.25.

Version Differences

Upgrade Path

Version Difference

Self-Check

v1.23 to v1.25

Since Kubernetes v1.25, PodSecurityPolicy has been replaced by pod Security Admission (Configuring Pod Security Admission).

  • To migrate PodSecurityPolicy capabilities to pod Security Admission, perform the following steps:
    1. Ensure that the cluster is of the latest CCE v1.23 version.
    2. Migrate PodSecurityPolicy capabilities to pod Security Admission. For details, see Migrating from Pod Security Policy to Pod Security Admission.
    3. After confirming that the functions are running properly after the migration, upgrade the CCE cluster to v1.25.
  • If you no longer need PodSecurityPolicy, delete PodSecurityPolicy from the cluster and upgrade the cluster to v1.25.

v1.21 to v1.23

For the Nginx Ingress Controller of an earlier version (community version v0.49 or earlier, or CCE nginx-ingress version v1.x.x), the created ingresses can be managed by the Nginx Ingress Controller even if kubernetes.io/ingress.class: nginx is not set in the ingress annotations. However, for the Nginx Ingress Controller of a later version (community version v1.0.0 or later, or CCE nginx-ingress version v2.x.x), the ingresses created without specifying the Nginx type will not be managed by the Nginx Ingress Controller, and ingress rules will become invalid, which interrupts services.

See nginx-ingress Upgrade Check.

v1.19 to v1.23

v1.19 to v1.21

The bug of exec probe timeouts is fixed in Kubernetes 1.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 1.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 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.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.

  • If you do not have your own webhook server, you can skip this check.
  • If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate.

v1.15 to v1.19

The control plane of CCE clusters of v1.19 is incompatible with kubelet v1.15. If a node fails to be upgraded or the node to be upgraded restarts after the master node is successfully upgraded, there is a high probability that the node is in the NotReady status.

This is because the node failed to be upgraded restarts the kubelet and trigger the node registration. In clusters of v1.15, the default registration tags (failure-domain.beta.kubernetes.io/is-baremetal and kubernetes.io/availablezone) are regarded as invalid tags by the clusters of v1.19.

The valid tags in the clusters of v1.19 are node.kubernetes.io/baremetal and failure-domain.beta.kubernetes.io/zone.

  1. In normal cases, this scenario is not triggered.
  2. After the master node is upgraded, do not suspend the upgrade so the node can be quickly upgraded.
  3. If a node fails to be upgraded and cannot be restored, evict applications on the node as soon as possible. Contact technical support and skip the node upgrade. After the upgrade is complete, reset the node.

In CCE 1.15 and 1.19 clusters, the Docker storage driver file system is switched from XFS to Ext4. As a result, the import package sequence in the pods of the upgraded Java application may be abnormal, causing pod exceptions.

Before the upgrade, check the Docker configuration file /etc/docker/daemon.json on the node. Check whether the value of dm.fs is xfs.

  • If the value is ext4 or the storage driver is Overlay, you can skip the next steps.
  • If the value is xfs, you are advised to deploy applications in the cluster of the new version in advance to test whether the applications are compatible with the new cluster version.
{
      "storage-driver": "devicemapper",
      "storage-opts": [
      "dm.thinpooldev=/dev/mapper/vgpaas-thinpool",
      "dm.use_deferred_removal=true",
      "dm.fs=xfs",
      "dm.use_deferred_deletion=true"
      ]
}

kube-apiserver of CCE 1.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 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.15. The CommonName field is processed as the host name. As a result, the authentication fails.

Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server.

  • If you do not have your own webhook server, you can skip this check.
  • If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate.
NOTICE:

To mitigate the impact of version differences on cluster upgrade, CCE performs special processing during the upgrade from 1.15 to 1.19 and still supports certificates without SANs. However, no special processing is required for subsequent upgrades. You are advised to rectify your certificate as soon as possible.

In clusters of v1.17.17 and later, CCE automatically creates pod security policies (PSPs) for you, which restrict the creation of pods with unsafe configurations, for example, pods for which net.core.somaxconn under a sysctl is configured in the security context.

After an upgrade, you can allow insecure system configurations as required. For details, see Configuring a Pod Security Policy.

If initContainer or Istio is used in the in-place upgrade of a cluster of v1.15, pay attention to the following restrictions:

In kubelet 1.16 and later versions, QoS classes are different from those in earlier versions. In kubelet 1.15 and earlier versions, only containers in spec.containers are counted. In kubelet 1.16 and later versions, containers in both spec.containers and spec.initContainers are counted. The QoS class of a pod will change after the upgrade. As a result, the container in the pod restarts.

You are advised to modify the QoS class of the service container before the upgrade to avoid this problem. For details, see Table 4.

v1.13 to v1.15

After a VPC network cluster is upgraded, the master node occupies an extra CIDR block due to the upgrade of network components. If no container CIDR block is available for the new node, the pod scheduled to the node cannot run.

Generally, this problem occurs when the nodes in the cluster are about to fully occupy the container CIDR block. For example, the container CIDR block is 10.0.0.0/16, the number of available IP addresses is 65,536, and the VPC network is allocated a CIDR block with the fixed size (using the mask to determine the maximum number of container IP addresses allocated to each node). If the upper limit is 128, the cluster supports a maximum of 512 (65536/128) nodes, including the three master nodes. After the cluster is upgraded, each of the three master nodes occupies one CIDR block. As a result, 506 nodes are supported.

Table 4 QoS class changes before and after the upgrade

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

Upgrade Backup

How to back up a node:

  • etcd database backup: CCE automatically backs up the etcd database during the cluster upgrade.
  • Master node backup (recommended, manual confirmation required): On the upgrade confirmation page, click Backup to back up the entire master node of the cluster. The backup process uses the Cloud Backup and Recovery (CBR) service and takes about 20 minutes. If there are many cloud backup tasks at the current site, the backup time may be prolonged.