Receber suporte

O principal objetivo do suporte do Google é resolver os incidentes de produção o mais rápido possível. Entender a configuração, analisar registros e métricas e colaborar com parceiros nos ajuda a resolver incidentes rapidamente.

O Google Cloud oferece vários pacotes de suporte para atender às suas necessidades. Todos os pacotes de suporte do Google Cloud incluem suporte para clusters do Anthos e Anthos em Bare Metal. Se você já tiver um pacote de suporte do Google Cloud, já terá suporte para os clusters do Anthos e Anthos em Bare Metal.

Para mais informações, consulte a documentação do suporte do Google Cloud.

Requisitos para suporte dos clusters do Anthos em Bare Metal

Para resolver problemas de incidentes críticos para a empresa de maneira eficaz:

Ferramentas de suporte

Para solucionar problemas de incidentes dos clusters do Anthos em Bare Metal, o suporte do Google Cloud depende de três informações:

Sua configuração do ambiente

Ao abrir um caso de suporte, a execução dos comandos a seguir fornece informações importantes sobre a configuração do cluster:

  • Para todos os tipos de cluster, execute o comando bmctl check cluster --snapshot para capturar informações sobre o Kubernetes e os nós. Anexe o tarball resultante ao caso de suporte.

  • Para clusters administrativos, híbridos e autônomos, execute o comando bmctl check cluster para verificar o status de integridade do cluster e dos nós. Anexe os registros resultantes ao caso de suporte. Eles devem existir 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 com o comando kubectl. Aqui está um comando de amostra usando 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, testando-o para ver se ele 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. Aqui está um teste de amostra com o comando kubectl que 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 concluído, esse comando retorna:

      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 com o comando kubectl. Veja um exemplo que usa o job de verificação de integridade da 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 Anthos em Bare Metal, os agentes do Cloud Logging são ativados por padrão e com escopo somente nos 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

Os registros podem ser consultados no Console do Cloud Logging.

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 a equipe de suporte 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 do Google Cloud para os clusters registrados.

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

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 ou na Central de suporte do Google Cloud e seleciona o Anthos e clusters do Anthos em Bare Metal como categoria e componente, respectivamente. São inseridas as informações necessárias e anexadas a saída de comandos bmctl relevantes ao caso.
  2. A consulta ao suporte é encaminhada para um engenheiro de suporte técnico especializado em clusters do Anthos em Bare Metal.
  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 do Google Cloud, inserindo o ID do histórico de consultas 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 a solução de problemas até conseguir uma resolução.

O que o Google aceita?

Geralmente, a equipe de suporte do Cloud suporta todos os componentes de software enviados como parte dos clusters do Anthos em Bare Metal, Anthos Service Mesh e Anthos Config Management. Consulte a tabela a seguir para ver uma lista mais completa do que é suportado ou não:

Compatível com o Google Cloud Incompatível
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)
Operações, monitoramento, geração de registros e agentes do Google Cloud 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
Anthos Identity Service
Anthos Service Mesh
Anthos Config Management

Política de suporte da versão

O suporte para clusters do Anthos em Bare Metal segue a Política de suporte de versão do Anthos. A partir da versão 1.14 do Anthos, o Google é compatível com cada cluster do Anthos em versão secundária bare metal por 12 meses após o lançamento inicial da versão secundária ou até o lançamento da terceira versão secundária subsequente, o que for mais longo.

A tabela a seguir mostra as versões compatíveis e não compatíveis com este produto.

