Gestión de balanceadores de carga VPC

Realice cambios en sus balanceadores de carga VPC existentes.

No cambie el nombre de ningún NLB o ALB de la VPC. Al cambiar el nombre de un equilibrador de carga de VPC se produce un error en el servicio LoadBalancer Kubernetes, lo que podría afectar a su carga de trabajo.

Balanceadores de carga VPC persistentes

Por defecto, los balanceadores de carga VPC se eliminan cuando se elimina el cluster al que están asociados. Sin embargo, al crear una definición de servicio LoadBalancer, puede hacer que su equilibrador de carga sea persistente para que siga estando disponible incluso después de que se elimine su clúster. Un equilibrador de carga VPC persistente puede aplicarse a un clúster diferente después de que se elimine su clúster anterior.

Los nombres de los balanceadores de carga VPC tienen el formato kube-<cluster_ID>-<kubernetes_lb_service_UID> por defecto. Cuando se elimina un clúster, este formato de nombre especifica los equilibradores de carga asociados que también se eliminan. Para asegurarse de que su equilibrador de carga no se elimine cuando elimine un clúster, incluya la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name en su definición de servicio LoadBalancer para dar a su equilibrador de carga un nombre único. El nombre del equilibrador de carga debe ser único dentro de su VPC y solo puede incluir caracteres alfanuméricos en minúsculas y guiones (-). La anotación puede aplicarse a todos los tipos de equilibrador de carga de VPC.

Usted es responsable de eliminar los equilibradores de carga VPC persistentes cuando ya no sean necesarios. Para eliminar un equilibrador de carga de VPC persistente, elimine la definición de servicio Kubernetes LoadBalancer a la que está asociado el equilibrador de carga de VPC.

Traslado de un equilibrador de carga de VPC de un clúster a otro

Los equilibradores de carga de VPC persistentes pueden separarse de un clúster de VPC y conectarse a otro. El nuevo clúster debe estar dentro de la misma VPC que el clúster original.

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

Los equilibradores de carga de VPC están vinculados a la definición de servicio Kubernetes LoadBalancer con la que se crearon. Para desvincular un equilibrador de carga de VPC persistente de un clúster, debe romper el vínculo con el servicio LoadBalancer. Al hacerlo, el servicio LoadBalancer queda inutilizado y puede eliminarse de forma segura. El equilibrador de carga de la VPC puede entonces adjuntarse a un clúster diferente.

Para romper el vínculo entre el equilibrador de carga de la VPC y el servicio LoadBalancer, puede renombrar el equilibrador de carga de la VPC o eliminar la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name de la definición del servicio LoadBalancer original. Tenga en cuenta que esta es la única circunstancia en la que debe cambiar el nombre de un equilibrador de carga de VPC, ya que al hacerlo se crea un error para el recurso Kubernetes. Sin embargo, si su objetivo final es utilizar el equilibrador de carga VPC en un clúster diferente, este error no interrumpe su carga de trabajo. No cambie el nombre del equilibrador de carga de la VPC si desea mantener el equilibrador de carga en el mismo clúster.

Adjuntar un equilibrador de carga 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 de Kubernetes que haga referencia al equilibrador de carga de VPC.

Al crear un nuevo servicio 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 la VPC (ALB, NLB) y el tipo de IP (pública, privada) deben coincidir con las especificaciones del servicio LoadBalancer. Por ejemplo, no se puede utilizar un servicio LoadBalancer existente en el nuevo clúster que especifique un tipo NLB para adjuntar 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.

No es necesario que los puertos de puerto y nodo especificados en el servicio LoadBalancer coincidan con aquellos con los que se creó el equilibrador de carga de la VPC. El equilibrador de carga de la VPC se reconfigura con las definiciones de puerto del servicio LoadBalancer al que está asociado en el nuevo clúster.

Comprobaciones de estado para los equilibradores de carga

Los equilibradores de carga de VPC se configuran automáticamente con comprobaciones de estado, que se configuran con la anotación externalTrafficPolicy. Puede utilizar anotaciones adicionales para personalizar comprobaciones de estado en sus balanceadores de carga.

  • Si externalTrafficPolicy se establece en Cluster, se aplican comprobaciones de estado de TCP. Si está configurando un equilibrador de carga de UDP, debe realizar especificaciones de puerto adicionales.
  • Si externalTrafficPolicy se establece en Local, se aplican comprobaciones de estado de HTTP. El tráfico entrante se entrega sólo al pod de aplicación que reside en ese nodo específico. Si no hay ningún pod de aplicación en ese nodo específico, el tráfico entrante se descarta.

