Antes de empezar

Cumple los requisitos previos de NLB 2.0 antes de continuar.

• Para crear NLB públicos en varias zonas, al menos una VLAN pública debe tener subredes portátiles disponibles en cada zona. Para crear NLB privados en varias zonas, al menos una VLAN privada debe tener subredes portátiles disponibles en cada zona. Puede añadir subredes siguiendo los pasos que se indican en Configuración de subredes para clústeres.

• Asegúrate de tener el rol de acceso al servicio IAM IBM Cloud de tipo Writer o Manager para el espacio default de nombres.

• Asegúrese de tener el número necesario de nodos trabajadores:

  • Clústeres clásicos: Si restringe el tráfico de red a los nodos trabajadores de extremo, asegúrese de que haya al menos dos nodos trabajadores de extremo habilitados en cada zona para que los NLB se desplieguen de forma uniforme.

• Cuando se vuelven a cargar los nodos de clúster o cuando una actualización maestra de clúster incluye una nueva imagen de keepalived, la IP virtual del equilibrador de carga se mueve a la interfaz de red de un nodo nuevo. Cuando esto ocurre, toda conexión de larga duración a su equilibrador de carga debe restablecerse. Considera la posibilidad de incluir una lógica de reintento en tu aplicación para que los intentos de restablecer la conexión se realicen rápidamente.

Para configurar un NLB 2.0 en un clúster multizona:

1. Despliegue la app en el clúster. Asegúrese de añadir una etiqueta a su despliegue en la sección de metadatos del archivo de configuración. Esta etiqueta personalizada identifica todos los pods en los que se ejecuta la app para incluirlos en el equilibrio de carga.

2. Cree un servicio equilibrador de carga para la app que desea exponer en internet público o en una red privada.

   1. Cree un archivo de configuración de servicio llamado, por ejemplo, myloadbalancer.yaml.
   2. Defina un servicio equilibrador de carga para la app que desee exponer. Puede especificar una zona, una VLAN y una dirección IP.

       apiVersion: v1
       kind: Service
       metadata:
         name: myloadbalancer
         annotations:
           service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
           service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
           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:
         type: LoadBalancer
         selector:
           <selector_key>: <selector_value>
         ports:
          - protocol: TCP
            port: 8080
            targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
         loadBalancerIP: <IP_address>
         externalTrafficPolicy: Local
       ```
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type`
       :   Anotación para especificar un equilibrador de carga de `private` o `public`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-zone`
       :   Anotación para especificar la zona en la que se despliega el servicio de equilibrador de carga. Para ver las zonas, ejecute `ibmcloud oc zone ls`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan`
       :   Anotación para especificar una VLAN en la que se despliega el servicio de equilibrador de carga. Para ver las VLAN, ejecute `ibmcloud oc vlan ls --zone ZONE`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"`
       :   Anotación para especificar un equilibrador de carga de la versión 2.0.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler`
       :   Opcional: Anotación para especificar el algoritmo de planificación. Los valores aceptados son `"rr"` para el método round-robin (predeterminado) o `"sh"` para el método Source Hashing. Para obtener más información, consulte [2.0: Planificación de algoritmos](#scheduling).
   
       `selector`
       :   La clave de etiqueta (`<selector_key>`) y el valor (`<selector_value>`) que ha utilizado en la sección `spec.template.metadata.labels` del  YAML de despliegue de aplicación.
   
       `port`
       :   El puerto que en el que está a la escucha el servicio.
   
       `loadBalancerIP`
       :   Opcional: para crear un NLB privado o para utilizar una dirección IP portátil específica para un NLB público, especifique la dirección IP que desea utilizar. La dirección IP debe estar en la zona y en la VLAN que especifique en las anotaciones. Si no especifica una dirección IP:
           :   Si el clúster está en una VLAN pública, se utiliza una dirección IP pública portátil. La mayoría de los clústeres están en una VLAN pública.
           :   Si el clúster solo está en una VLAN privada, se utiliza una dirección IP privada portátil.
   
       `externalTrafficPolicy: Local`
       :   Se establece en `Local`.
   
   
       Ejemplo de archivo de configuración para crear un servicio NLB 2.0 que `dal12` utilice el algoritmo de programación round-robin:
   
       ```yaml {: codeblock}
       apiVersion: v1
       kind: Service
       metadata:
         name: myloadbalancer
         annotations:
           service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12"
           service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
           service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "rr"
       spec:
         type: LoadBalancer
         selector:
           app: nginx
         ports:
          - protocol: TCP
            port: 8080
            targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
         externalTrafficPolicy: Local
       ```
   3. Opcional: Haz que tu servicio NLB solo esté disponible para un rango limitado de direcciones IP especificando las direcciones IP en el campo `spec.loadBalancerSourceRanges`. `loadBalancerSourceRanges` se implementa mediante `kube-proxy` en tu clúster utilizando reglas de iptables en los nodos de trabajo. Para obtener más información, consulta la [documentación de Kubernetes.](https://kubernetes.io/docs/concepts/services-networking/){: external}
   
   4. Cree el servicio en el clúster.
   
   ```sh {: pre}
       oc apply -f myloadbalancer.yaml
       ```
   

3. Verifique que el servicio de NLB se haya creado correctamente. Pueden transcurrir unos minutos hasta que el servicio de NLB se cree correctamente y la app esté disponible.

   oc describe service myloadbalancer
   

   Salida de ejemplo:

   NAME:                   myloadbalancer
   Namespace:              default
   Labels:                 <none>
   Selector:               app=liberty
   Type:                   LoadBalancer
   Zone:                   dal10
   IP:                     172.21.xxx.xxx
   LoadBalancer Ingress:   169.xx.xxx.xxx
   Port:                   <unset> 8080/TCP
   NodePort:               <unset> 32040/TCP
   Endpoints:              172.30.xxx.xxx:8080
   Session Affinity:       None
   Events:
       FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
       ---------    --------    -----    ----            -------------    ----     ------                      -------
       10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
       10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer
   

   La dirección IP de LoadBalancer Ingress es la dirección IP portátil asignada al servicio de NLB.

4. Si ha creado un NLB público, acceda a la app desde Internet.

   1. Abra el navegador web preferido.
   2. Especifique la dirección IP pública portátil y el puerto del NLB.

       http://169.xx.xxx.xxx:8080
       ```
   

