Este guia descreve a arquitetura de referência usada para implantar o Google Distributed Cloud (somente software) em bare metal. Este guia é destinado a administradores de plataformas que querem implantar o GKE Enterprise em uma plataforma bare metal em uma configuração altamente disponível e geograficamente redundante. Para entender melhor este guia, é necessário conhecer os conceitos básicos do GKE Enterprise, conforme descrito na Visão geral técnica do GKE Enterprise. Também é necessário ter um conhecimento básico dos conceitos do Kubernetes e do Google Kubernetes Engine (GKE), como descrito emAprenda os conceitos básicos do Kubernetes e Documentação do GKE para criar um anexo da VLAN de monitoramento.
Este guia tem um repositório de origem do GitHub que inclui scripts que podem ser usados para implantar a arquitetura descrita. Este guia também descreve os componentes arquitetônicos que acompanham os scripts e módulos usados para criar esses componentes. Recomendamos que você use esses arquivos como modelos para criar módulos que adotam as práticas recomendadas e as políticas da sua organização.
Modelo de arquitetura
No guia GKE Enterprise Architecture Foundations, a arquitetura da plataforma é descrita em camadas. Os recursos em cada camada fornecem um conjunto específico de funções. Esses recursos pertencem e são gerenciados por um ou mais perfis. Conforme mostrado no diagrama a seguir, a arquitetura da plataforma GKE Enterprise para bare metal consiste nas camadas e recursos a seguir:
- Infraestrutura: esta camada inclui armazenamento, computação e rede, gerenciadas com construções locais.
- Gerenciamento de dados: para os propósitos deste guia, a camada de gerenciamento de dados exige um banco de dados SQL gerenciado fora dos clusters do Kubernetes que estão sendo implantados.
- Camada de gerenciamento de contêineres: essa camada usa clusters do GKE.
- Camada de Service Management: essa camada usa o Cloud Service Mesh.
- Camada de gerenciamento de políticas: essa camada usa o Config Sync e o Controlador de Políticas.
- Camada de gerenciamento de aplicativos: essa camada usa o Cloud Build e o Cloud Source Repositories.
- Camada de observabilidade: essa camada usa os painéis Observabilidade do Google Cloud e Cloud Service Mesh.
Cada uma dessas camadas é repetida na pilha para diferentes ambientes de ciclo de vida, como desenvolvimento, preparação e produção.
As seções a seguir incluem apenas outras informações específicas de implantações bare metal. Elas se baseiam nas respectivas seções no guia GKE Enterprise Architecture Foundations. Recomendamos que você revise o guia enquanto lê este artigo.
Rede
Para mais informações sobre os requisitos de rede, consulte Requisitos de rede.
Para balanceadores de carga do Google Distributed Cloud, há duas opções disponíveis: agrupadas e manuais.
No modo empacotado, o software de balanceamento de carga L4 é implantado durante a criação do cluster. Os processos do balanceador de carga podem ser executados em um pool dedicado de nós de trabalho ou nos mesmos nós do plano de controle. Para anunciar endereços IP virtuais (VIPs), esse balanceador de carga tem duas opções:
- Protocolo de resolução de endereço (ARP): exige conectividade de camada 2 entre os nós que executam o balanceador de carga.
- Protocolo de gateway de borda (BGP): usa peering para interconectar a rede do cluster (que é um sistema autônomo) a outro sistema autônomo, como uma rede externa.
No modo manual, você configura suas próprias soluções de balanceamento de carga para o tráfego do plano de controle e do plano de dados. Há muitas opções de hardware e software disponíveis para balanceadores de carga externos. É preciso configurar o balanceador de carga externo para o plano de controle antes de criar um cluster bare metal. O balanceador de carga do plano de controle externo também pode ser usado para o tráfego do plano de dados, ou é possível configurar um balanceador de carga separado para ele. Para determinar a disponibilidade, o balanceador de carga precisa distribuir o tráfego para um pool de nós com base em uma verificação de prontidão configurável.
Para mais informações sobre balanceadores de carga para implantações bare metal, consulte Visão geral dos balanceadores de carga.
Arquitetura do cluster
O Google Distributed Cloud oferece suporte a vários modelos de implantação em bare metal, atendendo a diferentes necessidades de disponibilidade, isolamento e abrangência de recursos. Esses modelos de implantação são discutidos em Como escolher um modelo de implantação.
Gerenciamento de identidade
O Google Distributed Cloud usa o GKE Identity Service para se integrar a provedores de identidade. Ele é compatível com o OpenID Connect (OIDC) e com o Protocolo leve de acesso a diretórios (LDAP). Para aplicativos e serviços, o Cloud Service Mesh pode ser usado com várias soluções de identidade.
Para mais informações sobre o gerenciamento de identidade, consulte Gerenciamento de identidade com o OIDC no Google Distributed Cloud e Como autenticar com o OIDC ou Configurar o GKE Identity Service com LDAP.
Segurança e gerenciamento de políticas
Para o gerenciamento de políticas e segurança do Google Distributed Cloud, recomendamos o uso do Config Sync e do Policy Controller. O Controlador de Políticas permite criar e aplicar políticas nos clusters. O Config Sync avalia as alterações e as aplica a todos os clusters para alcançar o estado apropriado.
Serviços
Ao usar o modo empacotado do Google Distributed Cloud para balanceamento
de carga em implantações bare metal, é possível criar
serviços do
tipo LoadBalancer. Quando você cria esses serviços, o Google Distributed Cloud
atribui um endereço IP do pool de endereços IP do balanceador de carga configurado ao
serviço. O tipo de serviço LoadBalancer é usado para expor o serviço do Kubernetes fora do cluster para tráfego norte-sul.
Ao usar o Google Distributed Cloud, um
IngressGateway
também é criado no cluster por padrão. Não é possível criar serviços do tipo LoadBalancer
para o Google Distributed Cloud no modo manual. Em vez disso, você pode criar um objeto Ingress que use o IngressGateway ou criar NodePort- tipos e configurar manualmente o balanceador de carga externo para usar o serviço do Kubernetes como um back-end.
No Service Management, também conhecido como tráfego leste-oeste, recomendamos o uso do Cloud Service Mesh. O Cloud Service Mesh é baseado em APIs abertas do Istio e oferece observabilidade uniforme, autenticação, criptografia, controles de tráfego refinados e outros recursos e funções. Para mais informações sobre o Service Management, consulte Cloud Service Mesh.
Persistência e gerenciamento de estado
O Google Distributed Cloud em bare metal depende em grande parte da infraestrutura atual para armazenamento temporário, armazenamento de volume e armazenamento PersistentVolume. Os dados temporários usam os recursos do disco local no nó em que o pod do Kubernetes está programado. Para dados permanentes, o GKE Enterprise é compatível com a Container Storage Interface (CSI), uma API de padrão aberto compatível com muitos fornecedores de armazenamento. Para armazenamento de produção, recomendamos instalar um driver CSI de um parceiro de armazenamento do GKE Enterprise Ready. Para ver a lista completa de parceiros de armazenamento do GKE Enterprise Ready, consulte parceiros de armazenamento do GKE Enterprise Ready.
Para mais informações sobre armazenamento, consulte Como configurar o armazenamento.
Bancos de dados
O Google Distributed Cloud não oferece outros recursos específicos de banco de dados além dos recursos padrão da plataforma GKE Enterprise. A maioria dos bancos de dados é executada em um sistema externo de gerenciamento de dados. As cargas de trabalho na plataforma GKE Enterprise também podem ser configuradas para se conectar a qualquer banco de dados externo acessível.
Observabilidade
A Observabilidade do Google Cloud coleta registros e métricas de monitoramento para
clusters do Google Distributed Cloud de maneira semelhante às
políticas de coleta e monitoramento dos clusters do GKE. Por padrão, os registros do cluster e as métricas do componente do sistema são enviados para o Cloud Monitoring.
Para que a observabilidade do Google Cloud colete registros e
métricas de aplicativos, ative a opção clusterOperations.enableApplication no arquivo YAML de
configuração do cluster.
Para mais informações sobre observabilidade, consulte Como configurar a geração de registros e o monitoramento.
Caso de uso: implantação do Cymbal Bank
Neste guia, o aplicativo do Cymbal Bank/Bank of Anthos é usado para simular o processo de planejamento, implantação de plataforma e implantação de aplicativo do Google Distributed Cloud em bare metal.
O restante deste documento é composto por três seções. A seção Planejamento descreve as decisões tomadas com base nas opções discutidas nas seções de modelo da arquitetura. Na seção Implantação de plataforma, são abordados os scripts e módulos fornecidos por um repositório de origem para implantar a plataforma GKE Enterprise. Por fim, na seção Implantação do aplicativo, o aplicativo do Cymbal Bank é implantado na plataforma.
Este guia do Google Distributed Cloud pode ser usado para implantar em hosts autogerenciados ou instâncias do Compute Engine. Ao usar os recursos do Google Cloud, qualquer pessoa pode concluir este guia sem precisar acessar o hardware físico. O uso de instâncias do Compute Engine é apenas para fins de demonstração. NÃO use essas instâncias para cargas de trabalho de produção. Quando o acesso ao hardware físico estiver disponível e os mesmos intervalos de endereços IP forem usados, será possível usar o repositório de origem fornecido. Se o ambiente diferente do descrito na seção Como planejar, é possível modificar os scripts e módulos para acomodar as diferenças. O repositório de origem associado contém instruções para os cenários de instância de hardware físico e do Compute Engine.
Planejamento
A seção a seguir detalha as decisões arquitetônicas tomadas ao planejar e projetar a plataforma para a implantação do aplicativo Bank of GKE Enterprise no Google Distributed Cloud. Essas seções se concentram em um ambiente de produção. Para criar ambientes inferiores como desenvolvimento ou preparo, use etapas semelhantes.
Projetos do Google Cloud
Ao criar projetos no Google Cloud para Google Distributed Cloud, é necessário ter um projeto host da frota. Outros projetos são recomendados para cada ambiente ou função de negócios. Essa configuração de projeto permite organizar recursos com base no perfil que está interagindo com eles.
Nas subseções a seguir, discutiremos os tipos de projeto recomendados e os perfis associados a eles.
Projeto hub
O projeto hub hub-prod é destinado ao perfil do administrador
de rede. É nesse projeto que o data center local está conectado ao
Google Cloud usando a forma selecionada de conectividade híbrida. Para mais
informações sobre opções de conectividade híbrida, consulte
Conectividade do Google Cloud
Projeto host da frota
O projeto host
de frota fleet-prod é destinado ao perfil
dos administradores da plataforma. O projeto é onde os
clusters da Google Distributed Cloud são registrados. Esse projeto também
é onde os recursos do Google Cloud relacionados à plataforma residem. Esses recursos incluem a observabilidade do Google Cloud, o Cloud Source Repositories, entre outros. Um determinado projeto do Google Cloud só pode ter
uma única frota (ou nenhuma) associada a ele. Essa restrição reforça
o uso de projetos do Google Cloud para fornecer maior isolamento entre recursos
que não são governados ou consumidos em conjunto.
Projeto de equipe ou aplicativo
O aplicativo ou projeto de equipe app-banking-prod é destinado ao perfil dos
desenvolvedores. Esse projeto é onde residem os recursos do Google Cloud específicos
do aplicativo ou da equipe. O projeto inclui tudo, exceto clusters do GKE. Dependendo do número de equipes ou aplicativos, pode haver várias instâncias desse tipo de projeto. A criação
de projetos separados para equipes diferentes permite que você gerencie
o IAM, o faturamento e a cota separadamente para cada equipe.
Rede
Cada cluster do Google Distributed Cloud requer as seguintes sub-redes de endereço IP:
- Endereços IP de nós
- Endereços IP de pods do Kubernetes
- Endereços IP de serviço/cluster do Kubernetes
- Endereços IP do balanceador de carga (modo agrupado)
Para usar os mesmos intervalos de endereços IP não roteáveis para as sub-redes de serviço e o pod do Kubernetes em cada cluster, selecione um modelo de rede no modo ilha. Nessa configuração, os pods podem se comunicar diretamente em um cluster, mas não podem ser acessados diretamente de um cluster, usando endereços IP do pod. Essa configuração forma uma ilha dentro da rede que não está conectada à rede externa. Os clusters formam uma malha completa de nó para nó entre os nós de cluster da ilha, permitindo que o pod alcance diretamente outros pods dentro do cluster.
Alocação de endereço IP
| Cluster | Nó | Pod | Serviços | Balanceador de carga |
|---|---|---|---|---|
| metal-admin-dc1-000-prod | 10.185.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | N/A |
| metal-user-dc1a-000-prod | 10.185.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.1.3-10.185.1.10 |
| metal-user-dc1b-000-prod | 10.185.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.2.3-10.185.2.10 |
| metal-admin-dc2-000-prod | 10.195.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | N/A |
| metal-user-dc2a-000-prod | 10.195.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.1.3-10.195.1.10 |
| metal-user-dc2b-000-prod | 10.195.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.2.3-10.195.2.10 |
No modo de ilha, é importante garantir que as sub-redes de endereços IP escolhidas para os pods e serviços do Kubernetes não estejam em uso ou sejam roteáveis a partir da rede do nó.
Requisitos de rede
Para fornecer um balanceador de carga integrado para o Google Distributed Cloud que não exija configuração, use o modo de balanceador de carga em cada cluster. Quando as cargas de trabalho executam serviços LoadBalancer, um endereço IP é atribuído do pool do balanceador de carga.
Para informações detalhadas sobre os requisitos e a configuração do balanceador de carga em pacote, consulte Visão geral dos balanceadores de carga e Como configurar o balanceamento de carga em pacote.
Arquitetura do cluster
Para um ambiente de produção, recomendamos o uso de um modelo de implantação de cluster de administrador e de usuário com um cluster de administrador e dois clusters de usuário em cada localização geográfica para conseguir maior redundância e tolerância a falhas na Google Distributed Cloud.
Recomendamos usar no mínimo quatro clusters de usuários para cada ambiente de produção. Use dois locais com redundância geográfica, cada um com dois clusters tolerantes a falhas. Cada cluster tolerante a falhas tem conexões redundantes de hardware e de rede. Diminuir o número de clusters reduz a redundância ou a tolerância a falhas da arquitetura.
Para ajudar a garantir alta disponibilidade, o plano de controle de cada cluster usa três nós. Com um mínimo de três nós de trabalho por cluster, é possível distribuir as cargas de trabalho entre eles para diminuir o impacto quando um nó fica off-line. O número e o dimensionamento dos nós de trabalho dependem muito do tipo e número de cargas de trabalho executadas no cluster. O dimensionamento recomendado para cada um dos nós é discutido em Como configurar o hardware para o Google Distributed Cloud.
A tabela a seguir descreve o dimensionamento de nós recomendado para núcleos de CPU, memória e armazenamento em disco local nesse caso de uso.
| Tipo de nó | CPUs / vCPUs | Memória | Armazenamento |
|---|---|---|---|
| Plano de controle | 8 núcleos | 32 GiB | 256 GiB |
| Worker | 8 núcleos | 64 GiB | 512 GiB |
Para mais informações sobre os pré-requisitos e o dimensionamento da máquina, consulte Pré-requisitos da máquina do nó do cluster.
Gerenciamento de identidade
Para o gerenciamento de identidades, recomendamos uma integração com o OIDC por meio do GKE Identity Service. Nos exemplos fornecidos no repositório de origem, a autenticação local é usada para simplificar os requisitos. Se o OIDC estiver disponível, será possível modificar o exemplo para usá-lo. Para mais informações, consulte Gerenciamento de identidade com o OIDC no Google Distributed Cloud.
Segurança e gerenciamento de políticas
No caso de uso do Cymbal Bank, o Config Sync e o Controlador de Políticas
são usados para o gerenciamento de políticas. Um Cloud Source Repositories é criado para armazenar os
dados de configuração usados pelo Config Sync. O
operador ConfigManagement, usado para instalar e gerenciar o Config Sync
e o Controlador de Políticas, precisa de acesso somente leitura ao
repositório de origem da configuração. Para conceder esse acesso, use uma forma de autenticação aceitável. Neste exemplo, é usada uma conta de serviço do Google.
Serviços
Para o Service Management nesse caso de uso, o Cloud Service Mesh é usado para
fornecer uma base em que serviços distribuídos são criados. Por padrão, um IngressGateway também é criado no cluster, que processa objetos Ingress padrão do Kubernetes.
Persistência e gerenciamento de estado
Como o armazenamento permanente depende muito da infraestrutura atual, esse caso de uso não exige isso. Em outros casos, no entanto, sugerimos usar as opções de armazenamento de parceiros de armazenamento prontos para o GKE Enterprise. Se uma opção de armazenamento CSI estiver disponível, ela poderá ser instalada no cluster usando as instruções fornecidas pelo fornecedor. Para casos de uso avançados e de prova de conceito, você pode usar volumes locais. No entanto, na maioria dos casos de uso, não recomendamos o uso de volumes locais em ambientes de produção.
Bancos de dados
Muitos aplicativos com estado na Google Distributed Cloud usam bancos de dados como armazenamento de persistência. Um aplicativo de banco de dados com estado precisa acessar um banco de dados para fornecer a lógica de negócios aos clientes. Não há restrições para o tipo de Datastore usado pelo Google Distributed Cloud. Portanto, as decisões de armazenamento de dados precisam ser tomadas pelo desenvolvedor ou pelas equipes de gerenciamento de dados associadas. Como aplicativos diferentes podem exigir armazenamentos de dados diferentes, eles podem ser usados sem limitação. Os bancos de dados podem ser gerenciados no cluster, no local ou até mesmo na nuvem.
O aplicativo do Cymbal Bank é com estado e acessa dois bancos de dados PostgreSQL. O acesso ao banco de dados é configurado por meio de variáveis de ambiente. O banco de dados PostgreSQL precisa estar acessível para os nós que executam as cargas de trabalho, mesmo quando é gerenciado externamente pelo cluster. Neste exemplo, o aplicativo acessa um banco de dados PostgreSQL externo existente. Enquanto o aplicativo é executado na plataforma, o banco de dados é gerenciado externamente. Assim, o banco de dados não faz parte da plataforma GKE Enterprise. Se um banco de dados PostgreSQL estiver disponível, use-o. Caso contrário, crie e use um banco de dados do Cloud SQL para o aplicativo do Cymbal Bank.
Observabilidade
Cada cluster no caso de uso do Cymbal Bank está configurado para que a observabilidade do Google Cloud colete registros e métricas para os componentes e aplicativos do sistema. Há vários painéis do Cloud Monitoring criados pelo instalador do Console do Google Cloud que podem ser visualizados na página Painéis do Monitoring. Para mais informações sobre observabilidade, consulte Como configurar a geração de registros e o monitoramento e Como o Logging e o Monitoring para o Google Distributed Cloud funcionam.
Implantação de plataforma
Para mais informações, consulte a seção Implantar a plataforma da documentação no repositório de origem do GitHub.
Implantação do app
Para mais informações, consulte a seção Implantar o aplicativo da documentação no repositório de origem do GitHub.
A seguir
- Leia mais sobre o Cloud Service Mesh, o Config Sync e o Controlador de Políticas.
- Confira algumas das outras arquiteturas de referência do GKE Enterprise.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.