Topologías para implementar el equilibrador de carga de HAProxy

Al usar vSphere with Tanzu con redes de vDS, HAProxy brinda equilibrio de carga para desarrolladores que acceden al plano de control de Tanzu Kubernetes y para los servicios de Kubernetes del tipo equilibrador de carga. Revise las topologías posibles que puede implementar para el equilibrador de carga de HAProxy.

Redes de carga de trabajo en el clúster supervisor

Para configurar una instancia de clúster supervisor con la pila de redes de vSphere, debe conectar todos los hosts del clúster a una instancia de vSphere Distributed Switch. En función de la topología que implemente para las redes de carga de trabajo de clúster supervisor, cree uno o varios grupos de puertos distribuidos. Los grupos de puertos se designan como redes de cargas de trabajo para los espacios de nombres de vSphere.

Antes de agregar un host a un clúster supervisor, debe agregarlo a todas las instancias de vSphere Distributed Switch que formen parte del clúster.

Las redes de cargas de trabajo proporcionan conectividad a los nodos de los clústeres de Tanzu Kubernetes y a las máquinas virtuales del plano de control de clúster supervisor. La red de cargas de trabajo que proporciona conectividad a las máquinas virtuales del plano de control de Kubernetes se denomina red de carga de trabajo principal. Cada clúster supervisor debe tener una red de cargas de trabajo principal. Debe designar uno de los grupos de puertos distribuidos como la red de cargas de trabajo principal para clúster supervisor.

Nota: Las redes de carga de trabajo solo se agregan cuando habilita el clúster supervisor y no se pueden agregar más adelante.

Las máquinas virtuales del plano de control de Kubernetes en clúster supervisor usan tres direcciones IP del rango de direcciones IP que se asigna a la red de cargas de trabajo principal. Cada nodo de un clúster de Tanzu Kubernetes tiene una dirección IP independiente asignada desde el rango de direcciones de la red de cargas de trabajo que está configurada con el espacio de nombres en el que se ejecuta el clúster de Tanzu Kubernetes.

Asignación de rangos de direcciones IP

Cuando planifique la topología de red de clúster supervisor con el equilibrador de carga de HA Proxy, planee tener dos tipos de rangos de direcciones IP:

• Un rango para asignar direcciones IP virtuales para HAProxy. El rango de IP que se configura para los servidores virtuales de HAProxy está reservado por el dispositivo del equilibrador de carga. Por ejemplo, si el rango de direcciones IP virtuales es 192.168.1.0/24, no se podría acceder a todos los hosts de ese rango para otro tráfico que no sea el tráfico de IP virtual.
  Nota: No debe configurar una puerta de enlace dentro del rango de direcciones IP virtuales de HAProxy, ya que se podrían generar errores en todas las rutas a esa puerta de enlace.
• Un rango de direcciones IP para los nodos de clúster supervisor y los clústeres de Tanzu Kubernetes. Cada máquina virtual del plano de control de Kubernetes en clúster supervisor tiene asignada una dirección IP, lo que supone un total de tres direcciones IP. Cada nodo de un clúster de Tanzu Kubernetes también tiene asignada una dirección IP independiente. Debe asignar un rango de direcciones IP único a cada red de cargas de trabajo en el clúster supervisor que configure en un espacio de nombres.

Ejemplo de una configuración con una red de /24:

• Red: 192.168.120.0/24
• VIP de HAProxy: 192.168.120.128/25
• 1 dirección IP para la interfaz de carga de trabajo de HAProxy: 192.168.120.5

En función de las direcciones IP que estén libres en las primeras 128 direcciones, puede definir rangos de IP para las redes de cargas de trabajo en clúster supervisor, por ejemplo:

• 192.168.120.31-192.168.120.40 para la red de cargas de trabajo principal
• 192.168.120.51-192.168.120.60 para otra red de cargas de trabajo

Nota: Los rangos que defina para las redes de cargas de trabajo no deben superponerse con el rango de VIP de HAProxy.

Topología de red de HAProxy

Existen dos opciones de configuración de red para implementar HAProxy: Predeterminada y Front-end. La red predeterminada tiene 2 NIC: una para la red de administración y otra para la red de cargas de trabajo. La red de front-end tiene 3 NIC: red de administración, red de cargas de trabajo y red de front-end para los clientes. En la tabla se enumeran y describen las características de cada red.

En el caso de las instalaciones de producción, se recomienda implementar el equilibrador de carga de HAProxy con la configuración de Red de front-end. Si implementa el equilibrador de carga de HAProxy con la configuración Predeterminada, se recomienda asignar un tamaño de bloque de direcciones IP de /24 a la red de cargas de trabajo. Para ambas opciones de configuración, no se recomienda utilizar DHCP.