5. Para lograr una alta disponibilidad, repite los pasos 2 a 4 para añadir un NLB 2.0 en cada zona en la que tengas instancias de la aplicación.

6. Opcional: un servicio de NLB también hace que la app esté disponible a través de los NodePorts del servicio. Se puede acceder a los NodePorts en cada dirección IP pública o privada de cada nodo del clúster. Para bloquear el tráfico a los NodePorts mientras utiliza un servicio de NLB, consulte Control del tráfico de entrada a los servicios de equilibrador de carga de red (NLB) o de NodePort.

A continuación, puede registrar un subdominio de NLB.

Antes de empezar

Cumple los requisitos previos de NLB 2.0 antes de continuar.

• Debe tener una dirección IP pública o privada portátil disponible para asignarla al servicio de NLB. Para obtener más información, consulte Configuración de subredes para clústeres.

• Asegúrate de tener el rol de acceso al servicio IAM IBM Cloud de tipo Writer o Manager para el espacio default de nombres.

• Cuando se vuelven a cargar los nodos de clúster o cuando una actualización maestra de clúster incluye una nueva imagen de keepalived, la IP virtual del equilibrador de carga se mueve a la interfaz de red de un nodo nuevo. Cuando esto ocurre, toda conexión de larga duración a su equilibrador de carga debe restablecerse. Considera la posibilidad de incluir una lógica de reintento en tu aplicación para que los intentos de restablecer la conexión se realicen rápidamente.

Para crear un servicio de NLB 2.0 en un clúster de una sola zona:

1. Despliegue la app en el clúster. Asegúrese de añadir una etiqueta en la sección de metadatos del archivo de configuración de despliegue. Esta etiqueta personalizada identifica todos los pods en los que se ejecuta la app para incluirlos en el equilibrio de carga.

