O Google Kubernetes Engine (GKE) Enterprise é a plataforma de modernização de aplicativos do Google Cloud. Ele é baseado no Kubernetes e pode ser implantado no Google Cloud, em outras nuvens e no local com o Google Distributed Cloud (tanto no VMware quanto em servidores bare metal). Mesmo quando um cluster gerenciado pelo GKE Enterprise é executado no local, ele é projetado para ter uma conexão permanente com o Google Cloud por vários motivos, incluindo monitoramento e gerenciamento. No entanto, talvez você precise saber o que aconteceria se, por qualquer motivo, a conexão com o Google Cloud fosse perdida (por exemplo, devido a um problema técnico). Neste documento, descrevemos o impacto de uma perda de conectividade para clusters em uma implantação somente de software do Google Distributed Cloud (em bare metal ou no VMware) e quais soluções alternativas que podem ser usadas nesse evento.
Essas informações são úteis para arquitetos que precisam se preparar para uma desconexão forçada ou não planejada do Google Cloud e entender as consequências. No entanto, você não deve planejar usar uma implantação do Google Distributed Cloud somente de software desconectada do Google Cloud como um modo de trabalho nominal. Lembre-se de que criamos o GKE Enterprise para aproveitar a escalonabilidade e a disponibilidade dos serviços do Google Cloud. Este documento é baseado no design e na arquitetura dos vários componentes do GKE Enterprise durante uma interrupção temporária. Não podemos garantir que este documento esteja completo.
Neste documento, consideramos que você já conhece o GKE Enterprise. Se esse não for o caso, recomendamos que você leia primeiro as informações gerais técnicas do GKE Enterprise.
Validação e medição de licenças do GKE Enterprise
Se você ativou o GKE Enterprise, o que significa que a API Anthos (anthos.googleapis.com) está ativada no seu projeto do Google Cloud, o controlador de medição do GKE Enterprise, em execução no cluster, gera e atualiza o direito do GKE Enterprise periodicamente. A tolerância à desconexão é de 12 horas. Além disso, a medição e o faturamento são gerenciados por meio da conexão.
Nesta tabela, mostramos o comportamento dos recursos relacionados a licenciamento e medição em caso de desconexão temporária do Google Cloud.
| Recurso | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Validação de licença do GKE Enterprise | O controlador de medição do GKE Enterprise gera e atualiza o recurso personalizado de direitos do GKE Enterprise periodicamente, desde que anthos.googleapis.com esteja ativado no projeto do Google Cloud. | Os componentes que consomem o recurso personalizado de direitos são compatíveis com um período de carência. Eles continuam funcionando enquanto o recurso é atualizado no período de carência. | Ilimitados no momento. Depois que o período de carência expirar, os componentes começarão a registrar erros. Não é mais possível fazer upgrade do cluster. | Nenhum |
| Limite e faturamento | O controlador de medição do GKE Enterprise informa a capacidade de vCPU do cluster para a API Google Cloud Service Control para fins de faturamento. | Há um agente no cluster que mantém registros de faturamento no cluster quando desconectado, e os registros são recuperados quando o cluster se reconecta ao Google Cloud. | Ilimitado. No entanto, as informações de medição do GKE Enterprise são necessárias para compliance, conforme indicado nos Termos específicos de serviço de "Software Premium". | Nenhum |
Ciclo de vida do cluster
Nesta seção, abordamos cenários como criação, atualização, exclusão e redimensionamento de clusters, além do monitoramento do status dessas atividades.
Na maioria dos cenários, é possível usar ferramentas de CLI, como bmctl, gkectl e kubectl, para executar operações durante uma desconexão temporária. Também é possível monitorar o status dessas operações com essas ferramentas. Após a reconexão, o console do Google Cloud é atualizado para exibir os resultados das operações realizadas durante o período desconectado.
| Ação | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Criação de cluster | Use as ferramentas da CLI bmctl ou gkectl para criar clusters. Essa operação
requer uma conexão com o Google Cloud |
Não é possível criar clusters. | Zero | Nenhum |
| Upgrade do cluster | Use as ferramentas da CLI bmctl ou gkectl para fazer upgrade dos clusters. Essa operação
requer uma conexão com o Google Cloud |
Não é possível fazer upgrade de clusters. | Zero | Nenhum |
| Exclusão de cluster | Use as ferramentas da CLI bmctl ou gkectl para excluir clusters. Esta operação
não requer conexão com o Google Cloud. |
É possível excluir clusters. | Ilimitado | - |
| Como visualizar o status do cluster | Veja informações sobre os clusters no console do Google Cloud na lista de clusters do Google Kubernetes Engine. | As informações do cluster não são mostradas no console do Google Cloud. | Ilimitado | Use kubectl para consultar diretamente os clusters e receber as informações necessárias. |
| Como remover nós de um cluster | Você não precisa de uma conexão com o Google Cloud para remover nós de um cluster. | É possível remover nós de um cluster. | Ilimitado | - |
| Como adicionar nós a um cluster | O novo nó extrai imagens de contêiner do Container Registry para funcionar corretamente. Uma verificação de simulação é executada para confirmar que há conectividade com o Google Cloud. | As verificações de simulação executadas ao adicionar um novo nó validam a conectividade com o Google Cloud. Portanto, não é possível adicionar um novo nó a um cluster quando desconectado. | Zero | Nenhum |
Ciclo de vida do aplicativo
O gerenciamento de aplicativos em execução em um cluster no local geralmente não é afetado por uma desconexão temporária do Google Cloud. Apenas o Connect Gateway é afetado. Se você estiver usando o Container Registry, Artifact Registry, Cloud Build ou Google Cloud Deploy para gerenciar suas imagens de contêiner ou pipelines de CI/CD no Google Cloud, elas não ficam mais disponíveis em caso de desconexão. As estratégias para lidar com a desconexão desses produtos estão fora do escopo deste documento.
| Ação | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Implantação do app | Feito localmente usando kubectl, por meio de ferramentas de CI/CD ou usando o gateway de conexão. |
O gateway de conexão não está disponível. Todos os outros métodos de implantação ainda funcionam, desde que estejam conectados diretamente à API Kubernetes. | Ilimitado | Se você estava usando o Connect Gateway, mude para o uso local de kubectl. |
| Remoção de aplicativo | Feito localmente usando kubectl, por meio de ferramentas de CI/CD ou usando o gateway de conexão. |
O gateway de conexão não está disponível. Todos os outros métodos de implantação ainda funcionam, desde que estejam conectados diretamente à API Kubernetes. | Ilimitado | Se você estava usando o Connect Gateway, mude para o uso local de kubectl. |
| Escalonamento horizontal do aplicativo | Feito localmente usando kubectl, por meio de ferramentas de CI/CD ou usando o gateway de conexão. |
O gateway de conexão não está disponível. Todos os outros métodos de implantação ainda funcionam, desde que estejam conectados diretamente à API Kubernetes. | Ilimitado | Se você estava usando o Connect Gateway, mude para o uso local de kubectl. |
Como gerar registros e monitorar
A auditabilidade ajuda sua organização a atender aos requisitos regulamentares e às políticas de conformidade. O GKE Enterprise ajuda na capacidade de auditoria oferecendo geração de registros de aplicativos, Kubernetes e auditoria. Muitos clientes optam pelo Cloud Logging e Cloud Monitoring do Google para evitar o gerenciamento de uma infraestrutura de geração de registros e monitoramento no local. Outros clientes preferem centralizar seus registros em um sistema local para agregação. Para oferecer suporte a esses clientes, o GKE Enterprise fornece integração direta a serviços como Prometheus, Elastic, Splunk ou Datadog. Nesse modo, durante a desconexão temporária do Google Cloud, não há impacto na funcionalidade de geração de registros ou monitoramento.
| Recurso | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Geração de registros do aplicativo usando o Cloud Logging | Os registros são gravados no Cloud Logging. | Os registros são armazenados em buffer no disco local. | Buffer local de 4,5h ou 4GiB por nó. Quando o buffer é preenchido ou a desconexão dura 4,5 horas, as entradas mais antigas são descartadas. | Use uma solução local de geração de registros. |
| Geração de registros do sistema/Kubernetes usando o Cloud Logging | Os registros são gravados no Cloud Logging. | Os registros são armazenados em buffer no disco local. | Buffer local de 4,5h ou 4GiB por nó. Quando o buffer é preenchido ou a desconexão dura 4,5 horas, as entradas mais antigas são descartadas. | Use uma solução local de geração de registros. |
| Como gerar registros de auditoria usando registros de auditoria do Cloud | Os registros são gravados no Cloud Logging. | Os registros são armazenados em buffer no disco local. | Buffer local de 10 GiB por nó do plano de controle. Quando o buffer é preenchido, as entradas mais antigas são descartadas. | Configure o encaminhamento de registros para uma solução de geração de registros local. |
| Geração de registros do aplicativo usando outro provedor | É possível usar diferentes provedores terceirizados, como Elastic, Splunk, Datadog ou Loki. | Sem impacto | Ilimitado | - |
| Geração de registros do sistema/Kubernetes usando outro provedor | É possível usar diferentes provedores terceirizados, como Elastic, Splunk ou Datadog. | Sem impacto | Ilimitado | - |
| Métricas de aplicativo e do Kubernetes gravadas no Cloud Monitoring | As métricas são gravadas no Cloud Monitoring. | As métricas são armazenadas em buffer no disco local. | Buffer local de 24h ou 6GiB por nó para métricas do sistema e buffer local de 1GiB por nó para métricas de aplicativos. Quando o buffer é preenchido ou a desconexão dura 24 horas, as entradas mais antigas são descartadas | Use uma solução de monitoramento local. |
| Como acessar e ler dados de monitoramento do Kubernetes e das cargas de trabalho de aplicativos | Todas as métricas estão disponíveis no console do Google Cloud e pela API Cloud Monitoring. | As métricas não são atualizadas no Cloud Monitoring durante a desconexão. | Buffer local de 24h ou 6GiB por nó para métricas do sistema e buffer local de 1GiB por nó para métricas de aplicativos. Quando o buffer é preenchido ou a desconexão dura 24 horas, as entradas mais antigas são descartadas | Use uma solução de monitoramento local. |
| Regras de alertas e paginação de métricas | O Cloud Monitoring é compatível com alertas. É possível criar alertas para qualquer métrica. Os alertas podem ser enviados por canais diferentes. | Os alertas não são acionados enquanto estão desconectados. Os alertas são acionados somente com base em dados de métricas já enviados ao Cloud Monitoring | Use uma solução local de monitoramento e alerta. |
Gerenciamento de políticas e configurações
O Config Sync e o Policy Controller permitem gerenciar a configuração e as políticas em escala em todos os clusters. Você armazena configurações e políticas em um repositório Git, e elas são sincronizadas automaticamente com os clusters.
Config Sync
O Config Sync usa agentes no cluster para se conectar
diretamente a um repositório Git. Gerencie as alterações no URL do repositório ou nos parâmetros de sincronização com as ferramentas gcloud ou kubectl.
Durante a desconexão temporária, a sincronização não será afetada se os agentes no cluster ainda puderem acessar o repositório Git. No entanto, se você alterar os parâmetros de sincronização com a Google Cloud CLI ou o console do Google Cloud, eles não serão aplicados ao cluster durante a desconexão. É possível substituí-las temporariamente localmente usando kubectl. Todas as alterações locais são substituídas na reconexão.
Policy Controller
O Policy Controller permite a aplicação de políticas totalmente programáveis nos clusters. Essas políticas atuam como "trilhos" e impedem qualquer alteração que viole os controles de segurança, operacionais ou de conformidade definidos.
| Ação | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Como sincronizar a configuração de um repositório Git | Os agentes no cluster se conectam diretamente ao repositório Git. É possível alterar o URL do repositório ou os parâmetros de sincronização com uma API Google Cloud. | A sincronização de configurações não é afetada. Se você alterar os parâmetros de sincronização com a gcloud ou no console do Google Cloud, eles não serão aplicados ao cluster durante a desconexão. É possível substituí-las temporariamente localmente usando kubectl. Todas as alterações locais são substituídas na reconexão. |
Ilimitado | Nunca use a API Fleet com o Config Sync e só faça isso manualmente. |
| Como aplicar políticas em solicitações à API Kubernetes | O agente no cluster impõe restrições graças à integração com a API Kubernetes. Você gerencia políticas usando a API local do Kubernetes. Você gerencia a configuração do sistema do Policy Controller com uma API do Google Cloud. | A aplicação da política não é afetada. As políticas ainda são gerenciadas usando a API local do Kubernetes. As alterações na configuração do sistema do Policy Controller usando a API Google Cloud não são propagadas para o cluster, mas é possível substituí-las temporariamente no local. Todas as alterações locais são substituídas na reconexão. | Ilimitado | Nunca use a API Fleet para o Policy Controller e só configure essa conta manualmente. |
| Como instalar, configurar ou fazer upgrade do Config Sync usando a API Google Cloud | Use a API do Google Cloud para gerenciar a instalação e o upgrade dos agentes no cluster. Também é possível usar essa API (ou a gcloud ou o console do Google Cloud) para gerenciar a configuração desses agentes. | Os agentes no cluster continuam funcionando normalmente. Não é possível instalar, fazer upgrade ou configurar agentes no cluster usando a API Google Cloud. Após a reconexão, todas as instalações, upgrades ou configurações pendentes feitas usando a API continuam. | Zero | Nunca use a API Fleet para o Policy Controller e só configure essa conta manualmente. |
| Visualização do status do sistema ou da sincronização no console do Google Cloud | É possível ver a integridade dos agentes no cluster e o status de sincronização usando uma API Google Cloud ou o console do Google Cloud. | As informações de status na API Google Cloud ou no console do Google Cloud ficam desatualizadas. A API mostra um erro de conexão. Todas as informações permanecem disponíveis por cluster usando a 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 se conectar diretamente ao Cloud Identity para papéis de aplicativos e usuários, para gerenciar cargas de trabalho usando o Connect ou para autenticação de endpoints usando o OIDC. No caso de desconexão do Google Cloud, a conexão com o Cloud Identity também é severa e esses recursos não estão mais disponíveis. Para cargas de trabalho que exigem mais resiliência com uma desconexão temporária, é possível usar o GKE Identity Service para se integrar a um provedor LDAP ou OIDC (incluindo o ADFS) para configurar a autenticação do usuário final.
| Recurso | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Cloud Identity como provedor de identidade, usando o gateway do Connect | É possível acessar os recursos do GKE Enterprise usando o Cloud Identity como o provedor de identidade e se conectando por meio do gateway do Connect. | O gateway do Connect requer uma conexão com o Google Cloud. Não é possível se conectar aos clusters durante a desconexão. | Zero | Use o serviço de identidade do GKE para federar com outro provedor de identidade. |
| Identidade e autenticação usando um provedor de identidade de terceiros | Compatível com OIDC e LDAP. Use a CLI gcloud para fazer o primeiro login. Para provedores OIDC, é possível usar o console do Google Cloud para fazer login. Em seguida, é possível autenticá-lo normalmente na API do cluster (por exemplo, usando kubectl). |
Contanto que o provedor de identidade permaneça acessível para você e para o cluster, ainda será possível autenticar na API do cluster. Não é possível fazer login pelo console do Google Cloud. Só é possível atualizar localmente a configuração do OIDC ou LDAP dos clusters. Não é possível usar o console do Google Cloud. | Ilimitado | - |
| Autorização | O GKE Enterprise oferece suporte ao controle de acesso baseado em papéis (RBAC, na sigla em inglês). Os papéis podem ser atribuídos a usuários, grupos ou contas de serviço. As identidades e os grupos de usuários podem ser recuperados do provedor de identidade. | O sistema RBAC é local ao cluster do Kubernetes e não é afetado pela desconexão do Google Cloud. No entanto, se depender de identidades do Cloud Identity, elas não estarão disponíveis em caso de desconexão. | Ilimitado | - |
Gerenciamento de secrets e chaves
O gerenciamento de secrets e chaves é uma parte importante da sua postura de segurança. O comportamento do GKE Enterprise em caso de desconexão do Google Cloud depende do serviço que você está usando para esses recursos.
| Recurso | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Gerenciamento de secrets e chaves usando o Cloud Key Management Service e o Secret Manager | Use o Cloud Key Management Service diretamente para as chaves criptográficas e o Secret Manager para os secrets. | O Cloud Key Management Service e o Secret Manager não estão disponíveis. | Zero | Use sistemas locais. |
| Gerenciamento de chaves e secrets usando os serviços Hashicorp Vault e Google Cloud | Você configura o Hashicorp Vault para usar o Cloud Storage ou o Cloud Spanner para armazenar secrets e o Cloud Key Management Service para gerenciar chaves. | Se o Hashicorp Vault for executado no cluster do Anthos e também for afetado pela desconexão, o armazenamento de secret e o gerenciamento de chaves não estarão disponíveis durante a desconexão. | Zero | Use sistemas locais. |
| Gerenciamento de secrets e chaves usando o Hashicorp Vault e serviços locais | Configure o Hashicorp Vault para usar um back-end de armazenamento local para secrets e um sistema de gerenciamento de chaves no local, como um módulo de segurança de hardware. | A desconexão do Google Cloud não tem impacto. | Ilimitado | - |
Rede e serviços de rede
Balanceamento de carga
Para expor os serviços do Kubernetes hospedados em um cluster local aos usuários, é possível usar o balanceador de carga em pacote fornecido (MetalLB em bare metal, Seesaw ou MetalLB no VMware) ou seu balanceador de carga, fora do GKE Enterprise. Ambas as opções continuam funcionando em caso de uma desconexão do Google Cloud.
| Recurso | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Balanceador de carga em pacote L4 | Fornece balanceamento de carga L4 totalmente local, sem dependência de APIs ou rede do Google Cloud. | Sem alterações | Ilimitado | - |
| Balanceador de carga manual ou integrado | Compatível com F5 BIG-IP e outros que também são hospedados no local. | Sem alterações | Ilimitado | - |
Anthos Service Mesh
Use o Anthos Service Mesh para gerenciar, observar e proteger comunicações nos seus serviços em execução em um cluster no local. Nem todos os recursos do Anthos Service Mesh são compatíveis com o Google Distributed Cloud. Consulte a lista de recursos compatíveis para mais informações.
| Recurso | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Implantar ou atualizar políticas (roteamento, autorização, segurança, auditoria etc.) | Use o console do Google Cloud, kubectl, asmcli ou istioctl, para gerenciar as políticas do Anthos Service Mesh. |
Só é possível usar kubectl ou istioctl para gerenciar as políticas do Anthos Service Mesh. |
Ilimitado | Use kubectl ou istioctl |
| Autoridade de certificação (CA) | É possível usar a CA no cluster ou a CA da malha para gerenciar os certificados usados pelo Anthos Service Mesh. | Não há impacto se você estiver usando a CA no cluster. Se você estiver usando a CA da malha, os certificados expirarão após 24 horas. Novas instâncias de serviço não podem recuperar certificados. |
Ilimitado para CA no cluster. Serviço degradado durante 24h e nenhum serviço após 24h para CA da malha. |
Use a CA no cluster. |
| Cloud Monitoring para Anthos Service Mesh | Use o Cloud Monitoring para armazenar, explorar e explorar métricas relacionadas a HTTP provenientes do Anthos Service Mesh. | As métricas não são armazenadas. | Zero | Use uma solução de monitoramento local compatível, como o Prometheus. |
| Geração de registros de auditoria do Anthos Service Mesh | O Anthos Service Mesh depende das instalações locais de geração de registros do Kubernetes. O comportamento depende de como você configurou a geração de registros para o cluster do GKE Enterprise. | Depende de como você configurou a geração de registros para o cluster do GKE Enterprise. | - | - |
| Gateway de entrada | É possível definir IPs externos com o gateway de entrada do Istio. | Sem impacto | Ilimitado | - |
| Interface de rede de contêineres do Istio (CNI, na sigla em inglês) | É possível configurar o Anthos Service Mesh para usar a CNI do Istio em vez do iptables para gerenciar o tráfego. | Sem impacto | Ilimitado | - |
| Autenticação de usuário final do Anthos Service Mesh para aplicativos da Web | Use o gateway de entrada do Anthos Service Mesh para fazer a integração com seu próprio provedor de identidade (por meio do OIDC) para autenticar e autorizar usuários finais em aplicativos da Web que fazem parte da malha. | Sem impacto | Ilimitado | - |
Outros serviços de rede
| Recurso | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| DNS | O servidor DNS do Kubernetes é executado no cluster. | O serviço DNS do Kubernetes funciona normalmente enquanto é executado dentro do próprio cluster. | Ilimitado | - |
| Proxy de saída | É possível configurar o GKE Enterprise para usar um proxy em conexões de saída. | Se o proxy for executado no local, o GKE Enterprise ainda poderá usá-lo durante uma desconexão temporária. No entanto, se o proxy perder a conexão com o Google Cloud, todos os cenários deste documento ainda serão válidos. | Ilimitado | - |
Google Cloud Marketplace
| Recurso | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Como implantar e gerenciar aplicativos e serviços no Cloud Marketplace | O Cloud Marketplace está disponível no console do Google Cloud e pode ser usado para descobrir, adquirir e implantar soluções. | Não é possível usar o Cloud Marketplace. Algumas soluções do Cloud Marketplace podem ter requisitos de conectividade próprios que não estão documentados aqui. | Zero | Nenhum |
Suporte
Nesta seção, abordamos os possíveis cenários que podem acontecer ao interagir com o suporte do Google Cloud ou com seu parceiro operacional em um caso relacionado aos clusters do GKE no Google Distributed Cloud.
| Recurso | Comportamento conectado | Comportamento de desconexão temporário | Tolerância de desconexão máxima | Solução alternativa de perda de conectividade |
|---|---|---|---|---|
| Como compartilhar um snapshot do cluster com a equipe de suporte | Crie um snapshot do cluster localmente usando os comandos bmctl check cluster
ou gkectl diagnose snapshot. Você compartilha esse snapshot pelo
processo normal de suporte. |
Ainda é possível gerar o snapshot como uma operação local. Se você perdeu o acesso ao Google Cloud e às interfaces de suporte da Web, pode ligar para a equipe de suporte, desde que tenha assinado os planos de suporte Enhanced ou Premium. | Ilimitado | - |
| Compartilhar dados de registro relevantes com a equipe de suporte | É possível coletar registros localmente no seu cluster e compartilhá-los por meio do processo normal de suporte. | Ainda é possível coletar registros do cluster. Se você perdeu o acesso ao Google Cloud e às interfaces de suporte da Web, pode ligar para a equipe de suporte, desde que tenha assinado os planos de suporte Enhanced ou Premium. | Ilimitado | - |