Migra la configuración del balanceador de cargas F5 BIG-IP

Vista previa

Esta función está sujeta a las "Condiciones de la oferta de la fase previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles "sin modificaciones" y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

1.29: Versión preliminar
1.28: No disponible

En este documento, se muestra cómo migrar la configuración de la integración del balanceador de cargas F5 BIG-IP al modo de balanceo de cargas manual para clústeres en la versión 1.29. Si tus clústeres tienen la versión 1.30 o posterior, te recomendamos que sigas las instrucciones que se indican en Planifica la migración del clúster a las funciones recomendadas.

Usar F5 BIG-IP en el modo de balanceo de cargas manual te brinda la flexibilidad de actualizar tus agentes de F5 de forma independiente sin afectar la funcionalidad de tu balanceador de cargas de F5 ni tus servicios de Kubernetes. Si migras a la configuración manual, puedes obtener actualizaciones directamente de F5 para garantizar un rendimiento y una seguridad óptimos.

Nota: Si eliges cambiar la configuración de los archivos de configuración del clúster para usar el balanceo de cargas manual para F5 BIG-IP, esto no significa que tu balanceo de cargas sea manual. Con el balanceo de cargas de F5 incluido o manual, los agentes del balanceador de cargas te ayudan a administrar la configuración del balanceo de cargas de forma automática.

Esta migración es obligatoria en las siguientes circunstancias:

• Quieres habilitar funciones nuevas, como Controlplane V2, y también necesitas acceso a F5.

• Necesitas las capacidades que proporciona una versión del controlador de Ingress Services (CIS) de BIG-IP CIS superior a la v1.14.

Si las circunstancias anteriores no se aplican a tu caso, puedes seguir usando la configuración incluida para el balanceo de cargas de F5 BIG-IP.

De cualquier manera, seguimos admitiendo oficialmente F5 como solución de balanceador de cargas.

Compatibilidad con el balanceador de cargas de BIG-IP de F5

Admitimos el uso de F5 BIG-IP con agentes de balanceador de cargas, que consisten en los siguientes dos controladores:

• F5 Controller (prefijo del pod: load-balancer-f5): Concilia los servicios de Kubernetes de tipo LoadBalancer en el formato ConfigMap de la biblioteca principal del controlador común (CCCL) de F5.

• F5 BIG-IP CIS Controller v1.14 (prefijo de Pod: k8s-bigip-ctlr-deployment): Traduce ConfigMaps en configuraciones de balanceador de cargas de F5.

Estos agentes optimizan la configuración de los balanceadores de cargas de F5 en tu clúster de Kubernetes. Cuando creas un servicio de tipo LoadBalancer, los controladores configuran automáticamente el balanceador de cargas de F5 para dirigir el tráfico a los nodos del clúster.

Sin embargo, la solución agrupada tiene limitaciones:

• La expresividad de la API de Service es limitada. No puedes configurar el controlador de BIG-IP como quieras ni usar funciones avanzadas de F5. F5 ya proporciona una mejor compatibilidad con la API de Service de forma nativa.

• La implementación usa la API de ConfigMap de CCCL heredada y la CIS 1.x. Sin embargo, F5 ahora proporciona la API de ConfigMap AS3 más reciente y el CIS 2.x.

El controlador de CIS en el paquete de Google Distributed Cloud se mantuvo en la versión 1.14 debido a problemas de compatibilidad con la guía de actualización de F5 para la versión 2.x de CIS. Por lo tanto, para brindarte la flexibilidad necesaria para abordar las vulnerabilidades de seguridad y acceder a las funciones más recientes, estamos realizando la transición de los agentes de F5 de componentes incluidos a componentes instalados de forma independiente. Si migras, puedes seguir usando los agentes existentes sin interrupciones y los servicios que creaste anteriormente seguirán operativos.

