Network Load Balancer for VPC

En los clústeres VPC, configura un equilibrio de carga de red de VPC ( layer-4, VPC NLB) Network Load Balancer for VPC en cada zona de tu 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, el VPC NLB admite la conservación de direcciones IP de origen en todas las solicitudes de cliente de forma predeterminada.

• Los nombres de 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 identificador único de servicio LoadBalancer (UID) de Kubernetes en el nombre del VPC NLB.

• Los nombres de NLB de VPC persistentes 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 identificador único de servicio LoadBalancer (UID) de Kubernetes en el nombre del VPC NLB.

• 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.

Equilibrio de

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 la aplicación se implementan en varios nodos de trabajo del clúster, el VPC NLB distribuye las solicitudes entre los pods de la aplicación en los distintos nodos de trabajo de todas las zonas del clúster.

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.

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 de VPC ALB tienen el 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 identificador único del servicio LoadBalancer (UID) Kubernetes 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.

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

Equilibrio de

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.

Configuración de un NLB utilizando el rango de puertos

Los rangos de puertos se pueden utilizar en los NLB públicos cuando es necesario alojar un servicio de un único nombre de host que tiene varias aplicaciones de fondo, cada una de las cuales está a la escucha en un número de puerto distinto. Para utilizar rangos de puertos en el clúster de Kubernetes, se debe realizar una configuración manual. En primer lugar, se debe establecer la opción ibm-load-balancer-cloud-provider-vpc-port-range. Puede incluir uno o varios rangos, cada uno delimitado por una coma. El valor spec.ports.port también debe establecerse en el valor mínimo en el rango de puertos.

En el ejemplo siguiente, se utiliza un rango de puertos de 30000-30010.

Los servicios de Nodeport se deben crear manualmente para cada despliegue en el que el servicio de NLB reenvía la solicitud. El número de puerto de cada uno de estos servicios de Nodeport debe estar dentro del rango de puertos configurado en el servicio de NLB.

En el siguiente diagrama de ejemplo, se crea un servicio Nodeport con el puerto 30000 para el despliegue 1, mientras que se crea un servicio Nodeport con el puerto 30001 para el despliegue 2.

El usuario realiza una solicitud al puerto 30001 del NLB que contiene el rango de puertos. Esta solicitud se dirige al servicio de NLB de VPC que dirige la solicitud al servicio de Nodeport en el clúster que también está a la escucha en el puerto 30001, que en este caso es para el despliegue 2. A continuación, el servicio NodePort dirige la solicitud al puerto de destino de los pods seleccionados del despliegue 2.

Cree un NLB que utilice un rango de puertos utilizando el ejemplo siguiente. El selector y los pods de fondo deben estar asociados con el servicio equilibrador de carga de rango de puertos para que las comprobaciones de estado devuelvan correctamente y los datos se entreguen a los puertos del rango de puertos. Para utilizar el rango de puertos, debe crear servicios NodePort adicionales que tengan valores de puerto en el rango definido por el servicio equilibrador de carga.

1. Guarde la siguiente configuración de LoadBalancer de ejemplo como un archivo denominado loadbalancer.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-port-range: 30000-30010
     name: nlb-port-range
   spec:
     externalTrafficPolicy: Cluster
     ports:
     - port: 30000 # Must match min from the port range
       protocol: TCP
       nodePort: 30011 # Can be port in range or not
       targetPort: 8080
     selector:
       app: echo-server  # Must be valid for health checks to work
     type: LoadBalancer
   

2. Cree el servicio.

   oc apply -f loadbalancer.yaml
   

3. Cree un servicio de NodePort con valores de puerto que estén en el rango de puertos especificado en el LoadBalancer que ha creado anteriormente.

   apiVersion: v1
   kind: Service
   metadata:
     name: echo-server-node-port
   spec:
     ports:
     - port: 80
       protocol: TCP # The protocol of the port range
       nodePort: 30003 # Node port in the port range
       targetPort: 8080
     selector:
       app: echo-server
     type: NodePort
   

4. Crea el servicio NodePort.

   oc apply -f nodeport.yaml
   

5. Para acceder a un puerto que está en el rango proporcionado por NLB.

   curl https://<public ip assigned to NLB>:30003
   

   • 30003 = Es un puerto de nodo en el rango que responde a la solicitud
   • Otros puertos del rango no responden a menos que se creen servicios de puerto de nodo adicionales.

Configuración de un NLB de VPC privado

Exponga la app al tráfico de red privada configurando un servicio LoadBalancer de Kubernetes en cada zona del clúster. Cuando se crea el servicio LoadBalancer de Kubernetes, se crea automáticamente un equilibrador de carga de red para VPC (NLB de VPC) que direcciona las solicitudes a la app fuera de su clúster.

Antes de empezar

• Asegúrate de tener el rol de acceso al servicio IAM Writer o Manager IBM Cloud para el espacio de nombres en el que implementas el servicio LoadBalancer Kubernetes para el VPC NLB.
• Conéctese a la red privada de VPC, por ejemplo, mediante una conexión VPN de VPC.
• Acceda al clúster de Red Hat OpenShift.
• Para ver los VPC NLB, instale el plugin infrastructure-service. El prefijo para ejecutar mandatos es ibmcloud is.

  ibmcloud plugin install infrastructure-service
  

Para permitir que la aplicación reciba solicitudes de red privada,

1. Cree una subred de VPC que esté dedicada al NLB de VPC. Esta subred debe existir en la misma VPC y ubicación que el clúster, pero no se puede conectar al clúster ni a ningún nodo trabajador.

   1. En el panel de control de subredes de VPC, haz clic en Nueva subred.
   2. Especifique un nombre para la subred.
   3. Seleccione la ubicación en la que existe el clúster y la zona en la que desea crear el NLB de VPC.
   4. Seleccione el nombre de la VPC donde existe el clúster.
   5. Especifique el número de direcciones IP que se deben crear. Puesto que esta subred está dedicada al NLB de VPC, puede elegir un tamaño menor, como por ejemplo 16. Después, ya no puede cambiar el número de IP que tiene una subred de VPC. Si especifica un rango de IP específico, no utilice los siguientes rangos reservados: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 y 172.20.0.0/16.
   6. Pulse Crear subred. Una vez suministrada la subred, anote su ID.