2. Cree un servicio equilibrador de carga para la app que desea exponer en internet público o en una red privada.

   1. Cree un archivo de configuración de servicio llamado, por ejemplo, myloadbalancer.yaml.

   2. Defina un servicio de equilibrador de carga 2.0 para la app que desee exponer.

       apiVersion: v1
       kind: Service
       metadata:
         name: myloadbalancer
         annotations:
           service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
           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:
         type: LoadBalancer
         selector:
           <selector_key>: <selector_value>
         ports:
          - protocol: TCP
            port: 8080
            targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
         loadBalancerIP: <IP_address>
         externalTrafficPolicy: Local
       ```
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type`
       :   Anotación para especificar un equilibrador de carga de `private` o `public`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan`
       :   Opcional: Anotación para especificar una VLAN en la que se despliega el servicio de equilibrador de carga. Para ver las VLAN, ejecute `ibmcloud oc vlan ls --zone ZONE`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"`
       :   Anotación para especificar un equilibrador de carga 2.0.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler`
       :   Opcional: anotación para especificar un algoritmo de planificación. Los valores aceptados son `"rr"` para el método round-robin (predeterminado) o `"sh"` para el método Source Hashing. Para obtener más información, consulte [2.0: Planificación de algoritmos](#scheduling).
   
   
       `selector`
       :   La clave de etiqueta (`<selector_key>`) y el valor (`<selector_value>`) que ha utilizado en la sección `spec.template.metadata.labels` del  YAML de despliegue de aplicación.
   
   
       `port`
       :   El puerto que en el que está a la escucha el servicio.
   
   
       `loadBalancerIP`
       :   Opcional: para crear un NLB privado o para utilizar una dirección IP portátil específica para un NLB público, especifique la dirección IP que desea utilizar. La dirección IP debe estar en la VLAN que especifique en las anotaciones. Si no especifica una dirección IP:
           - Si el clúster está en una VLAN pública, se utiliza una dirección IP pública portátil. La mayoría de los clústeres están en una VLAN pública.
           - Si el clúster solo está en una VLAN privada, se utiliza una dirección IP privada portátil.
   
   
       `externalTrafficPolicy: Local`
       :   Se establece en `Local`.
   
   3. Opcional: Haz que tu servicio NLB solo esté disponible para un rango limitado de direcciones IP especificando las direcciones IP en el campo `spec.loadBalancerSourceRanges`. `loadBalancerSourceRanges` se implementa mediante `kube-proxy` en tu clúster utilizando reglas de iptables en los nodos de trabajo. Para obtener más información, consulta la [documentación de Kubernetes.](https://kubernetes.io/docs/concepts/services-networking/){: external}
   
   4. Cree el servicio en el clúster.
   
   ```sh {: pre}
       oc apply -f myloadbalancer.yaml
       ```
   

3. Verifique que el servicio de NLB se haya creado correctamente. Pueden transcurrir unos minutos hasta que el servicio se cree correctamente y la app esté disponible.

   oc describe service myloadbalancer
   

   Salida de ejemplo:

   NAME:                   myloadbalancer
   Namespace:              default
   Labels:                 <none>
   Selector:               app=liberty
   Type:                   LoadBalancer
   Location:               dal10
   IP:                     172.21.xxx.xxx
   LoadBalancer Ingress:   169.xx.xxx.xxx
   Port:                   <unset> 8080/TCP
   NodePort:               <unset> 32040/TCP
   Endpoints:              172.30.xxx.xxx:8080
   Session Affinity:       None
   Events:
       FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
       ---------    --------    -----    ----            -------------    ----     ------                      -------
       10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
       10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer
   

   La dirección IP de LoadBalancer Ingress es la dirección IP portátil asignada al servicio de NLB.

4. Si ha creado un NLB público, acceda a la app desde Internet.

   1. Abra el navegador web preferido.
   2. Especifique la dirección IP pública portátil y el puerto del NLB.

       http://169.xx.xxx.xxx:8080
       ```
   

5. Opcional: un servicio de NLB también hace que la app esté disponible a través de los NodePorts del servicio. Se puede acceder a los NodePorts en cada dirección IP pública o privada de cada nodo del clúster. Para bloquear el tráfico a los NodePorts mientras utiliza un servicio de NLB, consulte Control del tráfico de entrada a los servicios de equilibrador de carga de red (NLB) o de NodePort.

A continuación, puede registrar un subdominio de NLB.

Algoritmos de planificación soportados

Round Robin (rr)

El NLB recorre la lista de pods de app al direccionar conexiones a nodos trabajadores, tratando cada pod de app de forma equitativa. rotativa es el algoritmo de planificación predeterminado para los NLB de la versión 2.0.

Hashing de origen (sh)

El NLB genera una clave hash basándose en la dirección IP de origen del paquete de solicitud de cliente. A continuación, el NLB busca la clave hash en una tabla hash asignada estáticamente y direcciona la solicitud al pod de app que gestiona los hashes de ese rango. Este algoritmo garantiza que las solicitudes de un cliente concreto se dirijan siempre al mismo pod de app. Kubernetes utiliza reglas de Iptables, que hacen que las solicitudes se envíen a un pod aleatorio en el trabajador. Para utilizar este algoritmo de planificación, debe asegurarse de que no hay más de un pod de la app desplegado por cada nodo trabajador. Por ejemplo, si cada pod tiene la etiqueta run=<app_name>, añada la siguiente regla de antiafinidad a la sección spec del despliegue de la aplicación:

spec:
  affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: run
            operator: In
            values:
            - <APP_NAME>
        topologyKey: kubernetes.io/hostname

Algoritmos de planificación sin soporte

Hashing de destino (dh)

El destino del paquete, que es la dirección IP y el puerto del NLB, se utiliza para determinar qué nodo trabajador gestiona la solicitud de entrada. No obstante, la dirección IP y el puerto de los NLB de Red Hat OpenShift on IBM Cloud no cambian. El NLB está obligado a mantener la solicitud dentro del mismo nodo trabajador en el que se encuentra, por lo que únicamente los pods de app de un trabajador gestionan todas las solicitudes entrantes.

Algoritmos de recuento de conexiones dinámico

Los algoritmos siguientes dependen del recuento dinámico de conexiones entre los clientes y los NLB. No obstante, debido a que el retorno directo de servicio (DSR) evita que los pods del NLB 2.0 se incluyan en la vía del paquete de retorno, los NLB no realizan el seguimiento de las conexiones establecidas.

• Menos conexiones (lc)
• Menos conexiones según localidad (lblc)
• Menos conexiones según localidad con réplica (lblcr)
• No poner nunca en cola (nq)
• Retraso esperado más breve (seq)

Algoritmos de pod con ponderación

Los algoritmos siguientes dependen de pods de app ponderados. No obstante, en Red Hat OpenShift on IBM Cloud, todos los pods de app tienen el mismo peso asignado para el equilibrio de carga.

• Menos conexiones con ponderación (wlc)
• Rotación ponderada (wrr)