Impacto da desconexão temporária do Google Cloud

O software somente do Google Distributed Cloud é baseado no Kubernetes, e você pode implantá-lo no local em servidores VMware ou bare metal. Embora o Distributed Cloud seja 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 acontece se, por qualquer motivo, a conexão com Google Cloud for 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 Distributed Cloud (em bare metal ou no VMware) e quais soluções alternativas 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, não planeje usar uma implantação do Distributed Cloud somente de software desconectada do Google Cloud como um modo de trabalho nominal. Lembre-se de que projetamos o Distributed Cloud para aproveitar a escalonabilidade e a disponibilidade dos serviços do Google Cloud . Este documento se baseia no design e na arquitetura dos vários componentes do Google Cloud que funcionam de maneira compatível com o Distributed Cloud durante uma interrupção temporária. Não podemos garantir que este documento esteja completo.

Neste documento, presumimos que você já conhece o GKE. Se esse não for o caso, recomendamos que você leia primeiro a visão geral do GKE.

Validação e medição de licenças

Se você ativou a API Anthos (anthos.googleapis.com) no projeto Google Cloud , o controlador de medição em execução no cluster gera e atualiza o direito de licença periodicamente. A tolerância à desconexão é de 12 horas. Além disso, o sistema exige a conexão para gerenciar a medição e o faturamento.

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 O controlador de medição gera e atualiza o recurso personalizado de direitos de licença periodicamente, desde que anthos.googleapis.com esteja ativado no projeto 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. Ilimitado. 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 informa a capacidade de vCPU do cluster para a API Google Cloud Service Control para fins de faturamento. Um agente no cluster mantém registros de faturamento no cluster durante a desconexão e os recupera quando o cluster se reconecta ao Google Cloud. Ilimitado. No entanto, as informações de medição 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 mostrar 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 do cluster Use as ferramentas da CLI bmctl ou gkectl para criar clusters. Essa operação requer uma conexão com 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 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. Essa operação não requer uma conexão com Google Cloud. É possível excluir clusters. Ilimitado -
Como visualizar o status do cluster Veja informações sobre os clusters no console na lista de clusters do Google Kubernetes Engine. As informações do cluster não são mostradas no console. 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 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 Google Cloud. Portanto, não é possível adicionar um novo nó a um cluster quando desconectado. Zero Nenhum

Ciclo de vida do aplicativo

Uma desconexão temporária do Google Cloud geralmente não afeta o gerenciamento dos aplicativos em execução em um cluster no local. Apenas o Connect Gateway é afetado. Se você usa o Container Registry, o Artifact Registry, o Cloud Build ou o Cloud Deploy para gerenciar suas imagens de contêiner ou pipelines de CI/CD no Google Cloud, eles ficam indisponí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 Você implanta aplicativos 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 do Kubernetes. Ilimitado Se você usa o gateway do Connect, mude para o uso local de kubectl.
Remoção de aplicativo Você remove aplicativos 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 do Kubernetes. Ilimitado Se você usa o gateway do Connect, mude para o uso local de kubectl.
Escalonamento horizontal do aplicativo Você escalonar horizontalmente os aplicativos 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 do Kubernetes. Ilimitado Se você usa o gateway do Connect, mude para o uso local de kubectl.

Geração de registros e monitoramento

A auditabilidade ajuda sua organização a atender aos requisitos regulamentares e às políticas de conformidade. O Distributed Cloud ajuda na capacidade de auditoria ao oferecer registros de aplicativos, Kubernetes e auditoria. Muitos clientes optam pelo Cloud Logging e pelo Cloud Monitoring do Google para evitar o gerenciamento de uma infraestrutura de geração de registros e monitoramento no local. Outros clientes preferem centralizar os registros em um sistema local para agregação. Para oferecer suporte a esses clientes, o Distributed Cloud oferece integração direta com serviços como o Prometheus. 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 O sistema grava registros no Cloud Logging. O sistema armazena os registros 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 O sistema grava registros no Cloud Logging. O sistema armazena os registros 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 O sistema grava registros no Cloud Logging. O sistema armazena os registros em buffer no disco local. Buffer local de 10 GiB por nó do plano de controle. Quando o buffer é preenchido, o sistema descarta as entradas mais antigas. 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 O sistema grava métricas no Cloud Monitoring. O sistema armazena métricas 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, o sistema descarta as entradas mais antigas 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 e por meio da API Cloud Monitoring. O sistema não atualiza as métricas 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, o sistema descarta as entradas mais antigas 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. O sistema pode enviar alertas por canais diferentes. O sistema não aciona alertas enquanto está desconectado. O sistema só aciona alertas 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 o sistema as sincroniza automaticamente com os clusters.

Config Sync