2. Si el cliente que debe conectarse a la app mediante el NLB de VPC existe fuera de la VPC y la zona en la que ha creado la subred de VPC dedicada, debe crear una tabla de direccionamiento de entrada personalizada. Los NLB de VPC privados pueden añadir reglas a la tabla de direccionamiento personalizada para garantizar la disponibilidad del servicio para algunas condiciones de anomalía. Para obtener más información, consulte la tabla de las limitaciones conocidas y Acerca de rutas y tablas de direccionamiento.

   1. En el panel de control de las tablas de enrutamiento de VPC, haz clic en Crear.
   2. Especifique un nombre para la tabla de direccionamiento.
   3. Seleccione la ubicación y la zona donde ha creado la subred dedicada.
   4. Seleccione el nombre de la VPC donde existe la subred.
   5. Para el Tipo de tráfico, seleccione Ingress.
   6. En función del lugar en el que el cliente acceda a la app, elija un Origen del tráfico. Para obtener más información sobre cómo configurar conexiones a la red privada de VPC, consulte la documentación para elegir la conectividad de VPN de IBM Cloud VPC, Transit Gateway o Direct Link for VPC.
      • Red local: Direct link
      • Otra VPC o infraestructura clásica: Transit gateway
      • Otra zona dentro de la misma VPC:zona de VPC

3. 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.

4. Cree un archivo YAML de configuración para el servicio LoadBalancer de Kubernetes. Considere la posibilidad de nombrar el servicio con el formato <app_name>-vpc-nlb-<VPC_zone>.

   apiVersion: v1
   kind: Service
   metadata:
     name: <app_name>-vpc-nlb-<VPC_zone>
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp: "<tcp_port"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
     type: LoadBalancer
     selector:
       <selector_key>: <selector_value>
     ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   Opcional. Incluya un nombre exclusivo para que el equilibrador de carga de VPC sea persistente. Los equilibradores de carga de VPC persistentes no se suprimen cuando se suprime el clúster al que pertenecen. Para obtener más información, consulte Equilibradores de carga de VPC persistentes.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"

   Obligatorio: anotación para crear un VPC NLB.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

   Obligatorio: anotación para especificar un servicio que acepte solicitudes privadas.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   Obligatorio: anotación para especificar la subred dedicada en la que se despliega el NLB de VPC. El valor se puede especificar como un ID de subred de VPC, un nombre de subred de VPC o un CIDR de subred de VPC. Solo debe especificar una subred. La subred debe existir en la misma VPC que el clúster y en una zona en la que el clúster tenga nodos trabajadores, pero los nodos trabajadores se pueden conectar a esta subred. Los nodos trabajadores que existen en la misma zona que esta subred están configurados para recibir tráfico de la NLB de VPC. Para ver las subredes de todos los grupos de recursos, ejecute ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone>.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   Opcional: anotación para especificar un selector de etiqueta de nodo trabajador. Dentro de la misma zona que la subred dedicada para la NLB de VPC, puede configurar nodos trabajadores específicos para recibir tráfico seleccionando una de las claves de selector de etiqueta soportadas. Tenga en cuenta que solo puede incluir un selector de etiquetas en la anotación y que el selector se debe especificar en el formato "key=value". Si no se especifica esta anotación, todos los nodos trabajadores de la misma zona que la subred VPC que ha especificado en la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets están configurados para recibir tráfico desde la NLB de VPC. Si se especifica, se pasan por alto las etiquetas dedicated: edge en los nodos trabajadores.

   Se permiten las claves siguientes. - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp

   Opcional: especifique un puerto de nodo de TCP que se utilizará para las comprobaciones de estado de TCP en un equilibrador de carga de UDP. Necesario para los equilibradores de carga de UDP que tienen externalTrafficPolicy establecido en Cluster. Consulte Configuración de comprobaciones de estado de TCP para equilibradores de carga de UDP para ver más consideraciones antes de establecer un valor de puerto.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   Opcional: esta anotación establece el protocolo de comprobación de estado en el recurso del equilibrador de carga de VPC asociado con el servicio del equilibrador de carga de Kubernetes. Normalmente, el protocolo de comprobación de estado de LB de VPC viene determinado por el valor de externalTrafficPolicy en la especificación de servicio del equilibrador de carga de Kubernetes. Esta anotación altera temporalmente esa lógica. Esta anotación no modifica cómo se comporta Kubernetes, y kube-proxy en particular, en relación con los diversos valores de externalTrafficPolicy.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   Opcional. El puerto TCP que se utiliza para las comprobaciones de estado. Esta anotación sólo se aplica si también se especifica ibm-load-balancer-cloud-provider-vpc-health-check-protocol.

   • Si el puerto TCP especificado se encuentra fuera del rango de puertos de los nodos Kubernetes (30 000-32 767), deberá modificarse el grupo de seguridad de la VPC aplicado a los nodos de trabajo del clúster para permitir el tráfico entrante en dicho puerto.
   • Si esta anotación se aplica a un servicio de equilibrado de carga de Kubernetes asociado a un VPC ALB, deben modificarse las reglas de salida del grupo de seguridad asignado al VPC ALB para permitir el tráfico saliente hacia el puerto TCP especificado.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   Opcional. La ruta de comprobación de estado URL para las comprobaciones de estado de HTTP y HTTPS. Esta anotación sólo se aplica si ibm-load-balancer-cloud-provider-vpc-health-check-protocol se establece en http o https.

   • La ruta URL debe tener el formato de un destino de solicitud de origen.
   • Si no se especifica esta anotación y la anotación ibm-load-balancer-cloud-provider-vpc-health-check-protocol se establece en http o https, se aplica el valor predeterminado /.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   Opcional. Número de segundos que se debe esperar entre intentos de comprobación de estado. De forma predeterminada, este valor se establece en 5 y tiene un mínimo de 2 y un máximo de 60. Este valor debe ser mayor que el valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que se establece en 2 de forma predeterminada.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   Opcional. Número de segundos que se debe esperar una respuesta a una comprobación de estado. De forma predeterminada, este valor se establece en 2 y tiene un mínimo de 1 y un máximo de 59. Este valor debe ser menor que ibm-load-balancer-cloud-provider-vpc-health-check-delay, que se establece en 5 de forma predeterminada.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   Número máximo de reintentos de comprobación de estado para el equilibrador de carga de VPC. De forma predeterminada, este valor se establece en 2 y tiene un mínimo de 1 y un máximo de 10.

   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. Esta etiqueta personalizada identifica todos los pods en los que se ejecuta la app para incluirlos en el equilibrio de carga.

   port

   El puerto que en el que está a la escucha el servicio.

   targetPort

   Opcional: el puerto al que el servicio dirige el tráfico. La aplicación que se ejecuta en el pod debe estar a la escucha del tráfico entrante de TCP en este puerto de destino. El puerto de destino suele estar definido estáticamente en la imagen que se ejecuta en el pod de la aplicación. El puerto de destino configurado en el pod es diferente del puerto de nodo para el servicio y también puede ser diferente del puerto externo configurado en el LB de VPC.

   externalTrafficPolicy

   Obligatorio. Especificar Local o Cluster.

   Configúralo en Local para conservar la dirección IP de origen de las solicitudes de los clientes a tus aplicaciones. Este valor impide que el tráfico de entrada se reenvíe a un nodo diferente. Esta opción también configura las comprobaciones de estado de HTTP.

   Si Cluster se establece, DSR solo se implementa desde el nodo de trabajo al que el VPC NLB reenvía inicialmente la solicitud entrante. Después de que llegue la solicitud entrante, la solicitud se reenvía a un nodo trabajador que contiene el pod de la app, que puede estar en una zona diferente. La respuesta del pod de app se envía al nodo trabajador original, y ese nodo trabajador utiliza DSR para enviar la respuesta directamente al cliente, pasando por alto el VPC NLB. Esta opción también configura las comprobaciones de estado de TCP. En el caso de los equilibradores de carga de UDP, service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp es necesario el si se elige la opción Cluster. Para obtener más información, consulta Configuración de comprobaciones de estado de TCP para los equilibradores de carga de UDP.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   Opcional. Número de nodos trabajadores por zona a los que se dirige el equilibrador de carga. El valor predeterminado es 8. Para un cluster con nodos trabajadores en tres zonas, esto resulta en que el balanceador de carga enruta a 24 nodos trabajadores en total. El número total de nodos trabajadores de todas las zonas a los que se dirige el equilibrador de carga no puede superar los 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.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   Opcional. Un grupo de seguridad gestionado por el cliente para añadir al equilibrador de carga de la VPC. Si no desea utilizar el IBM, especifique un grupo de seguridad que posea y gestione. Esta opción elimina el grupo de seguridad gestionado por IBM y lo sustituye por el grupo de seguridad que especifique. Al eliminar la anotación de un equilibrador de carga existente, se sustituye el grupo de seguridad que ha añadido por el grupo de seguridad gestionado por IBM. Puede añadir o eliminar esta anotación en cualquier momento. Usted es responsable de gestionar su grupo de seguridad y mantenerlo actualizado.

