Configuración del equilibrio de carga

El equilibrador de carga de NSX-T Data Center está integrado con OpenShift y actúa como enrutador de OpenShift.

NCP supervisa los eventos de endpoint y la ruta de OpenShift, y configura las reglas de equilibrio de carga en el equilibrador de carga en función de la especificación de ruta. A raíz de ello, el equilibrador de carga de NSX-T Data Center reenviará el tráfico entrante de capa 7 a los pods de back-end adecuados según las reglas.

La configuración del equilibrio de carga conlleva configurar un servicio de equilibrador de carga de Kubernetes o una ruta de OpenShift. También se debe configurar el controlador de replicación de NCP. El servicio de equilibrador de carga corresponde al tráfico de capa 4, mientras que la ruta de OpenShift corresponde al tráfico de capa 7.

Cuando se configura un servicio de equilibrador de carga de Kubernetes, se le asigna una dirección IP del bloque de IP externo que se haya configurado. El equilibrador de carga se expone en esta dirección IP y en el puerto del servicio. Puede especificar el nombre o el identificador de un grupo de IP usando la especificación loadBalancerIP en la definición del equilibrador de carga. La IP del servicio de equilibrador de carga se asignará a partir de este grupo de direcciones IP. Si la especificación loadBalancerIP está vacía, la IP se asignará a partir del bloque de direcciones IP externo que configure.

El grupo de direcciones IP especificado por loadBalancerIP debe tener la etiqueta scope: ncp/owner, tag: cluster:<cluster_name>.

Para usar el equilibrador de carga de NSX-T Data Center, hay que configurar el equilibrio de carga de NCP. En el archivo ncp_rc.yml, haga lo siguiente:

1. Establezca use_native_loadbalancer como True.
2. Establezca pool_algorithm como WEIGHTED_ROUND_ROBIN.
3. Establezca lb_default_cert_path y lb_priv_key_path como los nombres de ruta completa del archivo de certificado firmado por CA y del archivo de clave privada, respectivamente. A continuación se incluye un script de ejemplo que permite generar un certificado firmado por CA. Adicionalmente, monte la clave y el certificado predeterminados en el pod de NCP. Consulte las instrucciones más adelante.
4. (Opcional) Especifique una configuración de persistencia con los parámetros l4_persistence y l7_persistence. 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

5. (Opcional) Establezca service_size como SMALL, MEDIUM o LARGE. El valor predeterminado es SMALL.
6. Si ejecuta OpenShift 3.11, debe aplicar la siguiente configuración de manera que OpenShift no asigne una dirección IP al servicio de equilibrador de carga.

   • Establezca ingressIPNetworkCIDR como 0.0.0.0/32 en networkConfig en el archivo /etc/origin/master/master-config.yaml.
   • Reinicie los controladores y el servidor de API con los siguientes comandos:

        master-restart api
        master-restart controllers

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

Particionamiento de enrutadores

En OpenShift 4, cada ruta puede tener cualquier número de etiquetas en su campo de metadatos. Un enrutador utiliza selectores para seleccionar un subconjunto de rutas de todo el grupo de rutas. Una selección también puede incluir etiquetas en los espacios de nombres de la ruta. Las rutas seleccionadas forman una partición de ruta.

Puede crear particiones de rutas para fines como el siguiente:

• Configure la entrada en función de las etiquetas de ruta o los espacios de nombres.
• Configure diferentes rutas para las aplicaciones.
• Distribuya la carga de trabajo entre varios servicios del equilibrador de carga para mejorar el rendimiento.

Esta función solo admite el particionamiento de servicios de equilibrador de carga de capa 7.

Pasos para configurar el particionamiento del enrutador:

1. Establezca la opción enable_lb_crd en True en la sección [k8s] de configmap.yaml y aplique el archivo YAML. Cree y aplique un archivo YAML que defina un CRD de equilibrador de carga (CustomResourceDefinition). Por ejemplo,

   apiVersion: vmware.com/v1alpha1
   kind: LoadBalancer
   metadata:
       name: lbs-crd-1
   spec:
       httpConfig:
           virtualIP: 192.168.4.4          # VIP for HTTP/HTTPS server. Default to auto_allocate
           port: 81                        # HTTP port number. Default to 80
           tls:
               port: 9998                  # HTTPS port number. default to 443
               secretName: default_secret  # Default certificate for HTTPS server. Default to nil
               secretNamespace: default    # Need to be set with secretName
           xForwardedFor: INSERT           # Available values are INSERT, REPLACE. Default to nil
           affinity:
               type: source_ip             # Available values are sourceIP, cookie
               timeout: 100                # Default to 10800
       size: MEDIUM                        # Default to SMALL

