Google's primary support objective is to resolve production incidents as quicklyas possible. We do this by understanding your configuration, analyzing logs andmetrics, and collaborating with partners to solve incidents quickly.

Cloud Customer Care offers a variety of support packages to accommodateyour support needs. All Cloud Customer Care support packages include support forGKE and Google Distributed Cloud. If you have an existingCloud Customer Care support package, then you already have support forGKE and Google Distributed Cloud.

For more information, see theCloud Customer Care hub.

Requirements for Google Distributed Cloud support

To effectively troubleshoot business-critical incidents, you must:

1. Check that the environment is current with the published end-of-supporttimeframes. For more information, see theVersion Support Policy section.
2. Enable Cloud Logging and Cloud Monitoring for system components. Formore information, see theSupport tools section.
3. When you open a support case, provide a configuration snapshot by using thegkectl diagnose snapshotcommand.

Support tools

To troubleshoot business-critical incidents effectively, Cloud Customer Care relieson three pieces of information:

• Your environment's configuration
• Logs from your admin and user clusters
• Metrics from your admin and user clusters

Configuration

When you open a support case, you are asked to run thegkectl diagnose snapshot--seed-config command and attach the resulting tar file to the support case.Thegkectl diagnose snapshot --seed-config command captures information aboutKubernetes and your nodes.

The tool is highly configurable and includes several predefined scenarios. Youcan also pass a YAML file with a customized set of information to gather. Formore information, seeDiagnosing Clusters.

Be sure to carefully review the information captured by the tool.

Do not attach highly confidential or sensitive information to your support case.You can add anexcludeWords field to your configuration file to omit sensitiveor confidential information.

Logs

When you create a new cluster, Cloud Logging agents are enabled by defaultand scoped only to system-level components. This replicates system-level logsinto the Google Cloud project associated with the cluster. System-levellogs are from Kubernetes pods running in one of the following namespaces:

• kube-system
• gke-system
• gke-connect
• istio-system
• config-management-system
• knative-serving

Logs can be queried from theCloud Logging console.

For more details, seeLogging and Monitoring.

Metrics

In addition to logs, metrics are also captured by the Cloud Monitoringagent. This replicates system-level metrics into the Google Cloud projectassociated with the cluster. System-level metrics are from Kubernetes podsrunning in the same namespaces listed inLogs.

For more details, seeLogging and Monitoring.

Google Cloud CLI and remote cluster access

If you open a support case, Cloud Customer Care might ask you for remote read-onlyaccess to your clusters to help diagnose and resolve issues more effectively.For the Cloud Customer Care to have sufficient access to troubleshoot your clusterissue remotely, do the following:

• Ensure that you've installed and updated to the latest version of theGoogle Cloud CLI. The Google Cloud CLI must be at version401.0.0 or later to give Cloud Customer Care the needed permissions. Werecommend that you update Google Cloud CLI regularly to pick up addedpermissions and other enhancements. To install the latest components of thegcloud CLI, use thegcloud components updatecommand.

• Ensure the target cluster is registered and you have the project ID,membership name, and kubeconfig file.

  • To get the user cluster kubeconfig file, seeHow to re-create user cluster kubeconfig.

  • Your membership name is the same as the cluster name. To get the admin oruser cluster name, you can use:

  gkectllistadmin--kubeconfigADMIN_CLUSTER_KUBECONFIGgkectllistclusters--kubeconfigADMIN_CLUSTER_KUBECONFIG

• To grant access to the cluster, you run a gcloud CLI command that generates anddisplays a set of Kubernetes role-based access control (RBAC) policies andapplies them to the target cluster. SeeReview the RBAC policies in advance.

For more information about giving Cloud Customer Care remote read-only access toyour clusters, seeGoogle Cloud Support for your registered clusters.

How we troubleshoot your environment

Here is an example of a typical support incident:

1. Someone—for example, the cluster administrator—opens a support case inthe Google Cloud console or withCloud Customer Care.

   1. In the console, go to theSupport overviewpage.

      Go to Support overview

   2. In theSupport information section, clickGet help.

   3. In theSelect your product field, enter the following:

      Google Distributed Cloud Virtual - vSphere (Anthos on VMWare)

   4. Click the item in theMatching products list, and then clickSelect.

   5. Enter the required information and attach the output of thegkectl diagnose snapshot command to the case.

2. The support case is routed to a Technical Support Engineer specializingin Google Distributed Cloud (software only) for VMware.

3. The support engineer examines the contents of the snapshot to gain contextof the environment.

4. The support engineer examines the logs and metrics in the Google Cloudproject, entering the support case ID as the business justification, whichis logged internally.

5. The support engineer responds to the case with an assessment andrecommendation. The support engineer and the user continue troubleshootinguntil they come to a resolution.

Collaborative Support Partners

Google maintains collaborative support relationships with select partners todeliver a more seamless support experience. With these relationships, Google isable to collaborate closely with that partner on behalf of our shared customers.

