La configuración del equilibrio de carga implica la configuración de un servicio de equilibrador de carga de Kubernetes o un recurso de entrada y la controladora de replicación de NCP.

Puede crear un equilibrador de carga de capa 4 mediante la configuración de un servicio de Kubernetes de tipo equilibrador de carga, así como un equilibrador de carga de capa 7 mediante la configuración de un recurso de entrada de Kubernetes.

Para configurar el equilibrio de carga en NCP, en el archivo ncp-rc.yml:

  1. Establezca use_native_loadbalancer como True.
  2. (Opcional) Establezca pool_algorithm como ROUND_ROBIN o LEAST_CONNECTION/IP_HASH. El valor predeterminado es ROUND_ROBIN.
  3. (Opcional) Establezca service_size como SMALL, MEDIUM o LARGE. El valor predeterminado es SMALL.

El algoritmo LEAST_CONNECTION/IP_HASH indica que el tráfico de la misma dirección IP de origen se enviará al mismo pod de back-end.

Para obtener detalles sobre lo que admiten los equilibradores de carga de NSX-T de diferentes tamaños, consulte la Guía de administración de NSX-T Data Center.

Después de que se crea el equilibrador de carga, no es posible cambiar su tamaño actualizando el archivo de configuración. Se puede cambiar mediante la interfaz de usuario o la API de NSX Manager.

Configuración de persistencia para el equilibrio de carga de capa 4 y capa 7

Puede especificar una configuración de persistencia con los parámetros l4_persistence y l7_persistence en ConfigMap de NCP. La opción disponible para la persistencia de capa 4 es la IP de origen. Las opciones disponibles para la persistencia de capa 7 son IP de origen y cookie. El valor predeterminado es <None>. Por ejemplo,
   # Choice of persistence type for ingress traffic through L7 Loadbalancer.
   # Accepted values:
   # 'cookie'
   # 'source_ip'
   l7_persistence = cookie

   # Choice of persistence type for ingress traffic through L4 Loadbalancer.
   # Accepted values:
   # 'source_ip'
   l4_persistence = source_ip

