Tipos de equilibradores de carga

En la tabla siguiente se describen las características básicas de cada opción de equilibrio de carga.

Application Load Balancer for VPC

Configure un equilibrador de carga de aplicación para VPC (VPC NLB) multizona de capa 7 para que sirva como punto de entrada externo para las solicitudes de entrada a una app del clúster. Tenga en cuenta los siguientes puntos a la hora de planificar la configuración de su VPC ALB.

No confunda el equilibrador de carga de aplicaciones para VPC con los equilibradores de carga de Ingress de Red Hat OpenShift on IBM Cloud. Los equilibradores de carga de aplicación de VPC (VPC NLB) se ejecutan fuera del clúster en la VPC y los servicios LoadBalancer de Kubernetes que cree los configuran. Los equilibradores de carga de aplicaciones (ALB) de Ingress son controladores Ingress que se ejecutan en nodos trabajadores del clúster.

• Los nombres VPC ALB tienen un formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Para ver el ID de clúster, ejecute ibmcloud oc cluster get --cluster <cluster_name>. Para ver el UID del servicio LoadBalancer de Kubernetes, ejecute oc get svc myloadbalancer -o yaml y busque el campo metadata.uid en la salida. Se eliminan los guiones (-) del UID del servicio Kubernetes LoadBalancer en el nombre del ALB de la VPC.

• De forma predeterminada, cuando se crea un servicio LoadBalancer de Kubernetes para una app del clúster, se crea un equilibrador de carga de aplicación para VPC en la VPC fuera del clúster. El VPC ALB direcciona las solicitudes para la app a través de los NodePorts privados que se abren automáticamente en los nodos trabajadores.

• Si crea un servicio público LoadBalancer de Kubernetes, acceder a la aplicación desde Internet a través del nombre de host asignado por el ALB de VPC al servicio LoadBalancer de Kubernetes con el formato 1234abcd-<region>.lb.appdomain.cloud. Aunque los nodos trabajadores solo están conectados a una subred de VPC privada, el VPC ALB puede recibir y direccionar las solicitudes públicas al servicio que expone la app. Tenga en cuenta que no es necesaria ninguna pasarela pública en la subred de VPC para permitir las solicitudes públicas a su VPC ALB. Sin embargo, si la app debe acceder a un URL público, debe conectar pasarelas públicas a las subredes de VPC a las que están conectados los nodos trabajadores.

• Si crea un servicio ** de Kubernetes **privadoLoadBalancer, la app solo resulta accesible para los sistemas que están conectados a las subredes privadas dentro de la misma región y VPC. Si está conectado a la red privada de VPC, puede acceder a su aplicación a través del nombre de host asignado por el ALB de VPC al servicio LoadBalancer de Kubernetes con el formato 1234abcd-<region>.lb.appdomain.cloud.

• Puede utilizar un ALB de VPC existente en un clúster diferente cambiando el nombre del ALB de VPC.

El diagrama siguiente muestra cómo un usuario accede a una app desde internet a través del VPC ALB.

1. Una solicitud a la aplicación utiliza el nombre de host que el ALB de VPC ha asignado al servicio LoadBalancer de Kubernetes, como por ejemplo 1234abcd-<region>.lb.appdomain.cloud.
2. El VPC ALB reenvía la solicitud automáticamente a uno de los puertos de nodo del nodo trabajador y luego a la dirección IP privada del pod de la app.
3. Si se despliegan varias instancias de la app en varios nodos trabajadores del clúster, el equilibrador de carga direcciona las solicitudes entre los pods de la app en diversos nodos trabajadores. Además, si tiene un clúster multizona, el VPC ALB direcciona las solicitudes a los nodos trabajadores de todas las subredes y zonas del clúster.

Equilibrador de carga de red para VPC

En los clústeres VPC, configure un layer-4 Network Load Balancer for VPC (VPC NLB) en cada zona de su clúster para que sirva como punto de entrada externo para las solicitudes entrantes a una aplicación.

