Clásico: Acerca de los equilibradores de carga de red (NLBs)

Los equilibradores de carga de red solo se pueden crear en clústeres clásicos. Para equilibrar la carga en clústeres de VPC, consulte Exposición de apps con equilibradores de carga para VPC.

Cuando se crea un clúster estándar, Red Hat® OpenShift® on IBM Cloud® suministra automáticamente una subred pública portátil y una subred privada portátil.

  • La subred pública portátil proporciona 5 direcciones IP que se pueden utilizar. El ALB de Ingress público predeterminado utiliza 1 dirección IP pública portátil. Las 4 direcciones IP públicas portables restantes se pueden utilizar para exponer apps individuales en Internet mediante la creación de servicios de equilibrador de carga de red, o NLB, público.
  • La subred privada portátil proporciona 5 direcciones IP utilizables. El ALB de entrada privado predeterminado utiliza 1 dirección IP privada portátil. Las 4 direcciones IP privadas portátiles restantes se pueden utilizar para exponer apps individuales en una red privada mediante la creación de servicios de equilibrador de carga, o NLB, privado.

Para conseguir que se pueda acceder a una app tanto a través de una dirección IP privada portátil como a través de una pública portátil, debe crear un NLB público y un NLB privado. Las direcciones IP públicas y privadas portátiles son IP flotantes estáticas y no cambian cuando se elimina un nodo de trabajador. Si se elimina el nodo de trabajo en el que se encuentra la dirección IP de NLB, un demonio de mantenimiento que supervisa constantemente la IP mueve automáticamente la IP a otro nodo de trabajo. Puede asignar cualquier puerto al NLB. El NLB sirve como punto de entrada externo para las solicitudes entrantes para la app. Para acceder al NLB desde Internet, puede utilizar la dirección IP pública del NLB y el puerto asignado con el formato <IP_address>:<port>. También puede crear entradas de DNS para los NLB registrando las direcciones IP de NLB con subdominios.

Al exponer una app con un servicio de NLB, la app pasa también a estar disponible automáticamente a través de los NodePorts del servicio. Los NodePorts son accesibles en cada dirección IP pública y privada de cada nodo trabajador dentro del clúster. Para bloquear el tráfico a los NodePorts mientras utiliza un NLB, consulte Control del tráfico de entrada a los servicios de equilibrador de carga de red (NLB) o de NodePort.

Aunque el protocolo SCTP de Kubernetes está disponible de forma general en el release de la comunidad Kubernetes, la creación de equilibradores de carga que utilizan este protocolo no está soportada en los clústeres IBM Cloud Kubernetes Service.

Comparación entre el equilibrio de carga básico y DSR en los NLB de la versión 1.0 y 2.0

Cuando crea un NLB, puede elegir un NLB de la versión 1.0, que realiza un equilibrio de carga básico, o un NLB de la versión 2.0, que realiza un equilibrio de carga DSR (retorno directo al servidor).

¿En qué se parecen las versiones 1.0 y 2.0 NLBs?
Los NLB de las versiones 1.0 y 2.0 son los dos equilibradores de carga de capa 4 que existen únicamente en el espacio del kernel de Linux. Ambas versiones se ejecutan dentro del clúster y utilizan recursos de nodos trabajadores. Por lo tanto, la capacidad disponible de los NLB siempre está dedicada a su clúster. Además, ninguna de las versiones de NLB termina la conexión. En su lugar, reenvían las conexiones a un pod de app.
¿En qué se diferencian las versiones 1.0 y 2.0 NLBs?
Cuando un cliente envía una solicitud a la app, el NLB direcciona los paquetes de solicitud a la dirección IP del nodo trabajador donde existe un pod de app. Los NLB de la versión 1.0 utilizan NAT (conversión de direcciones de red) para reescribir la dirección IP de origen del paquete de solicitud a la IP del nodo trabajador donde existe un pod de equilibrador de carga. Cuando el nodo trabajador devuelve el paquete de respuesta de app, utiliza dicha IP del nodo trabajador donde existe el NLB. A continuación, el NLB debe enviar el paquete de respuesta al cliente. Para evitar que se reescriba la dirección IP, puede habilitar la conservación de IP de origen. No obstante, la conservación de IP de origen requiere que los pods de equilibrador de carga y los pods de app se ejecuten en el mismo trabajador para que la solicitud no tenga que reenviarse a otro trabajador. Debe añadir tolerancias y afinidad de nodos a los pods de app. Para obtener más información sobre el equilibrio de carga básico con los NLB de la versión 1.0, consulte Componentes y arquitectura de un NLB 1.0.