En el caso de los clústeres de balanceo de cargas manual recién creados con F5 como solución de balanceo de cargas, debes instalar los controladores por tu cuenta. Del mismo modo, si tu clúster se migró desde F5 incluido y deseas usar una versión más reciente del CIS Controller, debes instalar los controladores por tu cuenta.

Requisitos

A continuación, se indican los requisitos para la migración:

• El clúster de administrador y todos los clústeres de usuario deben ser de la versión 1.29 o superior.

• Debes usar direcciones IP estáticas para los nodos del clúster de administrador y de usuario. El tipo de direccionamiento IP se establece en el campo network.ipMode.type y es inmutable. Si este campo está configurado como DHCP, no podrás migrar los clústeres.

Actualiza el archivo de configuración del clúster de usuario

Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:

1. Cambia loadBalancer.kind a "ManualLB".

2. Mantén los mismos valores para los campos loadBalancer.vips.controlPlaneVIP y loadBalancer.vips.ingressVIP.

3. Configura el nodePort que se usa para el tráfico HTTP que se envía a la VIP de entrada.

   1. Obtén el valor actual de nodePort de HTTP:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          get svc istio-ingress -n gke-system -oyaml | grep http2 -A 1

      Reemplaza USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de usuario.

   2. Agrega el valor del comando anterior al campo loadBalancer.manualLB.ingressHTTPNodePort, por ejemplo:

      loadBalancer:
        manualLB:
          ingressHTTPNodePort: 30243

4. Configura el nodePort que se usa para el tráfico HTTPS que se envía a la VIP de entrada:

   1. Obtén el valor actual de nodePort de HTTPS:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          get svc istio-ingress -n gke-system -oyaml | grep https -A 1

   2. Agrega el valor del comando anterior al campo loadBalancer.manualLB.ingressHTTPSNodePort, por ejemplo:

      loadBalancer:
        manualLB:
          ingressHTTPSNodePort: 30879

5. Configura el nodePort para el servidor de la API de Kubernetes:

   1. Obtén el valor actual de nodePort para el servidor de la API de Kubernetes:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep kube-apiserver-port -A 1

      Reemplaza lo siguiente:

      • ADMIN_CLUSTER_KUBECONFIG con la ruta de acceso del archivo kubeconfig del clúster de administrador

      • USER_CLUSTER_NAME: Es el nombre del clúster de usuario.

   2. Agrega el valor del comando anterior al campo loadBalancer.manualLB.controlPlaneNodePort, por ejemplo:

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968

6. Configura nodePort para el servidor de Konnectivity:

   1. Obtén el valor nodePort actual para el servidor de Konnectivity:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep konnectivity-server-port -A 1

   2. Agrega el valor del comando anterior al campo loadBalancer.manualLB.konnectivityServerNodePort, por ejemplo:

      loadBalancer:
        manualLB:
          konnectivityServerNodePort: 30563

7. Borra toda la sección loadBalancer.f5BigIP.

Actualiza el clúster de usuario

Ejecuta el siguiente comando para migrar el clúster:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Reemplaza lo siguiente:

• ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

• USER_CLUSTER_CONFIG: la ruta del archivo de configuración de tu clúster de usuario.

Actualiza el archivo de configuración del clúster de administrador

Realiza los siguientes cambios en el archivo de configuración del clúster de administrador:

1. Cambia loadBalancer.kind a "ManualLB".

2. Mantén el mismo valor para el campo loadBalancer.vips.controlPlaneVIP.

3. Comprueba el valor del campo adminMaster.replicas. Si el valor es 3, el clúster de administrador tiene alta disponibilidad (HA). Si el valor es 1, el clúster de administrador no es de alta disponibilidad.

4. Sigue estos pasos solo para los clústeres de administrador sin HA:

   1. Obtén el valor de nodePort para el servidor de la API de Kubernetes:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          get svc kube-apiserver -n kube-system -oyaml | grep nodePort

      Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

   2. Agrega el valor del comando anterior al campo loadBalancer.manualLB.controlPlaneNodePort, por ejemplo:

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968

