Move Windows (windows/amd64) GameServer support from Alpha to Beta

[markmandel]

Community Question First

Before committing to this work: is anyone actually running Agones GameServers on Windows nodes in production or at scale?

Windows CI infrastructure has real ongoing cost. If there is no active user base, it may be more appropriate to deprecate Windows support rather than invest in graduating it. Please comment with your use case if you rely on Windows GameServers — that feedback will directly shape whether this issue moves forward.

---

Summary

Windows GameServer support was added as Alpha and is documented as such in both the installation matrix and the Windows GameServers guide. The missing piece for Beta graduation is continuous integration on real Windows nodes — without it we cannot assert correctness or catch regressions.

Notably, Windows support in Agones is intentionally narrow: only the SDK sidecar (sdk-server) has Windows builds. All control-plane components (controller, allocator, extensions, ping) remain Linux-only. This significantly limits the scope of CI needed.

Criteria for Beta

Per the feature stage definitions:

• No known critical bugs.
• Automated testing covers the feature.
• Documentation is up to date.

Proposed CI Approach

Add a small Windows node pool to one of the existing GKE Standard e2e clusters. Windows node pools in GKE require at least one Linux node pool for system pods — the existing clusters already satisfy this — so no new cluster is needed.

Node pool spec (suggested):

• Machine type: n2-standard-4
• Windows versions: ltsc2022 (ltsc2019 as secondary)
• Node count: 2 nodes
• Added to one of the existing build/terraform/e2e/gke-standard/ cluster configs

Test subset:

Test	What it validates
TestCreateConnect (Windows variant)	GameServer schedules on a Windows node, SDK sidecar initialises, GameServer reaches Ready, UDP connectivity works

The test uses a Windows-specific GameServer manifest (mirroring examples/simple-game-server/gameserver-windows.yaml) with nodeSelector: kubernetes.io/os: windows and the Windows simple-game-server image.

Tasks

• Community validation: Confirm there is an active user base for Windows GameServers (see question above)
• Add a Windows node pool to the Terraform config for one of the existing e2e clusters
• Ensure the simple-game-server Windows image is built and pushed as part of the release pipeline
• Add a Windows TestCreateConnect variant (or parameterise the existing test with a Windows GameServer fixture)
• Add the Windows smoke test to ci/e2e-test-cloudbuild.yaml
• Run the smoke test consistently green across ≥ 2 weeks / several PRs
• Update site/content/en/docs/Installation/_index.md: Alpha → Beta
• Update site/content/en/docs/Guides/windows-gameservers.md to remove the Alpha caveat
• Add a blog/changelog entry noting the graduation

Notes

• GKE Windows node pools require a Linux node pool — already satisfied by existing e2e clusters.
• Windows nodes cannot run the Agones control plane; this is by design and unchanged.
• A dedicated Windows smoke test is required even with Windows nodes present in the cluster. GKE taints Windows nodes with node.kubernetes.io/os=windows:NoSchedule by default, so regular e2e GameServers (Linux images, no node selector) will never schedule there. Only a GameServer spec that explicitly sets nodeSelector: kubernetes.io/os: windows and uses a Windows container image will exercise the Windows node pool.
• The smoke suite intentionally covers only the sidecar path — no allocator, fleet, or HA tests needed for Beta.