A diferencia de los NLB de la versión 1.0, los NLB de la versión 2.0 no utilizan NAT al reenviar solicitudes a pods de app en otros trabajadores. Cuando un NLB 2.0 direcciona una solicitud de cliente, utiliza IP sobre IP (IPIP) para encapsular el paquete de solicitud original en otro paquete. Este paquete IPIP de encapsulado tiene una IP de origen del nodo trabajador donde se encuentra el pod de equilibrador de carga, lo que permite que el paquete de solicitud original pueda conservar la IP de cliente como su dirección IP de origen. A continuación, el nodo trabajador utiliza el retorno directo de servidor (DSR) para enviar el paquete de respuesta de la app a la IP de cliente. El paquete de respuesta se salta el NLB y se envía directamente al cliente, disminuyendo la cantidad de tráfico que debe gestionar el NLB. Para obtener más información sobre el equilibrio de carga de DSR con los NLB de la versión 2.0, consulte Componentes y arquitectura de un NLB 2.0.

Componentes y arquitectura de un NLB 1.0

El equilibrador de carga de red (NLB) 1.0 de TCP/UDP utiliza Iptables, una característica del kernel de Linux, para equilibrar la carga de las solicitudes en los pods de una app.

Flujo del tráfico en un clúster de una sola zona

En el siguiente diagrama se muestra cómo un NLB 1.0 dirige la comunicación procedente de Internet a una app en un clúster de una sola zona.

Exponer una aplicación en un clúster de zona única mediante un NLB ( 1.0 ).
Expose an app in a single-zone cluster by using an NLB 1.0

  1. Una solicitud enviada a la app utiliza la dirección IP pública del NLB y el puerto asignado en el nodo trabajador. Tenga en cuenta que si crea un subdominio de DNS para su NLB, los usuarios pueden acceder a la app a través del subdominio del NLB en su lugar. Un servicio del sistema DNS resuelve el subdominio en la dirección IP pública portátil del NLB.

  2. El NLB recibe la solicitud y la reenvía a la dirección IP privada del pod de la app a través de la red privada. La dirección IP de origen del paquete de la solicitud se cambia por la dirección IP pública del nodo trabajador en el que se ejecuta el pod del NLB. Si se despliegan varias instancias de app en el clúster, el NLB direcciona las solicitudes entre los pods de app.

  3. Cuando la app devuelve un paquete de respuesta, utiliza la dirección IP del nodo trabajador donde está el NLB que ha reenviado la solicitud de cliente. Luego el NLB envía el paquete de respuesta al cliente.

Flujo del tráfico en un clúster multizona

En el siguiente diagrama se muestra cómo un equilibrador de carga de red (NLB) 1.0 dirige la comunicación procedente de Internet a una app en un clúster multizona.

Use an NLB 1.0 to load balance apps in a multizone cluster
Use an NLB 1.0 to load balance apps in a multizone cluster

  1. Una solicitud a la app utiliza el subdominio DNS para sus NLB. También puede acceder al NLB en cada zona utilizando su dirección IP pública y puerto en el nodo trabajador. Tenga en cuenta que, de forma predeterminada, cada NLB 1.0 se configura solo en una zona. Para conseguir una alta disponibilidad, debe desplegar un NLB 1.0 en cada una de las zonas donde tenga instancias de la app.

  2. Un servicio del sistema DNS resuelve el subdominio en la dirección IP pública portátil de uno de los NLB y su puerto asignado en el nodo trabajador. Los NLB de las distintas zonas gestionan las solicitudes en un ciclo en rueda.

  3. El NLB recibe la solicitud y la reenvía a la dirección IP privada del pod de la app a través de la red privada. La dirección IP de origen del paquete de la solicitud se cambia por la dirección IP pública del nodo trabajador en el que se ejecuta el pod del NLB. Cada NLB direcciona las solicitudes a las instancias de la app en su propia zona y a las instancias de la app en otras zonas. Además, si se despliegan varias instancias de la app en una zona, el NLB direcciona las solicitudes entre los pods de la app de la zona.

  4. Cuando la app devuelve un paquete de respuesta, utiliza la dirección IP del nodo trabajador donde está el NLB que ha reenviado la solicitud de cliente. Luego el NLB envía el paquete de respuesta al cliente.

Componentes y arquitectura de un NLB 2.0

El NLB 2.0 es un equilibrador de carga de capa 4 que utiliza el servidor virtual IP (IPVS) del kernel de Linux. El NLB 2.0 admite TCP y UDP, se ejecuta delante de varios nodos trabajadores y utiliza el tunelado de IP sobre IP (IPIP) para distribuir el tráfico que llega a una dirección IP individual del equilibrador de carga en dichos nodos trabajadores.