2. Configure un enrutador con un selector de etiquetas de espacio de nombres ejecutando el siguiente comando (suponiendo que el dc/svc del enrutador sea router):

   oc set env dc/router NAMESPACE_LABELS="router=r1"

3. El enrutador configurado en el paso anterior controlará las rutas de los espacios de nombres seleccionados. Para que este selector coincida con un espacio de nombres, etiquete el espacio de nombres según corresponda. Por ejemplo,

   apiVersion: v1
   kind: Route
   metadata:
     name: cafe-route
     annotations:
       nsx/loadbalancer: lbs-crd-1
   spec:
     host: cafe.example.com
     to:
       kind: Service
       name: tea-svc
       weight: 1

   Ejecute el siguiente comando:

   oc label namespace targetns "router=r1"

   Reemplace targetns con el espacio de nombres exacto en el que se encuentran las rutas de destino. Por ejemplo,

   apiVersion: v1
   kind: Namespace
   metadata:
       name: qe
       annotations:
           nsx/loadbalancer: lbs-crd-1

   Nota: Si una ruta dentro de un espacio de nombres tiene otra anotación, la anotación de la ruta tendrá prioridad.

Ejemplo de equilibrador de carga de capa 7

Con el siguiente archivo YAML se configuran dos controladores de replicación (tea-rc y coffee-rc), dos servicios (tea-svc y coffee-svc) y dos rutas (cafe-route-multi y cafe-route) para proporcionar equilibrio de carga de capa 7.

# RC
apiVersion: v1
kind: ReplicationController
metadata:
  name: tea-rc
spec:
  replicas: 2
  template:
    metadata:
       labels:
         app: tea
    spec:
      containers:
      - name: tea
        image: nginxdemos/hello
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: ReplicationController
metadata:
  name: coffee-rc
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: nginxdemos/hello
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
# Services
apiVersion: v1
kind: Service
metadata:
  name: tea-svc
  labels:
    app: tea
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: tea
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
  labels:
    app: coffee
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: coffee
---
# Routes
apiVersion: v1
kind: Route
metadata:
  name: cafe-route-multi
spec:
  host: www.cafe.com
  path: /drinks
  to:
    kind: Service
    name: tea-svc
    weight: 1
  alternateBackends:
  - kind: Service
    name: coffee-svc
    weight: 2
---
apiVersion: v1
kind: Route
metadata:
  name: cafe-route
spec:
  host: www.cafe.com
  path: /tea-svc
  to:
    kind: Service
    name: tea-svc
    weight: 1

Notas adicionales

• Se admiten todos los modos de finalización: edge, passthrough y reencrypt.
• Se admiten subdominios comodín. Por ejemplo, si wildcardPolicy está establecido como Subdomain y el nombre de host se establece como wildcard.example.com, se atenderá cualquier solicitud a *.ejemplo.com.
• Si NCP genera un error al procesar un evento de ruta debido a una configuración errónea, será necesario corregir el archivo YAML de la ruta y, a continuación, eliminar y volver a crear el recurso de ruta.
• NCP no aplica la propiedad de nombre de host por espacios de nombres.
• Se admite un servicio de equilibrador de carga por cada clúster de Kubernetes.
• NSX-T Data Center creará un grupo y un servidor virtual de equilibrador de carga de capa 4 por cada puerto de servicio de equilibrador de carga. Se admiten los protocolos TCP y UDP.
• El equilibrador de carga de NSX-T Data Center viene en diferentes tamaños. Para obtener información sobre la configuración de un equilibrador de carga de NSX-T Data Center, 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.

• 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.
• En una especificación de ruta, el parámetro destinationCACertificate no es compatible y NCP lo ignorará.
• Cada ruta TLS debe tener un certificado firmado por una entidad de certificación (CA) diferente.

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