5. Cree el servicio LoadBalancer de Kubernetes en el clúster.

   oc apply -f <filename>.yaml -n <namespace>
   

6. Verifique que el servicio LoadBalancer de Kubernetes se ha creado correctamente en el clúster. Cuando se crea el servicio, el campo LoadBalancer Ingress se llena con una dirección IP externa asignada por el VPC NLB.

El VPC NLB tarda unos minutos en suministrarse en la VPC. La dirección IP externa del servicio LoadBalancer de Kubernetes podría estar pending hasta que el VPC NLB esté completamente suministrado.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Ejemplo de salida de CLI para un servicio `LoadBalancer` privado:
```sh {: screen}
NAME:                     myvpcnlb
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     10.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
Warning  SyncLoadBalancerFailed           13m (x5 over 15m)    service-controller  Error syncing load balancer: failed to ensure load balancer: kube-bqcssbbd0bsui62odcdg-2d93b07decf641d2ad3f9c2985122ec1 for service default/myvpcnlb is busy: offline/create_pending
Normal   EnsuringLoadBalancer             9m27s (x7 over 15m)  service-controller  Ensuring load balancer
Normal   EnsuredLoadBalancer              9m20s                service-controller  Ensured load balancer
Normal   CloudVPCLoadBalancerNormalEvent  8m17s                ibm-cloud-provider  Event on cloud load balancer myvpcnlb for service default/myvpcnlb with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

7. Verifique que el VPC NLB se ha creado correctamente en la VPC. En la salida, verifique que el VPC NLB tenga el estado operativo (Operating Status) online y el Estado de suministro (Provision Status) active.

   ibmcloud is load-balancers
   

   En el siguiente ejemplo de salida de la CLI, se crea el VPC NLB llamado kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e para el servicio LoadBalancer de Kubernetes:

   ID                                     Name                                                         Created          Host Name                                  Is Public   Listeners                               Operating Status   Pools                                   Private IPs              Provision Status   Public IPs                    Subnets                                Resource Group
   06496f64-a689-4693-ba23-320959b7b677   kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e   8 minutes ago    1234abcd-us-south.lb.appdomain.cloud       no         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.XXX.XXX.XXX           active             -               c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

8. Desde la conexión a la red privada de VPC, acceda a la dirección IP del servicio LoadBalancer de Kubernetes que ha encontrado en el paso 6 y el puerto de la app en el formato <external_IP>:<app_port>.

9. Opcional: repita estos pasos para desplegar un NLB de VPC privado en cada zona donde desee exponer la app. A continuación, puede registrar las direcciones IP externas del VPC NLB en cada zona con un subdominio DNS.

Registro de un registro DNS y un certificado TLS

Los VPC NLB proporcionan direcciones IP externas estáticas a través de las cuales puede acceder a la app. Para registrar un certificado SSL para el dominio de app para dar soporte a HTTPS, puede crear un subdominio proporcionado por IBM o puede traer su propio dominio personalizado.

Por ejemplo, suponga que tiene un clúster multizona y ejecuta réplicas de la app en nodos trabajadores en cada zona del clúster. Crea un VPC NLB por zona para exponer las réplicas de la app. A continuación, puede registrar las direcciones IP externas proporcionadas por cada VPC NLB con una entrada de DNS.

Después de crear un subdominio de DNS para NLB de VPC, no puede utilizar los mandatos nlb-dns health-monitor para crear una comprobación de estado personalizada. En su lugar, se utiliza la comprobación de estado de VPC predeterminada. Para obtener más información, consulte la documentación de VPC.

• Cree un VPC NLB por zona para su app. Asegúrese de definir un puerto HTTPS en su servicio LoadBalancer de Kubernetes que configura el VPC NLB.
• Para utilizar el certificado SSL para acceder a la app mediante HTTPS, la app debe poder finalizar las conexiones TLS.

Para registrar direcciones IP de NLB de VPC con un subdominio de DNS,

1. Recupere la dirección IP externa del equilibrador de carga.

   oc get svc -o wide
   

   Salida de ejemplo

   NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)            AGE      SELECTOR
   ...
   myapp-vpc-nlb-jp-tok-3    LoadBalancer   172.21.xxx.xxx   169.xx.xxx.xx     8080:30532/TCP     1d       run=webserver
   

2. Cree un subdominio de DNS personalizado o proporcionado por IBM para la dirección IP.

   • Dominio personalizado:

     1. Para registrar un dominio personalizado, póngase en contacto con su proveedor de DNS (Domain Name Service) o utilice un DNS de IBM Cloud.
     2. Defina un alias para el dominio personalizado especificando las direcciones IP del equilibrador de carga como registros A.

   • Subdominio proporcionado por IBM: utilice los mandatos nlb-dns para generar un subdominio con un certificado SSL para las direcciones IP. IBM Cloud se encarga de generar y mantener el certificado SSL comodín del subdominio.

     1. Cree un subdominio de DNS y un certificado SSL.

        ibmcloud oc nlb-dns create vpc-gen2 --type public --cluster <cluster_name_or_id> --ip <vpc_nlb1_ip> --ip <vpc_nlb2_ip> --ip <vpc_nlb3_ip>
        

     2. Verifique que se ha creado el subdominio. Para obtener más información, consulte Descripción del formato de subdominio.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        Salida de ejemplo

        Subdomain                                                                               IP(s)                                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     169.46.xx.x,169.48.xxx.xx,169.48.xxx.xx      None             created                   <certificate>
        

3. Abra un navegador web y especifique el URL para acceder a su app a través del subdominio.

Para utilizar el certificado SSL para acceder a la app mediante HTTPS, asegúrese de que ha definido un puerto HTTPS en el servicio LoadBalancer de Kubernetes. Puede verificar que las solicitudes se direccionan correctamente a través del puerto HTTPS ejecutando curl -v --insecure https://<domain>. Un error de conexión indica que no hay ningún puerto HTTPS abierto en el servicio. Además, asegúrese de que la app puede finalizar las conexiones TLS. Puede verificar que la aplicación termina TLS correctamente ejecutando curl -v https://<domain>. Un error de certificado indica que la app no está finalizando adecuadamente las conexiones TLS.

Configuración de un VPC ALB público o privado

Antes de empezar

• Asegúrate de tener el rol de acceso al servicio IAM Writer o Manager IBM Cloud para el espacio de nombres en el que implementas el servicio LoadBalancer Kubernetes para el VPC NLB.
• Acceda al clúster de Red Hat OpenShift.
• Para ver los VPC ALB, instale el plugin infrastructure-service. El prefijo para ejecutar mandatos es ibmcloud is.

  ibmcloud plugin install infrastructure-service
  

Para permitir que la aplicación reciba solicitudes públicas o privadas,

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 archivo YAML de configuración para el servicio LoadBalancer de Kubernetes y asigne al archivo el nombre myloadbalancer.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     name: myloadbalancer
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "<public_or_private>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
    type: LoadBalancer
    selector:
       <selector_key>: <selector_value>
    ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   Opcional. Incluya un nombre exclusivo para que el equilibrador de carga de VPC sea persistente. Los equilibradores de carga de VPC persistentes no se suprimen cuando se suprime el clúster al que pertenecen. Para obtener más información, consulte Equilibradores de carga de VPC persistentes.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"

   Opcional: Habilita el protocolo PROXY. El equilibrador de carga pasa la información de conexión de cliente, incluida la dirección IP del cliente, la dirección IP del servidor proxy y ambos números de puerto, en las cabeceras de solicitud a la app de fondo. Tenga en cuenta que la app de fondo debe estar configurada para aceptar el protocolo PROXY. Por ejemplo, puedes configurar una aplicación de NGINX para que acepte el protocolo PROXY siguiendo estos pasos.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type

   Anotación para especificar un servicio que acepta solicitudes públicas o privadas. Si no incluye esta anotación, se crea un LoadBalancer público.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   Anotación para especificar un selector de etiquetas de nodos de trabajo. Para identificar los nodos trabajadores que reciben tráfico, puede seleccionar una de las claves admitidas del selector de etiquetas. Tenga en cuenta que solo puede incluir un selector de etiquetas en la anotación y que el selector se debe especificar en el formato "key=value". Si no se especifica esta anotación, todos los nodos trabajadores del clúster se configuran para recibir tráfico desde el VPC ALB. Si se especifica, esta anotación prevalece sobre la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-zone y se pasan por alto las etiquetas dedicated: edge en los nodos trabajadores.

   Se permiten las siguientes claves: - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   Anotación para especificar una o varias subredes en las que se implementa el servicio VPC ALB. Si se especifica, esta anotación prevalece sobre la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-zone. Tenga en cuenta que puede especificar una subred distinta en la misma VPC que las subredes a las que está conectado el clúster. En este caso, aunque el VPC ALB se despliega en una subred diferente en la misma VPC, el VPC ALB puede seguir direccionando el tráfico a los nodos trabajadores de las subredes del clúster. Para ver las subredes de todos los grupos de recursos, ejecute ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone>.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-zone

   Anotación para especificar una zona de VPC a la que está conectado el clúster. Cuando especifica una zona en esta anotación, se producen dos procesos.

   1. El VPC ALB se despliega en la misma subred de la zona a la que están conectados los nodos trabajadores.
   2. Solo los nodos trabajadores del clúster de esta zona están configurados para recibir el tráfico del VPC ALB.

   Para ver las zonas, ejecute ibmcloud oc zone ls --provider vpc-gen2.

   Para colocar el equilibrador de carga en una zona específica, debe especificar esta anotación cuando cree el equilibrador de carga. Si después cambia esta anotación a otra zona, el equilibrador de carga no se mueve a la nueva zona. Sin embargo, el equilibrador de carga se vuelve a configurar para enviar tráfico sólo a los nodos de trabajador de la nueva zona.

   Si está establecida la etiqueta dedicated: edge en nodos de trabajador y especifica esta anotación, sólo se configuran para recibir tráfico los nodos periféricos de la zona especificada. Los nodos periféricos de otras zonas y los nodos no periféricos de la zona especificada no reciben tráfico del equilibrador de carga.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   Opcional: esta anotación establece el protocolo de comprobación de estado en el recurso del equilibrador de carga de VPC asociado con el servicio del equilibrador de carga de Kubernetes. Normalmente, el protocolo de comprobación de estado de LB de VPC viene determinado por el valor de externalTrafficPolicy en la especificación de servicio del equilibrador de carga de Kubernetes. Esta anotación altera temporalmente esa lógica. Esta anotación no modifica cómo se comporta Kubernetes, y kube-proxy en particular, en relación con los diversos valores de externalTrafficPolicy.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   Opcional. El puerto TCP que se utiliza para las comprobaciones de estado. Esta anotación sólo se aplica si también se especifica ibm-load-balancer-cloud-provider-vpc-health-check-protocol.

   • Si el puerto TCP especificado se encuentra fuera del rango de puertos de los nodos Kubernetes (30 000-32 767), deberá modificarse el grupo de seguridad de la VPC aplicado a los nodos de trabajo del clúster para permitir el tráfico entrante en dicho puerto.
   • Si esta anotación se aplica a un servicio de equilibrado de carga de Kubernetes asociado a un VPC ALB, deben modificarse las reglas de salida del grupo de seguridad asignado al VPC ALB para permitir el tráfico saliente hacia el puerto TCP especificado.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   Opcional. La ruta de comprobación de estado URL para las comprobaciones de estado de HTTP y HTTPS. Esta anotación sólo se aplica si ibm-load-balancer-cloud-provider-vpc-health-check-protocol se establece en http o https.

   • La ruta URL debe tener el formato de un destino de solicitud de origen.
   • Si no se especifica esta anotación y la anotación ibm-load-balancer-cloud-provider-vpc-health-check-protocol se establece en http o https, se aplica el valor predeterminado /.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   Opcional. Número de segundos que se debe esperar entre intentos de comprobación de estado. De forma predeterminada, este valor se establece en 5 y tiene un mínimo de 2 y un máximo de 60. Este valor debe ser mayor que el valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que se establece en 2 de forma predeterminada.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   Opcional. Número de segundos que se debe esperar una respuesta a una comprobación de estado. De forma predeterminada, este valor se establece en 2 y tiene un mínimo de 1 y un máximo de 59. Este valor debe ser menor que ibm-load-balancer-cloud-provider-vpc-health-check-delay, que se establece en 5 de forma predeterminada.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   Número máximo de reintentos de comprobación de estado para el equilibrador de carga de VPC. De forma predeterminada, este valor se establece en 2 y tiene un mínimo de 1 y un máximo de 10.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout

   Opcional. Tiempo de espera de conexión desocupada del escucha en segundos. El tiempo de espera desocupado predeterminado depende de los valores de la cuenta. Normalmente, este valor es 50. Sin embargo, algunas cuentas de la lista de elementos permitidos tienen valores de tiempo de espera más grandes. Si no establece la anotación, los equilibradores de carga utilizan el valor de tiempo de espera en su cuenta. Puede especificar explícitamente el tiempo de espera estableciendo esta anotación. El mínimo es 50. El máximo es 7200.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

   Opcional. Solo se puede aplicar para ALB de VPC privados en versión4.15 o después. El DNS instance que se debe asociar a este equilibrador de carga. Para más información, ver Registrar un registro DNS privado.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

   Opcional. Solo se puede aplicar para ALB de VPC privados en versión4.15 o después. El DNS zone que se debe asociar a este equilibrador de carga. Para más información, ver Registrar un registro DNS privado.

   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. Esta etiqueta personalizada identifica todos los pods en los que se ejecuta la app para incluirlos en el equilibrio de carga.

   port

   El puerto que en el que está a la escucha el servicio.

   targetPort

   Opcional: el puerto al que el servicio dirige el tráfico. La aplicación que se ejecuta en el pod debe estar a la escucha del tráfico entrante de TCP en este puerto de destino. El puerto de destino suele estar definido estáticamente en la imagen que se ejecuta en el pod de la aplicación. El puerto de destino configurado en el pod es diferente del puerto de nodo para el servicio y también puede ser diferente del puerto externo configurado en el LB de VPC.

   externalTrafficPolicy

   Obligatorio. Especifique Local o Cluster.

   Configúralo en Local para conservar la dirección IP de origen de las solicitudes de los clientes a tus aplicaciones. Este valor impide que el tráfico de entrada se reenvíe a un nodo diferente. Esta opción también configura las comprobaciones de estado de HTTP. En el caso de los equilibradores de carga de UDP, service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp es necesario el si se elige la opción Cluster. Para obtener más información, consulte Configuración de comprobaciones de estado de TCP para los equilibradores de carga de UDP.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   Opcional. Número de nodos trabajadores por zona a los que se dirige el equilibrador de carga. El valor predeterminado es 8. Para un cluster con nodos trabajadores en tres zonas, esto resulta en que el balanceador de carga enruta a 24 nodos trabajadores en total. El número total de nodos trabajadores de todas las zonas a los que se dirige el equilibrador de carga no puede superar los 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.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   Opcional. Un grupo de seguridad gestionado por el cliente para añadir al equilibrador de carga de la VPC. Si no desea utilizar el IBM, especifique un grupo de seguridad que posea y gestione. Esta opción elimina el grupo de seguridad gestionado por IBM y lo sustituye por el grupo de seguridad que especifique. Al eliminar la anotación de un equilibrador de carga existente, se sustituye el grupo de seguridad que ha añadido por el grupo de seguridad gestionado por IBM. Puede añadir o eliminar esta anotación en cualquier momento. Usted es responsable de gestionar su grupo de seguridad y mantenerlo actualizado.

3. Cree el servicio LoadBalancer de Kubernetes en el clúster.

   oc apply -f myloadbalancer.yaml -n <namespace>
   

4. Verifique que el servicio LoadBalancer de Kubernetes se ha creado correctamente en el clúster. Cuando se crea el servicio, el campo LoadBalancer Ingress se llena con un nombre de host asignado por el VPC ALB.

El VPC ALB tarda unos minutos en suministrarse en la VPC. No puede acceder a la aplicación utilizando el nombre de host del servicio LoadBalancer de Kubernetes hasta que el ALB de VPC no se haya suministrado totalmente.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Ejemplo de salida de CLI para un servicio `LoadBalancer` público:
```sh {: screen}
NAME:                     myvpcalb
Namespace:                default
Labels:                   <none>
Annotations:              
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.XX.XX
LoadBalancer Ingress:     1234abcd-us-south.lb.appdomain.cloud
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  30610/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     31438
Events:
    Type    Reason                           Age   From                Message