Flujo del tráfico en un clúster de una sola zona

En el siguiente diagrama se muestra cómo un NLB 2.0 dirige la comunicación procedente de Internet a una app en un clúster de una sola zona.

Exponer una aplicación en Red Hat OpenShift on IBM Cloud utilizando una versión 2.0
una aplicación en Red Hat OpenShift on IBM Cloud utilizando una versión 2.0

  1. Una solicitud de cliente enviada a la app utiliza la dirección IP pública del NLB y el puerto asignado en el nodo trabajador. En este ejemplo, el NLB tiene la dirección IP virtual 169.61.23.130 y se ejecuta en el nodo trabajador que tiene la dirección IP privada 10.73.13.25. Tenga en cuenta que si crea un subdominio de DNS para su NLB, los usuarios pueden acceder a la app a través del subdominio del NLB en su lugar. Un servicio del sistema DNS resuelve el subdominio en la dirección IP pública portátil del NLB.

  2. El NLB encapsula el paquete de solicitud de cliente (etiquetado como "SC" en la imagen) dentro de un paquete IPIP (etiquetado como "IPIP"). El paquete de solicitud de cliente mantiene la IP de cliente como su dirección IP de origen. El paquete de encapsulado IPIP utiliza la IP 10.73.14.25 del nodo trabajador como su dirección IP de origen.

  3. El NLB direcciona el paquete IPIP a un nodo trabajador en el que se encuentre un pod de app y que tiene la dirección IP privada 10.73.13.26. Si se despliegan varias instancias de app en el clúster, el NLB direcciona las solicitudes entre los trabajadores donde se hayan desplegado pods de app.

  4. El trabajador 10.73.14.26 desempaqueta el paquete de encapsulado IPIP y, a continuación, desempaqueta el paquete de solicitud de cliente. El paquete de solicitud de cliente se reenvía al pod de app en ese nodo trabajador.

  5. A continuación, el trabajador 10.73.14.26 utiliza la dirección IP de origen del paquete de solicitud original, la IP de cliente, para devolver el paquete de respuesta del pod de app directamente al cliente.

Flujo del tráfico en un clúster multizona

El diagrama siguiente muestra cómo los NLB versión 2.0 de cada zona dirigen el tráfico de Internet a una app en un clúster multizona.

Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0
Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0

  1. Una solicitud a la app utiliza el subdominio DNS para sus NLB. También puede acceder al NLB en cada zona utilizando su dirección IP pública y puerto en el nodo trabajador. Tenga en cuenta que, de forma predeterminada, cada NLB 2.0 se configura solo en una zona. Para conseguir una alta disponibilidad, debe desplegar un NLB 2.0 en cada una de las zonas donde tenga instancias de la app.

  2. Un servicio del sistema DNS resuelve el subdominio en la dirección IP pública portátil de uno de los NLB y su puerto asignado en el nodo trabajador. En este ejemplo, el NLB tiene la dirección IP virtual 169.61.23.130 y se ejecuta en el nodo trabajador que tiene la dirección IP privada 10.73.13.25. Los NLB de las distintas zonas gestionan las solicitudes en un ciclo en rueda.

  3. El NLB encapsula el paquete de solicitud de cliente (etiquetado como "SC" en la imagen) dentro de un paquete IPIP (etiquetado como "IPIP"). El paquete de solicitud de cliente mantiene la IP de cliente como su dirección IP de origen. El paquete de encapsulado IPIP utiliza la IP 10.73.14.25 del trabajador como su dirección IP de origen.

  4. El NLB direcciona el paquete IPIP a un nodo trabajador en el que se encuentre un pod de app y que tiene la dirección IP privada 10.73.13.26. Tenga en cuenta que cada NLB direcciona las solicitudes a las instancias de la app en su propia zona y a las instancias de la app en otras zonas. Además, si se despliegan varias instancias de la app en una zona, el NLB direcciona las solicitudes entre los pods de la app de la zona.

  5. El trabajador 10.73.14.26 desempaqueta el paquete de encapsulado IPIP y, a continuación, desempaqueta el paquete de solicitud de cliente. El paquete de solicitud de cliente se reenvía al pod de app en ese nodo trabajador.

  6. A continuación, el trabajador 10.73.14.26 utiliza la dirección IP de origen del paquete de solicitud original, la IP de cliente, para devolver el paquete de respuesta del pod de app directamente al cliente.