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 Google Cloud oferece uma variedade de 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 Google Kubernetes Engine (GKE) Enterprise Edition 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 solucionar problemas de incidentes críticos para a empresa com eficiência, você precisa realizar estas etapas:
- Verifique se o ambiente é atual com os prazos de fim de suporte publicados. Consulte a Política de suporte de versões abaixo.
- Ative o Cloud Logging e o Cloud Monitoring para os componentes do sistema. Para mais detalhes, 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 suporte do Google Cloud 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 histórico de consultas, você precisa executar o
comando gkectl diagnose snapshot --seed-config
e anexar o tarball resultante
ao histórico de consultas. O 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 saber mais, consulte Como diagnosticar clusters.
É possível adicionar um campo excludeWords
ao arquivo de configuração para omitir
informações confidenciais. Revise cuidadosamente as
informações capturadas pela ferramenta. Informações confidenciais ou altamente confidenciais
não podem ser anexadas ao seu histórico de consultas.
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 do Google Cloud associado ao cluster. Os registros no nível do sistema são de pods do Kubernetes em execução em um dos cinco namespaces:
- kube-system
- gke-system
- gke-connect
- istio-system
- config-management-system
- knative-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 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.
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 solucionar seu problema de 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 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_KUBECONFIG
Para 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 na Central de suporte do Google Cloud.
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 de
gkectl diagnose snapshot
ao 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 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.
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, a equipe de suporte do Cloud é compatível com todos os componentes de software enviados como parte do Google Distributed Cloud (somente software) para VMware. A tabela a seguir detalha isso:
Suporte do Google Cloud | 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 (consulte o Suporte ao desenvolvedor abaixo) |
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) |
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.
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 Termos de Serviço do Google Cloud. 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 Enterprise e a compatibilidade deles, consulte Suporte para upgrade e versão do GKE Enterprise.
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 Enterprise.
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 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.