Red	Características
Administración	El clúster supervisor utiliza la red de administración para conectarse al equilibrador de carga de HAProxy y programarlo. El endpoint de la API del plano de datos de HAProxy está enlazado a la interfaz de red conectada a la red de administración. La dirección IP de administración asignada a la máquina virtual del plano de control de HAProxy debe ser una dirección IP estática en la red de administración, de modo que el clúster supervisor pueda conectarse con confianza a la API del equilibrador de carga. La puerta de enlace predeterminada de la máquina virtual de HAProxy debe estar en esta red. Las consultas de DNS deben realizarse en esta red.
Carga de trabajo	La máquina virtual del plano de control de HAProxy utiliza la red de cargas de trabajo para acceder a los servicios de los nodos del clúster supervisor y del clúster de Tanzu Kubernetes. La máquina virtual del plano de control de HAProxy reenvía el tráfico a los nodos del clúster supervisor y del clúster de Tanzu Kubernetes en esta red. Si la máquina virtual del plano de control de HAProxy se implementa en el modo predeterminado (dos NIC), la red de cargas de trabajo debe proporcionar las redes lógicas que se utilizarán para acceder a los servicios del equilibrador de carga. En la configuración Predeterminada, las direcciones IP virtuales del equilibrador de carga y las direcciones IP del nodo del clúster de Kubernetes proceden de esta red. Se definirán como rangos independientes que no se superponen dentro de la red. Nota: La red de carga de trabajo debe estar en una subred diferente a la red de administración. Consulte los requisitos del sistema.
Front-end (opcional)	Los clientes externos (como usuarios o aplicaciones) que acceden a las cargas de trabajo del clúster usan la red de front-end para acceder a los servicios con carga equilibrada del back-end mediante direcciones IP virtuales. La red de front-end solo se utiliza cuando la máquina virtual del plano de control de HAProxy se implementa con tres NIC. Esta opción se recomienda para instalaciones de producción. La red de front-end es donde muestra la dirección IP virtual (VIP). HAProxy equilibrará y reenviará el tráfico al back-end adecuado.

En el siguiente diagrama se muestra una implementación de HAProxy con una topología de red de front-end. El diagrama indica dónde se espera que estén los campos de configuración durante el proceso de instalación y configuración.

Topología de clúster supervisor con una red de carga de trabajo y HA Proxy con dos NIC virtuales

En esta topología, se configura un clúster supervisor con una red de carga de trabajo para los siguientes componentes:

• Máquinas virtuales de plano de control de Kubernetes
• Los nodos de los clústeres de Tanzu Kubernetes.
• El rango de IP virtuales de HAProxy donde se conectan los servicios externos y los usuarios de desarrollo y operaciones. En esta configuración, HAProxy se implementa con dos NIC virtuales (configuración Predeterminada), una conectada a la red de administración y otra conectada a la red de cargas de trabajo principal. Debe planificar la asignación de direcciones IP virtuales en una subred independiente de la red de cargas de trabajo principal.

Designe un grupo de puertos como red de cargas de trabajo principal para el clúster supervisor y, a continuación, utilice el mismo grupo de puertos como red de cargas de trabajo para los espacios de nombres de vSphere. El clúster supervisor, los clústeres de Tanzu Kubernetes, HAProxy, los usuarios de desarrollo y operaciones y los servicios externos se conectan al mismo grupo de puertos distribuidos que se establece como red de cargas de trabajo principal.

Figura 1. clúster supervisor respaldado por una red

La ruta de tráfico para los usuarios de desarrollo y operaciones o las aplicaciones externas es la siguiente:

1. El usuario de desarrollo y operaciones o el servicio externo envían tráfico a una dirección IP virtual en la subred de red de cargas de trabajo del grupo de puertos distribuidos.
2. HAProxy equilibra la carga del tráfico de IP virtual con la dirección IP del nodo de Tanzu Kubernetes o la dirección IP de la máquina virtual del plano de control. HAProxy reclama la dirección IP virtual para que pueda equilibrar la carga del tráfico que entra en esa IP.
3. La máquina virtual del plano de control o el nodo del clúster de Tanzu Kubernetes entrega el tráfico a los pods de destino que se ejecutan dentro del clúster supervisor o el clúster de Tanzu Kubernetes, respectivamente.

Topología de clúster supervisor con una red de carga de trabajo aislada y HA Proxy con dos NIC virtuales

En esta topología, se configuran redes para los siguientes componentes:

• Máquinas virtuales del plano de control de Kubernetes. Una red de cargas de trabajo principal para controlar el tráfico de las máquinas virtuales del plano de control de Kubernetes.
• Nodos del clúster de Tanzu Kubernetes. Una red de cargas de trabajo. que asigna a todos los espacios de nombres del clúster supervisor. Esta red conecta los nodos del clúster de Tanzu Kubernetes.
• IP virtuales de HAProxy. En esta configuración, la máquina virtual de HAProxy se implementa con dos NIC virtuales (configuración Predeterminada). Puede conectar la máquina virtual de HAProxy a la red de cargas de trabajo principal o a la red de cargas de trabajo que utiliza para los espacios de nombres. También puede conectar HAProxy a una red de máquinas virtuales que ya exista en vSphere y que se pueda enrutar a las redes principal y de cargas de trabajo.

El clúster supervisor está conectado al grupo de puertos distribuidos que respalda la red de cargas de trabajo principal y los clústeres de Tanzu Kubernetes están conectados a un grupo de puertos distribuidos que respalda la red de cargas de trabajo. Los dos grupos de puertos deben ser enrutables de capa 3. El aislamiento de la capa 2 se puede implementar a través de las VLAN. El filtrado de tráfico de la capa 3 es posible a través de las puertas de enlace y los firewalls de IP.

Figura 2. clúster supervisor con una red de cargas de trabajo aislada

La ruta de tráfico para el servicio externo o los usuarios de desarrollo y operaciones es la siguiente:

1. El servicio externo o el usuario de desarrollo y operaciones envía tráfico a una dirección IP virtual. El tráfico se enruta a la red donde se conecta HAProxy.
2. HAProxy equilibra la carga del tráfico de IP virtual con la dirección IP del nodo de Tanzu Kubernetes o la máquina virtual del plano de control. HAProxy reclama la dirección IP virtual para que pueda equilibrar la carga del tráfico que entra en esa IP.
3. La máquina virtual del plano de control o el nodo del clúster de Tanzu Kubernetes entrega el tráfico a los pods de destino que se ejecutan dentro del clúster de Tanzu Kubernetes.

Topología de clúster supervisor con una red de carga de trabajo múltiple y HA Proxy con dos NIC virtuales

En esta topología, es posible configurar un grupo de puertos para que actúe como red de cargas de trabajo principal y un grupo de puertos dedicados que sirvan como red de cargas de trabajo para cada espacio de nombres. HAProxy se implementa con dos NIC virtuales (configuración Predeterminada) y puede conectarse a la red de cargas de trabajo principal o a cualquiera de las redes de cargas de trabajo. También puede utilizar una red de máquinas virtuales existente que se pueda enrutar a las redes principal y de cargas de trabajo.

La ruta de tráfico para los servicios externos o los usuarios de desarrollo y operaciones en esta topología es la misma que la de la topología de red de cargas de trabajo aislada.

Figura 3. Instancia de clúster supervisor respaldada por varias redes de cargas de trabajo aisladas

Topología de clúster supervisor con una red de carga de trabajo múltiple y HA Proxy con tres NIC virtuales

En esta configuración, se implementa la máquina virtual de HAProxy con tres NIC virtuales, por lo que HAProxy se conecta a una red de front-end. Los usuarios y los servicios externos de desarrollo y operaciones pueden acceder a HAProxy a través de IPs virtuales en la red front-end. Se recomienda implementar HA Proxy con tres NIC virtuales para entornos de producción.

Figura 4. HAProxy implementado con tres NIC virtuales

Seleccionar entre las posibles topologías

Antes de seleccionar alguna de las posibles topologías, debe evaluar las necesidades de su entorno:

1. ¿Necesita el aislamiento de Capa 2 entre el clúster supervisor y los clústeres de Tanzu Kubernetes?
   1. No: la topología más simple, con una red de cargas de trabajo que atienda a todos los componentes.
   2. Sí: la topología de red de cargas de trabajo aislada con redes principal y de cargas de trabajo independientes.
2. ¿Necesita aún más aislamiento de Capa 2 entre los clústeres de Tanzu Kubernetes?
   1. No: topología de red de cargas de trabajo aislada con redes principal y de cargas de trabajo independientes.
   2. Sí: topología con varias redes de cargas de trabajo con una red de cargas de trabajo independiente para cada espacio de nombres y una red de cargas de trabajo principal dedicada.
3. ¿Desea evitar que los usuarios de desarrollo y operaciones y los servicios externos enruten directamente a las máquinas virtuales del plano de control de Kubernetes y los nodos del clúster de Tanzu Kubernetes?
   1. No: configuración de HAProxy con dos NIC.
   2. Sí: configuración de HAProxy con tres NIC Esta configuración se recomienda para entornos de producción.