Esta seção descreve os controles usados na plataforma do desenvolvedor.
Identidade, papéis e grupos da plataforma
O acesso aos serviços do Google Cloud requer as identidades do Google Cloud. O blueprint usa a Identidade da carga de trabalho da frota para mapear as contas de serviço do Kubernetes usadas como identidades para pods em contas de serviço do Google Cloud que controlam o acesso aos serviços do Google Cloud. Para ajudar na proteção contra encaminhamentos entre ambientes, cada ambiente tem um pool de identidades separado (conhecido como um conjunto de provedores de identidade confiáveis) para as contas de Identidade da carga de trabalho.
Perfis de plataforma
Ao implantar o blueprint, três tipos de grupos de usuários são criados: uma equipe da plataforma de desenvolvimento, uma equipe de aplicativos (uma equipe por aplicativo) e uma equipe de operações de segurança.
A equipe da plataforma do desenvolvedor é responsável pelo desenvolvimento e gerenciamento da plataforma do desenvolvedor. Os membros desta equipe são os seguintes:
- Desenvolvedores de plataformas de desenvolvedor: esses membros da equipe estendem o projeto e o integram aos sistemas existentes. Esta equipe também cria novos modelos de aplicativos.
- Administrador da plataforma do desenvolvedor: essa equipe é responsável pelo
seguinte:
- Aprovação da criação de equipes de novos locatários.
- Executar tarefas programadas e não programadas que afetam vários locatários, incluindo:
- Aprovar a promoção de aplicativos para os ambientes de produção e não produção.
- Coordenar atualizações de infraestrutura.
- Planejar capacidade no nível da plataforma.
Um locatário da plataforma do desenvolvedor é uma única equipe de desenvolvimento de software responsável pela operação desse software. A equipe de locatário é composta por dois grupos: desenvolvedores de aplicativos e operadores de aplicativos. Os deveres dos dois grupos da equipe de locatários são os seguintes:
- Desenvolvedores de aplicativos: esta equipe escreve e depura o código do aplicativo. Às vezes,
eles também são chamados de engenheiros de software ou desenvolvedores de pilha completa. As
responsabilidades deles incluem o seguinte:
- Realizar testes e controle de qualidade em um componente de aplicativo quando ele é implantado no ambiente de desenvolvimento.
- Gerenciar recursos da nuvem de propriedade do aplicativo, como bancos de dados e buckets de armazenamento, no ambiente de desenvolvimento.
- Projetar esquemas de banco de dados ou armazenamento para uso em aplicativos.
- Operadores de aplicativos ou engenheiros de confiabilidade do site (SREs): esta equipe gerencia a confiabilidade dos aplicativos em execução nos ambientes de produção e o avanço seguro das alterações feitas pelos aplicativos. de desenvolvedores para a produção. Às vezes, eles são chamados de operadores de serviço, engenheiros de sistemas ou administradores de sistema. As
responsabilidades deles incluem o seguinte:
- Planejamento das necessidades de capacidade no nível do aplicativo.
- Criar políticas de alertas e definir objetivos de nível de serviço (SLOs) para serviços.
- Diagnosticar problemas de serviço usando registros e métricas específicos para esse aplicativo.
- Responder a alertas e páginas, como quando um serviço não atende aos SLOs.
- Trabalhar com um ou vários grupos de desenvolvedores de aplicativos.
- Aprovar a implantação de novas versões para produção.
- Gerenciar recursos de nuvem de propriedade do aplicativo nos ambientes de não produção e produção, por exemplo, backups e atualizações de esquema.
Estrutura organizacional da plataforma
O blueprint do aplicativo empresarial usa a estrutura organizacional fornecida pelo blueprint de base corporativa. O diagrama a seguir mostra como os projetos de blueprint do aplicativo empresarial se encaixam na estrutura do blueprint da base.
Projetos de plataforma
A tabela a seguir descreve os outros projetos, além daqueles fornecidos pelo blueprint de base, que o blueprint do aplicativo precisa para implantar recursos, configurações e aplicativos.
| Pasta | Projeto | Descrição |
|---|---|---|
|
|
Contém o pipeline de infraestrutura multilocatário para implantar a infraestrutura de locatário. |
|
Contém a fábrica de aplicativos , que é usada para criar uma arquitetura de aplicativos de locatário único e pipelines de integração e implantação contínuas (CI/CD). Também contém o Config Sync usado para a configuração do cluster do GKE. |
|
|
Contém os pipelines de CI/CD do aplicativo, que estão em projetos independentes para permitir a separação entre as equipes de desenvolvimento. Há um pipeline para cada aplicativo. |
|
|
|
Contém os clusters do GKE da plataforma do desenvolvedor e a lógica usada para registrar clusters no gerenciamento de frotas. |
( |
Contém serviços de aplicativos de locatário único, como bancos de dados ou outros serviços gerenciados, usados por uma equipe de aplicativos. |
Arquitetura do cluster de plataforma
O blueprint implanta aplicativos em três ambientes: desenvolvimento, não produção e produção. Cada ambiente está associado a uma frota. Neste blueprint, uma frota é um projeto que inclui um ou mais clusters. No entanto, as frotas também podem agrupar vários projetos. Uma frota oferece um limite de segurança lógico para controle administrativo. Com uma frota, é possível agrupar e normalizar logicamente clusters do Kubernetes, além de facilitar a administração da infraestrutura.
O diagrama a seguir mostra dois clusters do GKE, que são criados em cada ambiente para implantar aplicativos. Os dois clusters atuam como clusters idênticos do GKE em duas regiões diferentes para fornecer resiliência multirregional. Para aproveitar os recursos da frota, o blueprint usa o conceito de semelhança em objetos, serviços e identidades de namespace.
O blueprint de aplicativos empresariais usa clusters do GKE com espaços particulares ativados por meio do acesso do Private Service Connect ao plano de controle e de pools de nós particulares para remover possíveis superfícies de ataque da Internet. Nem os nós do cluster nem o plano de controle têm um endpoint público. Os nós do cluster executam o Container-Optimized OS para limitar a superfície de ataque, e os nós do cluster usam nós do GKE protegidos para limitar a capacidade de um invasor falsificar a identidade de um nó.
O acesso administrativo aos clusters do GKE é ativado por meio do gateway do Connect. Como parte da implantação de blueprint, uma instância do Cloud NAT é usada para cada ambiente para fornecer aos pods e ao Config Sync um mecanismo para acessar recursos na Internet, como o GitHub. O acesso aos clusters do GKE é controlado pela autorização do RBAC do Kubernetes baseada nos Grupos do Google para GKE. Os grupos permitem controlar identidades usando um sistema de gerenciamento de identidades central controlado por administradores de identidade.
Componentes do GKE Enterprise da plataforma
A plataforma para desenvolvedores usa componentes do GKE Enterprise para permitir que você crie, entregue e gerencie o ciclo de vida dos aplicativos. Os componentes do GKE Enterprise usados na implantação do blueprint são os seguintes:
- GKE para gerenciamento de contêineres
- Policy Controller para gerenciamento e aplicação de políticas
- Anthos Service Mesh para gerenciamento de serviços
- Autorização binária para atestado de imagens de contêiner
- Controlador de gateway do GKE para o controlador de gateway de vários clusters para clusters do GKE
Gerenciamento de frotas de plataformas
As frotas oferecem a capacidade de gerenciar vários clusters do GKE de uma única maneira unificada. O gerenciamento de equipe de frota facilita que os administradores de plataformas provisionem e gerenciem recursos de infraestrutura para locatários da plataforma do desenvolvedor. Os locatários têm controle com escopo de recursos dentro do próprio namespace, incluindo aplicativos, registros e métricas.
Para provisionar subconjuntos de recursos da frota por equipe, os administradores podem usar escopos de equipe. Com os escopos, é possível definir subconjuntos de recursos da frota para cada equipe, com cada escopo associado a um ou mais clusters de membros da frota.
Os namespaces da frota fornecem controle sobre quem tem acesso a namespaces específicos na sua frota. O aplicativo usa dois clusters do GKE implantados em uma frota, com três escopos de equipe, e cada escopo tem um namespace de frota.
O diagrama a seguir mostra os recursos da frota e do escopo que correspondem aos clusters de amostra em um ambiente, conforme implementado pelo blueprint.
Rede de plataforma
Para a rede, os clusters do GKE são implantados em uma VPC compartilhada criada como parte do blueprint de base empresarial. Os clusters do GKE exigem que vários intervalos de endereços IP sejam atribuídos nos ambientes de desenvolvimento, de não produção e de produção. Cada cluster do GKE usado pelo blueprint precisa de intervalos de endereços IP separados, alocados para os nós, pods, serviços e plano de controle. As instâncias do AlloyDB para PostgreSQL também exigem intervalos de endereços IP separados.
A tabela a seguir descreve as sub-redes VPC e os intervalos de endereços IP usados nos diferentes ambientes para implantar os clusters de blueprint. Para o ambiente de desenvolvimento na região 2 do cluster do GKE do aplicativo, o blueprint implanta apenas um espaço de endereço IP, mesmo que haja um espaço de endereço IP alocado para dois clusters de desenvolvimento do GKE.
| Recurso | Tipo de intervalo de endereços IP | Desenvolvimento | Não produção | Produção |
|---|---|---|---|---|
Região 1 do cluster do GKE do aplicativo |
Intervalo de endereços IP primário |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
Intervalo de endereços IP do pod |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Intervalo de endereços IP do serviço |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
Intervalo de endereços IP do plano de controle do GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
Região 2 do cluster do GKE do aplicativo |
Intervalo de endereços IP primário |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
Intervalo de endereços IP do pod |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Intervalo de endereços IP do serviço |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
Intervalo de endereços IP do plano de controle do GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
AlloyDB para PostgreSQL |
Intervalo de endereços IP do banco de dados |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
Se for necessário projetar seu próprio esquema de alocação de endereços IP, consulte Gerenciamento de endereços IP no GKE e Planejamento de endereços IPv4 no GKE.
DNS da plataforma
O blueprint usa o Cloud DNS para GKE para fornecer resolução de DNS a pods e serviços do Kubernetes. O Cloud DNS para GKE é um DNS gerenciado que não requer um provedor de DNS hospedado em cluster.
No blueprint, o Cloud DNS está configurado para o escopo da VPC. O escopo da VPC permite que os serviços em todos os clusters do GKE em um projeto compartilhem uma única zona de DNS. Uma única zona de DNS permite que os serviços sejam resolvidos em clusters, e as VMs ou pods fora do cluster podem resolver serviços no cluster.
Firewalls de plataforma
O GKE cria automaticamente regras de firewall ao criar Clusters do GKE, Serviços do GKE, Firewalls do gateway do GKE e Firewalls de entrada do GKE que permitem que os clusters operem nos seus ambientes. A prioridade de todas as regras de firewall criadas automaticamente é 1.000. Essas regras são necessárias porque o blueprint da base empresarial tem uma regra padrão para bloquear o tráfego na VPC compartilhada.
Acesso da plataforma aos serviços do Google Cloud
Como os aplicativos de blueprints usam clusters particulares, o Acesso privado do Google fornece acesso aos serviços do Google Cloud.
Alta disponibilidade da plataforma
O projeto foi criado para ser resiliente a falhas temporárias de zona e região. Os recursos necessários para manter os aplicativos em execução estão distribuídos por duas regiões. Selecione as regiões em que você quer implantar o blueprint. Os recursos que não estão no caminho crítico para exibição e resposta à carga são apenas uma região ou são globais. A tabela a seguir descreve os recursos e onde eles são implantados.
Local |
Região 1 |
Região 2 |
Global |
|---|---|---|---|
Ambientes com recursos neste local |
|
|
|
Projetos com recursos neste local |
|
|
|
Tipos de recursos neste local |
|
|
|
A tabela a seguir resume como diferentes componentes reagem a uma falha temporária de região ou de zona e como é possível atenuar esses efeitos.
Escopo da falha |
Efeitos de serviços externos |
Efeitos do banco de dados | Efeitos de criação e implantação | Efeitos de pipelines do Terraform |
|---|---|---|---|---|
Uma zona da região 1 |
Disponível. |
Disponível. A instância de espera fica ativa sem RPO. |
Pode ser necessário fazer mudanças manuais. Talvez seja necessário reiniciar qualquer
comando |
Pode ser necessário fazer mudanças manuais. Talvez seja necessário reiniciar qualquer
comando |
Uma zona da região 2 |
Disponível. |
Disponível. |
Disponível. |
Pode ser necessário fazer mudanças manuais. Talvez seja necessário reiniciar qualquer
comando |
Região 1 |
Disponível. |
Mudança manual necessária. Um operador precisa promover o cluster secundário manualmente. |
Indisponível. |
Indisponível. |
Região 2 |
Disponível. |
Disponível. |
Pode ser necessário fazer mudanças manuais. Os builds permanecem disponíveis. Talvez seja necessário implantar novas versões manualmente. As versões existentes podem não ser concluídas com sucesso. |
Disponível. |
As interrupções do provedor de nuvem são apenas uma fonte de inatividade. A alta disponibilidade também depende de processos e operações que ajudam a cometer erros com menor probabilidade. Na tabela a seguir, descrevemos todas as decisões tomadas no blueprint relacionadas à alta disponibilidade e os motivos para essas decisões.
| Decisão sobre o blueprint | Impacto na disponibilidade |
|---|---|
Gestão da mudança |
|
Use GitOps e IaC. |
Oferece suporte à revisão por pares de alterações e suporte à reversão rápida para configurações anteriores. |
Promova mudanças gradualmente nos ambientes. |
Reduz o impacto de erros de configuração e software. |
Tornar os ambientes de não produção e de produção semelhantes. |
Garante que as diferenças não atrasem a descoberta de um erro. Ambos os ambientes são birregionais. |
Altere os recursos replicados uma região por vez em um ambiente. |
Garante que os problemas que não são detectados por promoção gradual afetem apenas metade da infraestrutura de tempo de execução. |
Altere um serviço em uma região por vez em um ambiente. |
Garante que os problemas não detectados por promoção gradual afetem apenas metade das réplicas de serviço. |
Infraestrutura de computação replicada |
|
Use um plano de controle de cluster regional. |
O plano de controle regional está disponível durante o upgrade e o redimensionamento. |
Crie um pool de nós de várias zonas. |
Um pool de nós de cluster tem pelo menos três nós espalhados por três zonas. |
Configure uma rede VPC compartilhada. |
A rede VPC compartilhada abrange duas regiões. Uma falha regional afeta apenas o tráfego de rede de entrada e saída de recursos na região com falha. |
Replique o registro de imagens. |
As imagens são armazenadas no Artifact Registry, configurado para replicar em várias regiões. Assim, uma interrupção na região da nuvem não impede o escalonamento automático do aplicativo na região sobrevivente. |
Serviços replicados |
|
Implante réplicas de serviço em duas regiões. |
No caso de uma interrupção regional, um serviço do Kubernetes permanece disponível nos ambientes de produção e não produção. |
Usar atualizações graduais para alterações de serviço em uma região. |
É possível atualizar os serviços do Kubernetes usando um padrão de implantação de atualização gradual, que reduz o risco e a inatividade. |
Configurar três réplicas em uma região para cada serviço. |
Um serviço do Kubernetes tem pelo menos três réplicas (pods) para dar suporte a atualizações graduais no ambiente de produção e não produção. |
Espalhe os pods da implantação por várias zonas. |
Os serviços do Kubernetes são distribuídos entre VMs em diferentes zonas usando uma estrofe antiafinidade. Uma interrupção de nó único ou uma interrupção completa de zona pode ser tolerada sem gerar mais tráfego entre regiões entre serviços dependentes. |
Armazenamento replicado |
|
Implantar instâncias de banco de dados de várias zonas. |
O AlloyDB para PostgreSQL oferece alta disponibilidade em uma região. Os nós redundantes da instância principal estão localizados em duas zonas diferentes da região. A instância primária mantém a disponibilidade regional acionando um failover automático para a zona de espera quando a zona ativa encontra um problema. O armazenamento regional ajuda a fornecer durabilidade de dados no caso de uma perda de zona única. |
Replicar bancos de dados entre regiões. |
O AlloyDB para PostgreSQL usa a replicação entre regiões para fornecer recursos de recuperação de desastres. O banco de dados replica de maneira assíncrona os dados do cluster principal em clusters secundários localizados em regiões separadas do Google Cloud. |
Operações |
|
Provisionar aplicativos para o dobro da carga esperada. |
Se um cluster falhar (por exemplo, devido a uma interrupção de serviço regional), a parte do serviço executada no cluster restante poderá absorver totalmente a carga. |
Repare os nós automaticamente. |
Os clusters são configurados com o reparo automático de nós. Se as verificações de integridade consecutivas de um nó falharem repetidamente durante um período estendido, o GKE iniciará um processo de reparo desse nó. |
Verifique se os upgrades do pool de nós reconhecem aplicativos. |
As implantações definem um orçamento de interrupção de pod com |
Reinicia automaticamente os serviços que foram bloqueados. |
A implantação que apoia um serviço define uma sondagem de atividade, que identifica e reinicia processos com bloqueio. |
Verifica automaticamente se as réplicas estão prontas. |
A implantação que respalda um serviço define uma sondagem de prontidão, que identifica quando um aplicativo está pronto para ser disponibilizado após o início. Uma sondagem de prontidão elimina a necessidade de verificações manuais ou esperas cronometradas durante atualizações graduais e upgrades do pool de nós. |
A arquitetura de referência foi projetada para aplicativos com requisitos de alta disponibilidade zonais e regionais. Garantir a alta disponibilidade incorre em alguns custos (por exemplo, custos extras de espera ou custos de replicação entre regiões). Na seção Alternativas, descrevemos algumas maneiras de reduzir esses custos.
Cotas da plataforma, limites de desempenho e limites de escalonamento
É possível controlar cotas, desempenho e escalonamento de recursos na plataforma do desenvolvedor. A lista a seguir descreve alguns itens a serem considerados:
- A infraestrutura de base requer vários projetos, e cada locatário extra requer quatro projetos. Talvez seja necessário solicitar uma cota extra de projeto antes da implantação e antes de adicionar mais locatários.
- Há um limite de 100 recursos MultiClusterGateway para cada projeto. Cada serviço do Kubernetes voltado para a Internet na plataforma do desenvolvedor requer um MultiClusterGateway.
- O Cloud Logging tem um limite de 100 buckets em um projeto. O acesso ao registro por locatário no blueprint depende de um bucket para cada locatário.
- Para criar mais de 20 locatários, solicite um aumento na cota do projeto para recursos de escopo e namespace. Para instruções sobre como visualizar cotas, consulte Visualizar e gerenciar cotas. Use um filtro para encontrar os tipos de cota
gkehub.googleapis.com/global-per-project-scopesegkehub.googleapis.com/global-per-project-scope-namespaces.
A seguir
- Leia sobre a arquitetura de serviços (próximo documento desta série).