Receber suporte

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 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 resolver problemas de incidentes críticos para a empresa com eficiência, você precisa fazer o seguinte:

• Verifique se o ambiente está atualizado e dentro dos 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 seguinte seção Ferramentas de suporte.

Ferramentas de suporte

Para solucionar um incidente do Google Distributed Cloud, Cloud Customer Care depende de três informações:

• Sua configuração do ambiente
• Registros dos seus clusters
• Métricas dos seus clusters

Sua configuração do ambiente

Ao abrir um caso de suporte, forneça informações importantes sobre a configuração do cluster executando os seguintes comandos:

• Para todos os tipos de cluster, capture informações sobre o Kubernetes e os nós executando o comando bmctl check cluster --snapshot. Anexe o arquivo tar resultante ao caso de suporte.

• Para clusters de administrador, híbridos e autônomos, verifique o status de integridade do cluster e dos nós executando o comando bmctl check cluster. Anexe os registros resultantes ao caso de suporte. Os registros precisam estar no diretório bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].

• Para clusters de usuário, primeiro crie um arquivo YAML de verificação de integridade com o nome do cluster e o namespace e, em seguida, aplique o arquivo no cluster de administrador apropriado:

  1. Crie um arquivo YAML com as seguintes propriedades healthcheck. Este é um conteúdo de amostra de um cluster chamado user1 no namespace cluster-user1:

     apiVersion: baremetal.cluster.gke.io/v1
     kind: HealthCheck
     metadata:
       generateName: healthcheck-
       namespace: cluster-user1
     spec:
       clusterName: user1
     

  2. Depois de criar o arquivo YAML, aplique o recurso personalizado no cluster de administrador que está gerenciando o cluster de usuário usando o comando kubectl. Confira a seguir um comando de amostra que usa o arquivo YAML criado na etapa anterior. Na amostra, a variável ADMIN_KUBECONFIG especifica o caminho para o arquivo kubeconfig do cluster de administrador:

     kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml
     

     O comando retorna a seguinte resposta:

     healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
     

  3. Aguarde até que o job de verificação de integridade seja concluído. Para isso, teste para ver se o job de verificação de integridade concluiu a reconciliação. No caso de exemplo anterior, o nome do job de verificação de integridade é healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Confira a seguir um teste de amostra que usa o comando kubectl e aguarda 30 minutos para que o job de verificação de integridade seja concluído:

     kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \
         -n cluster-user1 --for=condition=Reconciling=False --timeout=30m
     

     Quando o job de verificação de integridade for concluído, o comando kubectl anterior vai retornar:

     healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf condition met
     

     É possível ver os resultados do job de verificação de integridade com o seguinte comando:

     kubectl --kubeconfig ADMIN_KUBECONFIG get healthcheck healthcheck-7c4qf \
         -n cluster-user1
     

     O comando retorna o seguinte resultado:

     NAME                PASS   AGE
     healthcheck-7c4qf   true   17m
     

  4. Reúna todos os registros do pod do job de verificação de integridade em um arquivo local usando o comando kubectl. Confira um exemplo que usa o job de verificação de integridade de amostra anterior:

     kubectl --kubeconfig ADMIN_KUBECONFIG logs -n cluster-user1 \
         -l baremetal.cluster.gke.io/check-name=healthcheck-7c4qf --tail=-1 > \
         healthcheck-7c4qf.log
     

Registros de cluster

Quando você cria um novo cluster do Google Distributed Cloud, 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 do Google Cloud associado ao cluster. Os registros no nível do sistema são dos pods do Kubernetes nos seguintes namespaces:

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

É possível consultar registros no Explorador de registros.

Observação: se o Cloud Logging estiver desativado, o suporte será oferecido somente com base no melhor esforço e poderá exigir muito mais esforço da equipe de engenharia no local.

Para mais detalhes, consulte Configurar geração de registros e monitoramento.

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 atendimento ao cliente do Cloud tenha acesso suficiente para resolver problemas no cluster remotamente, 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. Para mais informações sobre como conceder ao Cloud Customer Care acesso remoto somente leitura aos seus clusters, consulte Suporte remoto para clusters do GKE.