----    ------                           ----  ----                -------
Normal  EnsuringLoadBalancer             16m   service-controller  Ensuring load balancer
Normal  EnsuredLoadBalancer              15m   service-controller  Ensured load balancer
Normal  CloudVPCLoadBalancerNormalEvent  13m   ibm-cloud-provider  Event on cloud load balancer myvpcalb for service default/myvpcalb with UID 08cbacf0-2c93-4186-84b6-c4ab88a2faf9: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

5. Verifique que el VPC ALB se ha creado correctamente en la VPC. En la salida, verifique que el VPC ALB tenga el estado operativo (Operating Status) online y el Estado de suministro (Provision Status) active.

   No cambie el nombre de ningún VPC ALB que se haya creado automáticamente para los servicios LoadBalancer. Si cambia el nombre de un VPC ALB, Red Hat OpenShift on IBM Cloud crea automáticamente otro VPC ALB para el servicio LoadBalancer.

   ibmcloud is load-balancers
   

   En la siguiente salida de CLI de ejemplo, se crea el VPC ALB denominado kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306 para el servicio Kubernetes LoadBalancer:

   ID                                          Name                                                         Family        Subnets               Is public   Provision status   Operating status   Resource group
   r006-d044af9b-92bf-4047-8f77-a7b86efcb923   kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306   Application   mysubnet-us-south-3   true        active             online             default
   

