La configuration de l'équilibrage de charge implique la configuration d'un service Kubernetes LoadBalancer ou d'une ressource d'entrée et du contrôleur de réplication NCP.

Vous pouvez créer un équilibreur de charge de couche 4 en configurant un service Kubernetes de type équilibreur de charge et un équilibreur de charge de couche 7 en configurant une ressource d'entrée Kubernetes.

Pour configurer l'équilibrage de charge dans NCP, dans le fichier ncp-rc.yml :

  1. Définissez use_native_loadbalancer = True.
  2. (Facultatif) Définissez pool_algorithm sur ROUND_ROBIN ou LEAST_CONNECTION/IP_HASH. La valeur par défaut est ROUND_ROBIN.
  3. (Facultatif) Définissez service_size = SMALL, MEDIUM ou LARGE. La valeur par défaut est SMALL.

Avec l'algorithme LEAST_CONNECTION/IP_HASH, le trafic à partir de la même adresse IP source est envoyé au même espace de serveur principal.

Pour plus de détails sur la prise en charge des équilibrages de charge NSX-T de différentes tailles, reportez-vous au 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 de NSX Manager.

Configuration de la persistance pour l'équilibrage de charge des couches 4 et 7

Vous pouvez spécifier un paramètre de persistance avec les paramètres l4_persistence et l7_persistence dans le ConfigMap de NCP. 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

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

