Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Unintended force GKE cluster Control plane upgrade before EoL with no Release channel

We found our k8s cluster control plane was upgraded before EoL, in which the cluster does not have a Release channel.  According to the document, this should not happen.  Is this a spec?  We want to manage the upgrade timing by ourselves.  https://cloud.google.com/kubernetes-engine/docs/how-to/upgrading-a-cluster

Solved Solved
1 3 1,594
2 ACCEPTED SOLUTIONS

Hi ryotahashimoto,

In cases where you have a Kubernetes cluster without a release channel, you have the flexibility to manage the upgrade timing yourself. You can choose to keep node auto-upgrade enabled or disable it and define your own node upgrade strategy.

Even if your cluster is not enrolled in a release channel, Google Kubernetes Engine (GKE) will still perform regular control plane upgrades to newer versions. These upgrades typically involve moving to the next minor version and follow a scheduled upgrades start date. To stay updated on the latest information about scheduled upgrades, you can refer to the release notes.

It's important to note that control plane upgrades cannot be disabled in GKE as infrastructure security is a top priority. However, GKE provides the option to apply maintenance windows and exclusions. By utilizing these features, you can temporarily suspend upgrades for control planes and nodes within specified time frames.

For more details on managing release channels and the behavior of clusters without a channel, you can refer to the following documentation: No Channel in GKE Release Channels.

View solution in original post

Excellent answer and I want to add a few more details on how you can best achieve your goal of staying on a given minor release until EOL.

As indicated above, "no channel" follows "stable channel" in terms of automatic upgrades.  If you want to stay on a minor version until EOL, then you should actually enroll your clusters in the STABLE release channel and setup a maintenance exclusion with either of the following scopes:

No minor upgrades - maintain current Kubernetes minor version - In this case, the control plane and node pools will be auto-upgraded to patch versions only.

No minor or node upgrades - prevent node pool disruption - In this case, only the control plane will be auto-upgraded to patch versions and you can choose to manually upgrade node pools.

View solution in original post

3 REPLIES 3

Hi ryotahashimoto,

In cases where you have a Kubernetes cluster without a release channel, you have the flexibility to manage the upgrade timing yourself. You can choose to keep node auto-upgrade enabled or disable it and define your own node upgrade strategy.

Even if your cluster is not enrolled in a release channel, Google Kubernetes Engine (GKE) will still perform regular control plane upgrades to newer versions. These upgrades typically involve moving to the next minor version and follow a scheduled upgrades start date. To stay updated on the latest information about scheduled upgrades, you can refer to the release notes.

It's important to note that control plane upgrades cannot be disabled in GKE as infrastructure security is a top priority. However, GKE provides the option to apply maintenance windows and exclusions. By utilizing these features, you can temporarily suspend upgrades for control planes and nodes within specified time frames.

For more details on managing release channels and the behavior of clusters without a channel, you can refer to the following documentation: No Channel in GKE Release Channels.

Excellent answer and I want to add a few more details on how you can best achieve your goal of staying on a given minor release until EOL.

As indicated above, "no channel" follows "stable channel" in terms of automatic upgrades.  If you want to stay on a minor version until EOL, then you should actually enroll your clusters in the STABLE release channel and setup a maintenance exclusion with either of the following scopes:

No minor upgrades - maintain current Kubernetes minor version - In this case, the control plane and node pools will be auto-upgraded to patch versions only.

No minor or node upgrades - prevent node pool disruption - In this case, only the control plane will be auto-upgraded to patch versions and you can choose to manually upgrade node pools.

Thank you for your valuable contribution, @garisingh!

Top Labels in this Space
Top Solution Authors