Antes de empezar

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

   ibmcloud plugin install infrastructure-service
   

4. Para NLB de VPC privada: Conéctese a la red privada de su VPC, por ejemplo, a través de una conexión VPN de VPC.
5. Para NLB de VPC privada: Habilita tu app para recibir peticiones de red privada.
   1. Crea una subred de VPC dedicada a tu VPC NLB. 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. 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. Después de aprovisionar la subred, anote su ID.
   2. Si el cliente que se conecta a tu aplicación a través del VPC NLB se encuentra fuera de la VPC y de la zona de tu subred VPC dedicada, debes crear una tabla de enrutamiento de entrada personalizada. Para obtener más información, consulte la tabla de las limitaciones conocidas y Acerca de rutas y tablas de direccionamiento. Seleccione uno de los siguientes orígenes de tráfico para su tabla de enrutamiento de entrada personalizada: Para el tráfico procedente de una red local, seleccione Enlace directo. Para el tráfico procedente de otra VPC o de una infraestructura clásica, seleccione Pasarela de tránsito. Para el tráfico de otra zona dentro de la misma VPC, seleccione Zona VPC. Para obtener más información, consulte Configuración de la conectividad VPN de la VPC.

Configure el servicio LoadBalancer

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. En el archivo YAML, especifique la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type como "public" o "private". La sección annotations del archivo de ejemplo sólo incluye algunas anotaciones disponibles. Para obtener una lista completa de las anotaciones NLB de VPC obligatorias y opcionales, consulte Anotaciones y especificaciones.

   Para que su VPC NLB sea fácilmente identificable, 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: "public"
       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>"
   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.
   

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

   oc apply -f <filename>.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 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` público:
```sh {: screen}
NAME:                     myapp-vpc-nlb-us-east
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     169.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.
```

5. 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       yes         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.241.0.7               active             169.63.99.184                 c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

6. Acceda a la dirección IP del servicio LoadBalancer de Kubernetes que ha encontrado en el paso 4 y al puerto de la aplicación con el formato <external_IP>:<app_port>.

7. Opcional: repita estos pasos para desplegar un NLB público de VPC en cada zona en la que desee exponer su app. A continuación, puede registrar las direcciones IP externas del VPC NLB en cada zona con un subdominio DNS.

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 VPC NLB que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.

Configuración de un NLB público utilizando un rango de puertos

Los rangos de puertos se pueden utilizar en NLB públicos cuando existe la necesidad de alojar un servicio desde un único nombre de host que tiene múltiples aplicaciones backend, cada una escuchando en un número de puerto distinto. Para utilizar rangos de puertos en su cluster Kubernetes, es necesario realizar alguna configuración manual. En primer lugar, debe configurarse 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 fijarse en el valor mínimo del rango de puertos.

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

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

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

El usuario realiza una petición al puerto 30001 del NLB que contiene el rango de puertos. Esta solicitud se dirige al servicio NLB de la VPC que dirige la solicitud al servicio Nodeport del clúster que también está escuchando 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 mediante el siguiente ejemplo. El selector y los pods de backend deben estar asociados con el servicio de balanceador de carga de rango de puertos para que las comprobaciones de salud devuelvan éxito 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 del equilibrador de carga.

1. Guarde el siguiente ejemplo de configuración de LoadBalancer como un archivo llamado 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. Crea el servicio.

   oc apply -f loadbalancer.yaml
   

3. Cree un servicio NodePort con valores de puerto que se encuentren en el rango de puertos especificado en LoadBalancer que creó 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.

Anotaciones y especificaciones requeridas

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

Notas para crear un VPC NLB. Si no incluye esta anotación y especifica nlb, se crea un ALB de VPC por defecto.

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

(Obligatorio para los NLB privados) Anotación para especificar un servicio que acepte solicitudes privadas. Si no se incluye esta anotación, se crea un NLB VPC público.

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

(Obligatorio para NLB privados, opcional para NLB públicos) 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_ID --zone ZONE.

externalTrafficPolicy

Especifique Local o Cluster.

Establezca en Local para conservar la dirección IP de origen de las solicitudes de cliente a las apps. Esta configuración impide que el tráfico entrante se reenvíe a un nodo diferente. Esta opción también configura las comprobaciones de estado de HTTP.

Si se establece Cluster, DSR se implementa solo desde el nodo trabajador al que el VPC NLB reenvía primero la solicitud entrante. Una vez recibida la solicitud, ésta se reenvía a un nodo trabajador que contiene el pod de aplicación, 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 », es necesario utilizar el « service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp » 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 ».

Anotaciones y especificaciones opcionales

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

Incluya un nombre único para que su equilibrador de carga VPC sea persistente. Los balanceadores de carga VPC persistentes no se eliminan cuando se elimina el clúster al que pertenecen. Para obtener más información, consulte Balanceadores de carga VPC persistentes. Esta anotación sólo puede establecerse al crear el equilibrador de carga. No puede utilizarse en una operación de actualización.

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. El VPC NLB se despliega en la misma subred de la zona a la que están conectados los nodos trabajadores. Si más adelante cambia esta anotación a otra zona, el NLB de VPC no se mueve a la nueva zona. Si no especifica esta anotación o la dirección service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets annotation, el NLB de la VPC se despliega en la zona más óptima (como una zona que tenga nodos de trabajador en el estado Ready ). Si la etiqueta dedicated: edge está configurada en los nodos de trabajo y se especifica esta anotación, solo los nodos periféricos de la zona especificada se configurarán para recibir tráfico. 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. To see zones, run ibmcloud ks zone ls --provider vpc-gen2.

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

Anotación para especificar un selector de etiquetas de nodos de trabajo. Puede configurar nodos de trabajo específicos en su clúster para recibir tráfico especificando claves de selección de etiquetas. Solo se puede incluir un selector de etiqueta en la anotación, y dicho selector debe especificarse en el formato "key=value". Si no se especifica esta anotación, todos los nodos de trabajo del clúster se configuran para recibir tráfico procedente del VPC NLB. Esta anotación tiene prioridad sobre la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, y se ignoran las etiquetas dedicated: edge de los nodos de trabajo. Para limitar el tráfico a una zona específica, puede utilizar esta anotación para especificar nodos trabajadores en esa zona. Tenga en cuenta que el establecimiento de una nueva etiqueta en un nodo trabajador del clúster no configura automáticamente el nodo trabajador para recibir tráfico; debe volver a crear o actualizar el NLB de la VPC para que el nodo trabajador recién etiquetado reciba tráfico.

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

El puerto del nodo TCP que se debe utilizar para las comprobaciones de estado de TCP en un equilibrador de carga 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

Esta anotación establece el protocolo de comprobación de estado en el recurso del equilibrador de carga de la VPC asociado al servicio del equilibrador de carga Kubernetes. Las opciones disponibles son http, https, o tcp. Normalmente, el protocolo de comprobación del estado del VPC LB viene determinado por el valor de la configuración externalTrafficPolicy en la especificación del servicio del equilibrador de carga Kubernetes. Sin embargo, esta anotación anula esa lógica. Esta anotación no altera cómo Kubernetes, y kube-proxy en particular, se comporta con respecto a las diversas configuraciones de externalTrafficPolicy.

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

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), será necesario modificar 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, es necesario modificar las reglas de salida del grupo de seguridad asignado al VPC ALB para permitir el tráfico saliente hacia el puerto TCP especificado. Para obtener más información, consulte Comprensión de las redes VPC de clúster seguras por defecto y Creación y gestión de grupos de seguridad VPC.

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

La ruta de comprobación de salud URL para las comprobaciones de salud HTTP y HTTPs. Esta anotación sólo se aplica si ibm-load-balancer-cloud-provider-vpc-health-check-protocol está configurado como http o https. La ruta URL debe tener el formato de un destino de solicitud origen-forma. 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 por defecto /.

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

Opcional. El número de segundos que hay que esperar entre los intentos de chequeo. Por defecto, 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 de ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que por defecto es 2.

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

Opcional. El número de segundos que hay que esperar para recibir una respuesta a una comprobación de estado. Por defecto, este valor se establece en 2, y tiene un mínimo de 1 y un máximo de 59. Este valor debe ser inferior a ibm-load-balancer-cloud-provider-vpc-health-check-delay, que por defecto es 5.

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 la VPC. Por defecto, este valor se fija en 2, y tiene un mínimo de 1 y un máximo de 10.

service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"

Versión 4.16 o o posterior.

Registra la dirección IP del equilibrador de carga con el dominio de entrada especificado. Si el dominio especificado no existe, se crea un dominio que utiliza el proveedor interno gestionado por IBM (IBM NS1). Para crear un dominio nuevo, el nombre debe ser único en todos los dominios existentes (no solo en los de su clúster). Al eliminar el servicio del equilibrador de carga se elimina la dirección IP del dominio. Sin embargo, la eliminación de la anotación no elimina la dirección IP del dominio.

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. En el caso de un clúster con nodos de trabajo en tres zonas, esto hace que el equilibrador de carga dirija el tráfico a un total de 24 nodos de trabajo. 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

Versión 1.30 y posteriores.

Opcional. Un grupo de seguridad gestionado por el cliente para añadir al equilibrador de carga de la VPC. Si no desea utilizar el grupo de seguridad IBM-managed, especifique un grupo de seguridad que posea y gestione. Esta opción elimina el grupo de seguridad IBM-managed 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 añadido por el grupo de seguridad gestionado IBM. Puede añadir o eliminar esta anotación en cualquier momento. Usted es responsable de gestionar su grupo de seguridad y mantenerlo actualizado.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-allow-outbound-traffic

Disponible para los clusters que ejecutan Secure by Default. Anotación para crear grupos de seguridad para cada dirección IP de un ALB asociada a un puerto externo que especifique. Estas reglas se crean en el grupo de seguridad del clúster. Especifique los puertos externos válidos en una lista separada por comas, como 80,443. En este ejemplo, si cada ALB público asociado con cada valor de puerto externo tiene dos direcciones IP, se crea una regla de salida por dirección IP para un total de 4 reglas nuevas. Puede añadir o eliminar esta anotación en cualquier momento.

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 TCP en este puerto de destino. El puerto de destino suele definirse estáticamente en la imagen que se ejecuta en el pod de aplicación. El puerto de destino configurado en el pod es diferente del puerto de nodo para el servicio y también podría ser diferente del puerto externo que está configurado en la VPC LB.