Entrée

  • NSX-T Data Center crée un équilibreur de charge de couche 7 pour les entrées avec spécification TLS et un équilibreur de charge de couche 7 pour les entrées sans spécification TLS.
  • Tous les entrées obtiennent une adresse IP unique.
  • Une adresse IP est allouée à la ressource d'entrée à partir du pool d'adresses IP externe spécifié par l'option external_ip_pools dans la section [nsx_v3] de ncp.ini. L'équilibreur de charge est exposé sur cette adresse IP et les ports HTTP et HTTPS (80 et 443).
  • Une adresse IP est allouée à la ressource d'entrée à partir du pool d'adresses IP externe spécifié par l'option external_ip_pools_lb dans la section [nsx_v3] de ncp.ini. Si l'option external_ip_pools_lb n'existe pas, le pool spécifié par external_ip_pools est utilisé. L'équilibreur de charge est exposé sur cette adresse IP et les ports HTTP et HTTPS (80 et 443).
  • Vous pouvez spécifier un pool d'adresses IP différent en modifiant la configuration et en redémarrant NCP.
  • Vous pouvez spécifier un certificat par défaut pour TLS. Voir ci-dessous pour plus d'informations sur la création et le placement d'un certificat dans l'espace NCP.
  • Les entrées sans spécification TLS sont hébergées sur le serveur virtuel HTTP (port 80).
  • Les entrées avec spécification TLS sont hébergées sur le serveur virtuel HTTPS (port 443). L'équilibreur de charge agit comme serveur SSL et termine la connexion SSL client.
  • L'ordre de création des secrets et des entrées n'a pas d'importance. Si l'objet secret est présent et qu'une entrée y fait référence, le certificat est importé dans NSX-T Data Center. Si le secret est supprimé ou si la dernière entrée y faisant référence est supprimée, le certificat correspondant au secret est supprimé.
  • La modification d'une entrée par l'ajout ou la suppression d'une section TLS n'est pas prise en charge. Lorsque la clé tls est supprimée de la spécification des entrées, les règles d'entrée sont transférées vers le serveur virtuel HTTP (port 80) à partir du serveur virtuel HTTPS (port 443). De même, lorsque la clé tls est ajoutée à la spécification des entrées, les règles d'entrée sont transférées vers le serveur virtuel HTTPS (port 443) à partir du serveur virtuel HTTP (port 80).
  • En présence de règles en double dans les définitions d'entrée pour un cluster unique, seule la première règle s'applique.
  • Une seule entrée avec serveur principal par défaut est prise en charge par cluster. Le trafic ne correspondant à aucune règle d'entrée est transféré au serveur principal par défaut.
  • En présence de plusieurs entrées avec un serveur principal par défaut, seule la première est configurée. Les autres sont annotées avec une erreur.
  • La correspondance d'URI à l'aide de caractère générique est prise en charge grâce à l'utilisation des caractères d'expression régulière « . » et « * ». Par exemple, le chemin d'accès « /coffee/.* » correspond à « /coffee/ » suivi de zéro, un ou plusieurs caractères, tels que « /coffee/ », « /coffee/a », « /coffee/b », mais pas « /coffee », « /coffeecup » ou « /coffeecup/a ».
    Exemple de spécification d'entrée :
    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
  • Vous pouvez configurer la réécriture de demande d'URL en ajoutant une annotation à la ressource d'entrée. Par exemple,
    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

    les chemins d'accès /tea et /coffee seront réécrits en / avant que l'URL ne soit envoyée au service principal.

  • L'annotation d'entrée kubernetes.io/ingress.allow-http est prise en charge.
    • Si l'annotation est définie sur false, seules les règles HTTPS sont créées.
    • Si l'annotation est définie sur true ou si elle est manquante, les règles HTTP sont créées. Les règles HTTPS sont également créées si la section TLS est présente dans la spécification d'entrée.
  • Les erreurs sont annotées dans la ressource d'entrée. L'erreur clé est ncp/error.loadbalancer et la clé d'avertissement est ncp/warning.loadbalancer. L'erreur et l'avertissement possibles sont :
    • ncp/error.loadbalancer : DEFAULT_BACKEND_IN_USE

      Cette erreur indique qu'il existe déjà une entrée avec un serveur principal par défaut. L'entrée sera inactive. Il ne peut y avoir qu'un seul serveur principal par défaut pour un groupe d'entrées avec et sans TLS. Pour corriger l'erreur, supprimez et recréez l'entrée avec une spécification correcte.

    • ncp/warning.loadbalancer : SECRET_NOT_FOUND

      Cette erreur indique que le secret indiqué dans la spécification d'entrée n'existe pas. L'entrée sera partiellement active. Pour corriger l'erreur, créez le secret manquant. Notez qu'une fois qu'un avertissement est dans l'annotation, il ne sera pas effacé pendant le cycle de vie de la ressource d'entrée.

    • ncp/warning.loadbalancer : INVALID_INGRESS
      Cette erreur indique que l'une des conditions suivantes est vraie. L'entrée sera inactive. Pour corriger l'erreur, supprimez et recréez l'entrée avec une spécification correcte.
      • Une règle d'entrée est en conflit avec une autre règle d'entrée dans le même cluster Kubernetes.
      • L'annotation allow-http est définie sur False et l'entrée n'a pas de section TLS.
      • host et path ne sont pas spécifiés dans une règle d'entrée. Une telle règle d'entrée a la même fonctionnalité que le serveur principal par défaut d'entrée. Utilisez plutôt le serveur principal d'entrée par défaut.

