Obter apoio técnico

O objetivo principal do apoio técnico da Google é resolver incidentes de produção o mais rapidamente possível. Fazemos isto compreendendo a sua configuração, analisando registos e métricas, e colaborando com parceiros para resolver incidentes rapidamente.

O Cloud Customer Care oferece vários pacotes de apoio técnico para satisfazer as suas necessidades de apoio técnico. Todos os pacotes do Cloud Customer Care incluem apoio técnico para o GKE e o Google Distributed Cloud. Se tiver um pacote de apoio técnico do Cloud Customer Care, já tem apoio técnico para o GKE e o Google Distributed Cloud.

Para mais informações, consulte o hub do apoio ao cliente do Google Cloud.

Requisitos para o apoio técnico do Google Distributed Cloud

Para resolver problemas de incidentes críticos para a empresa de forma eficaz, tem de fazer o seguinte:

• Verifique se o seu ambiente está atualizado e dentro dos prazos de fim do apoio técnico publicados. Para mais informações, consulte a secção Política de Apoio Técnico de Versões.
• Ative o Cloud Logging e o Cloud Monitoring para os componentes do sistema. Para mais informações, consulte a secção Ferramentas de apoio técnico seguinte.

Ferramentas de apoio técnico

Para resolver problemas de um incidente do Google Distributed Cloud, o apoio ao cliente do Google Cloud depende de três informações:

• A configuração do ambiente
• Registos dos seus clusters
• Métricas dos seus clusters

A configuração do seu ambiente

Quando abrir um registo de apoio técnico, forneça informações importantes sobre a configuração do cluster executando os seguintes comandos:

• Para todos os tipos de clusters, capture informações sobre o Kubernetes e os seus nós executando o comando bmctl check cluster --snapshot. Anexe o ficheiro TAR resultante ao registo de apoio técnico.

• Para clusters de administrador, híbridos e autónomos, verifique o estado de funcionamento do cluster e dos nós executando o comando bmctl check cluster. Anexe os registos resultantes ao registo de apoio técnico. Os registos devem existir no diretório bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].

• Para clusters de utilizadores, primeiro, crie um ficheiro YAML de verificação do estado com o nome e o espaço de nomes do cluster e, em seguida, aplique o ficheiro no cluster de administrador adequado:

  1. Crie um ficheiro YAML com as seguintes propriedades healthcheck. Segue-se um exemplo de conteúdo para um cluster denominado user1 no espaço de nomes cluster-user1:

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

  2. Depois de criar o ficheiro YAML, aplique o recurso personalizado no cluster de administração que está a gerir o cluster de utilizadores através do comando kubectl. Segue-se um comando de exemplo que usa o ficheiro YAML criado no passo anterior. No exemplo, a variável ADMIN_KUBECONFIG especifica o caminho para o ficheiro kubeconfig do cluster de administrador:

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

     O comando devolve a seguinte resposta:

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

  3. Aguarde até que a tarefa de verificação de funcionamento esteja concluída. Para tal, teste se a tarefa de verificação do estado de funcionamento terminou a conciliação. No exemplo anterior, o nome da tarefa de verificação do estado é healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Segue-se um exemplo de teste que usa o comando kubectl e aguarda 30 minutos pela conclusão da tarefa de verificação do estado:

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

     Quando a tarefa de verificação de funcionamento estiver concluída, o comando kubectl anterior devolve:

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

     Pode ver os resultados da tarefa de verificação de estado com o seguinte comando:

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

     O comando devolve o seguinte resultado:

     NAME                PASS   AGE
     healthcheck-7c4qf   true   17m
     

  4. Reúna todos os registos do pod de tarefas de verificação de funcionamento num ficheiro local através do comando kubectl. Segue-se um exemplo que usa a tarefa de verificação do estado anterior:

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

Registos de clusters

Quando cria um novo cluster do Google Distributed Cloud, os agentes do Cloud Logging são ativados por predefinição e limitados apenas aos componentes ao nível do sistema. Isto replica os registos ao nível do sistema no projeto Google Cloud associado ao cluster. Os registos ao nível do sistema são de pods do Kubernetes nos seguintes espaços de nomes:

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

Pode consultar registos a partir do Explorador de registos.

Nota: se o Cloud Logging estiver desativado, o apoio técnico é oferecido apenas com base no melhor esforço possível e pode exigir um esforço adicional significativo por parte da sua equipa de engenharia no local.

Para mais detalhes, consulte o artigo Configure o registo e a monitorização.

CLI gcloud e acesso remoto ao cluster