6. Si ha creado un servicio LoadBalancer público, ejecute curl sobre el nombre de host del servicio LoadBalancer de Kubernetes asignado por el VPC ALB que ha encontrado en el paso 4. Ejemplo:

   curl 06496f64-us-south.lb.appdomain.cloud:8080
   

   Salida de ejemplo

   Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!
   

   Si ha creado un servicio LoadBalancer privado, debe estar conectado a la red de VPC privada para ejecutar curl sobre el nombre de host.

No suprima las subredes que ha conectado al clúster durante la creación del clúster o al añadir nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.

Los ALB y NLB de VPC que no estén vinculados a clústeres de Kubernetes u OpenShift se pueden actualizar directamente mediante comandos ibmcloud is o desde la sección Infraestructura de VPC de la consola. Por ejemplo, cambie el puerto de un escucha frontal o el valor de tiempo de espera de comprobación de estado. Sin embargo, en el caso de los equilibradores de carga de VPC vinculados a clústeres de Kubernetes u OpenShift, cualquier actualización que se les realice debe llevarse a cabo mediante anotaciones en la configuración de Ingress. El proveedor de IBM Cloud se resincroniza periódicamente con cualquier ALB y NLB de VPC asociados para garantizar que el equilibrador de carga en funcionamiento se ajuste a la configuración prevista de Ingress. Por lo tanto, si realiza algún cambio en dicho equilibrador de carga directamente a través de VPC en lugar de utilizar anotaciones de Ingress, dichos cambios se revertirán.

