Arquitetura

Arquitetura de cluster

O dispositivo isolado do Google Distributed Cloud (GDC) opera um único cluster que abrange todos os três nós bare metal, conhecido como o cluster de infraestrutura da organização. Um servidor de API de gestão dedicado, que é executado como cargas de trabalho de pods no cluster, aloja APIs do plano de gestão. As cargas de trabalho do utilizador, que incluem VMs e pods do Kubernetes, podem ser executadas neste cluster. Não existe nenhum cluster de utilizadores neste modelo de cluster.

Arquitetura de rede

O EL8000 inclui um backplane que cria quatro redes de camada 2 (L2) separadas no dispositivo:

1. Consola Integrated Lights-Out (iLO) (1GbEth)
2. Rede de gestão (1GbEth)
3. Rede de dados A (10GbEth)
4. Rede de dados B (10GbEth)

O diagrama seguinte mostra como as redes L2 estão ligadas ao comutador Mellanox (https://www.hpe.com/psnow/doc/a00043975enw.html?jumpid=in_pdp-psnow-qs). Cada rede numa placa conecta-se a um único comutador de rede. Todas as redes da consola iLO em cada servidor blade ligam-se ao comutador de rede 1. As redes de gestão ligam-se ao comutador de rede 2 e as redes de dados ligam-se aos comutadores 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 é anunciado através do Border Gateway Protocol (BGP) para a rede do cliente.

As portas de rede de gestão (16 e 18) têm acesso à gestão do sistema (VLAN 501), para que os clientes possam ter o dispositivo numa rede mais ampla e usar apenas ligações locais para realizar tarefas de administração do sistema.

Topologia de rede inferior

Rede física

O GDC consiste num cluster híbrido que funciona no modo de inquilino único. O cluster híbrido, ao qual nos referimos como cluster de infraestrutura, é composto pelos clusters de sistema e de administrador unidos:

O design físico centra-se num Mellanox SN2010 que funciona como uma porta de entrada entre o cluster de infraestrutura do dispositivo e a rede de clientes externa.

O cluster de infraestrutura é composto por 3 nós de metal puro (BMs). As associações nos GNs podem ser categorizadas da seguinte forma:

• Conetividade de rede de dados (sub-rede 198.18.2.0/24) que está sobre a VLAN 100. O BM tem uma NIC com 2 portas, NIC0P1 e NIC0P2, que estão unidas e ligadas ao comutador TOR. BM1 e BM2 ligam-se diretamente ao comutador, enquanto BM3 se liga ao TOR através de um comutador não gerido.
• A conetividade da rede de gestão ( sub-rede 198.18..0/24) está na VLAN 501. As interfaces ILO e MGMT estão ligadas através desta VLAN com interfaces de 1 G. As interfaces ILO e as interfaces MGMT nos nós BM ligam-se ao comutador através de comutadores não geridos.
• Talvez: adicionar rede OTS nas VLANs 200-203(?), sub-rede 198.18.1.x

A ligação do comutador Mellanox ao router do cliente oferece conetividade externa. As interfaces de 10 G são usadas para esta conetividade e o protocolo BGP é usado para anunciar os IPs de rede externos ao cliente. Os clientes usam os IPs externos para aceder aos serviços necessários fornecidos pela unidade do dispositivo.

Nota: o diagrama de rede físico apresentado anteriormente mostra um dispositivo de arranque ligado à porta 12 do comutador. Este programa de arranque destina-se a aprovisionar a unidade de dispositivo como parte da fase de arranque do lado inferior. Esta ligação não está presente quando o aparelho é enviado para o cliente.

Rede lógica

Existem duas redes locais virtuais (VLANs) que separam o tráfego:

1. VLAN 100: cluster (endereços de protocolo de Internet virtuais de entrada [VIPs], IPs de cluster/nó) com sub-rede IPv4 fornecida pelos clientes.
2. VLAN 501: gestão (iLO, Mgmt) com sub-rede IPv4 fornecida pelo cliente.

Topologia de rede superior

O cluster está configurado com o balanceamento de carga da camada 2 (L2). Os VIPs de entrada para o cluster são provenientes da mesma sub-rede que os nós. Quando um VIP de entrada é atribuído a um nó, o nó usa o protocolo de resolução de endereços (ARP) para que o nó seja acessível a partir do TOR.

O TOR interage com a rede do cliente através do BGP e anuncia o intervalo de entrada do cluster (prefixo agregado fornecido pelo cliente) à rede do cliente. Quando o rack se move para uma nova localização, podemos anunciar o intervalo de Ingress do cluster à nova rede de clientes. Quando o rack se move para uma nova localização, tem de atualizar manualmente os endereços IP nas interfaces TOR que se ligam à rede do cliente e atualizar as informações de peering BGP para adicionar os novos pares BGP.

Todos os IPs usados pelo cluster são atribuídos a partir do intervalo de IPs do rack ou codificados (para IPs internos do cluster).externalCidrBlock No diagrama seguinte, o exemplo externalCidrBlock é 10.0.0.0/24:

Intervalos de IP de cluster

Existem vários intervalos de IP que têm de ser configurados num cluster bare metal.

• CIDR do pod: o intervalo de IPs usado para atribuir IPs aos pods no cluster. Este intervalo usa o modo isolado, para que a rede física (ToR) não precise de saber sobre o CIDR do agrupamento. O único requisito é que o intervalo não pode sobrepor-se a nenhum serviço ao qual os pods do cluster precisem de aceder. Não é possível alterar o CIDR do pod após a criação do cluster.
• CIDR de serviço: usado para serviços de cluster internos com o mesmo requisito que o CIDR de pods.
• CIDR de nós: endereços IP dos nós do cluster do Kubernetes. Também não é possível alterar estes endereços após a criação do cluster.
• Intervalo de entrada: um intervalo de endereços IP usado para quaisquer serviços no cluster que sejam expostos externamente. Os clientes externos usam estes IPs para aceder a serviços no cluster. Este intervalo tem de ser anunciado à rede do cliente para que os clientes possam alcançar os IPs de entrada.
• VIP do plano de controlo: anunciado pelo cluster para acesso ao Kubernetes api-server (semelhante aos VIPs de entrada). Este IP virtual tem de ser da mesma sub-rede que o nó quando o cluster está no modo de equilíbrio de carga da camada 2.

O CIDR de pods e os CIDRs de serviços para os clusters estã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, uma vez que estes IPs não são expostos fora do cluster.

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

O intervalo de entrada e o VIP do painel de controlo para o cluster também são atribuídos a partir do externalCidrBlock. O TOR tem de anunciar o externalCidrBlock à rede do cliente para que estes VIPs sejam acessíveis aos clientes fora do bastidor.