Métricas do cluster

Além dos registros, o agente do Cloud Monitoring também captura métricas. 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 na seção Registros do cluster.

Observação: se o Cloud Monitoring estiver desativado, o suporte será oferecido somente com base no melhor esforço e poderá exigir um esforço extra significativo da equipe de engenharia no local.

Para mais detalhes, consulte Configurar geração de registros e monitoramento.

Como resolvemos problemas do ambiente

Veja um exemplo de um incidente típico de suporte:

1. O administrador do cluster abre um caso de suporte no console do Google Cloud com o Cloud Customer Care. Em seguida, eles selecionam GKE e Google Distributed Cloud como Categoria e Componente, respectivamente. Ele insere as informações necessárias e anexa a saída de comandos bmctl relevantes ao caso.

2. O caso de suporte é encaminhado para um engenheiro de suporte técnico especializado no Google Distributed Cloud.

3. O engenheiro de suporte examina o conteúdo do snapshot para ter contexto do ambiente.

4. O engenheiro de suporte examina os registros e as métricas no projeto Google Cloud. Eles inserem o ID do caso de suporte como a justificativa de negócios, que é registrada internamente.

5. 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.

O que o Google aceita?

Geralmente, Cloud Customer Care oferece suporte a todos os componentes de software enviados como parte do Google Distributed Cloud e do Cloud Service Mesh, Policy Controller, Config Sync e Config Controller. A tabela a seguir fornece uma lista mais completa do que é compatível ou não:

Google Cloud compatível	Sem suporte
Kubernetes e ambiente de execução do contêiner	Escolha do balanceador de carga (balanceamento de carga manual) pelo cliente
Connect e agente do Connect	Código do cliente (consulte Suporte ao desenvolvedor)
Google Cloud operações, monitoramento, geração de registros e agentes	Escolha do sistema operacional pelo cliente
Balanceador de carga em pacote	Servidor físico ou virtual, armazenamento e rede
Controlador de entrada	DNS externo, DHCP e sistemas de identidade
Serviço de identidade do GKE
Cloud Service Mesh
Policy Controller
Config Sync
Controlador de configuração

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.

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.y para x+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.y para 1.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. Embora não seja uma lista completa, as seções abaixo listam os papéis e as responsabilidades de diferentes partes.

Responsabilidades do Google

• Manutenção e distribuição do pacote de software do Google Distributed Cloud.

• Notificar os usuários sobre upgrades disponíveis para o Google Distributed Cloud e produzir scripts de upgrade para a versão anterior.

  O Google Distributed Cloud é compatível apenas com upgrades sequenciais de cluster (por exemplo: 1.31 → 1.32 → 1.33, mas não 1.31 → 1.33). Ao fazer upgrade de pools de nós, em alguns casos, é possível pular uma versão secundária. Para mais informações sobre a lógica de upgrade, consulte Regras de versão.

• Operar os serviços de operações do Cloud e Connect.

• Solucionar problemas, fornecer alternativas e corrigir a causa raiz dos problemas relacionados aos componentes fornecidos pelo Google

Responsabilidades do usuário

• Cuidar da administração geral do sistema para clusters no local
• Manter qualquer carga de trabalho de aplicativo implantada no cluster
• Executar, manter e corrigir a infraestrutura do data center, incluindo rede, servidores, sistema operacional, armazenamento e conectividade com Google Cloud.
• Executar, manter e corrigir balanceadores de carga de rede se a opção do balanceador de carga manual for escolhida.
• Fazer upgrade das versões do Google Distributed Cloud regularmente.
• Monitorar o cluster e os aplicativos e responder a qualquer incidente
• Garantir que os agentes de operações do Cloud sejam implantados nos clusters.
• Fornecer ao Google detalhes do ambiente para fins de solução de problemas

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 na Google Distributed Cloud. Acreditamos que o envolvimento anterior durante o desenvolvimento pode evitar incidentes críticos mais tarde 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.