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'équilibrage 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'équilibrage de charge. L'adresse IP du service d'équilibrage 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 {"ncp/owner": cluster:<cluster>}.

Pour utiliser l'équilibrage 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 LoadBalancer Kubernetes, 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'équilibrage 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

NCP gère toujours la terminaison Edge TLS et les routes HTTP, et ignore les routes de relais TLS. TLS chiffre à nouveau les routes indépendamment de leurs espaces de noms ou de leurs étiquettes d'espaces de noms. Pour limiter un routeur OpenShift à la gestion des routes de rechiffrement et de relais TLS, procédez comme suit :

  • Ajoutez un sélecteur d'étiquettes d'espaces de noms pour le routeur Openshift.

  • Ajoutez une étiquette d'espace de noms à l'espace de noms cible.

  • Créez des routes TLS de rechiffrement/relais dans l'espace de noms cible.

Par exemple, pour configurer un routeur avec un sélecteur d'étiquettes d'espaces de noms, exécutez la commande suivante (en partant du principe que le nom du compte de service de routeur est router) :

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

Le routeur gérera dorénavant les routes depuis les espaces de noms sélectionnés. Pour que ce sélecteur corresponde à un espace de noms, exécutez la commande suivante (en partant du principe que l’espace de noms est appelé ns1) :

oc label namespace ns1 "router=r1"

Exemple d'équilibrage 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

  • Seule la terminaison Edge est prise en charge pour le trafic HTTPS.

  • 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'équilibrage de charge de couche 4 pour chaque port de service LoadBalancer. TCP et UDP sont pris en charge.

  • L'équilibrage de charge NSX-T Data Center est fourni dans différentes tailles. Pour plus d'informations sur la configuration d'un équilibrage de charge NSX-T Data Center, consultez le Guide d'administration de NSX-T Data Center.

    Après la création de l'équilibrage de charge, la taille d'équilibrage 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'équilibrage 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'équilibrage de charge de couche 4 existant n'a pas la capacité, un nouvel équilibrage de charge de couche 4 sera créé. NCP supprimera également les équilibrages 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.

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