Os clusters do Anthos em bare metal agora são o Google Distributed Cloud (somente software) em bare metal. Para mais informações, consulte a visão geral do produto.

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 o Google Kubernetes Engine (GKE) Enterprise Edition e o Google Distributed Cloud. Se você já tem um pacote de suporte do Google Cloud, já tem suporte para o GKE Enterprise e o Google Distributed Cloud.

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

Requisitos para o suporte do Google Distributed Cloud

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

Verifique se o ambiente está atualizado e dentro dos prazos de fim de suporte publicados. Consulte a seção Política de suporte da versão para mais informações.
Ative o Cloud Logging e o Cloud Monitoring para componentes do sistema. Para detalhes, consulte a seguinte seção Ferramentas de suporte.

Ferramentas de suporte

Para solucionar um incidente do Google Distributed Cloud, o suporte do Google Cloud 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, 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 arquivo tar 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 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

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:

O administrador do cluster abre um caso de suporte no console do Google Cloud ou na Central de suporte do Google Cloud e seleciona a edição Enterprise do Google Kubernetes Engine (GKE) e a nuvem distribuída do Google como categoria e componente, respectivamente. São inseridas as informações necessárias e anexadas a saída de comandos bmctl relevantes ao caso.
O caso de suporte é encaminhado para um engenheiro de suporte técnico especializado no Google Distributed Cloud.
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 do 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.

O que o Google aceita?

Geralmente, a equipe de suporte do Cloud 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. 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
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 suporte para o Google Distributed Cloud segue a política de suporte do GKE Enterprise. 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.

Para conferir as datas de lançamento mais recentes do GKE Enterprise e as datas de fim da vida útil mais antigas, consulte Período de suporte do GKE Enterprise.

Para listas das versões do Google Distributed Cloud com e sem suporte, consulte Controle de versões.

Para informações de versão relacionadas a upgrades de cluster, consulte Regras de versão para upgrades.

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. 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 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 (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 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 desenvolvedores

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.