Windows Server Semi-Annual Channel end of servicing

This page provides information about the end of servicing for Windows ServerSemi-Annual Channel (SAC) node image types in Google Kubernetes Engine (GKE)Standard clusters. For instructions to migrate tosupported node images, refer toMigrate to supported Windows images.

About the Windows Server SAC removal

Microsoft is retiring the Windows Server Semi-Annual Channel on August 9, 2022.This coincides with theend of servicing for Windows Server, version 20H2.Windows Server will use the Long-Term Servicing Channel (LTSC) as the primaryrelease channel. With this change, Microsoft will no longer release criticalupdates, including security updates, for Windows Server SAC images. As a resultof this, GKE can no longer provide support for these images.

GKE Standard will no longer let you createnew nodepools that use Windows Server SAC image types. If you use one of the followingimage types in your existing node pools, you must migrate to a supported imagetype if you want to upgrade your GKE version.

  • windows_sac: Windows Server SAC with Docker
  • windows_sac_containerd: Windows Server SAC with containerd

Your existing Windows Server SAC node pools will continue to function asexpected after August 9, 2022. However, you risk exposing these nodes tosecurity vulnerabilities and platform instability because of the lack of futureupdates for SAC.

Timeline and milestones

AfterAugust 9, 2022, you can no longer do the following:

  • Create new clusters that use Windows Server SAC node images.
  • Create new node pools that use Windows Server SAC node images.
  • Enable node auto-provisioning with the--autoprovisioning-image-type flagset towindows_sac orwindows_sac_containerd.
  • Upgrade the GKE version of existing Windows Server SAC nodes.

What should you do?

We recommend that you migrate your Windows Server SAC node pools to thewindows_ltsc_containerd node image type. In GKE version 1.23and later, this is the only supported Windows Server image type for new clustersand node pools.

Thewindows_ltsc image type, which uses Docker as the container runtime, isnot supported in GKE version 1.23 and later because of theDocker node image deprecation.

Depending on your current GKE version, do the following:

  • GKE version 1.20 and earlier: Migrate your node pools tothewindows_ltsc image.
  • GKE version 1.21 and later: Migrate your node pools tothewindows_ltsc_containerd image.

Impact of migrating

If you currently use thewindows_sac image, which has Docker as the containerruntime, migrating to thewindows_ltsc_containerd image type might impact anyof your existing tooling that depends on Docker commands. For information on thepotential impact of migrating to an image type that uses containerd, refer tothe list of situations inAbout the Docker node image deprecation.

Migrate to Windows Server LTSC

The migration process consists of the following steps:

  1. Identify container images for architecture updates
  2. Build multi-arch Windows container images
  3. Update existing node pools to Windows Server LTSC

Identify container images for architecture updates

Single-architecture container images running on Windows Server SAC aren'tcompatible with Windows Server LTSC images. You'll need to identify incompatiblecontainer images and prepare to update their architecture. If you have multi-archimages, you should inspect them to make sure that the images support the WindowsServer 2019 LTSC variant, which has the version number10.0.17763.X.

Single-arch images

To inspect the supported Windows version, run the following command frominside a Windows Server SAC node where the Pod is running:

dockerimageinspectIMAGE_NAME

ReplaceIMAGE_NAME with the name of the containerimage.

If the image supports the Windows Server SAC variant, the output is similarto the following:

[  {    ...    "Architecture": "amd64",    "Os": "windows",    "OsVersion": "10.0.19042.1645" // 1645 can be any build number  }]

If the image supports the Windows Server LTSC variant, the output is similarto the following:

[  {    ...    "Architecture": "amd64",    "Os": "windows",    "OsVersion": "10.0.17763.2686" // 2686 can be any build number  }]

Multi-arch images

If you already use multi-arch Windows container images, inspect the imagesto ensure that they support the Windows Server 2019 LTSC variant, which hasthe version number10.0.17763.X.

dockermanifestinspectMANIFEST_NAME

ReplaceMANIFEST_NAME with the name of your Dockermanifest, such aseu.gcr.io/gke-release-staging/internet-explorer:v2.

The output is similar to the following:

{  {    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",    "size": 1575,    "digest": "...",    "platform": {        "architecture": "amd64",        "os": "windows",        "os.version": "10.0.17763.1935"  }}

Build multi-arch Windows container images

After you identify any images that need updates to support the Windows Server2019 LTSC variant, we recommend that you build multi-arch Windows Server images.

Building multi-arch images ensures that your containers run on any Windowsversion offered by GKE. Multi-arch images will ease yourmigration experience, because containerd detects the Windows Server LTSC versionon your migrated node pools and chooses the appropriate image from yourmanifest.

You can build these images manually, or by using the Cloud Buildgke-windows-builder. We recommend the Cloud Build builder, which isregularly updated to support new Windows Server LTSC images as they becomeavailable. For both manual and Cloud Build instructions formulti-arch images, refer toBuilding Windows Server multi-arch images.

Upgrade nodes to Windows Server LTSC

After you update your container images to support the Windows Server LTSC variant,migrate your node pools to the Windows Server LTSC node image. We stronglyrecommend that you test the migration in a staging or test cluster to ensure thatyour deployments work as intended before upgrading your production environment.To update your image, do one of the following:

  • Create new node pools and migrate workloads to the new nodes

  • Upgrade the image type on your existing node pools

Create new node pools

  1. Create a new node pool:

    gcloudcontainernode-poolscreateNODE_POOL_NAME\--cluster=CLUSTER_NAME\--image-type=WINDOWS_LTSC_IMAGE

    Replace the following:

    • NODE_POOL_NAME: the name of your new nodepool.
    • CLUSTER_NAME: the name of yourGKE cluster.
    • WINDOWS_LTSC_IMAGE: the Windows Server LTSCimage to use, which can bewindows_ltsc_containerd orwindows_ltsc.

  2. Add the following nodeSelector to your workload manifests:

    spec:...nodeSelector:kubernetes.io/os:windowscloud.google.com/gke-os-distribution:windows_ltsc

    You can also use this nodeSelector withwindows_sac as the label valueto tell GKE to avoid scheduling specific Pods on the newnodes.

  3. Deploy your updated manifests:

    kubectlapply-fMANIFEST_NAME

  4. Scale your old node pool to zero:

    gcloudcontainernode-poolsupdateOLD_POOL\--cluster=CLUSTER_NAME\--min-nodes=0\--max-nodes=NODE_COUNT

    Replace the following:

    • OLD_POOL: the name of your existing WindowsServer SAC node pool.
    • NODE_COUNT: the maximum number of nodes inthe node pool. Gradually scale this number down to 0 by repeatingthis command. If you encounter issues, scale this value back up.

  5. When fully migrated, delete the old node pool:

    gcloudcontainernode-poolsdeleteOLD_POOL\--cluster=CLUSTER_NAME

Update existing node pools

  1. Switch the node image type on your existing Windows Server SAC nodepools:

    gcloudcontainerclustersupgradeCLUSTER_NAME\--location=CONTROL_PLANE_LOCATION\--node-pool=NODE_POOL\--image-type=WINDOWS_LTSC_IMAGE

    Replace the following:

    • CLUSTER_NAME: the name of yourGKE cluster.
    • CONTROL_PLANE_LOCATION: the Compute Enginelocation of the control plane of yourcluster. Provide a region for regional clusters, or a zone for zonal clusters.
    • NODE_POOL: the name of your Windows ServerSAC node pool.
    • WINDOWS_LTSC_IMAGE: the Windows Server LTSCimage to use, which can bewindows_ltsc_containerd orwindows_ltsc.

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-18 UTC.