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.
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 |
---|---|---|
Implantar em várias regiões. |
Permitir a disponibilidade de aplicativos durante interrupções do serviço na região. |
|
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: |
Fornecer isolamento para ambientes que têm controles de acesso diferentes. |
|
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. |
|
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. |
|
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
- Leia sobre os controles da plataforma para desenvolvedores (próximo documento desta série).