Los VPC NLB proporcionan varias ventajas, como proporcionar un rendimiento más alto y un mejor rendimiento mediante el retorno directo de servidor (DSR - Direct Server Return). Con DSR, el nodo trabajador puede enviar paquetes de respuesta de app directamente a la dirección IP del cliente y omitir el VPC NLB, disminuyendo la cantidad de tráfico que el VPC NLB debe manejar. Además, puede configurar el NLB de la VPC para que incluya la preservación de la dirección IP de origen en todas las solicitudes de clientes incluyendo el externalTrafficPolicy: Local especificación.

• Los nombres NLB de VPC estándar tienen un formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Para ver el ID de clúster, ejecute ibmcloud oc cluster get --cluster <cluster_name>. Para ver el UID del servicio LoadBalancer de Kubernetes, ejecute oc get svc myloadbalancer -o yaml y busque el campo metadata.uid en la salida. Se eliminan los guiones (-) del UID del servicio Kubernetes LoadBalancer en el nombre NLB de la VPC.

• Al crear un servicio LoadBalancer de Kubernetes para una app en el clúster e incluir la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb", se crea un VPC NLB en la VPC fuera del clúster. El VPC NLB direcciona las solicitudes para la app a través de los NodePorts privados que se abren automáticamente en los nodos trabajadores.

• Si crea un servicio ** de Kubernetes **públicoLoadBalancer, puede acceder a la app desde internet a través de una dirección IP pública externa que asigna el VPC NLB al servicio LoadBalancer de Kubernetes. Aunque los nodos trabajadores solo están conectados a una subred de VPC privada, el VPC NLB puede recibir y direccionar las solicitudes públicas al servicio que expone la app. Tenga en cuenta que no es necesaria ninguna pasarela pública en la subred de VPC para permitir las solicitudes públicas a su VPC NLB. Sin embargo, si la app debe acceder a un URL público, debe conectar pasarelas públicas a las subredes de VPC a las que están conectados los nodos trabajadores.

• Si crea un servicio ** de Kubernetes **privadoLoadBalancer, la app solo resulta accesible para los sistemas que están conectados a las subredes privadas dentro de la misma región y VPC. Si está conectado a la red de VPC privada, puede acceder a la app a través de la dirección IP privada externa que se asigna mediante el NLB de VPC al servicio LoadBalancer de Kubernetes.

El diagrama siguiente muestra cómo un usuario accede a una app desde internet a través del VPC NLB.

1. Una solicitud enviada a la app utiliza la dirección IP externa que el VPC NLB asigna al servicio LoadBalancer de Kubernetes.
2. El VPC NLB reenvía la solicitud automáticamente a uno de los puertos de nodo del nodo trabajador y luego a la dirección IP privada del pod de la app.
3. Si las instancias de aplicación se despliegan en varios nodos trabajadores del clúster, el NLB de la VPC enruta las solicitudes entre los pods de aplicación en varios nodos trabajadores a través de todas las zonas del clúster.

Limitaciones

Revise los siguientes valores predeterminados y limitaciones.