O Config Sync usa agentes no cluster para se conectar diretamente a um repositório Git. Gerencie as mudanças no URL do repositório ou nos parâmetros de sincronização com a Google Cloud CLI ou as ferramentas 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 CLI gcloud ou o console, o cluster não os aplicará durante a desconexão. É possível substituí-las temporariamente localmente usando kubectl. A reconexão substitui todas as mudanças locais.

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 mudar 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 CLI gcloud ou no console, o cluster não os aplicará durante a desconexão. É possível substituí-las temporariamente localmente usando kubectl. A reconexão substitui todas as mudanças locais. Ilimitado Nunca use a API Fleet com o Config Sync e só configure essa conta usando a API Kubernetes.
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 Google Cloud. A aplicação da política não é afetada. Você ainda gerencia políticas usando a API local do Kubernetes. O sistema não propaga as mudanças na configuração do sistema do Policy Controller usando a API Google Cloud para o cluster, mas é possível substituí-las temporariamente no local. A reconexão substitui todas as mudanças locais. Ilimitado Nunca use a API Fleet para o Policy Controller e só configure essa conta usando a API Kubernetes.
Instalar, configurar ou fazer upgrade do Config Sync usando a API Google Cloud Use a API Google Cloud para gerenciar a instalação e o upgrade dos agentes no cluster. Também é possível usar essa API (ou a CLI gcloud ou o console) 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 com o Policy Controller e só configure essa conta usando a API Kubernetes.
Como ver o status do sistema ou de sincronização no console É possível ver a integridade dos agentes no cluster e o status de sincronização usando uma Google Cloud API ou o console. As informações de status na API ou no console ficam desatualizadas. Google Cloud 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

Esta seção descreve como os recursos de segurança, incluindo identidade, autenticação, autorização e gerenciamento de secrets, são afetados por uma desconexão temporária do Google Cloud.

Identidade, autenticação e autorização

O Distributed Cloud pode se conectar diretamente ao Cloud Identity para papéis de aplicativos e usuários, gerenciar cargas de trabalho usando o Connect ou para autenticação de endpoints usando o OIDC. Uma desconexão do Google Cloud interrompe a conexão com o Cloud Identity, tornando esses recursos indisponí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 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 Distributed Cloud usando o Cloud Identity como provedor de identidade e se conectando pelo gateway do Connect. O gateway do Connect requer uma conexão com 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 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. Só é possível atualizar a configuração do OIDC ou LDAP dos clusters localmente. Não é possível usar o console. Ilimitado -
Autorização O Distributed Cloud é compatível com o controle de acesso baseado em papéis (RBAC). Os papéis podem ser atribuídos a usuários, grupos ou contas de serviço. O sistema recupera identidades e grupos de usuários do provedor de identidade. O sistema RBAC é local ao cluster do Kubernetes, e a desconexão do Google Cloud não o afeta. 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 Distributed Cloud 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 secrets e chaves usando o Hashicorp Vault e os serviços do 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 local e a desconexão também o afetar, o armazenamento de secrets 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

Esta seção aborda os serviços de rede e de rede para clusters locais, incluindo como eles são afetados por uma desconexão temporária doGoogle Cloud. Ele fornece informações sobre balanceamento de carga, Cloud Service Mesh e outros serviços de rede.

Balanceamento de carga

Para expor os serviços do Kubernetes hospedados em um cluster local aos usuários, você tem as seguintes opções:

Essas opções de balanceamento de carga permanecem operacionais mesmo se forem desconectadas 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 doGoogle 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 -

Cloud Service Mesh

Use o Cloud Service Mesh para gerenciar, observar e proteger comunicações nos seus serviços em execução em um cluster no local. O Distributed Cloud não é compatível com todos os recursos do Cloud Service Mesh. 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, kubectl, asmcli ou istioctl para gerenciar as políticas do Cloud Service Mesh. Só é possível usar kubectl ou istioctl para gerenciar as políticas do Cloud Service Mesh. Ilimitado Use kubectl ou istioctl
Autoridade de certificação (CA) É possível usar a AC no cluster ou a autoridade certificadora do Cloud Service Mesh para gerenciar os certificados usados pelo Cloud Service Mesh. Não há impacto se você estiver usando a AC no cluster.
Se você estiver usando a autoridade de certificação do Cloud Service Mesh, os certificados vão expirar após 24 horas. Novas instâncias de serviço não podem recuperar certificados.		 Ilimitado para a AC no cluster.
Serviço degradado durante 24 horas e nenhum serviço após 24 horas para a autoridade certificadora do Cloud Service Mesh.		 Use a CA no cluster.
Cloud Monitoring para Cloud Service Mesh Use o Cloud Monitoring para armazenar, explorar e explorar métricas relacionadas a HTTP provenientes do Cloud 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 Cloud Service Mesh O Cloud 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 local. Depende de como você configurou a geração de registros para o cluster local. - -
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 Cloud 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 Cloud Service Mesh para aplicativos da Web Use o gateway de entrada do Cloud 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 os clusters locais para usar um proxy em conexões de saída. Se o proxy for executado no local, o cluster ainda poderá usá-lo durante uma desconexão temporária. No entanto, se o proxy perder a conexão com 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, e você pode usá-lo 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 cenários que podem ser abordados ao interagir com o Google Cloud suporte ou com seu parceiro operacional para um caso relacionado ao GKE nos clusters GDC.

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 -