Esta secção descreve os controlos usados na plataforma de programadores.
Identidade, funções e grupos da plataforma
O acesso aos Google Cloud serviços requer Google Cloud identidades. O projeto usa a federação de identidades da carga de trabalho da frota para o GKE para mapear as contas de serviço do Kubernetes que são usadas como identidades para pods para Google Cloud contas de serviço que controlam o acesso aos Google Cloud serviços. Para ajudar a proteger contra escalamentos entre ambientes, cada ambiente tem um Workload Identity Pool separado (conhecido como um conjunto de fornecedores de identidades fidedignos) para a respetiva Workload Identity Federation para contas do GKE.
Personagens fictícias da plataforma
Quando implementa o esquema, cria três tipos de grupos de utilizadores: uma equipa da plataforma de programadores, uma equipa de aplicações (uma equipa por aplicação) e uma equipa de operações de segurança.
A equipa da plataforma de programadores é responsável pelo desenvolvimento e pela gestão da plataforma de programadores. Os membros desta equipa são os seguintes:
- Programadores de plataformas de programadores: estes membros da equipa expandem o plano e integram-no nos sistemas existentes. Esta equipa também cria novos modelos de aplicações.
- Administrador da plataforma de programadores: esta equipa é responsável pelo seguinte:
- Aprovar a criação de novas equipas de inquilinos.
- Executar tarefas agendadas e não agendadas que afetam vários inquilinos, incluindo o seguinte:
- Aprovar a promoção de aplicações para o ambiente de não produção e o ambiente de produção.
- Coordenar atualizações de infraestrutura.
- Criar planos de capacidade ao nível da plataforma.
Um inquilino da plataforma de programadores é uma única equipa de programação de software e os responsáveis pelo funcionamento desse software. A equipa do inquilino é composta por dois grupos: programadores de aplicações e operadores de aplicações. As funções dos dois grupos da equipa do inquilino são as seguintes:
- Programadores de aplicações: esta equipa escreve e depura o código da aplicação. Por vezes, também são denominados engenheiros de software ou programadores full-stack. As respetivas responsabilidades incluem o seguinte:
- Realizar testes e garantia de qualidade num componente de aplicação quando este é implementado no ambiente de desenvolvimento.
- Gerir recursos na nuvem pertencentes à aplicação (como bases de dados e contentores de armazenamento) no ambiente de desenvolvimento.
- Conceber esquemas de bases de dados ou de armazenamento para utilização por aplicações.
- Operadores de aplicações ou engenheiros de fiabilidade do site (SREs): esta equipa
gere a fiabilidade das aplicações que estão a ser executadas nos
ambientes de produção e o avanço seguro das alterações feitas pelos
programadores de aplicações para produção. Por vezes, são denominados operadores de serviços, engenheiros de sistemas ou administradores de sistemas. As responsabilidades incluem
o seguinte:
- Planeamento das necessidades de capacidade ao nível da aplicação.
- Criar políticas de alerta e definir objetivos ao nível do serviço (SLOs) para serviços.
- Diagnosticar problemas de serviço através de registos e métricas específicos dessa aplicação.
- Responder a alertas e páginas, como quando um serviço não cumpre os respetivos SLOs.
- Trabalhar com um grupo ou vários grupos de programadores de aplicações.
- Aprovar a implementação de novas versões em produção.
- Gerir recursos da nuvem pertencentes à aplicação nos ambientes de não produção e de produção (por exemplo, cópias de segurança e atualizações de esquemas).
Estrutura organizacional da plataforma
O esquema da aplicação empresarial usa a estrutura da organização fornecida pelo esquema da base empresarial. O diagrama seguinte mostra como os projetos de plano detalhado de aplicações empresariais se enquadram na estrutura do plano detalhado de base.
Projetos de plataformas
A tabela seguinte descreve os projetos adicionais, além dos fornecidos pelo projeto base, de que o projeto de aplicação precisa para implementar recursos, configurações e aplicações.
| Pasta | Projeto | Descrição |
|---|---|---|
|
|
Contém o pipeline de infraestrutura multilocatário para implementar a infraestrutura do inquilino. |
|
Contém a fábrica de aplicações , que é usada para criar uma arquitetura de aplicações de inquilino único e pipelines de integração contínua e implementação contínua (CI/CD). Este projeto também contém o Config Sync que é usado para a configuração do cluster do GKE. |
|
|
Contém as pipelines de CI/CD da aplicação, que estão em projetos independentes para permitir a separação entre as equipas de desenvolvimento. Existe um pipeline para cada aplicação. |
|
|
|
Contém os clusters do GKE para a plataforma do programador e a lógica usada para registar clusters para a gestão de frotas. |
( |
Contém quaisquer serviços de aplicações de inquilino único, como bases de dados ou outros serviços geridos que são usados por uma equipa de aplicações. |
Arquitetura de cluster da plataforma
O projeto implementa aplicações em três ambientes: desenvolvimento, não produção e produção. Cada ambiente está associado a uma frota. Neste plano, 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 o controlo administrativo. Uma frota oferece uma forma de agrupar e normalizar logicamente os clusters do Kubernetes, e facilita a administração da infraestrutura.
O diagrama seguinte mostra dois clusters do GKE, que são criados em cada ambiente para implementar aplicações. Os dois clusters atuam como clusters GKE idênticos em duas regiões diferentes para oferecer resiliência multirregional. Para tirar partido das capacidades da frota, o esquema usa o conceito de igualdade em objetos, serviços e identidade do espaço de nomes.
O projeto de arquitetura de aplicações empresariais usa clusters do GKE com espaços privados ativados através do acesso do Private Service Connect ao plano de controlo e pools de nós privados para remover potenciais superfícies de ataque da Internet. Nem os nós nem o painel de controlo do cluster têm um ponto final público. Os nós do cluster executam o SO otimizado para contentores para limitar a respetiva superfície de ataque, e os nós do cluster usam nós do GKE protegidos para limitar a capacidade de um atacante se fazer passar por um nó.
O acesso administrativo aos clusters do GKE está ativado através do gateway Connect. Como parte da implementação do projeto, é usada uma instância do Cloud NAT para cada ambiente para dar aos pods e ao Config Sync um mecanismo de acesso a recursos na Internet, como o GitHub. O acesso aos clusters do GKE é controlado pela autorização RBAC do Kubernetes, que se baseia nos Grupos Google para o GKE. Os grupos permitem-lhe controlar identidades através de um sistema de gestão de identidades central que é controlado por administradores de identidades.
Componentes do GKE Enterprise da plataforma
A plataforma do programador usa componentes do GKE Enterprise para lhe permitir criar, fornecer e gerir o ciclo de vida das suas aplicações. Os componentes do GKE Enterprise usados na implementação do projeto são os seguintes:
- GKE para gestão de contentores
- Policy Controller para gestão e aplicação de políticas
- Cloud Service Mesh para a gestão de serviços
- Autorização binária para atestação de imagem de contentor
- GKE Gateway Controller para o controlador de gateway de vários clusters para clusters do GKE
Gestão de frotas de plataformas
As frotas permitem-lhe gerir vários clusters do GKE de uma forma unificada. A gestão da equipa de frotas facilita o aprovisionamento e a gestão de recursos de infraestrutura para inquilinos da plataforma de programadores por parte dos administradores da plataforma. Os inquilinos têm controlo limitado dos recursos no respetivo espaço de nomes, incluindo as respetivas aplicações, registos e métricas.
Para aprovisionar subconjuntos de recursos da frota por equipa, os administradores podem usar âmbitos de equipa. Os âmbitos de equipa permitem-lhe definir subconjuntos de recursos da frota para cada equipa, com cada âmbito de equipa associado a um ou mais clusters de membros da frota.
Os espaços de nomes da frota oferecem controlo sobre quem tem acesso a espaços de nomes específicos na sua frota. A aplicação usa dois clusters do GKE implementados numa frota, com três âmbitos de equipa, e cada âmbito tem um espaço de nomes da frota.
O diagrama seguinte mostra os recursos de frota e âmbito que correspondem aos clusters de exemplo num ambiente, conforme implementado pelo projeto.
Redes de plataformas
Para as redes, os clusters do GKE são implementados numa VPC partilhada criada como parte do esquema base empresarial. Os clusters do GKE requerem a atribuição de vários intervalos de endereços IP nos ambientes de desenvolvimento, não produção e produção. Cada cluster do GKE usado pelo projeto precisa de intervalos de endereços IP separados alocados para os nós, os pods, os serviços e o painel de controlo. As instâncias do AlloyDB para PostgreSQL também requerem intervalos de endereços IP separados.
A tabela seguinte descreve as sub-redes da VPC e os intervalos de endereços IP que são usados nos diferentes ambientes para implementar os clusters de esquemas. Para o ambiente de desenvolvimento na região 2 do cluster do GKE da aplicação, o projeto implementa apenas um espaço de endereços IP, apesar de haver espaço de endereços IP atribuído a dois clusters do GKE de desenvolvimento.
| Recurso | Tipo de intervalo de endereços IP | Programação | Não produção | Produção |
|---|---|---|---|---|
Região do cluster do GKE da aplicação 1 |
Intervalo de endereços IP principal |
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 de 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 controlo do GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
Região 2 do cluster do GKE da aplicação |
Intervalo de endereços IP principal |
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 de 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 controlo 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 da base de dados |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
Se precisar de criar o seu próprio esquema de atribuição de endereços IP, consulte o artigo Gestão de endereços IP no GKE e o artigo Planeamento de endereços IPv4 do GKE.
DNS da plataforma
O projeto usa o Cloud DNS para GKE para fornecer resolução de DNS para pods e serviços Kubernetes. O Cloud DNS para o GKE é um DNS gerido que não requer um fornecedor de DNS alojado no cluster.
No projeto, o Cloud DNS está configurado para o âmbito da VPC. O âmbito da VPC permite que os serviços em todos os clusters do GKE num projeto partilhem uma única zona de DNS. Uma única zona DNS permite que os serviços sejam resolvidos em clusters e que as VMs ou os pods fora do cluster possam resolver serviços dentro do cluster.
Firewalls de plataformas
O GKE cria automaticamente regras da firewall quando cria clusters do GKE, serviços do GKE, firewalls do GKE Gateway e firewalls de entrada do GKE que permitem que os clusters funcionem nos seus ambientes. A prioridade de todas as regras de firewall criadas automaticamente é 1000. Estas regras são necessárias porque o esquema base empresarial tem uma regra predefinida para bloquear o tráfego na VPC partilhada.
Acesso à plataforma para serviços Google Cloud
Uma vez que as aplicações de plantas usam clusters privados, o acesso privado à Google fornece acesso aos serviços Google Cloud .
Alta disponibilidade da plataforma
O projeto foi concebido para ser resiliente a interrupções de zonas e regiões. Os recursos necessários para manter as aplicações em execução estão distribuídos por duas regiões. Selecione as regiões nas quais quer implementar o esquema. Os recursos que não estão no caminho crítico para a publicação e a resposta ao carregamento estão apenas numa região ou são globais. A tabela seguinte descreve os recursos e onde são implementados.
Localização |
Região 1 |
Região 2 |
Global |
|---|---|---|---|
Ambientes com recursos nesta localização |
|
|
|
Projetos com recursos nesta localização |
|
|
|
Tipos de recursos nesta localização |
|
|
|
A tabela seguinte resume a forma como os diferentes componentes reagem a uma indisponibilidade da região ou a uma indisponibilidade da zona, e como pode mitigar estes efeitos.
Âmbito da falha |
Efeitos de serviços externos |
Efeitos de base de dados | Crie e implemente efeitos | Efeitos dos pipelines do Terraform |
|---|---|---|---|---|
Uma zona da região 1 |
Disponível. |
Disponível. A instância em espera fica ativa com um RPO de zero. |
Disponível, mas pode ser necessária uma alteração manual. Pode ter de reiniciar qualquer comando |
Disponível, mas pode ser necessária uma alteração manual. Pode ter de reiniciar qualquer comando |
Uma zona da região 2 |
Disponível. |
Disponível. |
Disponível. |
Disponível, mas pode ser necessária uma alteração manual. Pode ter de reiniciar qualquer comando |
Região 1 |
Disponível. |
É necessária uma alteração manual. Um operador tem de promover o cluster secundário manualmente. |
Indisponível. |
Indisponível. |
Região 2 |
Disponível. |
Disponível. |
Disponível, pode ser necessária uma alteração manual As compilações permanecem disponíveis. Pode ter de implementar novas compilações manualmente. As compilações existentes podem não ser concluídas com êxito. |
Disponível. |
As indisponibilidades dos fornecedores de nuvem são apenas uma origem de tempo de inatividade. A elevada disponibilidade também depende de processos e operações que ajudam a reduzir a probabilidade de erros. A tabela seguinte descreve todas as decisões tomadas no plano detalhado relacionadas com a alta disponibilidade e os motivos dessas decisões.
| Decisão do modelo | Impacto na disponibilidade |
|---|---|
Gestão da mudança |
|
Use GitOps e IaC. |
Suporta a revisão por pares das alterações e permite reverter rapidamente para as configurações anteriores. |
Promova alterações gradualmente através de ambientes. |
Reduz o impacto dos erros de software e de configuração. |
Torne os ambientes de não produção e de produção semelhantes. |
Garante que as diferenças não atrasam a deteção de um erro. Ambos os ambientes são de duas regiões. |
Altere os recursos replicados uma região de cada vez num ambiente. |
Garante que os problemas que não são detetados pela promoção gradual afetam apenas metade da infraestrutura de tempo de execução. |
Altere um serviço numa região de cada vez num ambiente. |
Garante que os problemas que não são detetados pela promoção gradual afetam apenas metade das réplicas do serviço. |
Infraestrutura de computação replicada |
|
Use um plano de controlo de cluster regional. |
O plano de controlo regional está disponível durante a atualização e a alteração do tamanho. |
Crie um node pool de várias zonas. |
Um conjunto de nós do cluster tem, pelo menos, três nós distribuídos por três zonas. |
Configure uma rede de VPC partilhada. |
A rede de VPC partilhada abrange duas regiões. Uma falha regional afeta apenas o tráfego de rede para e a partir de recursos na região com falhas. |
Replique o registo de imagens. |
As imagens são armazenadas no Artifact Registry, que está configurado para replicar para várias regiões, para que uma interrupção da região da nuvem não impeça o aumento da escala da aplicação na região sobrevivente. |
Serviços replicados |
|
Implemente réplicas de serviço em duas regiões. |
Em caso de uma indisponibilidade regional, um serviço Kubernetes permanece disponível nos ambientes de produção e não produção. |
Use atualizações contínuas para alterações de serviço numa região. |
Pode atualizar os serviços do Kubernetes através de um padrão de implementação de atualização contínua que reduz o risco e o tempo de inatividade. |
Configure três réplicas numa região para cada serviço. |
Um serviço Kubernetes tem, pelo menos, três réplicas (pods) para suportar atualizações contínuas no ambiente de produção e não produção. |
Distribua os pods da implementação por várias zonas. |
Os serviços do Kubernetes estão distribuídos por VMs em diferentes zonas através de uma secção anti-affinity. É possível tolerar uma interrupção de um único nó ou uma indisponibilidade total da zona sem incorrer em tráfego entre regiões adicional entre serviços dependentes. |
Armazenamento replicado |
|
Implemente instâncias de bases de dados em várias zonas. |
O AlloyDB para PostgreSQL oferece alta disponibilidade numa região. Os nós redundantes da instância principal estão localizados em duas zonas diferentes da região. A instância principal mantém a disponibilidade regional acionando uma comutação por falha automática para a zona de espera se a zona ativa encontrar um problema. O armazenamento regional ajuda a garantir a durabilidade dos dados em caso de perda numa única zona. |
Replique bases de dados entre regiões. |
O AlloyDB for PostgreSQL usa a replicação entre regiões para oferecer capacidades de recuperação de desastres. A base de dados replica de forma assíncrona os dados do cluster principal em clusters secundários localizados emGoogle Cloud regiões separadas. |
Operações |
|
Aprovisione aplicações para o dobro da carga esperada. |
Se um cluster falhar (por exemplo, devido a uma interrupção do serviço regional), a parte do serviço que é executada no cluster restante pode absorver totalmente a carga. |
Repare nós automaticamente. |
Os clusters estão configurados com a reparação automática de nós. Se as verificações de estado consecutivas de um nó falharem repetidamente durante um período prolongado, o GKE inicia um processo de reparação para esse nó. |
Certifique-se de que as atualizações do node pool têm em atenção a aplicação. |
As implementações definem um orçamento de interrupção de pods com |
Reiniciar automaticamente os serviços bloqueados. |
A implementação que suporta um serviço define uma sondagem de atividade, que identifica e reinicia processos bloqueados. |
Verificar automaticamente se as réplicas estão prontas. |
A implementação que suporta um serviço define uma sondagem de prontidão, que identifica quando uma aplicação está pronta para publicação após o início. Uma sonda de prontidão elimina a necessidade de verificações manuais ou esperas cronometradas durante as atualizações contínuas e as atualizações do conjunto de nós. |
A arquitetura de referência foi concebida para aplicações com requisitos de alta disponibilidade zonais e regionais. Garantir a elevada disponibilidade implica alguns custos (por exemplo, custos de peças sobresselentes em espera ou custos de replicação entre regiões). A secção Alternativas descreve algumas formas de mitigar estes custos.
Quotas da plataforma, limites de desempenho e limites de escalabilidade
Pode controlar as quotas, o desempenho e o dimensionamento dos recursos na plataforma para programadores. A lista seguinte descreve alguns itens a considerar:
- A infraestrutura base requer vários projetos e cada inquilino adicional requer quatro projetos. Pode ter de pedir uma quota de projeto adicional antes da implementação e antes de adicionar mais inquilinos.
- Existe um limite de 100 recursos MultiClusterGateway para cada projeto. Cada serviço Kubernetes virado para a Internet na plataforma do programador requer um MultiClusterGateway.
- O Cloud Logging tem um limite de 100 contentores num projeto. O acesso aos registos por inquilino no esquema baseia-se num contentor para cada inquilino.
- Para criar mais de 20 inquilinos, pode pedir um aumento da quota do projeto para recursos de âmbito e espaço de nomes de âmbito. Para ver instruções sobre como ver as quotas, consulte o artigo Veja e faça a gestão das quotas. Use um filtro para encontrar os tipos de quotas
gkehub.googleapis.com/global-per-project-scopesegkehub.googleapis.com/global-per-project-scope-namespaces.
O que se segue?
- Leia acerca da arquitetura de serviços (documento seguinte nesta série).