El ajuste externalTrafficPolicy: Local podría hacer que fallaran las comprobaciones de estado de los nodos trabajadores del equilibrador de carga. Normalmente, este resultado es el comportamiento esperado y no indica necesariamente un problema, ya que el tráfico se elimina intencionadamente si el equilibrador de carga intenta conectarse a cualquier nodo que no tenga un pod de aplicación. Para obtener más información, consulte ¿Por qué fallan las comprobaciones de estado del equilibrador de carga de VPC en mis nodos de trabajador?.

Personalización de las comprobaciones de estado de los equilibradores de carga VPC

Para tener un mayor control sobre las comprobaciones de estado del equilibrador de carga de su VPC, puede utilizar anotaciones opcionales para personalizar sus comprobaciones de estado con configuraciones avanzadas para intervalos de prueba, tiempos de espera 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 de equilibrador de carga de VPC asociado al servicio de equilibrador de carga Kubernetes. Normalmente, el protocolo de comprobación de estado de VPC LB viene determinado por el valor del ajuste externalTrafficPolicy de la especificación del servicio de balanceador de carga Kubernetes. 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
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 de Kubernetes (30 000-32 767), se debe 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 equilibrador 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 de acceso URL debe tener el formato de un destino de solicitud de formulario 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 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 valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que se establece en 2 por defecto.
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 al valor ibm-load-balancer-cloud-provider-vpc-health-check-delay, que se establece en 5 por defecto.
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 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. En el caso de los clústeres de 4.14 y versiones anteriores, si el puerto del nodo se encuentra fuera del 30000-32767 rango, debe modificar el grupo de seguridad del clúster 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 se interrumpe 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, para las versiones de clúster 4.14 y anteriores, debe modificar el grupo de seguridad del clúster VPC kube-<cluster-ID> para que acepte el tráfico entrante procedente de dicho 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.

Cambiar la subred o zona de un equilibrador de carga

Después de crear un VPC NLB, no se puede reconfigurar la subred de escucha con la que se creó. Si desea cambiar la subred de escucha de un VPC NLB existente, debe eliminar, actualizar y volver a aplicar el servicio LoadBalancer correspondiente de Kubernetes.

  1. Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

  2. Obtenga una lista de los servicios de Kubernetes y busque el nombre del servicio LoadBalancer que desea cambiar.

    oc get services

    Ejemplo de salida.

    NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                        AGE
my-load-balancer         LoadBalancer   172.21.77.198   52.118.150.107   8080:32767/TCP,443:30943/TCP   5d

  3. Busque el equilibrador de carga de VPC que corresponde al servicio LoadBalancer de Kubernetes.

    Los nombres del equilibrador de carga de VPC están en el formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Para ver el ID de clúster, ejecute ibmcloud ks cluster get --cluster CLUSTER_NAME. Para ver el UID del servicio LoadBalancer de Kubernetes, ejecute oc get svc LOAD_BALANCER_NAME -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 equilibrador de carga de la VPC.

    ibmcloud is load-balancers

    Ejemplo de salida.

    ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group      
r000-5aaaa11f6-c111-111f-b2e0-1c11aaaaf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf11111111fe4ca3f11111cb   Network       subnet-1                                  true        active             online             default                                                    Application

  4. Obtenga la definición de servicio LoadBalancer de Kubernetes y guarde la salida como un archivo yaml llamado my-lb.yaml.

    oc describe service my-load-balancer -o yaml

  5. Suprima el servicio LoadBalancer de Kubernetes. Esta acción también suprime el equilibrador de carga de VPC correspondiente.

    oc delete service my-load-balancer

  6. Actualice el archivo de definición de servicio LoadBalancer de Kubernetes con los cambios de subred o de zona que desea implementar. No cambie el nombre del servicio LoadBalancer. Para obtener detalles sobre la especificación de subredes o zonas para los equilibradores de carga de red, consulte Configuración de un equilibrador de carga de red para VPC.

  7. Aplique el nuevo archivo de definición LoadBalancer.

    oc apply -f my-lb.yaml

  8. Verifique que el servicio LoadBalancer de Kubernetes se vuelva a crear correctamente en el clúster. Al crear el servicio, el campo LoadBalancer (Ingreso de ) se rellena con una dirección IP externa para el NLB.

    oc describe service my-load-balancer

    Ejemplo de salida.

    NAME:                     my-load-balancer
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.X.XXX.XX
LoadBalancer Ingress:     169.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.XX.XX.XXX:8080,172.XX.XX.XX:8080,172.XX.XX.XX:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
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/my-load-balancer with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.

  9. Verifique que el equilibrador de carga de VPC se vuelva a crear y que se actualice la subred o la zona. Ten en cuenta que el aprovisionamiento del equilibrador de carga de VPC tarda unos minutos y es posible que veas un estado create_pending hasta que se haya completado el aprovisionamiento.

    ibmcloud is load-balancers

    Ejemplo de salida.

    ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group     
r006-5ecc68f6-c751-409f-b2e0-1c69babf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf03445796fe4ca3f73885cb   Network       subnet-2                                  true        active             online             default