Registro de un registro DNS y un certificado TLS

El equilibrador de carga de aplicación para VPC (ALB de VPC) proporciona un nombre de host HTTP predeterminado con el formato 1234abcd-<region>.lb.appdomain.cloud a través del que puede acceder a la aplicación. Sin embargo, si desea un certificado TLS para el dominio de app para dar soporte a HTTPS, puede crear un subdominio proporcionado por IBM o puede traer su propio dominio personalizado tanto para equilibradores de carga de VPC ALB.

Después de crear un subdominio de DNS para el nombre de host de ALB de VPC, no puede utilizar los mandatos nlb-dns health-monitor para crear una comprobación de estado personalizada. En su lugar, se utiliza la comprobación de estado del equilibrador de carga de VPC predeterminada que se proporciona para el nombre de host del VPC ALB predeterminado. Para obtener más información, consulte la documentación de VPC.

Antes de empezar

• Configure un VPC ALB. Asegúrese de definir un puerto HTTPS en su servicio LoadBalancer de Kubernetes que configura el VPC ALB.
• Para utilizar el certificado TLS para acceder a la app mediante HTTPS, la app debe poder finalizar las conexiones TLS.

Para registrar un nombre de host de ALB de VPC con un subdominio de DNS,

1. Recupere el nombre de host del ALB de VPC ejecutando el mandato get svc. En la salida, busque el nombre de host en la columna EXTERNAL-IP. Por ejemplo, 1234abcd-us-south.lb.appdomain.cloud.

   oc get svc -o wide
   

   Salida de ejemplo

   NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                            PORT(S)     AGE       SELECTOR
   ...
   webserver-lb    LoadBalancer   172.21.xxx.xxx   1234abcd-us-south.lb.appdomain.cloud   8080:30532/TCP     1d       run=webserver
   

