L'équilibreur de charge NSX-T Data Center est intégré à OpenShift et est utilisé comme routeur OpenShift.

NCP surveille les événements de routage et de point de terminaison OpenShift, et configure les règles d'équilibrage de charge en fonction de la spécification de la route. En conséquence, l'équilibreur de charge NSX-T Data Center transférera le trafic de couche 7 entrant vers les espaces principaux en fonction des règles.

La configuration de l'équilibrage de charge implique la configuration d'un service Kubernetes LoadBalancer ou d'une route OpenShift. Vous devez également configurer le contrôleur de réplication NCP. Le service LoadBalancer est pour le trafic de couche 4 et la route OpenShift est pour le trafic de couche 7.

Lorsque vous configurez un service Kubernetes LoadBalancer, une adresse IP est allouée au service à partir du bloc d'adresses IP externe que vous configurez. L'équilibreur de charge est exposé sur cette adresse IP et sur le port de service. Vous pouvez spécifier le nom ou l'ID d'un pool d'adresses IP à l'aide de la spécification loadBalancerIP dans la définition de l'équilibreur de charge. L'adresse IP du service d'équilibreur de charge sera allouée à partir de ce pool d'adresses IP. Si la spécification loadBalancerIP est vide, l'adresse IP sera allouée à partir du bloc d'adresses IP externe que vous configurez.

Le pool d'adresses IP spécifié par loadBalancerIP doit avoir la balise scope: ncp/owner, tag: cluster:<cluster_name>.

Pour utiliser l'équilibreur de charge NSX-T Data Center, vous devez configurer l'équilibrage de charge dans NCP. Dans le fichier ncp_rc.yml, procédez comme suit :

  1. Définissez use_native_loadbalancer = True.
  2. Définissez pool_algorithm sur WEIGHTED_ROUND_ROBIN.
  3. Définissez lb_default_cert_path et lb_priv_key_path comme noms de chemin d'accès complet du fichier de certificat signé par une autorité de certification et du fichier de clé privée, respectivement. Reportez-vous à la section ci-dessous pour un exemple de script permettant de générer un certificat signé par une autorité de certification. En outre, placez le certificat et la clé par défaut dans l'espace NCP. Reportez-vous à la section ci-dessous pour obtenir des instructions.
  4. (Facultatif) Spécifiez un paramètre de persistance avec les paramètres l4_persistence et l7_persistence. Les options disponibles pour la persistance de la couche 4 est l'adresse IP source. Les options disponibles pour la persistance de la couche 7 sont le cookie et l'adresse IP source. La valeur par défaut est <None>. Par exemple, 
       # 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. (Facultatif) Définissez service_size = SMALL, MEDIUM ou LARGE. La valeur par défaut est SMALL.
  6. Si vous utilisez OpenShift 3.11, vous devez effectuer la configuration suivante pour qu'OpenShift n'attribue aucune adresse IP au service LoadBalancer.
    • Définissez ingressIPNetworkCIDR sur 0.0.0.0/32 sous networkConfig dans le fichier /etc/origin/master/master-config.yaml.
    • Redémarrez le serveur d'API et les contrôleurs à l'aide des commandes suivantes : 
         master-restart api
   master-restart controllers

Pour un service Kubernetes LoadBalancer, vous pouvez également spécifier sessionAffinity sur la spécification de service pour configurer le comportement de persistance du service si la persistance de couche 4 globale est désactivée, c'est-à-dire que l4_persistence est défini sur <None>. Si l4_persistence est défini sur source_ip, sessionAffinity sur la spécification de service peut être utilisé pour personnaliser le délai d'expiration de la persistance pour le service. Le délai d'expiration de la persistance de couche 4 par défaut est de 10 800 secondes (identique à celui spécifié dans la documentation Kubernetes pour les services) (https://kubernetes.io/docs/concepts/services-networking/service). Tous les services ayant un délai d'expiration de persistance par défaut partageront le même profil de persistance d'équilibreur de charge NSX-T. Un profil dédié sera créé pour chaque service avec un délai d'expiration de persistance non défini par défaut.