Se abrir um registo de apoio técnico, o Cloud Customer Care pode pedir-lhe acesso remoto só de leitura aos seus clusters para ajudar a diagnosticar e resolver problemas de forma mais eficaz. Para que o Cloud Customer Care tenha acesso suficiente para resolver problemas do seu cluster remotamente, certifique-se de que instalou e atualizou para a versão mais recente da CLI do Google Cloud. A CLI Google Cloud tem de estar na versão 401.0.0 ou superior para conceder ao Cloud Customer Care as autorizações necessárias. Recomendamos que atualize a CLI do Google Cloud regularmente para receber autorizações adicionadas 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 apoio ao cliente do Google Cloud acesso remoto só de leitura aos seus clusters, consulte o artigo Apoio técnico remoto para clusters do GKE.

Métricas de cluster

Além dos registos, o agente do Cloud Monitoring também captura métricas. Isto replica as métricas ao nível do sistema no Google Cloud projeto associado ao cluster. As métricas ao nível do sistema são provenientes de pods do Kubernetes que são executados nos mesmos espaços de nomes que estão listados na secção Registos do cluster.

Nota: se o Cloud Monitoring estiver desativado, o apoio técnico é oferecido apenas com base no melhor esforço possível e pode exigir um esforço adicional significativo por parte da sua equipa de engenharia no local.

Para mais detalhes, consulte o artigo Configure o registo e a monitorização.

Como resolvemos problemas no seu ambiente

Segue-se um exemplo de um incidente de apoio técnico típico:

1. O administrador do cluster abre um registo de apoio ao cliente na consola com o apoio ao cliente da Google Cloud. Google Cloud Em seguida, selecionam GKE e Google Distributed Cloud como Categoria e Componente, respetivamente. Introduzem as informações necessárias e anexam o resultado dos comandos bmctl relevantes ao registo.

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

3. O engenheiro de apoio técnico examina o conteúdo da captura de ecrã para obter contexto do ambiente.

4. O engenheiro de apoio técnico examina os registos e as métricas no Google Cloud projeto. Introduzem o ID do registo de apoio técnico como a justificação comercial, que é registada internamente.

5. O engenheiro de apoio técnico responde ao registo com uma avaliação e uma recomendação. O técnico de apoio técnico e o utilizador continuam a resolver problemas até encontrarem uma solução.

O que é suportado pela Google?

Geralmente, o Apoio técnico ao cliente do Google Cloud suporta 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 seguinte apresenta uma lista mais completa do que é e não é suportado:

Google Cloud suportado	Não suportado
O Kubernetes e o tempo de execução do contentor	Escolha do balanceador de carga pelo cliente (balanceamento de carga manual)
Ligue-se ao agente	Código do cliente (consulte o apoio técnico para programadores)
Google Cloud Operações, monitorização, registo e agentes	Escolha do sistema operativo pelo cliente
Balanceador de carga integrado	Servidor físico ou virtual, armazenamento e rede
Controlador de entrada	Sistemas de DNS, DHCP e identidade externos
GKE Identity Service
Cloud Service Mesh
Controlador de políticas
Config Sync
Config Controller

Política de apoio técnico de versões

O objetivo desta Política de Apoio Técnico de Versões é dar-lhe a flexibilidade de agendar atualizações quando satisfazem as necessidades da sua empresa, ao mesmo tempo que equilibra a rápida evolução do Kubernetes e do Google Distributed Cloud.

O software Google Distributed Cloud segue apenas o esquema de controlo de versões e o ciclo de lançamento do Kubernetes. Os lançamentos menores ocorrem aproximadamente três vezes por ano. Os patches para cada versão secundária suportada ocorrem aproximadamente todos os meses. Tal como o Kubernetes, o Google Distributed Cloud suporta as três versões secundárias mais recentes em simultâneo.

A Google suporta cada versão secundária do Google Distributed Cloud durante o período mais longo entre:

• 12 meses após o lançamento inicial da versão secundária.
• O lançamento da terceira versão secundária subsequente.

Por exemplo, a versão secundária 1.33 foi lançada a 2 de setembro de 2025. Esta versão menor e todos os respetivos patches são suportados até 2 de setembro de 2026 ou à data de lançamento da versão menor 1.36, consoante o que ocorrer mais tarde.

Recomendamos que mantenha o 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ões inclui:

• Apoio técnico de resolução de problemas do Cloud Customer Care.
• Vulnerabilidades de segurança CVE para o Kubernetes e componentes relacionados.
• Patches gerais para o Kubernetes e componentes relacionados.

Quando a sua versão atinge o fim do ciclo de vida, pode continuar a abrir registos para receber apoio técnico para o seguinte:

• Ajudar com problemas técnicos.
• Assistência com problemas de faturação.
• Orientações sobre a utilização do produto, incluindo ajuda com a resolução de problemas e os testes.

O apoio técnico alargado pode ser aprovado condicionalmente como um evento único, com a fixação de versões e os requisitos da cronologia de atualizações futuras. Para mais informações, contacte o engenheiro de clientes principal da sua conta ou o gestor de conta. Em alternativa, pode apresentar um registo de apoio técnico através da Google Cloud consola. Esses pedidos são encaminhados para o grupo de engenharia de clientes da sua conta.

Período de apoio técnico

A tabela seguinte mostra as versões secundárias suportadas para o Google Distributed Cloud e as datas de fim de vida (EOL) mais antigas:

Versão do Google Distributed Cloud	Data de lançamento	Data de fim de vida^*
1,33	2025-09-02	02/09/2026 ou data de lançamento da versão 1.36
1,32	2025-05-06	06-05-2026 ou data de lançamento da versão 1.35
1.31	2024-12-18	18/12/2025 ou data de lançamento da versão 1.34

* A data de fim de vida é a mais tardia destas duas datas.

Para saber mais sobre a compatibilidade de versões do Google Distributed Cloud e dosGoogle Cloud produtos relacionados, consulte o artigo Apoio técnico de versões e atualizações.

Esquema de controlo de versões

O Google Distributed Cloud usa a versão semântica do Kubernetes para se referir às versões do Kubernetes suportadas, mas anexa uma versão de patch do GKE. Isto resulta num número de versão do formulário: x.y.z-gke.N.

Versão principal do Kubernetes (x)

Normalmente, as versões principais são incrementadas se forem introduzidas alterações incompatíveis com versões anteriores 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 uma duração de aproximadamente 15 semanas. As APIs descontinuadas 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, Kubernetes 1. O Kubernetes 1.29 é a versão secundária que sucede ao Kubernetes 1.28.

Versão de patch do Google Distributed Cloud (z-gke.N)

Um lançamento 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 a compilação. Os lançamentos de patches incluem atualizações de segurança e correções de erros. Uma versão de lançamento de patch do Google Distributed Cloud não tem correlação com uma versão de patch do Kubernetes.

Modelo de responsabilidade partilhada

A execução de uma aplicação de produção essencial para a empresa no Google Distributed Cloud requer que várias partes tenham responsabilidades diferentes. Embora não seja uma lista exaustiva, as secções seguintes listam as funções e as responsabilidades das diferentes partes.

Responsabilidades da Google

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

• Notificar os utilizadores sobre as atualizações disponíveis para o Google Distributed Cloud e produzir scripts de atualização para a versão anterior.

  O Google Distributed Cloud só suporta atualizações sequenciais de clusters (por exemplo: 1.31 → 1.32 → 1.33, mas não 1.31 → 1.33). Quando atualiza pools de nós, em alguns casos, pode ignorar uma versão secundária. Para mais informações sobre a lógica de atualização, consulte o artigo Regras de versão.

• Operar os serviços Connect e Cloud Operations.

• Resolução de problemas, fornecimento de soluções alternativas e correção da causa principal de quaisquer problemas relacionados com componentes fornecidos pela Google.

Responsabilidades do utilizador

• Administração geral do sistema para clusters no local.
• Manter qualquer carga de trabalho da aplicação implementada no cluster.
• Executar, manter e aplicar patches à infraestrutura do centro de dados, incluindo redes, servidores, sistema operativo, armazenamento e conetividade à Google Cloud.
• Executar, manter e aplicar patches aos balanceadores de carga de rede se for escolhida a opção de balanceador de carga manual.
• Atualizar regularmente as versões do Google Distributed Cloud.
• Monitorização do cluster e das aplicações, e resposta a quaisquer incidentes.
• Garantir que os agentes das operações na nuvem são implementados nos clusters.
• Fornecer à Google detalhes ambientais para fins de resolução de problemas.

Apoio técnico para programadores

A Google não oferece apoio técnico especificamente para as suas cargas de trabalho de aplicações. No entanto, oferecemos apoio técnico para programadores de melhor esforço para garantir que os seus programadores podem executar aplicações no Google Distributed Cloud. Acreditamos que a interação mais cedo durante o desenvolvimento pode evitar incidentes críticos mais tarde na implementação.

Este apoio técnico para programadores de melhor esforço está disponível para clientes com qualquer pacote de apoio técnico pago e é tratado como uma prioridade P3 para um problema que bloqueie um lançamento ou uma prioridade P4 para consulta geral. Nesta classificação, o nível de prioridade 0 é a prioridade mais elevada.