Service de type LoadBalancer

  • NSX-T Data Center crée un serveur virtuel et un pool d'équilibreur de charge de couche 4 pour chaque port de service.
  • TCP et UDP sont pris en charge.
  • Chaque service aura une adresse IP unique.
  • Une adresse IP est allouée au service à partir d'un pool d'adresses IP externe basé sur le champ loadBalancerIP dans la définition LoadBalancer. Le champ loadBalancerIP peut être vide, avoir une adresse IP ou le nom ou l'ID d'un pool d'adresses IP. Si le champ loadBalancerIP est vide, l'adresse IP est allouée à partir du pool d'adresses IP externe spécifié par l'option external_ip_pools_lb dans la section [nsx_v3] de ncp.ini. Si l'option external_ip_pools_lb n'existe pas, le pool spécifié par external_ip_pools est utilisé. Le service de LoadBalancer est exposé sur cette adresse IP et sur le port de service.
  • Vous pouvez spécifier un pool d'adresses IP différent en modifiant la configuration et en redémarrant NCP.
  • Le pool d'adresses IP spécifié par loadBalancerIP doit avoir la balise scope: ncp/owner, tag: cluster:<cluster_name>.

  • Les erreurs sont annotées dans un service. L'erreur clé est ncp/error.loadbalancer. Les erreurs possibles sont :
    • ncp/error.loadbalancer : IP_POOL_NOT_FOUND

      Cette erreur indique que vous spécifiez loadBalancerIP : <nsx-ip-pool> mais <nsx-ip-pool> n'existe pas. Le service sera inactif. Pour corriger l'erreur, spécifiez un pool d'adresses IP valide, supprimez et recréez le service.

    • ncp/error.loadbalancer : IP_POOL_EXHAUSTED

      Cette erreur indique que vous spécifiez loadBalancerIP : <nsx-ip-pool> mais le pool d'adresses IP a épuisé ses adresses IP. Le service sera inactif. Pour corriger l'erreur, spécifiez un pool d'adresses IP ayant des adresses IP disponibles, supprimez et recréez le service.

    • ncp/error.loadbalancer : IP_POOL_NOT_UNIQUE

      Cette erreur indique que plusieurs pools d'adresses IP portent le nom spécifié par loadBalancerIP : <nsx-ip-pool>. Le service sera inactif.

    • ncp/error.loadbalancer : POOL_ACCESS_DENIED

      Cette erreur indique que le pool d'adresses IP spécifié par loadBalancerIP n'a pas la balise scope: ncp/owner, tag: cluster:<cluster_name> ou le cluster spécifié dans la balise ne correspond pas au nom du cluster Kubernetes.

    • ncp/error.loadbalancer : LB_VIP_CONFLICT

      Cette erreur indique que l'adresse IP dans le champ loadBalancerIP est la même que celle d'un service actif. Le service sera inactif.

  • 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.

Équilibreur de charge et stratégie réseau

Lorsque le trafic est transféré vers les espaces à partir du serveur virtuel d'équilibreur de charge NSX, l'adresse IP source est l'adresse IP du port de liaison montante du routeur de niveau 1. Cette adresse se trouve sur le réseau privé de transit de niveau 1. En conséquence, les stratégies réseaux basées sur CIDR peuvent interdire un trafic normalement autorisé. Pour éviter ce problème, la stratégie réseau doit être configurée de telle sorte que l'adresse IP du port de liaison montante du routeur de niveau 1 fasse partie du bloc CIDR autorisé. Cette adresse IP interne sera visible dans le champ status.loadbalancer.ingress.ip et sous forme d'annotation (ncp/internal_ip_for_policy) sur la ressource d'entrée.

Par exemple, si l'adresse IP externe du serveur virtuel est 4.4.0.5 et que l'adresse IP du port de liaison montante du routeur de niveau 1 interne est 100.64.224.11, l'état sera :
    status:
      loadBalancer:
      ingress:
      - ip: 4.4.0.5
      - ip: 100.64.224.11
L'annotation sur la ressource d'entrée et le service de type LoadBalancer sera :
    ncp/internal_ip_for_policy: 100.64.224.11
L'adresse IP 100.64.224.11 doit appartenir au CIDR autorisé dans le sélecteur ipBlock de la stratégie réseau. Par exemple,
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    ...
    ingress:
    - from:
      - ipBlock:
         cidr: 100.64.224.11/32

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

Placer le certificat et la clé par défaut dans l'espace NCP

Une fois le certificat et la clé privée générés, placez-les dans le répertoire /etc/nsx-ujo sur la machine virtuelle hôte. En supposant que les fichiers de certificat et de clé sont nommés lb-default.crt et lb-default.key, respectivement, modifiez ncp-rc.yaml afin que ces fichiers, stockés sur l'hôte, soient placés dans l'espace. Par exemple,
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