Arquitetura

Last reviewed 2024-04-19 UTC

No diagrama a seguir, mostramos a arquitetura de alto nível que é implantada pelo blueprint para um único ambiente. Essa arquitetura é implantada em três ambientes separados: produção, não produção e desenvolvimento.

A arquitetura do blueprint.

O diagrama inclui os seguintes pontos:

  • O Cloud Load Balancing distribui o tráfego de aplicativos entre regiões para objetos do serviço do Kubernetes. Por trás de cada serviço há um agrupamento lógico de pods relacionados.
  • O Anthos Service Mesh permite que os serviços do Kubernetes se comuniquem uns com os outros.
  • Os serviços do Kubernetes são agrupados em locatários, que são representados como namespaces do Kubernetes. Os locatários são uma abstração que representa vários usuários e cargas de trabalho que operam em um cluster, com RBAC separado para controle de acesso. Cada locatário também tem o próprio projeto para recursos de nuvem específicos do locatário, como bancos de dados, buckets de armazenamento e assinaturas do Pub/Sub.
  • Namespaces com as próprias identidades para acessar serviços de peering e recursos da nuvem. A identidade é consistente com o mesmo namespace em clusters diferentes por causa da Identidade da carga de trabalho da frota. Cada ambiente tem um pool de Identidade da carga de trabalho separado para reduzir o escalonamento de privilégios entre ambientes.
  • Cada serviço tem um pipeline dedicado que cria e implanta esse serviço. O mesmo pipeline é usado para implantar o serviço no ambiente de desenvolvimento, implantar o serviço no ambiente de não produção e, por fim, implantá-lo no ambiente de produção.

Principais decisões de arquitetura sobre a plataforma para desenvolvedores

A tabela a seguir descreve as decisões de arquitetura que o blueprint implementa.

Área de decisão Decisão Motivo

Arquétipo de implantação

Implantar em várias regiões.

Permitir a disponibilidade de aplicativos durante interrupções do serviço na região.

Arquitetura organizacional

Implantar com base no blueprint de fundação empresarial.

Usar a estrutura organizacional e os controles de segurança disponibilizados pela fundação.

Usar as três pastas do ambiente configuradas na fundação: development, nonproduction e production.

Fornecer isolamento para ambientes que têm controles de acesso diferentes.

Arquitetura de cluster da plataforma para desenvolvedores

Empacotar e implantar aplicativos como contêineres.

Permitir a separação de responsabilidades, operações eficientes e portabilidade de aplicativos.

Executar aplicativos nos clusters do GKE.

Usar um serviço de contêiner gerenciado criado pela empresa pioneira em contêineres.

Replicar e executar contêineres de aplicativos em uma configuração ativo-ativo.

Ter maior disponibilidade e lançamentos progressivos rápidos, melhorando a velocidade de desenvolvimento.

Provisionar o ambiente de produção com dois clusters do GKE em duas regiões diferentes.

Conseguir maior disponibilidade do que uma única região da nuvem.

Provisionar o ambiente de não produção com dois clusters do GKE em duas regiões diferentes.

Realizar mudanças em configurações inter-regionais, como balanceadores de carga, antes da implantação na produção.

Provisionar o ambiente de desenvolvimento com uma única instância de cluster do GKE.

Ajuda a reduzir custos.

Configurar planos de controle altamente disponíveis para cada cluster do GKE.

Verificar se o plano de controle do cluster está disponível durante o upgrade e o redimensionamento.

Usar o conceito de semelhança em namespaces, serviços e identidades em cada cluster do GKE.

Garantir que objetos do Kubernetes com o mesmo nome em clusters diferentes sejam tratados como a mesma coisa. Essa normalização é feita para facilitar a administração de recursos da frota.

Ative os espaços de endereço IP particulares para clusters do GKE com o acesso do Private Service Connect ao plano de controle e os pools de nós particulares.

Ajudar a proteger a API do cluster do Kubernetes contra ataques de verificação.

Ativar o acesso administrativo aos clusters do GKE pelo gateway do Connect.

Usar um comando para buscar credenciais de acesso a vários clusters. Usar grupos e provedores de identidade de terceiros para gerenciar o acesso ao cluster.

Usar o Cloud NAT para fornecer aos pods do GKE acesso a recursos com endereços IP públicos.