To benefit from Collaborative Support, you must maintain support agreements withboth Google and the partner in question.

Google has a collaborative support relationship in place with thepartners specified on theCollaborative Support Partners page.

Data about support issues may be shared with Collaborative Support Partners, asdescribed in Google'sTechnical Support Services Guidelines.

What does Google support?

Generally, Cloud Customer Care supports all software components shipped aspart of Google Distributed Cloud (software only) for VMware. The following tableprovides further details:

Supported features

This document lists the features for Google Distributed Cloud for supportedreleases. The table is not intended to be an exhaustive list, but it highlightssome of the benefits of upgrading your clusters to the latest supported version.

Features are listed by their product launch stage, either as Preview or GeneralAvailability. Features listed as Preview are covered by thePre-GA Offerings Terms of the Google Cloud Terms ofService. Preview offerings are intended for use in test environments only andmight have limited support. Changes to pre-GA products and features might not becompatible with other pre-GA versions. General Availability features are open toall customers, and are fully supported. For more information, seeProduct launch stages.

For information about supported GKE components and their compatibility, seeGKE version and upgrade support.

^{1 Windows Server OS node pools are deprecated inversion 1.32 and will be unavailable in version 1.33 and higher. Support forWindows Server OS node pools ends May 25, 2026. We recommend that you beginmigration planning immediately to ensure a smooth transition before the supportperiod ends.}

Version Support Policy

The objective of this Version Support Policy is to give you the flexibility toschedule upgrades when it meets your business needs, while balancing the rapidevolution of both Kubernetes and Google Distributed Cloud.

Google Distributed Cloud software only follows the Kubernetesversioningscheme and release cycle. Minor releases happen approximatelythree times per year. Patches for each supported minor version occurapproximately monthly. Like Kubernetes, Google Distributed Cloud supports thelatest three minor versions concurrently.

Google supports each Google Distributed Cloud minor version for the later of:

• 12 months after the initial release of the minor version.
• The release of the third subsequent minor version.

For example, minor version 1.33 released on September 02, 2025. This minorversion and all of its patches are supported until either September 02, 2026 orthe release date of minor version 1.36, whichever date is later.

We encourage you to maintain your Google Distributed Cloud environment with theproduct's latest minor release andrecommended patchversion.

This version support policy includes:

• Break-fix support from Cloud Customer Care.
• CVE security vulnerabilities to Kubernetes and related components.
• General patches to Kubernetes and related components.
• CVE security vulnerabilities to Ubuntu or Container-Optimized OS.
• General patches to Ubuntu or Container-Optimized OS.

When your version reaches end-of-life, you can continue to open cases to receivesupport for the following:

• Help with technical issues.
• Assistance with billing issues.
• Guidance on product usage, including help with troubleshooting and testing.

Extended support can be conditionally approved as a one-time event, withversion-pinning, and future upgrade timeline requirements. For additionalinformation, reach out to the lead customer engineer for your account or theaccount manager. Alternatively, you canfile a supportcase through Google Cloud console. Such requests are routedto the customer engineering group for your account.

Support period

The following table shows the supported minor releases forGoogle Distributed Cloud and the earliest end-of-life (EOL) dates:

* The EOL will be the later of these two dates.

To learn more version compatibility for Google Distributed Cloud and relatedGoogle Cloud products, seeVersion and upgradesupport.

Versioning scheme

Google Distributed Cloud uses Kubernetessemantic versioning to refer to supportedKubernetes versions, but appends a GKE patch version. Thisresults in a version number of the form:x.y.z-gke.N.

Kubernetes major version (x)

Major versions are typically incremented if any backwardsincompatible changes are introduced to the public API. A major versionincrements the Kubernetes version fromx.y tox+1.y.

Kubernetes minor version (y)

Kubernetes releases a new minor versionthree times a year.Each release cycle is approximately 15 weeks long.DeprecatedAPIs mightbe removed with a new minor version. A minor version increments theKubernetes version from1.y to1.y+1; for example, Kubernetes 1.29 is the minor release that followsKubernetes 1.28.

Google Distributed Cloud patch release (z-gke.N)

A patch release, such as 1.28.300-gke.131,increments the patch version (z) by 100 and includes a-gke.N suffix, whichindicates the build. Patch releases include security updates and bug fixes.A Google Distributed Cloud patch release version doesn't correlate to aKubernetes patch version.

Shared responsibility model

Running a business-critical production application on Google Distributed Cloudrequires multiple parties to carry different responsibilities. Theseresponsibilities are described atGKE shared responsibility.

Developer support

Google doesn't provide support specifically for your application workloads.However, we do providebest-effort developer support to ensure your developerscan run applications on clusters created using Google Distributed Cloud. We believe thatengaging earlier during development can prevent critical incidents later in thedeployment.

Thisbest-effort developer support is available to customers with any paidsupport package and is treated as a P3 priority for an issue blocking a launch,or a P4 priority for general consultation. In this classification, prioritylevel 0 is the highest priority.