Arquitectura

Arquitectura de clúster

El dispositivo air-gapped de Google Distributed Cloud (GDC) opera un único clúster que abarca los tres nodos de hardware, conocido como clúster de infraestructura de la organización. Un servidor de APIs de gestión dedicado, que se ejecuta como cargas de trabajo de pods en el clúster, aloja APIs del plano de gestión. Las cargas de trabajo de los usuarios, que incluyen tanto máquinas virtuales como pods de Kubernetes, pueden ejecutarse en este clúster. No hay ningún clúster de usuarios en este modelo de clústeres.

Arquitectura de red

La EL8000 incluye una placa de circuito impreso que crea cuatro redes de capa 2 (L2) independientes dentro del dispositivo:

1. Consola Integrated Lights-Out (iLO) (1 GbE)
2. Red de gestión (1 GbE)
3. Red de datos A (10GbEth)
4. Red de datos B (10GbEth)

En el siguiente diagrama se muestra cómo se conectan las redes de nivel 2 al switch Mellanox (https://www.hpe.com/psnow/doc/a00043975enw.html?jumpid=in_pdp-psnow-qs). Cada red de un blade se conecta a un único conmutador de red. Todas las redes de la consola iLO de cada blade de servidor se conectan al conmutador de red 1. Las redes de gestión se conectan al conmutador de red 2 y las redes de datos se conectan a los conmutadores 3 y 4.

Los puertos de red del cliente (15 y 17) tienen acceso al clúster (VLAN 100) y solo se permite el tráfico a la CIDR de entrada. El CIDR de entrada está disponible para los servicios y el intervalo se anuncia a través del protocolo de pasarela fronteriza (BGP) a la red del cliente.

Los puertos de red de gestión (16 y 18) tienen acceso a la gestión del sistema (VLAN 501), por lo que los clientes pueden tener el dispositivo en una red más amplia y usar solo conexiones locales para realizar tareas de administración del sistema.

Topología de red inferior

Red física

El GDC consta de un clúster híbrido que funciona en modo de un solo arrendatario. El clúster híbrido, al que llamamos clúster de infraestructura, consta de los clústeres de sistema y de administrador combinados:

El diseño físico se centra en un Mellanox SN2010 que actúa como una pasarela entre el clúster de infraestructura del dispositivo y la red externa del cliente.

El clúster de infraestructura consta de 3 nodos Bare Metal (BMs). Las conexiones de los BMs se pueden clasificar de la siguiente manera:

• Conectividad de red de datos (subred 198.18.2.0/24) a través de la VLAN 100. El BM tiene una NIC con 2 puertos, NIC0P1 y NIC0P2, que están enlazados y conectados al conmutador TOR. BM1 y BM2 se conectan directamente al switch, mientras que BM3 se conecta al TOR mediante un switch no gestionado.
• La conectividad de la red de gestión ( subred 198.18..0/24) se realiza a través de la VLAN 501. Las interfaces ILO y MGMT están conectadas a través de esta VLAN mediante interfaces 1G. Las interfaces ILO y MGMT de los nodos BM se conectan al conmutador mediante conmutadores no gestionados.
• Quizá: añadir la red de OTS en las VLANs 200-203(?), subred 198.18.1.x

La conexión del switch Mellanox al router del cliente proporciona conectividad externa. Para esta conectividad, se usan interfaces de 10 G y el protocolo BGP para anunciar las IPs de la red externa al cliente. Los clientes usan las IPs externas para acceder a los servicios necesarios que proporciona la unidad del dispositivo.

Nota: El diagrama de la red física que se ha mostrado anteriormente muestra un dispositivo de arranque conectado al puerto 12 del switch. Este bootstrapper se usa para aprovisionar la unidad de dispositivo como parte de la fase de arranque de la parte inferior. Esta conexión no estará presente cuando el aparato se envíe al cliente.

Red lógica

Hay dos redes de área local virtuales (VLANs) que separan el tráfico:

1. VLAN 100: clúster (direcciones de protocolo de Internet virtuales de entrada [VIPs], IPs de clúster o nodo) con subred IPv4 proporcionada por los clientes.
2. VLAN 501: gestión (iLO, Mgmt) con subred IPv4 proporcionada por el cliente.

Topología de red superior

El clúster se configura mediante el balanceo de carga de capa 2 (L2). Las IPs virtuales de Ingress del clúster proceden de la misma subred que los nodos. Cuando se asigna una IP virtual de entrada a un nodo, el nodo utiliza el protocolo de resolución de direcciones (ARP) para que se pueda acceder a él desde el TOR.

El TOR se empareja con la red del cliente mediante BGP y anuncia el intervalo de entrada del clúster (prefijo agregado proporcionado por el cliente) a la red del cliente. Cuando el rack se traslade a una nueva ubicación, podremos anunciar el intervalo de Ingress del clúster a la nueva red del cliente. Cuando la estantería se traslade a una nueva ubicación, debes actualizar manualmente las direcciones IP de las interfaces TOR que se conectan a la red del cliente y actualizar la información de peering de BGP para añadir los nuevos peers de BGP.

Todas las IPs que usa el clúster se asignan desde el rackexternalCidrBlock o se codifican de forma rígida (en el caso de las IPs internas del clúster). En el siguiente diagrama, el ejemplo de externalCidrBlock es 10.0.0.0/24:

Intervalos de IP de clúster

Hay varios intervalos de IP que deben configurarse en un clúster de hardware desnudo.

• CIDR de los pods: el intervalo de IPs que se usa para asignar IPs a los pods del clúster. Este intervalo usa el modo de isla, por lo que la red física (ToR) no necesita conocer el CIDR del pod. El único requisito es que el intervalo no se solape con ningún servicio al que necesiten acceder los pods del clúster. El CIDR de los pods no se puede cambiar una vez creado el clúster.
• CIDR de servicio: se usa para los servicios de clúster internos y tiene el mismo requisito que el CIDR de pod.
• CIDR de nodo: direcciones IP de los nodos del clúster de Kubernetes. Estas direcciones tampoco se pueden cambiar una vez creado el clúster.
• Intervalo de entrada: intervalo de direcciones IP que se usa para cualquier servicio del clúster que se exponga externamente. Los clientes externos usan estas IPs para acceder a los servicios del clúster. Este intervalo debe anunciarse en la red del cliente para que los clientes puedan acceder a las IPs de entrada.
• IP virtual del plano de control: el clúster la anuncia para acceder a la api-server de Kubernetes (similar a las IPs virtuales de Ingress). Esta VIP debe pertenecer a la misma subred que el nodo cuando el clúster esté en modo de balanceo de carga de capa 2.

Los CIDR de los pods y los servicios de los clústeres están codificados. El CIDR de los pods es 192.168.0.0/16 y el CIDR de los servicios es 10.96.0.0/12. El clúster usa los mismos dos CIDRs, ya que estas IPs no se exponen fuera del clúster.

Los nodos se aprovisionan con direcciones IP del externalCidrBlock definido en el cell.yaml de GDC. El cliente proporciona estas direcciones IP antes de que se aprovisione el rack.

El intervalo de Ingress y la IP virtual del plano de control del clúster también se asignan desde externalCidrBlock. El TOR debe anunciar el externalCidrBlock a la red del cliente para que los clientes que no estén en el rack puedan acceder a estas IPs virtuales.