Arquitetura de referência do GKE Enterprise: Google Distributed Cloud Virtual para Bare Metal

Last reviewed 2023-08-15 UTC

Neste guia, descrevemos a arquitetura de referência usada para implantar o GDCV para 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 GDCV para Bare Metal

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:

Um modelo mental GDCV for bare metal que mostra as camadas discutidas no documento.

  1. Infraestrutura: esta camada inclui armazenamento, computação e rede, gerenciadas com construções locais.
  2. 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.
  3. Camada de gerenciamento de contêineres: essa camada usa clusters do GKE.
  4. Camada de Service Management: essa camada usa o Anthos Service Mesh.
  5. Camada de gerenciamento de políticas: essa camada usa o Config Sync e o Controlador de Políticas.
  6. Camada de gerenciamento de aplicativos: essa camada usa o Cloud Build e o Cloud Source Repositories.
  7. Camada de observabilidade: essa camada usa os painéis Observabilidade do Google Cloud e Anthos 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 do GDCV para 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 GDCV para balanceadores de carga Bare Metal, há duas opções disponíveis: agrupado e manual.

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:

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 de GDCV para Bare Metal, consulte Visão geral dos balanceadores de carga.

Arquitetura do cluster

A GDCV para Bare Metal oferece suporte a vários modelos de implantação, 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

A GDCV para Bare Metal usa o serviço de identidade do GKE para se integrar com 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 Anthos 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 GDVC for bare metal e Como autenticar-se com o OIDC ou Configurar o Anthos Identity Service com LDAP.

Segurança e gerenciamento de políticas

Para o GDCV de segurança e gerenciamento de políticas Bare Metal, 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 a GDCV para o modo empacotado do Bare Metal para balanceamento de carga, é possível criar serviços do tipo LoadBalancer. Quando você cria esses serviços, o GDCV for Bare Metal 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 GDCV para Bare Metal, um IngressGateway também é criado no cluster por padrão. Não é possível criar serviços do tipo LoadBalancer para GDCV para Bare Metal 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 Anthos Service Mesh. O Anthos 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 Anthos Service Mesh.

Persistência e gerenciamento de estado

O GDCV para 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 GDCV para Bare Metal não fornece 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 GDCV para clusters Bare Metal 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 GDCV for 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 sobre GDCV for bare metal pode ser usado para implantar em hosts autogerenciados ou em 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

Na seção a seguir, detalhamos as decisões arquitetônicas tomadas ao planejar e projetar a plataforma para a implantação do aplicativo do Bank of GKE Enterprise no GDCV para Bare Metal. 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 GDCV para Bare Metal, é 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 do GDCV para Bare Metal 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 GDCV para Bare Metal requer as seguintes sub-redes de endereços IP:

  1. Endereços IP de nós
  2. Endereços IP de pods do Kubernetes
  3. Endereços IP de serviço/cluster do Kubernetes
  4. 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 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 GDCV for bare metal 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 dos clusters

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 no GDCV for bare metal.

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 GDCV para Bare Metal.

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.

Dimensionamento de nós
Tipo de nó CPUs / vCPUs Memória Armazenamento
Plano de controle 8 núcleos 32 GiB 256 GiB
intelectual 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 identidades com o OIDC em GDCV para Bare Metal.

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 Anthos 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 no GDCV para Bare Metal 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 GDCV para Bare Metal. 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 banc