Versão secundária Data da versão Data de fim da vida útil mais antiga Patches disponíveis Versão do Kubernetes
1.15 (Mais recente) 27 de abril de 2023 27 de abril de 2024 1.15.2 v1.26.5-gke.1200
1.15.1 v1.26.2-gke.1001
1.15.0 v1.26.2-gke.1001
1.14 8 de dezembro de 2022 8 de dezembro de 2023 1.14.6 v1.25.10-gke.1200
1.14.5 v1.25.7-gke.1000
1.14.4 v1.25.7-gke.1000
1.14.3 v1.25.6-gke.1000
1.14.2 v1.25.5-gke.1001
1.14.1 v1.25.5-gke.1001
1.14.0 v1.25.3-gke.1400
1.13 29 de setembro de 2022 17 de agosto de 2023 1.13.9 v1.24.14-gke.1200
1.13.8 v1.24.11-gke.1000
1.13.7 v1.24.11-gke.1000
1.13.6 v1.24.9-gke.2500
1.13.5 v1.24.9-gke.2500
1.13.4 v1.24.9-gke.2500
1.13.3 v1.24.7-gke.1700
1.13.2 v1.24.7-gke.300
1.13.1 v1.24.5-gke.400
1.13.0 v1.24.2-gke.1900
1.12 (Sem suporte) 29 de junho de 2022 29 de março de 2023 1.12.9 v1.23.17-gke.300
1.12.8 v1.23.16-gke.100
1.12.7 v1.23.15-gke.2400
1.12.6 v1.23.13-gke.1700
1.12.5 v1.23.13-gke.1700
1.12.4 v1.23.11-gke.500
1.12.3 v1.23.10-gke.1000
1.12.2 v1.23.5-gke.1505
1.12.1 v1.23.5-gke.1505
1.12.0 v1.23.5-gke.1504
1.11 (sem suporte) 21 de março de 2022 21 de dezembro de 2022 1.11.8 v1.22.15-gke.3300
1.11.7 v1.22.14-gke.500
1.11.6 v1.22.8-gke.204
1.11.5 v1.22.8-gke.204
1.11.4 v1.22.8-gke.204
1.11.3 v1.22.8-gke.203
1.11.2 v1.22.8-gke.200
1.11.1 v1.22.8-gke.200
1.11.0 v1.22.8-gke.200
1.10 (sem suporte) 10 de dezembro de 2021 10 de setembro de 2022 1.10.8 v1.21.13-gke.202
1.10.7 v1.21.13-gke.202
1.10.6 v1.21.13-gke.201
1.10.5 v1.21.6-gke.1503
1.10.4 v1.21.6-gke.1503
1.10.3 v1.21.5-gke.1300
1.10.2 v1.21.5-gke.1300
1.10.1 v1.21.5-gke.1200
1.10.0 v1.21.5-gke.1200
1.9 (sem suporte) 23 de setembro de 2021 23 de junho de 2022 1.9.8 v1.21.13-gke.200
1.9.7 v1.21.6-gke.1503
1.9.6 v1.21.5-gke.1300
1.9.5 v1.21.5-gke.1300
1.9.4 v1.21.5-gke.1200
1.9.3 v1.21.5-gke.1200
1.9.2 v1.21.4-gke.201
1.9.1 v1.21.4-gke.201
1.9.0 v1.21.4-gke.200
1.8 (sem suporte) 21 de junho de 2021 21 de março de 2022 1.8.9 v1.20.9-gke.102
1.8.8 v1.20.9-gke.102
1.8.7 v1.20.9-gke.102
1.8.6 v1.20.9-gke.102
1.8.5 v1.20.9-gke.102
1.8.4 v1.20.9-gke.101
1.8.3 v1.20.9-gke.101
1.8.2 v1.20.8-gke.1500
1.8.1 v1.20.5-gke.1301
1.8.0 v1.20.5-gke.1301
1.7 (sem suporte) 25 de março de 2021 25 de dezembro de 2021 1.7.7 v1.19.14-gke.2201
1.7.6 v1.19.14-gke.2201
1.7.5 v1.19.14-gke.2201
1.7.4 v1.19.14-gke.400
1.7.3 v1.19.13-gke.100
1.7.2 v1.19.10-gke.1602
1.7.1 v1.19.7-gke.1200
1.7.0 v1.19.7-gke.1200
1.6 (sem suporte) 30 de novembro de 2020 30 de agosto de 2021 1.6.4 v1.18.20-gke.3000
1.6.3 v1.18.18-gke.100
1.6.2 v1.18.6-gke.6600
1.6.1 v1.18.6-gke.6600
1.6.0 v1.18.6-gke.6600

Recursos compatíveis

Este documento lista a disponibilidade dos recursos e funcionalidades dos clusters do Anthos em bare metal 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 listados como "Visualização" são cobertos pelos Termos de ofertas pré-GA dos Termos de Serviço do Google Cloud. Os produtos e recursos anteriores à disponibilidade geral têm suporte limitado, e as mudanças nesses produtos podem não ser compatíveis com outras versões anteriores. Para mais informações, consulte as descrições da fase de lançamento. Cuidado: as ofertas de pré-lançamento destinam-se ao uso somente em ambientes de teste.

