A edição Google Kubernetes Engine (GKE) Enterprise é a Google Cloud plataforma de modernização de aplicações. Baseia-se no Kubernetes e pode ser implementado no Google Cloud, noutras nuvens e nas instalações com o Google Distributed Cloud (tanto no VMware como em servidores bare metal). Mesmo quando um cluster gerido pelo GKE Enterprise é executado no local, foi concebido para ter uma ligação permanente aoGoogle Cloud por vários motivos, incluindo a monitorização e a gestão. No entanto, pode ter de saber o que acontece se, por qualquer motivo, a ligação a Google Cloud for perdida (por exemplo, devido a um problema técnico). Este documento descreve o impacto de uma perda de conetividade para clusters numa implementação apenas de software do Google Distributed Cloud (em hardware simples ou no VMware) e as soluções alternativas que pode usar neste evento.
Estas informações são úteis para os arquitetos que precisam de se preparar para uma desconexão não planeada ou forçada do Google Cloud e compreender as respetivas consequências. No entanto, não deve planear usar uma implementação do Google Distributed Cloud apenas de software desligada do Google Cloud como um modo de funcionamento nominal. Lembre-se de que concebemos o GKE Enterprise para tirar partido da escalabilidade e da disponibilidade dosGoogle Cloud serviços. Este documento baseia-se na conceção e na arquitetura dos vários componentes do GKE Enterprise durante uma interrupção temporária. Não podemos garantir que este documento seja exaustivo.
Este documento pressupõe que conhece o GKE. Se não for esse o caso, recomendamos que leia primeiro a vista geral do GKE.
Validação e medição de licenças do GKE Enterprise
Se ativou o GKE Enterprise, o que significa que a API Anthos (anthos.googleapis.com) está ativada no seu Google Cloud projeto, o controlador de medição do GKE Enterprise, em execução no cluster, gera e atualiza periodicamente a autorização do GKE Enterprise. A tolerância para a desassociação é de 12 horas. Além disso, a medição e a faturação são geridas através da associação.
Esta tabela lista o comportamento das funcionalidades relacionadas com licenciamento e medição em caso de desconexão temporária de Google Cloud.
| Funcionalidade | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Validação de licenças do GKE Enterprise | O controlador de medição do GKE Enterprise gera e atualiza o recurso personalizado de autorização do GKE Enterprise periodicamente, desde que o anthos.googleapis.com esteja ativado no Google Cloud projeto. | Os componentes que consomem o recurso personalizado de concessão suportam um período de tolerância: continuam a funcionar desde que o recurso personalizado de concessão seja atualizado dentro do período de tolerância. | Atualmente, ilimitado. Após a expiração do período de tolerância, os componentes começam a registar erros. Já não pode atualizar o cluster. | Nenhum |
| Medição e faturação | O controlador de medição do GKE Enterprise comunica a capacidade de vCPU do cluster à API Service Control para fins de faturação. Google Cloud | Existe um agente no cluster que persiste os registos de faturação no cluster quando está desligado, e os registos são obtidos assim que o cluster restabelece a ligação a Google Cloud. | Ilimitado. No entanto, as informações de medição do GKE Enterprise são necessárias para a conformidade, conforme indicado nos Termos Específicos do Serviço para "Software Premium". | Nenhum |
Ciclo de vida do cluster
Esta secção aborda cenários como a criação, a atualização, a eliminação e a alteração do tamanho dos clusters, bem como a monitorização do estado destas atividades.
Na maioria dos cenários, pode usar ferramentas CLI, como bmctl, gkectl e kubectl, para realizar operações durante uma desconexão temporária. Também pode
monitorizar o estado destas operações com estas ferramentas. Após o restabelecimento da ligação, a consola é atualizada para apresentar os resultados das operações realizadas durante o período sem ligação.Google Cloud
| Ação | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Criação de clusters | Usa as ferramentas de CLI bmctl ou gkectl para criar clusters. Esta operação
requer uma ligação ao dispositivo Google Cloud. |
Não pode criar clusters. | Zero | Nenhum |
| Atualização do cluster | Usa as ferramentas de CLI bmctl ou gkectl para atualizar clusters. Esta operação
requer uma ligação ao dispositivo Google Cloud. |
Não pode atualizar clusters. | Zero | Nenhum |
| Eliminação de clusters | Usa as ferramentas CLI bmctl ou gkectl para eliminar clusters. Esta operação não requer uma ligação a Google Cloud. |
Pode eliminar clusters. | Ilimitado | - |
| Visualizar o estado do cluster | Pode ver informações sobre os seus clusters na Google Cloud consola, na lista de clusters do Google Kubernetes Engine. | As informações do cluster não são apresentadas na Google Cloud consola. | Ilimitado | Use kubectl para consultar diretamente os seus clusters e obter as informações de que
precisa. |
| Remover nós de um cluster | Não precisa de uma ligação à Internet Google Cloud para remover nós de um cluster. | Pode remover nós de um cluster. | Ilimitado | - |
| Adicionar nós a um cluster | O novo nó extrai imagens de contentores do Container Registry para funcionar corretamente. É executada uma verificação prévia para validar se existe conetividade com Google Cloud. | As verificações prévias executadas quando adiciona um novo nó validam se existe conetividade com Google Cloud. Por conseguinte, não pode adicionar um novo nó a um cluster quando está desligado. | Zero | Nenhum |
Ciclo de vida da aplicação
A gestão das suas aplicações em execução num cluster no local não é afetada por uma desconexão temporária do Google Cloud. Apenas o Connect Gateway é afetado. Se estiver a usar o Container Registry, o Artifact Registry, o Cloud Build ou o Cloud Deploy para gerir as suas imagens de contentores ou pipelines de CI/CD noGoogle Cloud, estes deixam de estar disponíveis em caso de desativação. As estratégias para lidar com a desassociação desses produtos estão fora do âmbito deste documento.
| Ação | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Implementação de aplicações | Feito localmente com kubectl, através de ferramentas de CI/CD ou com o Connect Gateway. |
O gateway do Connect não está disponível. Todos os outros métodos de implementações continuam a funcionar desde que se liguem diretamente à API Kubernetes. | Ilimitado | Se estava a usar o Connect Gateway, mude para a utilização kubectl localmente. |
| Remoção de aplicações | Feito localmente com kubectl, através de ferramentas de CI/CD ou com o Connect Gateway. |
O gateway do Connect não está disponível. Todos os outros métodos de implementações continuam a funcionar desde que se liguem diretamente à API Kubernetes. | Ilimitado | Se estava a usar o Connect Gateway, mude para a utilização kubectl localmente. |
| Expansão da aplicação | Feito localmente com kubectl, através de ferramentas de CI/CD ou com o Connect Gateway. |
O gateway do Connect não está disponível. Todos os outros métodos de implementações continuam a funcionar desde que se liguem diretamente à API Kubernetes. | Ilimitado | Se estava a usar o Connect Gateway, mude para a utilização kubectl localmente. |
Registo e monitorização
A capacidade de auditoria ajuda a sua organização a cumprir os respetivos requisitos regulamentares e políticas de conformidade. O GKE Enterprise ajuda na capacidade de auditoria oferecendo registo de aplicações, registo do Kubernetes e registo de auditoria. Muitos clientes optam por tirar partido do Cloud Logging e do Cloud Monitoring da Google para evitar a gestão de uma infraestrutura de registo e monitorização no local. Outros clientes preferem centralizar os respetivos registos num sistema no local para agregação. Para oferecer apoio técnico a estes clientes, o GKE Enterprise oferece integração direta com serviços como o Prometheus, Elastic, Splunk ou Datadog. Neste modo, durante a desativação temporária da ligação ao Google Cloud, não existe qualquer impacto na funcionalidade de registo ou monitorização.
| Funcionalidade | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Registo de aplicações através do Cloud Logging | Os registos são escritos no Cloud Logging. | Os registos são colocados em buffer no disco local. | 4,5 h ou 4 GiB de buffer local por nó. Quando o buffer fica cheio ou a desconexão dura 4,5 horas, as entradas mais antigas são eliminadas. | Use uma solução de registo local. |
| Registo do sistema/Kubernetes com o Cloud Logging | Os registos são escritos no Cloud Logging. | Os registos são colocados em buffer no disco local. | 4,5 h ou 4 GiB de buffer local por nó. Quando o buffer fica cheio ou a desconexão dura 4,5 horas, as entradas mais antigas são eliminadas. | Use uma solução de registo local. |
| Registo de auditoria com os registos de auditoria do Cloud | Os registos são escritos no Cloud Logging. | Os registos são colocados em buffer no disco local. | Buffer local de 10 GiB por nó do plano de controlo. Quando o buffer fica cheio, as entradas mais antigas são eliminadas. | Configure o encaminhamento de registos para uma solução de registo local. |
| Registo de aplicações através de outro fornecedor | Pode usar diferentes fornecedores externos, como Elastic, Splunk, Datadog ou Loki. | Nenhum impacto | Ilimitado | - |
| Registo do sistema/Kubernetes através de outro fornecedor | Pode usar diferentes fornecedores externos, como Elastic, Splunk ou Datadog. | Nenhum impacto | Ilimitado | - |
| Métricas de aplicações e do Kubernetes escritas no Cloud Monitoring | As métricas são escritas no Cloud Monitoring. | As métricas são armazenadas em buffer no disco local. | 24 horas ou 6 GiB de buffer local por nó para métricas do sistema e 1 GiB de buffer local por nó para métricas da aplicação. Quando o buffer fica cheio ou a desativação dura 24 horas, as entradas mais antigas são eliminadas | Use uma solução de monitorização local. |
| Aceder e ler dados de monitorização de cargas de trabalho de aplicações e do Kubernetes | Todas as métricas estão disponíveis na Google Cloud consola e através da API Cloud Monitoring. | As métricas não são atualizadas no Cloud Monitoring durante a desativação. | 24 horas ou 6 GiB de buffer local por nó para métricas do sistema e 1 GiB de buffer local por nó para métricas da aplicação. Quando o buffer fica cheio ou a desconexão dura 24 horas, as entradas mais antigas são eliminadas | Use uma solução de monitorização local. |
| Regras de alerta e paginação para métricas | O Cloud Monitoring suporta alertas. Pode criar alertas para qualquer métrica. Os alertas podem ser enviados através de diferentes canais. | Os alertas não são acionados quando a ligação está interrompida. Os alertas só são acionados a partir de dados de métricas já enviados para o Cloud Monitoring | Use uma solução de monitorização e alertas local. |
Gestão de políticas e configurações
O Config Sync e o Policy Controller permitem-lhe gerir a configuração e as políticas em grande escala, em todos os seus clusters. Armazena configurações e políticas num repositório Git, e estas são sincronizadas automaticamente com os seus clusters.
Config Sync
O Config Sync usa agentes no cluster para estabelecer ligação
diretamente a um repositório Git. Pode gerir as alterações ao URL do repositório ou aos parâmetros de sincronização com as ferramentas gcloud ou kubectl.
Durante a desativação temporária, a sincronização não é afetada se os agentes no cluster ainda conseguirem aceder ao repositório Git. No entanto, se alterar os parâmetros de sincronização com a CLI do Google Cloud ou a consola, estes não são aplicados ao cluster durante a desassociação. Google Cloud Pode substituí-los temporariamente
localmente através do comando kubectl. As alterações locais são substituídas quando a ligação é restabelecida.
Controlador de políticas
O Policy Controller permite a aplicação de políticas totalmente programáveis para os seus clusters. Estas políticas atuam como "guardrails" e impedem quaisquer alterações que violem os controlos de segurança, operacionais ou de conformidade que definiu.
| Ação | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Sincronizar a configuração a partir de um repositório Git | Os agentes no cluster estabelecem ligação diretamente ao repositório Git. Pode alterar o URL do repositório ou os parâmetros de sincronização com uma Google Cloud API. | A sincronização das configurações não é afetada. Se alterar os parâmetros de sincronização com o gcloud ou na Google Cloud consola, estes não são aplicados ao cluster durante a desassociação. Pode substituí-los temporariamente de forma local através do kubectl. Todas as alterações locais são substituídas quando a ligação é restabelecida. |
Ilimitado | Nunca use a API Fleet para a sincronização de configuração e configure-a apenas através da API Kubernetes. |
| Aplicação de políticas em pedidos à API Kubernetes | O agente no cluster aplica restrições graças à sua integração com a API Kubernetes. Faz a gestão das políticas através da API Kubernetes local. Pode gerir a configuração do sistema do Policy Controller com uma Google Cloud API. | A aplicação de políticas não é afetada. As políticas continuam a ser geridas através da API Kubernetes local. As alterações à configuração do sistema do Policy Controller através da API não são propagadas para o cluster, mas pode substituí-las temporariamente localmente.Google Cloud Quaisquer alterações locais são substituídas quando a ligação é restabelecida. | Ilimitado | Nunca use a API Fleet para o Policy Controller e configure-a apenas através da API Kubernetes. |
| Instalar, configurar ou atualizar o Config Sync através da Google Cloud API | Usa a Google Cloud API para gerir a instalação e a atualização de agentes no cluster. Também usa esta API (ou o gcloud ou a Google Cloud consola) para gerir a configuração destes agentes. | Os agentes no cluster continuam a funcionar normalmente. Não pode instalar, atualizar nem configurar agentes no cluster através da API Google Cloud . Todas as instalações, atualizações ou configurações pendentes feitas através da API prosseguem após a nova ligação. | Zero | Nunca use a API Fleet para o Policy Controller e configure-a apenas através da API Kubernetes. |
| Ver o estado do sistema ou da sincronização na Google Cloud consola | Pode ver o estado de funcionamento dos agentes no cluster e o estado de sincronização através de uma Google Cloud API ou da Google Cloud consola. | As informações de estado na Google Cloud API ou Google Cloud na consola ficam desatualizadas. A API apresenta um erro de ligação. Todas as informações permanecem disponíveis por cluster através da API Kubernetes local. | Zero | Use a CLI nomos ou a API Kubernetes local. |
Segurança
Identidade, autenticação e autorização
O GKE Enterprise pode ligar-se diretamente ao Cloud ID para funções de utilizador e de aplicação, para gerir cargas de trabalho através do Connect ou para autenticação de pontos finais através do OIDC. Em caso de desconexão do Google Cloud, a ligação ao Cloud ID também é interrompida e essas funcionalidades deixam de estar disponíveis. Para cargas de trabalho que requerem resiliência adicional através de uma desassociação temporária, pode usar o GKE Identity Service para integrar com um fornecedor LDAP ou OIDC (incluindo o ADFS) para configurar a autenticação do utilizador final.
| Funcionalidade | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| O Cloud ID como fornecedor de identidade, através do gateway Connect | Pode aceder aos recursos do GKE Enterprise através do Cloud ID como fornecedor de identidade e estabelecer ligação através do gateway Connect. | O gateway Connect requer uma ligação ao Google Cloud. Não pode estabelecer ligação aos seus clusters durante a desassociação. | Zero | Use o serviço de identidade do GKE para federar com outro fornecedor de identidade. |
| Identidade e autenticação através de um fornecedor de identidade de terceiros | Suporta OIDC e LDAP. Utiliza a CLI gcloud para iniciar sessão primeiro. Para fornecedores OIDC, pode usar a Google Cloud consola para iniciar sessão. Em seguida, pode autenticar-se normalmente na API do cluster (por exemplo, através de kubectl). |
Enquanto o fornecedor de identidade permanecer acessível para si e para o cluster, pode continuar a autenticar-se na API do cluster. Não pode iniciar sessão através da Google Cloud consola. Só pode atualizar a configuração do OIDC ou LDAP dos seus clusters localmente. Não pode usar a Google Cloud consola. | Ilimitado | - |
| Autorização | O GKE Enterprise suporta o controlo de acesso baseado em funções (RBAC). As funções podem ser atribuídas a utilizadores, grupos ou contas de serviço. As identidades e os grupos de utilizadores podem ser obtidos do fornecedor de identidade. | O sistema RBAC é local para o cluster do Kubernetes e não é afetado pela desassociação do Google Cloud. No entanto, se depender de identidades provenientes do Cloud ID, estas não estão disponíveis em caso de desligamento. | Ilimitado | - |
Gestão de chaves e segredos
A gestão de segredos e chaves é uma parte importante da sua postura de segurança. O comportamento do GKE Enterprise em caso de desativação da ligação ao Google Cloud depende do serviço que está a usar para essas funcionalidades.
| Funcionalidade | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Gestão de segredos e chaves através do Cloud Key Management Service e do Secret Manager | Usa diretamente o Cloud Key Management Service para as suas chaves criptográficas e o Secret Manager para os seus segredos. | O Cloud Key Management Service e o Secret Manager não estão disponíveis. | Zero | Em alternativa, use sistemas locais. |
| Gestão de chaves e segredos com o Hashicorp Vault e os serviços Google Cloud | Configura o Hashicorp Vault para usar o Cloud Storage ou o Spanner para armazenar segredos e o Cloud Key Management Service para gerir chaves. | Se o Hashicorp Vault for executado no seu cluster do Anthos e também for afetado pela desconexão, o armazenamento de segredos e a gestão de chaves não estão disponíveis durante a desconexão. | Zero | Em alternativa, use sistemas locais. |
| Gestão de chaves e segredos através do Hashicorp Vault e de serviços no local | Configura o Hashicorp Vault para usar um back-end de armazenamento no local para segredos e um sistema de gestão de chaves no local (como um módulo de segurança de hardware). | A desassociação de Google Cloud não tem impacto. | Ilimitado | - |
Redes e serviços de rede
Balanceamento de carga
Para expor os serviços Kubernetes alojados num cluster no local aos utilizadores, pode optar por usar o balanceador de carga integrado fornecido (MetalLB em hardware simples, Seesaw ou MetalLB no VMware) ou o seu balanceador de carga, externo ao GKE Enterprise. Ambas as opções continuam a funcionar em caso de desligamento do Google Cloud.
| Funcionalidade | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Balanceador de carga agrupado de nível 4 | Oferece equilíbrio de carga da camada 4 totalmente local, sem dependência de APIs ou rede.Google Cloud | Sem alteração | Ilimitado | - |
| Balanceador de carga manual ou integrado | Suporta F5 BIG-IP e outros que também estão alojados no local. | Sem alteração | Ilimitado | - |
Cloud Service Mesh
Pode usar o Cloud Service Mesh para gerir, observar e proteger as comunicações entre os seus serviços executados num cluster no local. Nem todas as funcionalidades do Cloud Service Mesh são suportadas no Google Distributed Cloud. Consulte a lista de funcionalidades suportadas para mais informações.
| Funcionalidade | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Implementar ou atualizar políticas (encaminhamento, autorização, segurança, auditoria, etc.) | Pode usar a consola Google Cloud , a kubectl, o asmcli ou o istioctl para gerir as políticas do Cloud Service Mesh. |
Só pode usar o kubectl ou o istioctl para gerir políticas da Cloud Service Mesh. |
Ilimitado | Use kubectl ou istioctl |
| Autoridade de certificação (AC) | Pode usar a AC no cluster ou a autoridade de certificação do Cloud Service Mesh para gerir os certificados usados pelo Cloud Service Mesh. | Não existe qualquer impacto se estiver a usar a AC no cluster. Se estiver a usar a autoridade de certificação do Cloud Service Mesh, os certificados expiram após 24 horas. As novas instâncias de serviço não conseguem obter certificados. |
Ilimitado para a CA no cluster. Serviço degradado durante 24 horas e sem serviço após 24 horas para a autoridade de certificação do Cloud Service Mesh. |
Use a AC no cluster. |
| Cloud Monitoring para Cloud Service Mesh | Pode usar o Cloud Monitoring para armazenar, explorar e tirar partido das métricas relacionadas com HTTP provenientes do Cloud Service Mesh. | As métricas não são armazenadas. | Zero | Use uma solução de monitorização local compatível, como o Prometheus. |
| Registo de auditoria do Cloud Service Mesh | O Cloud Service Mesh baseia-se nas instalações de registo do Kubernetes local. O comportamento depende de como configurou o registo para o cluster do GKE Enterprise. | Depende da forma como configurou o registo para o seu cluster do GKE Enterprise. | - | - |
| Gateway de entrada | Pode definir IPs externos com o Istio Ingress Gateway. | Nenhum impacto | Ilimitado | - |
| Interface de rede de contentores (CNI) do Istio | Pode configurar o Cloud Service Mesh para usar o Istio CNI em vez de iptables para gerir o tráfego. | Nenhum impacto | Ilimitado | - |
| Autenticação do utilizador final do Cloud Service Mesh para aplicações Web | Pode usar o gateway de entrada do Cloud Service Mesh para fazer a integração com o seu próprio fornecedor de identidade (através do OIDC) para autenticar e autorizar utilizadores finais em aplicações Web que fazem parte da malha. | Nenhum impacto | Ilimitado | - |
Outros serviços de rede
| Funcionalidade | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| DNS | O servidor DNS do Kubernetes é executado no cluster. | O serviço DNS do Kubernetes funciona normalmente, uma vez que é executado no próprio cluster. | Ilimitado | - |
| Proxy de saída | Pode configurar o GKE Enterprise para usar um proxy para ligações de saída. | Se o seu proxy for executado no local, o GKE Enterprise continua a poder usá-lo durante uma desconexão temporária. No entanto, se o proxy perder a ligação a Google Cloud, todos os cenários deste documento continuam a aplicar-se. | Ilimitado | - |
Google Cloud Marketplace
| Funcionalidade | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Implementar e gerir aplicações e serviços a partir do Cloud Marketplace | O Cloud Marketplace está disponível na Google Cloud consola e pode usá-lo para descobrir, adquirir e implementar soluções. | Não pode usar o Cloud Marketplace. Algumas soluções do Cloud Marketplace podem ter os seus próprios requisitos de conetividade que não estão documentados aqui. | Zero | Nenhum |
Apoio técnico
Esta secção aborda os cenários que pode ter de percorrer enquanto interage com o Google Cloud apoio técnico ou o seu parceiro de operações para um registo relacionado com os seus clusters do GKE on GDC.
| Funcionalidade | Comportamento ligado | Comportamento de desconexão temporária | Tolerância máxima de desconexão | Solução alternativa para a perda de conetividade |
|---|---|---|---|---|
| Partilhar uma captura de ecrã de um cluster com a equipa de apoio técnico | Pode criar uma captura instantânea do cluster localmente através dos comandos bmctl check cluster
ou gkectl diagnose snapshot. Partilhe este instantâneo através do processo de apoio técnico normal. |
Continua a poder gerar a captura de ecrã, uma vez que é uma operação local. Se tiver perdido o acesso ao Google Ads e às respetivas interfaces Web de apoio técnico, pode telefonar à equipa de apoio técnico, desde que tenha subscrito os planos de apoio técnico Melhorado ou Premium. Google Cloud | Ilimitado | - |
| Partilhar dados de registo relevantes com a equipa de apoio técnico | Pode recolher registos localmente a partir do cluster e partilhá-los através do processo de apoio técnico normal. | Pode continuar a recolher registos do seu cluster. Se tiver perdido o acesso ao Google Ads e às respetivas interfaces Web de apoio técnico, pode telefonar à equipa de apoio técnico, desde que tenha subscrito os planos de apoio técnico Melhorado ou Premium. Google Cloud | Ilimitado | - |