Google Kubernetes Engine Best Practices
On this page, we’ve collected several Google Kubernetes Engine (GKE) best practices.
We recommned using Release Channels for all GKE clusters. Using Release Channels has several advantages:
- Google automatically manages the version and upgrade cadence for your Kubernetes Control Plane and its nodes.
- Clusters on a Release Channel are allowed to use the
No minor upgradesand
No minor or node upgradesscope of maintenance exclusions - in other words, enrolling a cluster in a Release Channel gives you more control over node upgrades.
- Clusters enrolled in
rapidchannel have access to the newest Kubernetes version first. Agones strives to support the newest release in
rapidchannel to allow you to test the newest Kubernetes soon after it’s available in GKE.
NoteGKE Autopilot clusters must be on Release Channels.
What channel should I use?
We recommend the
regular channel, which offers a balance between stability and freshness. See this guide for more discussion.
If you need to disallow minor version upgrades for more than 6 months, consider choosing the freshest Kubernetes version possible: Choosing the freshest version on
regular will extend the amount of time before your cluster reaches end of life.
What versions are available on a given channel?
You can query the versions available across different channels using
gcloud container get-server-config \
Replace the following:
- COMPUTE_REGION: the Google Cloud region where you will create the cluster.
Managing Game Server Disruption on GKE
If your game session length is less than an hour, use the
eviction API to configure your game servers appropriately - see Controlling Disruption.
For sessions longer than an hour, there are currently two possible approaches to manage disruption:
(GKE Standard/Autopilot) Blue/green deployment at the cluster level: If you are using an automated deployment process, you can:
- create a new,
greencluster within a release channel e.g. every week,
- use maintenance exclusions to prevent node upgrades for 30d, and
- scale the
Fleeton the old,
bluecluster down to 0, and
- use multi-cluster allocation on Agones, which will then direct new allocations to the new
bluehas 0 desired), then
- delete the old,
bluecluster when the
Fleetsuccessfully scales down.
- create a new,
(GKE Standard only) Use node pool blue/green upgrades
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.
Last modified February 20, 2024: Document `Distributed` pod scheduling. (#3662) (24e7f83)