5. Ejecuta el siguiente comando para ver si hay un nodePort de complementos:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       get deploy monitoring-operator -n kube-system -oyaml | grep admin-ingress-nodeport

   Si el comando anterior genera un valor, agrégalo al campo loadBalancer.manualLB.addonsNodePort, por ejemplo:

   loadBalancer:
     manualLB:
       addonsNodePort: 31405

6. Borra toda la sección loadBalancer.f5BigIP.

Actualiza el clúster de administrador

Ejecuta el siguiente comando para actualizar el clúster:

gkectl update admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

Reemplaza lo siguiente:

• ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

• ADMIN_CLUSTER_CONFIG: Es la ruta de acceso al archivo de configuración del clúster de administrador.

Verifica que aún existan recursos heredados de F5

Después de actualizar tus clústeres para que usen el balanceo de cargas manual, el tráfico a tus clústeres no se interrumpe porque los recursos existentes de F5 siguen existiendo, como puedes ver si ejecutas el siguiente comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG \
  api-resources --verbs=list -o name   | xargs -n 1 kubectl --kubeconfig CLUSTER_KUBECONFIG get --show-kind --ignore-not-found --selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

Reemplaza CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de administrador o del clúster de usuario.

El resultado esperado es similar al siguiente:

Clúster de administrador:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z

Clúster de usuario:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z

Verifica tu balanceador de cargas

Después de la migración, no deberías tener que cambiar ningún parámetro de configuración en tu balanceador de cargas, ya que conservaste las mismas VIP y los mismos valores de nodePort. En las siguientes tablas, se describen las asignaciones de VIP a direcciones IP de nodos:nodePort.

Clúster de administrador con alta disponibilidad

Tráfico a los nodos del plano de control

Google Distributed Cloud controla automáticamente el balanceo de cargas del tráfico del plano de control para los clústeres de administrador con HA. Si bien no es necesario que configures una asignación en el balanceador de cargas, debes especificar una dirección IP en el campo loadBalancer.vips.controlPlaneVIP.

Tráfico a los servicios en los nodos del complemento

Si tu clúster de administrador tenía un valor para addonsNodePort, deberías ver una asignación a las direcciones IP y el valor de nodePort para el tráfico a los servicios en los nodos de complementos:

• (addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Debes tener esta asignación para todos los nodos del clúster de administrador, tanto los nodos del plano de control como los nodos de complemento.

Clúster de administrador sin alta disponibilidad

Tráfico del plano de control

A continuación, se muestra la asignación a la dirección IP y el valor de nodePort para el nodo del plano de control:

• (controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)

Debes tener esta asignación para todos los nodos del clúster de administrador, tanto el nodo del plano de control como los nodos de complemento.

Tráfico a los servicios en los nodos del complemento

Si tu clúster de administrador tenía un valor para addonsNodePort, deberías tener la siguiente asignación a las direcciones IP y los valores de nodePort para los servicios que se ejecutan en los nodos de complementos:

• (addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Debes tener esta asignación para todos los nodos del clúster de administrador, tanto el nodo del plano de control como los nodos de complemento.

Clúster de usuario

Tráfico del plano de control

A continuación, se muestra la asignación a las direcciones IP y los valores de nodePort para el tráfico del plano de control:

• (controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)
• (controlPlaneVIP:8132) -> (NODE_IP_ADDRESSES:konnectivityServerNodePort)

Debes tener esta asignación para todos los nodos del clúster de administrador, tanto el clúster de administrador como los nodos del plano de control del clúster de usuario.

Tráfico del plano de datos

A continuación, se muestra la asignación a las direcciones IP y los valores de nodePort para el tráfico del plano de datos:

• (ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort)
• (ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)

Nota: La verificación de estado en ingressVIP fallará hasta que configures al menos una entrada.