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 Overview.

Precautions

Notes and Constraints

Performing Pre-upgrade Check

Before upgrading a cluster, check the health status of the cluster and nodes and ensure that they are available.

Method 1: Use the console.

On the CCE console, click Resource Management in the navigation pane, and click Clusters and Nodes separately to check whether the cluster and nodes are normal.

Method 2: Run kubectl commands.

  1. Run the following command to verify that all cluster modules are in the Healthy state:

    kubectl get cs

    Information similar to the following is displayed:
     NAME                 STATUS    MESSAGE              ERROR
 scheduler            Healthy   ok
 controller-manager   Healthy   ok
 etcd-0               Healthy   {"health": "true"}
 etcd-1               Healthy   {"health": "true"}
 etcd-2               Healthy   {"health": "true"}

    In the command output, the value of STATUS must be Healthy for all items.

  2. Run the following command to verify that all nodes are in the Ready state:

    kubectl get nodes

    All nodes must be in the Ready state.

     NAME                   STATUS    ROLES     AGE       VERSION
 xxx.xxx.xx.xx   Ready     <none>    38d       v1.9.7-r1
 xxx.xxx.xx.xx   Ready     <none>    38d       v1.9.7-r1
 xxx.xxx.xx.xx   Ready     <none>    38d       v1.9.7-r1

Pre-upgrade Checklist

Before upgrading a cluster, follow the pre-upgrade checklist to identify risks and problems in advance.

Table 2 Cluster upgrade check items

Module

Item

Cluster

Check whether the node IP addresses (including EIPs) of the current cluster are used in other configurations or whitelists.

Perform the pre-upgrade check.

Workload

Record the number and status of workloads for comparison after the upgrade.

For the databases you use (such as Direct Connect, Redis, and MongoDB), you need to consider the changes in their whitelists, routes, or security group policies in advance.

Storage

Record the storage status to check whether storage resources are lost after the upgrade.

Networking

Check and back up the load balancing services and ingresses.

If Direct Connect is used, check whether the upgrade causes changes in the IP addresses of nodes or pods where services are deployed. To handle changes, you need to enable routes on Direct Connect in advance.

Add-on

When Kubernetes 1.9 is upgraded to 1.11, the kube-dns of the cluster is uninstalled and replaced with CoreDNS. Back up the DNS address configured in kube-dns so that you can use it in CoreDNS when the domain name resolution is abnormal.

O&M

Private configurations: Check whether data plane passwords, certificates, and environment variables are configured for nodes or containers in the cluster before the upgrade. If a container is restarted (for example, the node is abnormal and the pod is re-scheduled), the configurations will be lost and your service will be abnormal.

Check and back up kernel parameters or system configurations.

Upgrade Backup

Currently, there are two backup modes for cluster upgrade:

Parent topic: Upgrading a Cluster