Explanation
After a new version of Kubernetes has been released and when Container Engine for Kubernetes supports the new version, you can use Container Engine for Kubernetes to upgrade master nodes running older versions of Kubernetes. Because Container Engine for Kubernetes distributes the KubernetesControl Plane on multiple Oracle-managed master nodes (distributed across different availability domains in a region where supported) to ensure high availability, you're able to upgrade the Kubernetes version running on master nodes with zero downtime.
Having upgraded master nodes to a new version of Kubernetes, you can subsequently create new node pools running the newer version. Alternatively, you can continue to create new node pools that will run older versions of Kubernetes (providing those older versions are compatible with the Kubernetes version running on the master nodes).
Note that you upgrade master nodes by performing an 'in-place' upgrade, but you upgrade worker nodes by performing an 'out-of-place' upgrade. To upgrade the version of Kubernetesrunning on worker nodes in a node pool, you replace the original node pool with a new node pool that has new worker nodes running the appropriate Kubernetes version. Having 'drained' existing worker nodes in the original node pool to prevent new pods starting and to delete existing pods, you can then delete the original node pool.
Upgrading the Kubernetes Version on Worker Nodes in a Cluster:
After a new version of Kubernetes has been released and when Container Engine for Kubernetes supports the new version, you can use Container Engine for Kubernetes to upgrade master nodes running older versions of Kubernetes. Because Container Engine for Kubernetes distributes the Kubernetes Control Plane on multiple Oracle-managed master nodes (distributed across different availability domains in a region where supported) to ensure high availability, you're able to upgrade the Kubernetes version running on master nodes with zero downtime.
You can upgrade the version of Kubernetes running on the worker nodes in a clusterin two ways:
(A) Perform an 'in-place' upgrade of a node pool in the cluster, by specifying a more recent Kubernetes version for new worker nodes starting in the existing node pool. First, you modify the existing node pool's properties to specify the morerecent Kubernetes version. Then, you 'drain' existing worker nodes in the node pool to prevent new pods starting, and to delete existing pods. Finally, you terminate each of the worker nodes in turn.
When new worker nodes are started in the existing node pool, they run the more recent Kubernetes version you specified. See Performing an In-Place Worker Node Upgrade by Updating anExisting Node Pool.
(B) Perform an 'out-of-place' upgrade of a node pool in the cluster, by replacing the original node pool with a new node pool. First, you create a new node pool with a more recent Kubernetes version. Then, you 'drain' existing worker nodes in the original node pool to prevent new pods starting, and to delete existing pods.
Finally, you delete the original node pool. When new worker nodes are started in the new node pool, they run the more recent Kubernetes version you specified. See Performing an Out-of-Place Worker Node Upgrade by Replacing an Existing Node Pool with a New Node Pool.
Note that in both cases:
The more recent Kubernetes version you specify for the worker nodes in the node pool must be compatible with the Kubernetes version running on the master nodes in the cluster. See Upgrading Clusters to Newer Kubernetes Versions).
You must drain existing worker nodes in the original node pool. If you don't drain the worker nodes, workloads running onthe cluster are subject to disruption.
References:
https://docs.cloud.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengupgradingk8sworkernode.htm