Architecture

Architecture d'un cluster

L'appliance Google Distributed Cloud (GDC) sous air gap exploite un seul cluster qui englobe les trois nœuds Bare Metal, appelé cluster d'infrastructure de l'organisation. Un serveur d'API de gestion dédié, qui s'exécute en tant que charges de travail de pod sur le cluster, héberge les API du plan de gestion. Les charges de travail utilisateur, qui incluent à la fois des VM et des pods Kubernetes, peuvent s'exécuter sur ce cluster. Ce modèle de cluster ne contient aucun cluster d'utilisateur.

Architecture de réseau

L'EL8000 inclut un fond de panier qui crée quatre réseaux de couche 2 (L2) distincts dans l'appareil :

1. Console Integrated Lights-Out (iLO) (1GbEth)
2. Réseau de gestion (1 GbEth)
3. Réseau de données A (10GbEth)
4. Réseau de données B (10GbEth)

Le diagramme suivant montre comment les réseaux de couche 2 sont connectés au commutateur Mellanox (https://www.hpe.com/psnow/doc/a00043975enw.html?jumpid=in_pdp-psnow-qs). Chaque réseau d'une lame se connecte à un seul commutateur réseau. Tous les réseaux de console iLO de chaque lame de serveur se connectent au commutateur réseau 1. Les réseaux de gestion se connectent au commutateur réseau 2, et les réseaux de données se connectent aux commutateurs 3 et 4.

Les ports réseau du client (15 et 17) ont accès au cluster (VLAN 100), et seul le trafic vers le CIDR d'entrée est autorisé. Le CIDR d'entrée est disponible pour les services, et la plage est annoncée sur le protocole BGP (Border Gateway Protocol) au réseau client.

Les ports réseau de gestion (16 et 18) ont accès à la gestion du système (VLAN 501). Les clients peuvent ainsi placer l'appareil sur un réseau plus étendu et n'utiliser que des connexions locales pour effectuer des tâches d'administration système.

Topologie de réseau inférieure

Réseau physique

GDC se compose d'un cluster hybride fonctionnant en mode locataire unique. Le cluster hybride, que nous appelons cluster d'infrastructure, se compose des clusters système et d'administrateur fusionnés :

La conception physique est axée sur un Mellanox SN2010 qui sert de passerelle entre le cluster d'infrastructure de l'appliance et le réseau client externe.

Le cluster d'infrastructure se compose de trois nœuds Bare Metal. Les connexions sur les BCM peuvent être classées comme suit :

• Connectivité au réseau de données (sous-réseau 198.18.2.0/24) via le VLAN 100. La BM dispose d'une carte d'interface réseau avec deux ports, NIC0P1 et NIC0P2, qui sont liés et connectés au commutateur TOR. BM1 et BM2 se connectent directement au commutateur, tandis que BM3 se connecte au TOR à l'aide d'un commutateur non géré.
• La connectivité du réseau de gestion ( sous-réseau 198.18..0/24) s'effectue via le VLAN 501. Les interfaces ILO et MGMT sont connectées sur ce VLAN à l'aide d'interfaces 1G. Les interfaces ILO et MGMT sur les nœuds BM se connectent au commutateur à l'aide de commutateurs non gérés.
• Peut-être : ajouter la mise en réseau OTS sur les VLAN 200 à 203(?), sous-réseau 198.18.1.x

La connexion entre le commutateur Mellanox et le routeur client fournit une connectivité externe. Des interfaces 10G sont utilisées pour cette connectivité, et le protocole BGP est utilisé pour annoncer les adresses IP du réseau externe au client. Les clients utilisent les adresses IP externes pour accéder aux services nécessaires fournis par l'unité Appliance.

Remarque : Le schéma du réseau physique affiché précédemment montre un dispositif de bootstrap connecté au port 12 du commutateur. Ce programme d'amorçage permet de provisionner l'appliance lors de la phase d'amorçage côté réseau interne. Cette connexion ne sera pas présente lorsque l'appareil sera expédié au client.

Réseau logique

Deux réseaux locaux virtuels (VLAN) séparent les différents types de trafic :

1. VLAN 100 : cluster (adresses IP virtuelles d'Ingress, adresses IP de cluster/de nœud) avec sous-réseau IPv4 fourni par les clients.
2. VLAN 501 : gestion (iLO, Mgmt) avec sous-réseau IPv4 fourni par le client.

Topologie du réseau supérieur

Le cluster est configuré à l'aide de l'équilibrage de charge de couche 2 (L2). Les adresses IP virtuelles d'entrée du cluster proviennent du même sous-réseau que les nœuds. Lorsqu'une adresse IP virtuelle d'entrée est attribuée à un nœud, celui-ci utilise le protocole ARP (Address Resolution Protocol) pour être accessible depuis le TOR.

Le TOR est appairé au réseau client à l'aide de BGP et annonce la plage d'Ingress du cluster (préfixe agrégé fourni par le client) au réseau client. Lorsque le rack est déplacé vers un nouvel emplacement, nous pouvons diffuser la plage d'Ingress du cluster sur le nouveau réseau client. Lorsque le rack est déplacé, vous devez mettre à jour manuellement les adresses IP des interfaces TOR qui se connectent au réseau client, ainsi que les informations d'appairage BGP pour ajouter les nouveaux pairs BGP.

Toutes les adresses IP utilisées par le cluster sont allouées à partir de externalCidrBlock du rack ou codées en dur (pour les adresses IP internes au cluster). Dans le schéma suivant, l'exemple externalCidrBlock est 10.0.0.0/24 :

Plages d'adresses IP du cluster

Plusieurs plages d'adresses IP doivent être configurées dans un cluster Bare Metal.

• CIDR des pods : plage d'adresses IP utilisée pour attribuer des adresses IP aux pods du cluster. Cette plage utilise le mode île, de sorte que le réseau physique (ToR) n'a pas besoin de connaître le CIDR du pod. La seule exigence est que la plage ne chevauche aucun service auquel les pods du cluster doivent accéder. Le CIDR du pod ne peut pas être modifié une fois le cluster créé.
• CIDR du service : utilisé pour les services de cluster internes avec la même exigence que le CIDR du pod.
• CIDR du nœud : adresses IP des nœuds du cluster Kubernetes. Ces adresses ne peuvent pas non plus être modifiées une fois le cluster créé.
• Plage d'entrée : plage d'adresses IP utilisée pour tous les services du cluster qui sont exposés en externe. Les clients externes utilisent ces adresses IP pour accéder aux services du cluster. Cette plage doit être annoncée au réseau client afin que les clients puissent accéder aux adresses IP d'entrée.
• Adresse IP virtuelle du plan de contrôle : annoncée par le cluster pour accéder à l'api-server Kubernetes (semblable aux adresses IP virtuelles d'entrée). Cette adresse IP virtuelle doit provenir du même sous-réseau que le nœud lorsque le cluster est en mode d'équilibrage de charge L2.

Les CIDR de pod et de service des clusters sont codés en dur. Le CIDR du pod est 192.168.0.0/16 et le CIDR du service est 10.96.0.0/12. Le cluster utilise les deux mêmes CIDR, car ces adresses IP ne sont pas exposées en dehors du cluster.

Les nœuds sont provisionnés avec des adresses IP issues de l'ensemble externalCidrBlock défini dans le cell.yaml de GDC. Ces adresses IP sont fournies par le client avant le provisionnement du rack.

La plage d'entrée et l'adresse IP virtuelle du plan de contrôle pour le cluster sont également allouées à partir de externalCidrBlock. Le TOR doit annoncer externalCidrBlock au réseau client afin que ces VIP soient accessibles aux clients en dehors du rack.