Before starting with the actual upgrade process we need to identify which third party resources are going to be affected by the process. As Google has already documented in the following guide most the of the deprecated APIs in Kubernetes 1.22 are for former Beta APIs that have since graduated from Beta (v1beta1) to GA (v1). Therefore we need a way to identify which Third Party Applications are actually incompatible with the new version, so to do that I have used a cli tool called Pluto designed by Fairwinds to achieve this goal.
So in the following section I will show some of the commands I have used to ensure that both my Kubernetes Manifests deployed by Flux are compatible with the version.
pluto cli output
Actually as you can see from the screenshot from above,
I have identified that at least one Helm Chart is being affected by executing the following command: pluto detect-helm (consult the help -h to see the available parameters)
Also I have identified that the RBAC role used by Traefik is affected because Pluto can scan you local manifests either by specifying the a specific file or by specifying a specific directory by executing the following command: pluto detect-files (consult the help -h to see the available parameters) in my case I have scanned all the files inside a path by specifying pluto detect-files -d .
For now I will proceed with the upgrade process and I will remediate those issues after the upgrade has been completed. So let’s dive in…
The Upgrade process is described also by Google in the following guide. In my case I had a GKE Cluster running 1.21.14-gke.700 and I wanted to upgrade it to 1.22.12-gke.2300, actually Google will normally upgrade the Cluster Automatically both Control Plane and the respective Nodepools if you have set Auto-upgrade enabled and there is no incompatible API used.
In my case the cluster is using the default Upgrade Strategy called Surge and it is actually a Rolling Upgrade of the nodes belonging in nodepool without specific order. Of course you can create a nodepool and specify a different Upgrade strategy like Blue-Green.
So the upgrade are going to be split into two stages first of all we need to upgrade the Control Plane and then as a second stage we can proceed with the Upgrade of the Worker Nodes one Node pool at a time for sure we can initiate the upgrade process of the Nodepools in parallel.
Lets upgrade the Control Plane, we are going to execute the following command found bellow:
gcloud container clusters upgrade <cluster-name> --master \
--cluster-version 1.22.12-gke.2300
Google will warns us because it is a Breaking Change so you will see the following warning and of course we need to confirm the action before proceeding further.
Upcoming breaking change: Starting with v1.22, Kubernetes has removed several v1beta1 APIs for more stable v1 APIs. Read more about this change — https://cloud.google.com/kubernetes-engine?/docs/deprecations/apis-1-22. Please ensure that your cluster is not using any deprecated v1beta1 APIs prior to upgrading to GKE 1.22. Master of cluster [cluster-name] will be upgraded from version [1.21.14-gke.700] to version [1.22.12-gke.2300]. This operation is long-running and will block other operations on the cluster (including delete) until it has run to completion.
Do you want to continue (Y/n)?
After confirming the previous prompt in order to initiate the upgrade we can monitor the upgrade process by opening a new shell and executing the following command: gcloud container operation list (consult the help — help to see the available parameters) it will take a few minutes after that we can proceed with the upgrade of the Worker Nodes.
So lets upgrade the Default Nodepool to 1.22.12-gke.2300 by executing the following command found bellow:
gcloud container clusters upgrade <cluster-name> \
--node-pool=default-pool \
--cluster-version 1.22.12-gke.2300
Google will warns us again but this time will display slightly different warning and it will ask us also to provide our confirmation in order to proceed with the process.
All nodes in node pool [default-pool] of cluster [cluster-name] will be upgraded from version [1.21.14-gke.700] to version [1.22.12-gke.2300]. This operation is long-running and will block other operations on the cluster (including delete) until it has run to completion.
Do you want to continue (Y/n)?
And then we can monitor the process from the same terminal because GCP will inform us about the progression of the upgrade process, finally after the node have been upgraded we can run again the command gcloud container operation list in order to verify the upgrade process has been completed successfully and to find out how much time the process has needed to complete.
Perfect, that concludes this tutorial, I hope you enjoy it as much as I do, until next time, Cheers !!!
Media Attribution
I would like to thank Clark Tibbs for designing the awesome photo I am using in my posts.
Top comments (0)