Para los equilibradores de carga de Kubernetes, también puede establecer sessionAffinity en la especificación del servicio para configurar su comportamiento de persistencia si la persistencia global de capa 4 está desactivada (es decir, si l4_persistence se ha establecido como <None>). Si se ha establecido l4_persistence como source_ip, se puede utilizar sessionAffinity en la especificación de servicio para personalizar el tiempo de espera de la persistencia del servicio. El tiempo de espera predeterminado de la persistencia de capa 4 es de 10800 segundos (como se especifica en la documentación de Kubernetes para servicios (https://kubernetes.io/docs/concepts/services-networking/service). Los servicios con un tiempo de espera de persistencia predeterminado compartirán el mismo perfil de persistencia del equilibrador de carga de NSX-T. Se creará un perfil dedicado para cada servicio con un tiempo de espera de persistencia no predeterminado.

Nota: Si el servicio back-end de una entrada es un servicio de tipo equilibrador de carga, el servidor virtual de capa 4 para el servicio y el servidor virtual de capa 7 para la entrada no pueden tener configuraciones de persistencia diferentes (por ejemplo, source_ip para la capa 4 y cookie para la capa 7). En tal caso, la configuración de persistencia para ambos servidores virtuales debe ser la misma ( source_ip, cookie o None) o una de ellas debe ser None (y la otra configuración puede ser source_ip o cookie). A continuación, se muestra un ejemplo de este escenario:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
-----
apiVersion: v1
kind: Service
metadata:
  name: tea-svc <==== same as the Ingress backend above
  labels:
    app: tea
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: tcp
  selector:
    app: tea
  type: LoadBalancer

Entrada

  • NSX-T Data Center creará un equilibrador de carga de capa 7 para las entradas con especificación TLS y otro equilibrador de carga de capa 7 para las entradas sin especificación TLS.
  • Todas las entradas obtendrán una sola dirección IP.
  • Al recurso de entrada se le asigna una dirección IP del grupo de direcciones IP externas que la opción external_ip_pools especifica en la sección [nsx_v3] de ncp.ini. El equilibrador de carga se expone en esta dirección IP y los puertos HTTP y HTTPS (80 y 443).
  • Al recurso de entrada se le asigna una dirección IP del grupo de direcciones IP externas que la opción external_ip_pools_lb especifica en la sección [nsx_v3] de ncp.ini. Si la opción external_ip_pools_lb no existe, se utiliza el grupo que external_ip_pools especifica. El equilibrador de carga se expone en esta dirección IP y los puertos HTTP y HTTPS (80 y 443).
  • Puede utilizar otro grupo de direcciones IP cambiando la configuración y reiniciando NCP.
  • Puede especificar un certificado predeterminado para TLS. A continuación podrá obtener información sobre la generación de un certificado y el montaje de este en el pod de NCP.
  • Las entradas sin especificación TLS se alojarán en el servidor virtual HTTP (puerto 80).
  • Las entradas con especificación TLS se alojarán en el servidor virtual HTTPS (puerto 443). El equilibrador de carga actuará como servidor SSL y finalizará la conexión SSL de cliente.
  • El orden de creación de los secretos y las entradas es indiferente. Si existe el objeto secreto y hay una entrada que hace referencia a este, el certificado se importará a NSX-T Data Center. Si se eliminan el secreto o la última entrada que hace referencia a este, se eliminará el certificado correspondiente a dicho secreto.
  • Se admite la modificación de una entrada agregando o quitando la sección TLS. Cuando la clave tls se quita de la especificación de entrada, las reglas de entrada se transferirán del servidor virtual HTTPS (puerto 443) al servidor virtual HTTP (puerto 80). De igual modo, cuando la clave tls se agrega a la especificación de entrada, las reglas de entrada se transferirán del servidor virtual HTTP (puerto 80) al servidor virtual HTTPS (puerto 443).
  • Si hay reglas duplicadas en las definiciones de entrada de un solo clúster, solo se aplicará la primera regla.
  • Solo se admite una entrada con un back-end predeterminado en cada clúster. El tráfico que no coincida con ninguna regla de entrada se reenviará al back-end predeterminado.
  • Si hay varias entradas con back-end predeterminados, solo se configurará la primera. Las demás se anotarán con un error.
  • La coincidencia de URI de comodines se admite mediante los caracteres de expresión regular "." y "*". Por ejemplo, la ruta de acceso "/coffee/.*" coincide con "/coffee/" seguida de uno o varios caracteres (o bien de ninguno), como "/coffee/", "/coffee/a" o "/coffee/b", pero no con "/coffee", "/coffeecup" ni "/coffeecup/a".
    Un ejemplo de especificación de entrada:
    kind: Ingress
    metadata:
      name: cafe-ingress
    spec:
      rules:
      - http:
          paths:
          - path: /coffee/.*    #Matches /coffee/, /coffee/a but NOT /coffee, /coffeecup, etc.
            backend:
              serviceName: coffee-svc
              servicePort: 80
  • Puede configurar la reescritura de solicitud de la URL agregando una anotación en el recurso de entrada. Por ejemplo,
    kind: Ingress
    metadata:
      name: cafe-ingress
      annotations:
        ingress.kubernetes.io/rewrite-target: /
    spec:
      rules:
      - host: cafe.example.com
        http:
          paths:
          - path: /tea
            backend:
              serviceName: tea-svc
              servicePort: 80
          - path: /coffee
            backend:
              serviceName: coffee-svc
              servicePort: 80

    Las rutas de acceso /tea y /coffee se reescribirán como / antes de enviar la URL al servicio back-end.

  • Se admite la anotación de entrada kubernetes.io/ingress.allow-http.
    • Si la anotación se establece como false, solo se crearán reglas HTTPS.
    • Si falta la anotación o esta se establece como true, se crearán reglas HTTP. Asimismo, se crearán reglas HTTPS si la sección TLS está presente en la especificación de entrada.
  • Los errores se anotan en el recurso de entrada. La clave de error es ncp/error.loadbalancer y la clave de advertencia es ncp/warning.loadbalancer. El error y la advertencia posibles son:
    • ncp/error.loadbalancer: DEFAULT_BACKEND_IN_USE

      Este error indica que ya existe una entrada con un back-end predeterminado. La entrada estará inactiva. Solo puede haber un back-end predeterminado para un grupo de entradas con y sin TLS. Para solucionar el error, elimine y vuelva a crear la entrada con una especificación correcta.

    • ncp/warning.loadbalancer: SECRET_NOT_FOUND

      Este error indica que el secreto especificado en la especificación de entrada no existe. La entrada se activará parcialmente. Para solucionar el error, cree el secreto que falta. Tenga en cuenta que las advertencias incluidas en la anotación no se borrarán durante el ciclo de vida del recurso de entrada.

    • ncp/warning.loadbalancer: INVALID_INGRESS
      Este error indica que se cumple una de las siguientes condiciones. La entrada estará inactiva. Para solucionar el error, elimine y vuelva a crear la entrada con una especificación correcta.
      • Una regla de entrada entra en conflicto con otra regla de entrada en el mismo clúster de Kubernetes.
      • La anotación allow-http se establece como False y la entrada no tiene una sección TLS.
      • Una regla de entrada no tiene host ni path especificados. Una regla de entrada de este tipo tiene la misma funcionalidad que el back-end predeterminado de entrada. Utilice el back-end predeterminado de entrada en su lugar.

Servicio de tipo equilibrador de carga

  • NSX-T Data Center creará un grupo y un servidor virtual de equilibrador de carga de capa 4 por cada puerto de servicio.
  • Se admiten los protocolos TCP y UDP.
  • Cada servicio tendrá una dirección IP exclusiva.
  • Al servicio se le asigna una dirección IP de un grupo de direcciones IP externas según el campo loadBalancerIP de la definición del equilibrador de carga. El campo loadBalancerIP puede estar vacío, tener una dirección IP o el nombre o identificador de un grupo de direcciones IP. Si el campo loadBalancerIP está vacío, se asignará la dirección IP del grupo de direcciones IP externas especificada en la opción external_ip_pools_lb de la sección [nsx_v3] de ncp.ini. Si la opción external_ip_pools_lb no existe, se utiliza el grupo que external_ip_pools especifica. El servicio de equilibrador de carga se expone en esta dirección IP y en el puerto del servicio.
  • Puede utilizar otro grupo de direcciones IP cambiando la configuración y reiniciando NCP.
  • El grupo de direcciones IP especificado por loadBalancerIP debe tener la etiqueta scope: ncp/owner, tag: cluster:<cluster_name>.

  • Se anota un error en un servicio. La clave de error es ncp/error.loadbalancer. Los posibles errores son:
    • ncp/error.loadbalancer: IP_POOL_NOT_FOUND

      Este error indica que especifica loadBalancerIP: <nsx-ip-pool>, pero <nsx-ip-pool> no existe. El servicio estará inactivo. Para solucionar el error, especifique un grupo de direcciones IP válido, y elimine y vuelva a crear el servicio.

    • ncp/error.loadbalancer: IP_POOL_EXHAUSTED

      Este error indica que especifica loadBalancerIP: <nsx-ip-pool>, pero el grupo de direcciones IP ya agotó las direcciones IP. El servicio estará inactivo. Para solucionar el error, especifique un grupo de direcciones IP que tenga direcciones IP disponibles, y elimine y vuelva a crear el servicio.

    • ncp/error.loadbalancer: IP_POOL_NOT_UNIQUE

      Este error indica que varios grupos de direcciones IP tienen el nombre que loadBalancerIP especifica: <nsx-ip-pool>. El servicio estará inactivo.

    • ncp/error.loadbalancer: POOL_ACCESS_DENIED

      Este error indica que el grupo de direcciones IP que loadBalancerIP especifica no tiene la etiqueta scope: ncp/owner, tag: cluster:<cluster_name> o que el clúster especificado en la etiqueta no coincide con el nombre del clúster de Kubernetes.

    • ncp/error.loadbalancer: LB_VIP_CONFLICT

      Este error indica que la dirección IP especificada en el campo loadBalancerIP es la misma que la dirección IP de un servicio activo. El servicio estará inactivo.

  • Se admite el ajuste de escala automático del equilibrador de carga de capa 4. Si se crea o se modifica un servicio de equilibrador de carga de Kubernetes de manera que requiera servidores virtuales adicionales y el equilibrador de carga de capa 4 existente no tiene la capacidad, se creará un nuevo equilibrador de carga de capa 4. NCP también eliminará un equilibrador de carga de capa 4 que ya no tenga servidores virtuales asociados. Esta función está habilitada de forma predeterminada. Se puede deshabilitar estableciendo l4_lb_auto_scaling como false en ConfigMap de NCP.

Equilibrador de carga y directiva de red

Cuando el tráfico se reenvía a los pods desde el servidor virtual del equilibrador de carga de NSX, la IP de origen es la dirección IP del puerto de enlace ascendente del enrutador de nivel 1. Esta dirección se encuentra en la red de tránsito de nivel 1 privada y puede hacer que las directivas de red basadas en CIDR impidan el tráfico que se debería permitir. Para evitar este problema, la directiva de red debe configurarse de manera que la dirección IP del puerto de enlace ascendente del enrutador de nivel 1 sea parte del bloque de CIDR permitido. Esta dirección IP interna estará visible en el campo status.loadbalancer.ingress.ip y como una anotación (ncp/internal_ip_for_policy) en el recurso de entrada.

Por ejemplo, si la dirección IP externa del servidor virtual es 4.4.0.5 y la dirección IP del puerto de enlace ascendente del enrutador de nivel 1 interno es 100.64.224.11, el estado será:
    status:
      loadBalancer:
      ingress:
      - ip: 4.4.0.5
      - ip: 100.64.224.11
La anotación de la entrada y el servicio del tipo de recurso del equilibrador de carga será:
    ncp/internal_ip_for_policy: 100.64.224.11
La dirección IP 100.64.224.11 debe pertenecer al CIDR permitido en el selector de ipBlock de la directiva de red. Por ejemplo,
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    ...
    ingress:
    - from:
      - ipBlock:
         cidr: 100.64.224.11/32

Script de ejemplo para generar un certificado firmado por CA

Con el siguiente script se genera un certificado firmado por CA y una clave privada que se almacenan en los archivos <nombredearchivo>.crt y <nombredearchivo>.key respectivamente. El comando genrsa genera una clave de CA. La clave de CA debe estar cifrada. Se puede especificar un método de cifrado con el comando (p. ej., aes256).
#!/bin/bash
host="www.example.com"
filename=server

openssl genrsa -out ca.key 4096
openssl req -key ca.key -new -x509 -days 365 -sha256 -extensions v3_ca -out ca.crt -subj "/C=US/ST=CA/L=Palo Alto/O=OS3/OU=Eng/CN=${host}"
openssl req -out ${filename}.csr -new -newkey rsa:2048 -nodes -keyout ${filename}.key -subj "/C=US/ST=CA/L=Palo Alto/O=OS3/OU=Eng/CN=${host}"
openssl x509 -req -days 360 -in ${filename}.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out ${filename}.crt -sha256

Montar la clave y el certificado predeterminados en el pod de NCP

Tras generar la clave privada y el certificado, colóquelos en el directorio /etc/nsx-ujo en la máquina virtual del host. Suponiendo que los archivos de clave y de certificado se llaman lb-default.crt y lb-default.key respectivamente, edite ncp-rc.yaml para que estos archivos en el host se monten en el pod. Por ejemplo,
spec:
  ...
  containers:
  - name: nsx-ncp
    ...
    volumeMounts:
    ...
    - name: lb-default-cert
      # Mount path must match nsx_v3 option "lb_default_cert_path"
      mountPath: /etc/nsx-ujo/lb-default.crt
    - name: lb-priv-key
      # Mount path must match nsx_v3 option "lb_priv_key_path"
      mountPath: /etc/nsx-ujo/lb-default.key
  volumes:
  ...
  - name: lb-default-cert
    hostPath:
      path: /etc/nsx-ujo/lb-default.crt
  - name: lb-priv-key
    hostPath:
      path: /etc/nsx-ujo/lb-default.key