Arquitetura

Arquitetura do cluster

O dispositivo com isolamento físico do Google Distributed Cloud (GDC) opera um único cluster que abrange todos os três nós bare metal, conhecido como cluster de infraestrutura da organização. Um servidor de API de gerenciamento dedicado, que é executado como cargas de trabalho de pod no cluster, hospeda APIs do plano de gerenciamento. As cargas de trabalho do usuário, que incluem VMs e pods do Kubernetes, podem ser executadas nesse cluster. Não há um cluster de usuário neste modelo de cluster.

Arquitetura de rede

O EL8000 inclui um backplane que cria quatro redes separadas da camada 2 (L2) dentro do dispositivo:

1. Console Integrated Lights-Out (iLO) (1GbEth)
2. Rede de gerenciamento (1GbEth)
3. Rede de dados A (10GbEth)
4. Rede de dados B (10GbEth)

O diagrama a seguir mostra como as redes L2 estão conectadas ao switch Mellanox (https://www.hpe.com/psnow/doc/a00043975enw.html?jumpid=in_pdp-psnow-qs). Cada rede em um blade se conecta a um único switch de rede. Todas as redes do console iLO em cada blade de servidor se conectam ao switch de rede 1. As redes de gerenciamento se conectam ao switch de rede 2, e as redes de dados se conectam aos switches 3 e 4.

As portas de rede do cliente (15 e 17) têm acesso ao cluster (VLAN 100), e apenas o tráfego para o CIDR de entrada é permitido. O CIDR de entrada está disponível para serviços, e o intervalo é divulgado pelo Border Gateway Protocol (BGP) para a rede do cliente.

As portas de rede de gerenciamento (16 e 18) têm acesso ao gerenciamento do sistema (VLAN 501) para que os clientes possam ter o dispositivo em uma rede mais ampla e usar apenas conexões locais para realizar tarefas de administração do sistema.

Topologia de rede inferior

Rede física

O GDC consiste em um cluster híbrido que opera em um modo de locatário único. O cluster híbrido, que chamamos de cluster de infraestrutura, consiste nos clusters de sistema e de administrador mesclados:

O design físico é centrado em um Mellanox SN2010 que atua como um gateway entre o cluster de infraestrutura do appliance e a rede externa do cliente.

O cluster de infraestrutura consiste em três nós bare metal (BMs). As conexões nos BMs podem ser categorizadas da seguinte maneira:

• Conectividade de rede de dados (sub-rede 198.18.2.0/24) na VLAN 100. O BM tem uma NIC com duas portas, NIC0P1 e NIC0P2, que são unidas e conectadas ao switch TOR. O BM1 e o BM2 se conectam diretamente ao switch, enquanto o BM3 se conecta ao TOR usando um switch não gerenciado.
• A conectividade da rede de gerenciamento ( sub-rede 198.18..0/24) é feita pela VLAN 501. As interfaces ILO e MGMT são conectadas por essa VLAN usando interfaces de 1G. As interfaces ILO e MGMT nos nós BM se conectam ao switch usando switches não gerenciados.
• Talvez: adicione rede OTS nas VLANs 200 a 203(?) e na sub-rede 198.18.1.x.

A conexão do switch Mellanox ao roteador do cliente fornece conectividade externa. Interfaces de 10 G são usadas para essa conectividade, e o protocolo BGP é usado para anunciar os IPs de rede externa ao cliente. Os clientes usam os IPs externos para acessar os serviços necessários fornecidos pela unidade do Appliance.

Observação: o diagrama da rede física mostrado anteriormente exibe um dispositivo de bootstrap conectado à porta 12 do switch. Esse inicializador é usado para provisionar a unidade do eletrodoméstico como parte da fase de inicialização do lado de baixo. Essa conexão não estará presente quando o dispositivo for enviado ao cliente.

Rede lógica

Há duas redes locais virtuais (VLANs) separando os vários tráfegos:

1. VLAN 100: cluster (endereços IP virtuais de entrada (VIPs), IPs de cluster/nó) com sub-rede IPv4 fornecida pelos clientes.
2. VLAN 501: gerenciamento (iLO, Mgmt) com sub-rede IPv4 fornecida pelo cliente.

Topologia de rede superior

O cluster é configurado usando o balanceamento de carga da camada 2 (L2). Os VIPs do Ingress para o cluster vêm da mesma sub-rede que os nós. Quando um VIP de entrada é atribuído a um nó, ele usa o protocolo de resolução de endereços (ARP) para que o nó possa ser acessado pelo TOR.

O TOR faz peering com a rede do cliente usando o BGP e anuncia o intervalo de entrada do cluster (prefixo agregado fornecido pelo cliente) para a rede do cliente. Quando o rack é movido para um novo local, podemos anunciar o intervalo de Entrada do cluster para a nova rede do cliente. Quando o rack é movido para um novo local, é necessário atualizar manualmente os endereços IP nas interfaces TOR que se conectam à rede do cliente e atualizar as informações de peering do BGP para adicionar os novos peers do BGP.

Todos os IPs usados pelo cluster são alocados do externalCidrBlock do rack ou codificados (para IPs internos do cluster). No diagrama a seguir, o exemplo externalCidrBlock é 10.0.0.0/24:

Intervalos de IP do cluster

Há vários intervalos de IP que precisam ser configurados em um cluster bare metal.

• CIDR do pod: o intervalo de IP usado para atribuir IPs aos pods no cluster. Esse intervalo usa o modo ilha para que a rede física (ToR) não precise saber sobre o CIDR do pod. O único requisito é que o intervalo não se sobreponha a nenhum serviço que os pods do cluster precisem acessar. O CIDR do pod não pode ser alterado depois que o cluster é criado.
• CIDR de serviço: usado para serviços internos do cluster com o mesmo requisito do CIDR de pod.
• CIDR do nó: endereços IP dos nós do cluster do Kubernetes. Esses endereços também não podem mudar depois da criação do cluster.
• Intervalo de entrada: um intervalo de endereços IP usado para qualquer serviço no cluster que seja exposto externamente. Os clientes externos usam esses IPs para acessar serviços no cluster. Esse intervalo precisa ser anunciado para a rede do cliente para que os clientes possam alcançar os IPs de entrada.
• VIP do plano de controle: anunciado pelo cluster para acesso ao Kubernetes api-server (semelhante aos VIPs de entrada). Esse VIP precisa ser da mesma sub-rede que o nó quando o cluster está no modo de balanceamento de carga L2.

Os CIDRs de pod e serviço dos clusters são codificados. O CIDR do pod é 192.168.0.0/16 e o CIDR do serviço é 10.96.0.0/12. O cluster usa os mesmos dois CIDRs, já que esses IPs não são expostos fora do cluster.

Os nós são provisionados com endereços IP do conjunto externalCidrBlock definido no GDC cell.yaml. Esses endereços IP são fornecidos pelo cliente antes do provisionamento do rack.

O intervalo de entrada e o VIP do plano de controle do cluster também são alocados do externalCidrBlock. O TOR precisa anunciar o externalCidrBlock para a rede do cliente para que esses VIPs sejam acessíveis a clientes fora do rack.