Os recursos listados como disponibilidade geral (GA, na sigla em inglês) são totalmente compatíveis, abertos a todos os clientes e prontos para uso em produção.

Recurso/funcionalidade 1.12 (Sem suporte) 1.13 1.14 1.15 (Mais recente)
Políticas de alertas Visualizar Visualizar Visualizar Visualizar
Ambiente de execução de VM do Anthos GA GA GA GA
Grupos do Azure Active Directory (AD) não disponível não disponível GA GA
Autorização binária não disponível não disponível não disponível Visualizar
Balanceamento de carga em pacote com o BGP GA GA GA GA
Cloud Audit Logging GA GA GA GA
Suporte a CLI de backup e restauração de clusters GA GA GA GA
Rotação de autoridades de certificação (CAs, na sigla em inglês) de cluster GA GA GA GA
Suporte à CLI de redefinição de nós do cluster GA GA GA GA
ambiente de execução de contêineres containerd GA GA GA GA
Grupo de controle v2 não disponível não disponível Visualizar GA
IP dinâmico fixo com protocolo de gateway de borda (BGP) Visualizar GA GA GA
Gateway NAT de saída GA GA GA GA
Modo IPv4 plano (estático) GA GA GA GA
Compatibilidade com IPv6 plano (modo BGP) Visualizar GA GA GA
Suporte ao balanceador de carga baseado em BGP para IPv6 Visualizar GA GA GA
Pilha dupla IPv4/IPv6 GA GA GA GA
Compatibilidade com KSA GA GA GA GA
Coletor gerenciado para o Google Cloud Managed Service para Prometheus Visualizar GA GA GA
Conectividade com vários clusters Visualizar Visualizar Visualizar Visualizar
Multi-NIC para pods GA GA GA GA
Gateway de conectividade de rede Visualizar Visualizar Visualizar Visualizar
node-problem-detector GA GA GA GA
Compatibilidade com o espelho do registro Visualizar GA GA GA
Modo de computação seguro (seccomp) Visualizar Visualizar GA GA
Rede SR-IOV GA GA GA GA
Métricas da API Summary GA GA GA GA
Identidade da carga de trabalho GA GA GA GA
VPC Service Controls não disponível não disponível não disponível Visualizar
Upgrades de nós paralelos não disponível não disponível Visualizar GA

Modelo de responsabilidade compartilhada

A execução de um aplicativo de produção essencial para os negócios nos clusters do Anthos em Bare Metal exige que várias partes tenham responsabilidades diferentes. Ainda que não seja uma lista completa, as seções a seguir listam os papéis e as responsabilidades.

Responsabilidades do Google

  • Manutenção e distribuição de um pacote de software dos clusters do Anthos em Bare Metal.
  • Notificar os usuários sobre upgrades disponíveis para clusters do Anthos em Bare Metal e produzir scripts de upgrade para a versão anterior. Os clusters do Anthos em Bare Metal são compatíveis apenas com upgrades sequenciais (por exemplo: 1.2 → 1.3 → 1.4 e não 1.2 → 1.4).
  • Operar os serviços de operações do Cloud e Connect.
  • Solução de problemas, solução alternativa e correção da 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 o Google Cloud.
  • Executar, manter e corrigir balanceadores de carga de rede se a opção do balanceador de carga manual for escolhida.
  • Fazer upgrade dos clusters do Anthos em versões Bare Metal 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 desenvolvedores

O Google não suporta as cargas de trabalho de aplicativos em execução nos clusters do Anthos em Bare Metal. No entanto, oferecemos suporte para desenvolvedores com base no melhor esforço para garantir que os desenvolvedores possam executar aplicativos com facilidade nos clusters do Anthos em Bare Metal. Acreditamos que o envolvimento prévio durante o desenvolvimento pode evitar incidentes críticos posteriores à implantação.

Esse suporte ao desenvolvedor está disponível para clientes com um pacote de suporte pago e é tratado como prioridade P3 para um problema que bloqueia um lançamento ou como prioridade P4 para consultoria geral.