2. Cree un subdominio de DNS personalizado o proporcionado por IBM para el nombre de host del equilibrador de carga.

   • Dominio personalizado: Proporcione su propio dominio personalizado y asígnele un alias especificando la IP externa del equilibrador de carga, en el formato 1234abcd-us-south.lb.appdomain.cloud de un registro de nombre canónico (CNAME).

     1. Para registrar un dominio personalizado, póngase en contacto con su proveedor de DNS (Domain Name Service) o utilice un DNS de IBM Cloud.
     2. Define un alias para tu dominio personalizado especificando la IP externa del equilibrador de carga como un registro de nombre canónico (CNAME). En el ejemplo siguiente, se puede acceder al equilibrador de carga con la IP externa de 1234abcd-us-south.lb.appdomain.cloud en www.your-custom-domain.com.

     Host/Servicio

     El prefijo donde desea acceder a la app como, por ejemplo, www.

     Tipo de recurso

     Seleccione CNAME.

     TTL

     Seleccione un tiempo de vida.

     Valor/Destino

     La IP externa de LoadBalancer que ha recuperado anteriormente. Por ejemplo, 1234abcd-us-south.lb.appdomain.cloud.. Tenga en cuenta que cuando utilice IBM Cloud DNS, asegúrese de especificar un punto final.

   • Subdominio proporcionado por IBM: utilice los mandatos nlb-dns para generar un subdominio con un certificado TLS para el nombre de host del ALB de VPC. IBM Cloud se encarga de generar y mantener el certificado TLS comodín del subdominio.

     1. Cree un subdominio de DNS y un certificado TLS.

        ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_id> --lb-host <vpc_lb_hostname> --type (public|private)
        

     2. Verifique que se ha creado el subdominio. Para obtener más información, consulte Descripción del formato de subdominio.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        Salida de ejemplo

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
        

3. Si ha creado un subdominio para un ALB de VPC pública, abra un navegador web e introduzca URL para acceder a su aplicación a través del subdominio, tal y como se muestra en el ejemplo www.your-custom-domain.com. Si ha creado un subdominio para un VPC ALB privado, debe estar conectado a la red de VPC privada para probar el acceso a su subdominio.

Para utilizar el certificado TLS para acceder a la app mediante HTTPS, asegúrese de que ha definido un puerto HTTPS en el servicio LoadBalancer de Kubernetes. Puede verificar que las solicitudes se direccionan correctamente a través del puerto HTTPS ejecutando curl -v --insecure https://<domain>. Un error de conexión indica que no hay ningún puerto HTTPS abierto en el servicio. Además, asegúrese de que la app puede finalizar las conexiones TLS. Puede verificar que la aplicación termina TLS correctamente ejecutando curl -v https://<domain>. Un error de certificado indica que la app no está finalizando adecuadamente las conexiones TLS.

Registrar un registro DNS privado para un ALB de VPC privado

En versión4.15 o posterior puede utilizar las siguientes anotaciones opcionales para asociar un DNS propio instance que sirve un DNS personalizado zone con un VPC ALB privado. Para ello se deben establecer ambas anotaciones opcionales. Si no están especificados entonces DNS A registros para este balanceador de carga hostname La propiedad se agregará a la zona DNS pública.lb.appdomain.cloud.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn" :
El DNS instance que se debe asociar a este equilibrador de carga. La instancia especificada puede estar en una región o cuenta diferente, sujeta a las políticas de IAM. Valores posibles: 9 ≤ longitud ≤ 512

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id" :
El DNS zone que se debe asociar a este equilibrador de carga. La zona especificada puede estar en una región o cuenta diferente, sujeta a las políticas de IAM. Valores posibles: 1 ≤ longitud ≤ 128; el valor debe coincidir con la expresión regular [a-z0-9-]^*[a-z0-9]$

Debe hacer lo siguiente como requisito previo antes de poder utilizar esta función:

• Cree la zona DNS que se puede vincular a un equilibrador de carga
• Habilite la autorización de servicio a servicio entre VPC LB yDNS Services
• Agregar la VPC del cluster a las redes permitidas de la zona

Para obtener información detallada, consulte los documentos Integración de un equilibrador de carga de aplicaciones c IBM Cloud DNS Services y Añadir una VPC como red permitida a la zona DNS.

Ejemplo:

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

Desconexión de un equilibrador de carga de VPC de un clúster

Los equilibradores de carga de VPC están vinculados a la definición del servicio LoadBalancer Kubernetes con la que se crearon. Para desconectar un equilibrador de carga de VPC persistente de un clúster, debe romper el enlace con el servicio LoadBalancer renombrando el equilibrador de carga de VPC o eliminando la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name de la definición de servicio LoadBalancer original. También puede desconectar un equilibrador de carga de VPC persistente de un clúster suprimiendo el clúster.

