You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"CIS GKE Benchmark Recommendation: 6.5.3. Ensure Node Auto-Upgrade is enabled for GKE nodes
[...]
In Google Kubernetes Engine, the masters are patched and upgraded for you automatically. Node auto-upgrade also automatically upgrades nodes in your cluster."
"Node pools with auto-upgrades enabled are scheduled for upgrades when they meet the selection criteria (announced in the release notes). Rollouts are phased across multiple weeks to ensure cluster and fleet stability.
[...]
Note: Enabling auto-upgrades does not cause your nodes to upgrade immediately. For more information, see Cluster and node upgrades."
"When you create a cluster using the Google Cloud Console, auto-upgrade is enabled on the cluster and its node pools by default, and Google upgrades your clusters when a new GKE version is selected for auto-upgrade.
When you create a cluster using the gcloud command or the GKE API, node auto-upgrade is currently enabled by default."
"New GKE versions are released regularly, but a version is not selected for auto-upgrade right away. When a GKE version has accumulated enough cluster usage to prove stability over time, Google selects it as an auto-upgrade target for clusters running a subset of older versions.
New auto-upgrade targets are announced in the release notes. Until an available version is selected for auto-upgrade, you can upgrade to it manually. Occasionally, a version is selected for cluster auto-upgrade and node auto-upgrade during different weeks."
"Regular:
Production clusters that need features not yet offered in the Stable channel.
These versions are considered production-quality. Known issues generally have known workarounds.
Stable:
Production clusters that require stability above all else, and for which frequent upgrades are too risky. These versions are considered production-quality, with historical data to indicate that they are stable and reliable in production."
"version - (Optional) The Kubernetes version for the nodes in this pool. Note that if this field and auto_upgrade are both specified, they will fight each other for what the node version should be, so setting both is highly discouraged. While a fuzzy version can be specified, it's recommended that you specify explicit versions as Terraform will see spurious diffs when fuzzy versions are used. See the google_container_engine_versions data source's version_prefix field to approximate fuzzy versions in a Terraform-compatible way."
Putting all of this together, there are a few problems that stand out:
For many production environments, pinning the k8s version (and dependency versions in general) is a requirement to avoid always being forced onto the latest version without testing.
The terraform docs say a node pool version should not be specified if auto-upgrade is also enabled. If the node pool version is set to "latest", then auto_upgrade is disabled (or conflicting with the specified version), and we're not conforming to the GKE hardening recommendations.
Looking at the current output of gcloud container get-server-config --region us-central1, and comparing it to the GKE release notes reveals that currently:
We probably shouldn't be forcing version "latest" (1.15.9-gke.12), as it is ahead of the "regular" channel (1.15.9-gke.8). If we want something newer than the default "stable" channel 1.14.x releases, a better option would be to configure the cluster to use the "regular" channel with auto_upgrade, rather than explicitly setting the version.
The text was updated successfully, but these errors were encountered:
Transfered from #451
@morgante I traced this out last week, and found that it does not appear to conform to the GKE hardening recommendations.
https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#upgrade_your_infrastructure_in_a_timely_fashion_default_2019-11-11
"CIS GKE Benchmark Recommendation: 6.5.3. Ensure Node Auto-Upgrade is enabled for GKE nodes
[...]
In Google Kubernetes Engine, the masters are patched and upgraded for you automatically. Node auto-upgrade also automatically upgrades nodes in your cluster."
https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-upgrades
"Node pools with auto-upgrades enabled are scheduled for upgrades when they meet the selection criteria (announced in the release notes). Rollouts are phased across multiple weeks to ensure cluster and fleet stability.
[...]
Note: Enabling auto-upgrades does not cause your nodes to upgrade immediately. For more information, see Cluster and node upgrades."
https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-upgrades#upgrading_automatically
"When you create a cluster using the Google Cloud Console, auto-upgrade is enabled on the cluster and its node pools by default, and Google upgrades your clusters when a new GKE version is selected for auto-upgrade.
When you create a cluster using the gcloud command or the GKE API, node auto-upgrade is currently enabled by default."
https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-upgrades#auto-upgrade-version-selection
"New GKE versions are released regularly, but a version is not selected for auto-upgrade right away. When a GKE version has accumulated enough cluster usage to prove stability over time, Google selects it as an auto-upgrade target for clusters running a subset of older versions.
New auto-upgrade targets are announced in the release notes. Until an available version is selected for auto-upgrade, you can upgrade to it manually. Occasionally, a version is selected for cluster auto-upgrade and node auto-upgrade during different weeks."
https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels
"Regular:
Production clusters that need features not yet offered in the Stable channel.
These versions are considered production-quality. Known issues generally have known workarounds.
Stable:
Production clusters that require stability above all else, and for which frequent upgrades are too risky. These versions are considered production-quality, with historical data to indicate that they are stable and reliable in production."
https://cloud.google.com/kubernetes-engine/docs/release-notes
https://cloud.google.com/kubernetes-engine/docs/release-notes-regular
https://cloud.google.com/kubernetes-engine/docs/release-notes-stable
https://www.terraform.io/docs/providers/google/r/container_node_pool.html#version
"version - (Optional) The Kubernetes version for the nodes in this pool. Note that if this field and auto_upgrade are both specified, they will fight each other for what the node version should be, so setting both is highly discouraged. While a fuzzy version can be specified, it's recommended that you specify explicit versions as Terraform will see spurious diffs when fuzzy versions are used. See the google_container_engine_versions data source's version_prefix field to approximate fuzzy versions in a Terraform-compatible way."
Putting all of this together, there are a few problems that stand out:
We probably shouldn't be forcing version "latest" (1.15.9-gke.12), as it is ahead of the "regular" channel (1.15.9-gke.8). If we want something newer than the default "stable" channel 1.14.x releases, a better option would be to configure the cluster to use the "regular" channel with auto_upgrade, rather than explicitly setting the version.
The text was updated successfully, but these errors were encountered: