En este documento, se describen la implementación, el clúster y la arquitectura de red del dispositivo aislado de Google Distributed Cloud (GDC).
Arquitectura de implementación
En el siguiente diagrama, se ilustra cómo el hardware del dispositivo se ajusta dentro de una red del cliente que incluye componentes opcionales, como HSM, un servidor NTP y clientes adicionales dentro de la red. El dispositivo está equipado con un plano de administración, un plano de datos, servidores y un servidor habilitado para 1 GPU, todos diseñados para ejecutar cargas de trabajo directamente en el borde.
Arquitectura del clúster
El dispositivo aislado de GDC opera un solo clúster que abarca los tres nodos de hardware, conocido como clúster de infraestructura de la organización. Un servidor de la API de administración dedicado, que se ejecuta como cargas de trabajo de pods en el clúster, aloja las APIs del plano de administración. En este clúster, se pueden ejecutar cargas de trabajo del usuario, que incluyen tanto VMs como Pods de Kubernetes. No hay clúster de usuario en este modelo de clúster.
Arquitectura de la red
El EL8000 incluye una placa posterior que crea cuatro redes independientes de capa 2 (L2) dentro del dispositivo:
- Consola integrada Lights-Out (iLO) (1 GbE)
- Red de administración (1 GbE)
- Red de datos A (10GbEth)
- Red de datos B (10 GbE)
En el siguiente diagrama, se muestra cómo las redes de capa 2 se conectan al conmutador Mellanox (https://www.hpe.com/psnow/doc/a00043975enw.html?jumpid=in_pdp-psnow-qs). Cada red de una blade se conecta a un solo conmutador de red. Todas las redes de la consola de iLO en cada blade del servidor se conectan al conmutador de red 1. Las redes de administració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 al CIDR de entrada. El CIDR de entrada está disponible para los servicios, y el rango se anuncia a través del Protocolo de puerta de enlace fronteriza (BGP) a la red del cliente.
Los puertos de red de administración (16 y 18) tienen acceso a la administración del sistema (VLAN 501) para que los clientes puedan 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 opera en modo de un solo arrendatario. El clúster híbrido, al que nos referimos como clúster de infraestructura, consta de los clústeres del sistema y de administrador combinados:
El diseño físico se centra en un Mellanox SN2010 que actúa como puerta de enlace entre el clúster de infraestructura del dispositivo y la red externa del cliente.
El clúster de infraestructura consta de 3 nodos de Bare Metal (BM). Las conexiones en las cuentas de BM se pueden categorizar de la siguiente manera:
- Conectividad de red de datos (subred 198.18.2.0/24) a través de la VLAN 100
La BM tiene una NIC con 2 puertos,
NIC0P1yNIC0P2, que están vinculados y conectados al conmutador TOR.BM1yBM2se conectan directamente al conmutador, mientras queBM3se conecta al TOR a través de un conmutador no administrado. - La conectividad de la red de administración ( subred 198.18..0/24) se realiza a través de la VLAN 501. Las interfaces ILO y MGMT se conectan a través de esta VLAN con interfaces de 1 G. Las interfaces de ILO y las interfaces de MGMT en los nodos de BM se conectan al conmutador a través de conmutadores no administrados.
- Tal vez: Agrega redes de OTS en las VLAN 200 a 203(?), subred 198.18.1.x
La conexión del conmutador Mellanox al router del cliente proporciona conectividad externa. Para esta conectividad, se usan interfaces de 10 G, y el protocolo BGP se usa 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 de Appliance.
Red lógica
Hay dos redes de área local virtuales (VLAN) que separan el tráfico diverso:
- VLAN 100: Clúster (direcciones IP virtuales de entrada (VIP), IPs de clúster o nodo) con subred IPv4 proporcionada por los clientes.
- VLAN 501: Administración (iLO, Mgmt) con subred IPv4 proporcionada por el cliente.
Topología de red superior
El clúster se configura con el balanceo de cargas de capa 2 (L2). Las VIP de Ingress para el clúster provienen de la misma subred que los nodos. Cuando se asigna una VIP de Ingress a un nodo, este usa el Protocolo de resolución de direcciones (ARP) para que se pueda acceder a él desde el TOR.
Los pares del TOR se conectan con la red del cliente a través de BGP y anuncian el rango de entrada del clúster (prefijo agregado proporcionado por el cliente) a la red del cliente. Cuando el rack se mueve a una nueva ubicación, podemos anunciar el rango de entrada del clúster a la nueva red del cliente. Cuando el rack se traslada a una nueva ubicación, debes actualizar manualmente las direcciones IP en las interfaces TOR que se conectan a la red del cliente y actualizar la información de intercambio de tráfico de BGP para agregar los nuevos pares de BGP.
Todas las IPs que usa el clúster se asignan desde el externalCidrBlock del rack o se codifican de forma rígida (para las IPs internas del clúster). En el siguiente diagrama, el ejemplo de externalCidrBlock es 10.0.0.0/24:
Rangos de IP del clúster
Hay varios rangos de IP que se deben configurar en un clúster de equipos físicos.
- CIDR del Pod: Es el rango de IP que se usa para asignar IPs a los Pods del clúster. Este rango usa el modo isla, por lo que la red física (ToR) no necesita conocer el CIDR del Pod. El único requisito es que el rango no se superponga con ningún servicio al que deban acceder los Pods del clúster. El CIDR del pod no se puede cambiar después de crear el clúster.
- CIDR de servicio: Se usa para los servicios internos del clúster con el mismo requisito que el CIDR del Pod.
- CIDR del nodo: Direcciones IP de los nodos del clúster de Kubernetes. Estas direcciones tampoco pueden cambiar después de que se crea el clúster.
- Rango de entrada: Es un rango de direcciones IP que se usa para cualquier servicio del clúster que se expone de forma externa. Los clientes externos usan estas IPs para acceder a los servicios dentro del clúster. Este rango debe anunciarse a la red del cliente para que los clientes puedan acceder a las IPs de Ingress.
- VIP del plano de control: El clúster la anuncia para acceder a
api-serverde Kubernetes (similar a las VIP de Ingress). Esta VIP debe provenir de la misma subred que el nodo cuando el clúster está en modo de balanceo de cargas L2.
Los CIDR de Pod y de Service para los clústeres están codificados de forma rígida.
El CIDR del Pod es 192.168.0.0/16 y el CIDR del Service es 10.96.0.0/12. El clúster usa los mismos dos CIDR, ya que estas IPs no se exponen fuera del clúster.
Los nodos se aprovisionan con direcciones IP del conjunto externalCidrBlock establecido en el cell.yaml de GDC. El cliente proporciona estas direcciones IP antes de que se aprovisione el rack.
El rango de Ingress y la VIP del plano de control para el clúster también se asignan desde externalCidrBlock. El TOR debe anunciar el externalCidrBlock a la red del cliente para que los VIP sean accesibles para los clientes fuera del rack.