Note : Si le service du serveur principal d'une entrée est un service de type LoadBalancer, le serveur virtuel de couche 4 pour le service et le serveur virtuel de couche 7 pour l'entrée ne peuvent pas avoir de paramètres de persistance différents, par exemple, source_ip pour la couche 4 et cookie pour la couche 7. Dans un tel scénario, les paramètres de persistance des deux serveurs virtuels doivent être les mêmes ( source_ip, cookie ou None), ou l'un d'entre eux peut être None (l'autre peut alors être source_ip ou cookie). Exemple d'un tel scénario : 
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

Partitionnement de routeur

Dans OpenShift 4, chaque route peut avoir n'importe quel nombre d'étiquettes dans son champ de métadonnées. Un routeur utilise des sélecteurs pour sélectionner un sous-ensemble de routes dans l'ensemble du pool de routes. Une sélection peut également impliquer des étiquettes sur les espaces de noms de la route. Les routes sélectionnées forment une partition de route.

Vous pouvez créer des partitions de route à des fins telles que les suivantes :
  • Configurer l'entrée en fonction des étiquettes de route ou des espaces de noms.
  • Configurer différentes routes pour les applications.
  • Distribuer la charge de travail sur plusieurs services d'équilibreur de charge pour améliorer les performances.

Cette fonctionnalité prend uniquement en charge le partitionnement des services d'équilibreur de charge de couche 7.

Étapes de configuration du partitionnement de routeur :
  1. Définissez l'option enable_lb_crd sur True dans la section [k8s] de configmap.yaml et appliquez le fichier YAML. Créez et appliquez un fichier YAML qui définit un CRD LoadBalancer (CustomResourceDefinition). Par exemple,
    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. Configurez un routeur avec un sélecteur d'étiquette d'espace de noms en exécutant la commande suivante (en supposant que le dc/svc du routeur est le routeur) :
    oc set env dc/router NAMESPACE_LABELS="router=r1"
  3. Le routeur configuré à l'étape précédente gérera les routes à partir des espaces de noms sélectionnés. Pour que ce sélecteur corresponde à un espace de noms, nommez l'espace de noms en conséquence. Par exemple,
    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
    Exécutez la commande suivante : 
    oc label namespace targetns "router=r1"
    Remplacez targetns par l'espace de noms exact dans lequel se trouvent les routes cibles. Par exemple, 
    apiVersion: v1
kind: Namespace
metadata:
    name: qe
    annotations:
        nsx/loadbalancer: lbs-crd-1

    Remarque : si une route à l'intérieur d'un espace de noms a une autre annotation, l'annotation de route est prioritaire.

Exemple d'équilibreur de charge de couche 7

Le fichier YAML suivant configure deux contrôleurs de réplication (tea-rc et coffee-rc), deux services (tea-svc et coffee-svc) et deux routes (cafe-route-multi et cafe-route) pour assurer l'équilibrage de charge de couche 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

Remarques supplémentaires

  • Tous les modes de terminaison sont pris en charge : edge, passthrough et reencrypt.
  • Un sous-domaine de caractères génériques est pris en charge. Par exemple, si wildcardPolicy est défini sur Sous-domaine et que le nom d'hôte est défini sur wildcard.example.com, toute demande à *.example.com est traitée.
  • Si NCP génère une erreur lors du traitement d'un événement Route en raison d'une mauvaise configuration, vous devez corriger le fichier Route YAML, puis supprimer et recréer la ressource Route.
  • NCP n'applique pas la propriété de nom d'hôte par espaces de noms.
  • Un service LoadBalancer est pris en charge par cluster Kubernetes.
  • NSX-T Data Center crée un serveur virtuel et un pool d'équilibreur de charge de couche 4 pour chaque port de service LoadBalancer. TCP et UDP sont pris en charge.
  • L'équilibreur de charge NSX-T Data Center est fourni dans différentes tailles. Pour plus d'informations sur la configuration d'un équilibreur de charge NSX-T Data Center, consultez le Guide d'administration de NSX-T Data Center.

    Après la création de l'équilibreur de charge, la taille d'équilibreur de charge ne peut pas être modifiée en mettant à jour le fichier de configuration. Elle peut être modifiée au moyen de l'interface utilisateur ou de l'API.

  • La mise à l'échelle automatique de l'équilibreur de charge de couche 4 est prise en charge. Si un service LoadBalancer Kubernetes est créé ou modifié pour qu'il requiert des serveurs virtuels supplémentaires et que l'équilibreur de charge de couche 4 existant n'a pas la capacité, un nouvel équilibreur de charge de couche 4 sera créé. NCP supprimera également les équilibreurs de charge de couche 4 qui n'ont plus aucun serveur virtuel associé. Cette fonctionnalité est activée par défaut. Vous pouvez la désactiver en définissant l4_lb_auto_scaling sur false dans le ConfigMap NCP.
  • Dans une spécification de route, le paramètre destinationCACertificate n'est pas pris en charge et sera ignoré par NCP.
  • Chaque route TLS doit disposer d'un certificat signé par une autorité de certification différent.

Exemple de script permettant de générer un certificat signé par une autorité de certification

Le script ci-dessous génère un certificat signé par une autorité de certification et une clé privée stockés dans les fichiers <filename>.crt et <finename>.key, respectivement. La commande genrsa génère une clé d'autorité de certification. La clé d'autorité de certification doit être chiffrée. Vous pouvez spécifier une méthode de chiffrement avec la commande aes256, par exemple. 
#!/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