Melhorar a postura de segurança geral do cluster, porque os pods não são expostos diretamente à Internet, mas ainda podem acessar recursos voltados à Internet.

Configurar os nós para que usem o Container-Optimized OS e os nós protegidos do GKE.

Limitar a superfície de ataque dos nós.

Associe cada ambiente a uma frota do GKE.

Permitir o gerenciamento de conjuntos de clusters do GKE como uma unidade.

Usar o pipeline de infraestrutura de fundação para implantar a fábrica de aplicativos, o pipeline com escopo da frota e o pipeline de infraestrutura multilocatário.

Fornecer um mecanismo controlável, auditável e repetível para implantar a infraestrutura de aplicativos.

Configurar clusters do GKE usando os recursos de gerenciamento de configurações e políticas do GKE Enterprise.

Fornecer um serviço que permita configuração como código para clusters do GKE.

Usar uma fábrica de aplicativos para implantar os pipelines de CI/CD de aplicativos usados no blueprint.

Fornecer um padrão repetível para implantar pipelines de aplicativos com mais facilidade.

Usar um pipeline de CI/CD de aplicativo para criar e implantar os componentes de aplicativo do blueprint.

Fornecer um mecanismo controlável, auditável e repetível para implantar aplicativos.

Configurar o pipeline de CI/CD de aplicativo para que use o Cloud Build, o Cloud Deploy e o Artifact Registry.

Usar serviços gerenciados de criação e implantação para otimizar em termos de segurança, escalonamento e simplicidade.

Usar contêineres imutáveis entre ambientes e assiná-los com autorização binária.

Fornecer uma procedência do código clara e verificar se o código foi testado em vários ambientes.

Use o Google Cloud Observability, que inclui o Cloud Logging e o Cloud Monitoring.

Simplificar operações usando um serviço gerenciado integrado do Google Cloud.

Ativar o Container Threat Detection (um serviço do Security Command Center) para monitorar a integridade dos contêineres.

Usar um serviço gerenciado que aumente a segurança monitorando continuamente os contêineres.

Controlar o acesso aos clusters do GKE pelo controle de acesso baseado em função (RBAC) do Kubernetes, baseado nos Grupos do Google para o GKE.

Reforçar a segurança vinculando o controle de acesso às identidades do Google Cloud.

Arquitetura de serviço

Usar uma conta de serviço exclusiva do Kubernetes para cada serviço do Kubernetes. Ela funciona como uma conta de serviço do IAM com o uso da Identidade da carga de trabalho.

Aumentar a segurança minimizando as permissões que cada serviço precisa receber.

Expor serviços pela API GKE Gateway.

Simplificar o gerenciamento de configurações fornecendo uma abordagem declarativa e baseada em recursos para gerenciar regras de entrada e configurações de balanceamento de carga.

Executar serviços de modo distribuído usando o Anthos Service Mesh com o Certificate Authority Service.

Fornecer segurança reforçada aplicando autenticação entre serviços, além de fornecer tolerância automática a falhas com o redirecionamento do tráfego de serviços não íntegros.

Usar a replicação entre regiões para o AlloyDB para PostgreSQL.

Oferecer alta disponibilidade na camada do banco de dados.

Arquitetura de rede

As instâncias de VPC compartilhada são configuradas em cada ambiente, e os clusters do GKE são criados em projetos de serviço.

A VPC compartilhada oferece gerenciamento centralizado de configuração de rede e mantém a separação de ambientes.

Usar o Cloud Load Balancing em uma configuração multirregional e com vários clusters.

Fornecer um único endereço IP anycast para acessar clusters do GKE regionalizados para serviços de alta disponibilidade e baixa latência.

Usar conexões HTTPS para acesso do cliente aos serviços. Redirecionar todas as solicitações HTTP do cliente para HTTPS.

Ajudar a proteger dados sensíveis em trânsito e a evitar ataques do tipo "person-in-the-middle".

Usar o Gerenciador de certificados para gerenciar certificados públicos.

Gerenciar certificados de maneira unificada.

Proteger a interface da Web com o Google Cloud Armor.

Aumentar a segurança protegendo contra ataques volumétricos e vulnerabilidades comuns de web apps.

Suas decisões podem variar em relação ao blueprint. Para conhecer alternativas às recomendações padrão, consulte este link.

A seguir