O principal objetivo do suporte do Google é resolver os incidentes de produção o mais rápido possível. Fazemos isso entendendo sua configuração, analisando registros e métricas e colaborando com parceiros para resolver incidentes rapidamente.
O Cloud Customer Care oferece vários pacotes de suporte para atender às suas necessidades. Todos os pacotes de suporte do Cloud Customer Care incluem suporte para o GKE e o Google Distributed Cloud. Se você já tem um pacote de suporte do Cloud Customer Care, já tem suporte para o GKE e o Google Distributed Cloud.
Para mais informações, consulte o hub do Cloud Customer Care.
Requisitos para o suporte do Google Distributed Cloud
Para solucionar problemas de incidentes críticos para a empresa com eficiência, você precisa realizar estas etapas:
- Verifique se o ambiente está atualizado com os prazos de fim de suporte publicados. Para mais informações, consulte a seção Política de suporte de versões.
- Ative o Cloud Logging e o Cloud Monitoring para componentes do sistema. Para mais informações, consulte a seção Ferramentas de suporte.
- Ao abrir um histórico de consultas, forneça um snapshot de configuração usando o
comando
gkectl diagnose snapshot.
Ferramentas de suporte
Para resolver problemas de incidentes críticos para a empresa de maneira eficaz, o Cloud Customer Care depende de três informações:
- Configuração do seu ambiente
- Registros dos clusters de administrador e de usuário
- Métricas dos clusters de administrador e de usuário
Configuração
Ao abrir um caso de suporte, você precisa executar o comando gkectl diagnose snapshot
--seed-config e anexar o arquivo tar resultante ao caso.
O comando gkectl diagnose snapshot --seed-config captura informações sobre
o Kubernetes e os nós.
A ferramenta é altamente configurável e inclui vários cenários predefinidos. Você também pode transmitir um arquivo YAML com um conjunto personalizado de informações para coletar. Para mais informações, consulte Diagnóstico de clusters.
Revise cuidadosamente as informações capturadas pela ferramenta.
Não anexe informações altamente confidenciais ou sensíveis ao seu caso de suporte.
É possível adicionar um campo excludeWords ao arquivo de configuração para omitir informações sensíveis
ou confidenciais.
Registros
Quando você cria um novo cluster, os agentes do Cloud Logging são ativados por padrão e têm escopo somente para componentes no nível do sistema. Isso replica registros no nível do sistema no projeto Google Cloud associado ao cluster. Os registros no nível do sistema são de pods do Kubernetes em execução em um dos seguintes namespaces:
kube-systemgke-systemgke-connectistio-systemconfig-management-systemknative-serving
Os registros podem ser consultados no Console do Cloud Logging.
Para mais detalhes, consulte Logging e Monitoring.
Métricas
Além dos registros, as métricas também são capturadas pelo agente do Cloud Monitoring. Isso replica as métricas no nível do sistema para o projeto Google Cloud associado ao cluster. As métricas no nível do sistema são de pods do Kubernetes em execução nos mesmos namespaces listados em Registros.
Para mais detalhes, consulte Logging e Monitoring.
Google Cloud CLI e acesso remoto ao cluster
Se você abrir um caso de suporte, o Cloud Customer Care poderá solicitar acesso remoto somente leitura aos clusters para diagnosticar e resolver problemas de maneira mais eficaz. Para que o Cloud Customer Care tenha acesso suficiente para resolver problemas no cluster remotamente, faça o seguinte:
Verifique se você instalou e atualizou para a versão mais recente da Google Cloud CLI. A Google Cloud CLI precisa estar na versão 401.0.0 ou mais recente para conceder as permissões necessárias ao Cloud Customer Care. Recomendamos que você atualize a Google Cloud CLI regularmente para receber permissões adicionais e outras melhorias. Para instalar os componentes mais recentes da CLI gcloud, use o comando
gcloud components update.Verifique se o cluster de destino está registrado e se você tem o ID do projeto, o nome da assinatura e o arquivo kubeconfig.
Para conferir o arquivo kubeconfig do cluster de usuário, consulte Como recriar o kubeconfig do cluster de usuário.
O nome da assinatura é igual ao nome do cluster. Para conferir o nome do cluster de administrador ou de usuário, use:
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIGPara conceder acesso ao cluster, execute um comando gcloud CLI que gera e exibe um conjunto de políticas de controle de acesso baseado em papéis (RBAC) do Kubernetes e aplica essas políticas ao cluster de destino. Consulte as políticas de RBAC com antecedência.
Para mais informações sobre como conceder ao Cloud Customer Care acesso remoto somente leitura aos seus clusters, consulte Suporte do Google Cloud para os clusters registrados.
Como resolvemos problemas do ambiente
Veja um exemplo de um incidente típico de suporte:
Alguém, por exemplo, o administrador do cluster, abre um caso de suporte no console do Google Cloud ou com o Cloud Customer Care.
No console, acesse a página Visão geral do suporte.
Na seção Informações de suporte, clique em Receber ajuda.
No campo Selecionar seu produto, insira o seguinte:
Google Distributed Cloud Virtual - vSphere (Anthos on VMWare)Clique no item na lista Produtos correspondentes e em Selecionar.
Insira as informações necessárias e anexe a saída do comando
gkectl diagnose snapshotao caso.
O caso de suporte é encaminhado para um engenheiro de suporte técnico especializado no Google Distributed Cloud (somente software) para VMware.
O engenheiro de suporte examina o conteúdo do snapshot para ter contexto do ambiente.
O engenheiro de suporte examina os registros e as métricas no projeto Google Cloud, inserindo o ID do histórico de consultas como a justificativa de negócios, que é registrada internamente.
O engenheiro de suporte responde ao caso com uma avaliação e recomendação. O engenheiro de suporte e o usuário continuam solucionando até conseguir uma resolução.
Parceiros de suporte colaborativo
O Google mantém relações de suporte colaborativas com parceiros selecionados para oferecer uma experiência de suporte mais perfeita. Com esses relacionamentos, o Google pode colaborar de perto com esse parceiro em nome dos nossos clientes compartilhados.
Para se beneficiar do suporte colaborativo, é necessário manter contratos de suporte com o Google e o parceiro em questão.
O Google tem uma relação de suporte colaborativo em vigor com os parceiros especificados na página Parceiros de suporte colaborativo.
Os dados sobre problemas de suporte podem ser compartilhados com os parceiros de suporte colaborativo, conforme descrito nas Diretrizes de Serviços de Suporte Técnico do Google.
O que o Google aceita?
Geralmente, o Cloud Customer Care oferece suporte a todos os componentes de software enviados como parte do Google Distributed Cloud (somente software) para VMware. A tabela a seguir fornece mais detalhes:
| Cloud Customer Care | Suporte colaborativo | Incompatível |
|---|---|---|
| Kubernetes e ambiente de execução do contêiner |
VMware vSphere (servidor vCenter e ESXi) |
Produtos VMware além do vSphere |
| Ubuntu canônico para SO de convidado/nó |
Balanceadores de carga F5 BIG-IP |
Código do cliente (para mais informações, consulte a seção Suporte ao desenvolvedor) |
| Controlador do vCenter |
Soluções de hardware e de infraestrutura hiperconvergente, conforme listado na página Parceiros de suporte colaborativo |
Escolha do cliente do SO host |
| Controlador F5 |
Servidor físico, armazenamento e rede |
|
| Calico e políticas de rede relacionadas |
DNS externo, DHCP e sistemas de identidade |
|
| Controlador de entrada |
Calico Enterprise Edition |
|
| Prometheus e Grafana |
||
| Stackdriver Monitoring, Stackdriver Logging e agentes do Stackdriver |
||
| Federação da identidade com provedores compatíveis com OIDC |
||
| Hub, Connect e agente do Connect |
||
| Knative serving / Knative |
||
| LoadBalancer em pacote (Seesaw) |
Recursos compatíveis
Este documento lista os recursos do Google Distributed Cloud para versões compatíveis. A tabela não é uma lista completa, mas destaca alguns dos benefícios de fazer upgrade dos clusters para a versão mais recente compatível.
Os recursos são listados pelo estágio de lançamento do produto, como "Visualização" ou "Disponibilidade geral". Os recursos listados como "Visualização" são cobertos pelos Termos de ofertas pré-GA dos Google Cloud Termos de Serviço. As ofertas de pré-lançamento podem ser usadas somente em ambientes de teste e podem ter suporte limitado. As alterações em produtos e recursos pré-GA podem não ser compatíveis com outras versões pré-GA. Os recursos de "Disponibilidade geral" estão abertos a todos os clientes e são totalmente compatíveis. Para mais informações, consulte Estágios de lançamento do produto.
Para informações sobre os componentes compatíveis do GKE e a compatibilidade deles, consulte Suporte para upgrade e versão do GKE.
1 Os pools de nós do Windows Server OS foram descontinuados na versão 1.32 e não estarão disponíveis na versão 1.33 e mais recentes. O suporte para pools de nós do SO Windows Server termina em 25 de maio de 2026. Recomendamos que você comece o planejamento da migração imediatamente para garantir uma transição tranquila antes do fim do período de suporte.
Política de suporte da versão
O objetivo dessa política de suporte de versão é oferecer a flexibilidade de programar upgrades para atender às necessidades do seu negócio, enquanto equilibra a evolução rápida do Kubernetes e do Google Distributed Cloud.
O software do Google Distributed Cloud segue apenas o esquema de controle de versões e o ciclo de lançamento do Kubernetes. Os lançamentos secundários acontecem aproximadamente três vezes por ano. Os patches para cada versão secundária compatível são lançados aproximadamente uma vez por mês. Assim como o Kubernetes, o Google Distributed Cloud oferece suporte às três versões secundárias mais recentes simultaneamente.
O Google oferece suporte a cada versão secundária do Google Distributed Cloud até:
- 12 meses após o lançamento inicial da versão secundária.
- Lançamento da terceira versão secundária subsequente.
Por exemplo, a versão secundária 1.33 lançada em 2 de setembro de 2025. Essa versão secundária e todos os patches dela têm suporte até 2 de setembro de 2026 ou até a data de lançamento da versão secundária 1.36, o que ocorrer por último.
Recomendamos que você mantenha seu ambiente do Google Distributed Cloud com a versão secundária mais recente do produto e a versão de patch recomendada.
Esta política de suporte de versão inclui:
- Suporte de interrupção/correção do Cloud Customer Care.
- Vulnerabilidades de segurança comuns para o Kubernetes e componentes relacionados.
- Patches gerais do Kubernetes e componentes relacionados.
- Vulnerabilidades de segurança CVE para o Ubuntu ou o Container-Optimized OS.
- Patches gerais do Ubuntu ou Container-Optimized OS.
Quando sua versão chegar ao fim da vida útil, você poderá continuar abrindo casos para receber suporte para o seguinte:
- Ajuda com problemas técnicos.
- Ajuda com problemas de faturamento.
- Orientação sobre o uso do produto, incluindo ajuda para testes e solução de problemas.
O suporte estendido pode ser aprovado condicionalmente como um evento único, com fixação de versão e requisitos futuros de linha do tempo de upgrade. Para mais informações, entre em contato com o engenheiro de clientes principal da sua conta ou com o gerente de contas. Se preferir, registre um caso de suporte no console Google Cloud . Essas solicitações são encaminhadas ao grupo de engenharia de clientes da sua conta.
Período de suporte
A tabela a seguir mostra as versões secundárias compatíveis do Google Distributed Cloud e as datas mais antigas de fim da vida útil (EOL):
| Versão do Google Distributed Cloud | Data de lançamento | Data de fim de vida útil* |
|---|---|---|
| 1,33 | 2025-09-02 | Data de lançamento em 02/09/2026 ou 1.36 |
| 1.32 | 2025-05-06 | Data de lançamento em 06/05/2026 ou 1.35 |
| 1.31 | 2024-12-18 | Data de lançamento em 18/12/2025 ou 1.34 |
* O EOL será a data mais recente dessas duas datas.
Para saber mais sobre a compatibilidade de versões do Google Distributed Cloud e de produtos Google Cloud relacionados, consulte Suporte para versões e upgrades.
Esquema de controle de versão
O Google Distributed Cloud usa o
controle de versões semântico do Kubernetes para se referir às versões
compatíveis do Kubernetes, mas anexa uma versão do patch do GKE. Isso
resulta em um número de versão do formulário: x.y.z-gke.N.
- Versão principal do Kubernetes (x)
- As versões principais geralmente são incrementadas se alguma mudança incompatível com versões
anteriores for introduzida na API pública. Uma versão principal
incrementa a versão do Kubernetes de
x.yparax+1.y. - Versão secundária do Kubernetes (y)
- O Kubernetes lança uma nova versão secundária
três vezes por ano.
Cada ciclo de lançamento tem aproximadamente 15 semanas. As APIs
obsoletas podem
ser removidas com uma nova versão secundária. Uma versão secundária incrementa a versão do Kubernetes de
1.ypara1.y+1. Por exemplo, o Kubernetes 1. 29 é a versão secundária que segue o Kubernetes 1.28. - Versão de patch do Google Distributed Cloud (z-gke.N)
- Uma versão de patch, como 1.28.300-gke.131,
incrementa a versão de patch (z) em 100 e inclui um sufixo
-gke.N, que indica o build. As versões de patch incluem atualizações de segurança e correções de bugs. Uma versão de patch do Google Distributed Cloud não está relacionada a uma versão de patch do Kubernetes.
Modelo de responsabilidade compartilhada
A execução de um aplicativo de produção essencial para os negócios na Google Distributed Cloud exige que várias partes tenham responsabilidades diferentes. Essas responsabilidades são descritas em Responsabilidade compartilhada do GKE.
Suporte para o desenvolvedor
O Google não fornece suporte especificamente para as cargas de trabalho do aplicativo, No entanto, oferecemos suporte para desenvolvedores com base no melhor esforço para garantir que eles possam executar aplicativos em clusters criados usando a Google Distributed Cloud. Acreditamos que o envolvimento imediato durante o desenvolvimento pode evitar incidentes críticos na implantação.
Esse suporte ao desenvolvedor baseado no melhor esforço está disponível para clientes com qualquer pacote de suporte pago e é tratado como uma prioridade P3 para um problema que bloqueia um lançamento ou como uma prioridade P4 para consulta geral. Nessa classificação, o nível de prioridade 0 é o mais alto.