• Revise las limitaciones conocidas para los VPC ALB y las limitaciones conocidas para los VPC NLB.
• Los ALB de VPC privados no aceptan todo el tráfico, sólo el tráfico de RFC 1918.
• Los NLB de VPC privados se deben crear en una subred de VPC dedicada que debe existir en la misma VPC y ubicación que el clúster, pero la subred no se puede conectar al clúster ni a ningún nodo de trabajador.
• Red Hat OpenShift: Aunque el protocolo Kubernetes SCTP está disponible de forma general en la versión de la comunidad Kubernetes, la creación de equilibradores de carga que utilicen este protocolo no es compatible con los clústeres IBM Cloud Kubernetes Service.
• Se crea un equilibrador de carga de VPC para cada servicio LoadBalancer de Kubernetes que se crea, y solo direcciona las solicitudes a dicho servicio LoadBalancer de Kubernetes. En todos los clústeres de VPC de la VPC se pueden crear un máximo de 50 equilibradores de carga de VPC. Para obtener más información, consulte la documentación de cuotas de VPC.
• El balanceador de carga de la VPC puede enrutar peticiones a un número limitado de nodos trabajadores. El número máximo de nodos a los que puedes dirigir peticiones depende de cómo establezcas la anotación externalTrafficPolicy.
  • Si establece externalTrafficPolicy: Cluster en la configuración del equilibrador de carga:
    • El balanceador de carga de la VPC enruta a los primeros 8 nodos trabajadores que se descubren en cada zona. Para un cluster con nodos trabajadores en tres zonas, esto resulta en que el balanceador de carga enruta a 24 nodos trabajadores en total. Para un clúster de una sola zona, el equilibrador de carga enruta a 8 nodos trabajadores en total. Puede cambiar el número de nodos de trabajador por zona a los que se dirige el equilibrador de carga con service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota, pero el número total en todas las zonas no puede ser superior a 50. Si el clúster tiene menos de 50 nodos trabajadores en todas las zonas, especifique 0 para enrutar a todos los nodos trabajadores de una zona. El kube-proxy configura las tablas IP para enrutar el tráfico entrante desde el nodo trabajador al pod de aplicación en cualquier nodo en el que resida el pod de aplicación.
  • Si establece externalTrafficPolicy: Local en la configuración del equilibrador de carga, el equilibrador de carga de la VPC se crea solo si hay 50 nodos de trabajador o menos en el clúster. Este límite está establecido por las limitaciones de cuota de la VPC de 50 miembros de pool por pool de equilibrador de carga de VPC. Para evitar esta limitación, utilice la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector para limitar qué nodos de trabajador están en el grupo del equilibrador de carga. Por ejemplo, puede utilizar esta anotación para forzar el tráfico entrante a un grupo de trabajadores específico. Si utiliza esta anotación para forzar el tráfico a un pool de trabajadores específico, también debe asegurarse de que el pod de aplicación también se ejecuta en el mismo pool de trabajadores.
• Si define el archivo YAML de configuración para el servicio LoadBalancer de Kubernetes, no se da soporte a las siguientes anotaciones y valores:
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
  • spec.loadBalancerIP
  • spec.loadBalancerSourceRanges
  • Solo VPC NLB: service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
  • Solo VPC ALB: el valor externalTrafficPolicy: Local recibe soporte, pero el valor no conserva la IP de origen de la solicitud.
• Al eliminar un clúster de VPC, también se eliminan automáticamente los equilibradores de carga de VPC no persistentes, que se nombran con el formato kube-<cluster_ID>-<kubernetes_lb_service_UID> y son creados automáticamente por Red Hat OpenShift on IBM Cloud para los servicios Kubernetes LoadBalancer de ese clúster. Sin embargo, los balanceadores de carga persistentes con nombres únicos y los balanceadores de carga de VPC que creó manualmente en su VPC no se eliminan.
• Puede registrar un máximo de 128 subdominios para los nombres de host del equilibrador de carga de VPC. Este límite se puede aumentar a petición abriendo un caso de soporte.
• Los subdominios que registre para los balanceadores de carga VPC están limitados a 130 caracteres o menos.
• Los ALB de VPC escuchan en las mismas subredes de VPC en las que están asignados los nodos de trabajador del clúster, a menos que el servicio de equilibrador de carga Kubernetes se cree con las anotaciones service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets o service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, que limitan el tráfico a nodos específicos.
  • Las subredes y zonas del ALB de la VPC pueden actualizarse o modificarse una vez creado el ALB. Si añade más zonas al clúster o actualiza el servicio de equilibrador de carga Kubernetes con las anotaciones service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets o service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, el ALB de la VPC se actualiza para escuchar en las nuevas subredes.
• Los NLB de VPC sólo escuchan en una única subred de VPC en una única zona. No pueden configurarse para escuchar en múltiples subredes VPC o para escuchar en múltiples zonas. Puede especificar la subred única para que un NLB escuche con las anotaciones service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets o service.kubernetes.io/ibm-load-balancer-cloud-provider-zone.
  • Los NLB de VPC reenvían el tráfico entrante a todos los nodos trabajadores del clúster a menos que restrinja el tráfico entrante a nodos trabajadores específicos con el service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector o service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotations. Para limitar el tráfico a una zona específica, puede utilizar estas anotaciones para especificar nodos trabajadores en esa zona.
• La inhabilitación de la asignación de NodePort del equilibrador de carga no está soportada para los equilibradores de carga de VPC.
• Los NLB de VPC pueden configurarse tanto con UDP como con TCP en el mismo LB de VPC, pero el puerto de escucha debe ser diferente.