Si elimina la anotación, el servicio LoadBalancer original revierte y crea un equilibrador de carga de VPC no persistente en el clúster original. Este equilibrador de carga de VPC no persistente sigue el convenio de denominación de kube-<cluster_ID>-<kubernetes_lb_service_UID>.

Conexión de un equilibrador de carga de VPC a un clúster

Una vez que un equilibrador de carga de VPC persistente se ha desvinculado de un clúster, puede vincularlo a otro clúster creando una nueva definición de servicio LoadBalancer Kubernetes que haga referencia al equilibrador de carga de VPC.

Cuando crea un nuevo servicio de LoadBalancer en el nuevo clúster, puede utilizar la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name para especificar el nombre del equilibrador de carga de VPC que desea adjuntar.

Al crear el servicio LoadBalancer, el tipo de equilibrador de carga de VPC (ALB, NLB) y el tipo de IP (público, privado) deben coincidir con las especificaciones del servicio LoadBalancer. Por ejemplo, un servicio de LoadBalancer existente en el nuevo clúster que especifica un tipo de NLB no se puede utilizar para conectar un ALB de VPC al clúster. Las anotaciones que especifican el tipo de equilibrador de carga y el tipo de IP son service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features y service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type, respectivamente.

No es necesario que el puerto y los puertos de nodo especificados en el servicio LoadBalancer coincidan con los puertos con los que se ha creado el equilibrador de carga de VPC. El equilibrador de carga de VPC se vuelve a configurar con las definiciones de puerto del servicio de LoadBalancer con el que está asociado en el nuevo clúster.

Personalización de comprobaciones de estado para equilibradores de carga de VPC

Para obtener más control sobre las comprobaciones de estado del equilibrador de carga de VPC, puede utilizar anotaciones opcionales para personalizar las comprobaciones de estado con configuraciones avanzadas para intervalos de prueba, tiempos de espera excedidos y reintentos. Puede cambiar o eliminar estas personalizaciones en cualquier momento.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

Opcional: esta anotación establece el protocolo de comprobación de estado en el recurso del equilibrador de carga de VPC asociado con el servicio del equilibrador de carga de Kubernetes. Normalmente, el protocolo de comprobación de estado de LB de VPC viene determinado por el valor de externalTrafficPolicy en la especificación de servicio del equilibrador de carga de Kubernetes. Esta anotación altera temporalmente esa lógica. Esta anotación no modifica cómo se comporta Kubernetes, y kube-proxy en particular, en relación con los diversos valores de externalTrafficPolicy.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

Opcional. El puerto TCP que se utiliza para las comprobaciones de estado. Esta anotación sólo se aplica si también se especifica ibm-load-balancer-cloud-provider-vpc-health-check-protocol.

• Si el puerto TCP especificado se encuentra fuera del rango de puertos de los nodos Kubernetes (30 000-32 767), deberá modificarse el grupo de seguridad de la VPC aplicado a los nodos de trabajo del clúster para permitir el tráfico entrante en dicho puerto.
• Si esta anotación se aplica a un servicio de equilibrado de carga de Kubernetes asociado a un VPC ALB, deben modificarse las reglas de salida del grupo de seguridad asignado al VPC ALB para permitir el tráfico saliente hacia el puerto TCP especificado.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

Opcional. La ruta de comprobación de estado URL para las comprobaciones de estado de HTTP y HTTPS. Esta anotación sólo se aplica si ibm-load-balancer-cloud-provider-vpc-health-check-protocol se establece en http o https.

• La ruta URL debe tener el formato de un destino de solicitud de origen.
• Si no se especifica esta anotación y la anotación ibm-load-balancer-cloud-provider-vpc-health-check-protocol se establece en http o https, se aplica el valor predeterminado /.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

Opcional. Número de segundos que se debe esperar entre intentos de comprobación de estado. De forma predeterminada, este valor se establece en 5 y tiene un mínimo de 2 y un máximo de 60. Este valor debe ser mayor que el valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que se establece en 2 de forma predeterminada.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

Opcional. Número de segundos que se debe esperar una respuesta a una comprobación de estado. De forma predeterminada, este valor se establece en 2 y tiene un mínimo de 1 y un máximo de 59. Este valor debe ser menor que el valor ibm-load-balancer-cloud-provider-vpc-health-check-delay, que se establece en 5 de forma predeterminada.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

Número máximo de reintentos de comprobación de estado para el equilibrador de carga de VPC. De forma predeterminada, este valor se establece en 2 y tiene un mínimo de 1 y un máximo de 10.

Habilitación de comprobaciones de estado de TCP para los equilibradores de carga de UDP

Como no hay comprobaciones de estado de UDP, los equilibradores de carga de UDP que utilizan comprobaciones de estado de TCP deben tener un puerto TCP adicional especificado con la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp.

Puede especificar el puerto de nodo TCP para otro equilibrador de carga o NodePort que se ejecuta en el clúster. Sin embargo, si el puerto del nodo reside fuera del rango de 30000-32767, debe modificar el grupo de seguridad del clúster de VPC kube-<cluster-ID> para permitir el tráfico entrante al puerto especificado.

Ten en cuenta que, si el valor de puerto especificado corresponde a un servicio que deja de funcionar de forma inesperada o cuyo valor de puerto se reconfigura, las comprobaciones de estado de TCP dejarán de funcionar hasta que el servicio vuelva a estar operativo o hasta que reconfigures la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp con un nuevo valor de puerto TCP. Para evitarlo, puede especificar el puerto kubelet 10250, que es un valor de puerto estático que no experimenta interrupciones de servicio. Sin embargo, debe modificar el grupo de seguridad de clúster de VPC kube-<cluster-ID> para aceptar el tráfico entrante desde el puerto kubelet.

¿Quieres evitar la complejidad que supone especificar puertos adicionales de TCP para las comprobaciones de estado en un equilibrador de carga de UDP? Establezca externalTrafficPolicy en Local para utilizar las comprobaciones de estado de HTTP, que no requieren especificaciones de puerto adicionales.