NCP créera 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. Vous pouvez également créer des CRD (CustomResourceDefinitions) pour gérer la mise à l'échelle d'entrée.

Notez les points suivants :
  • 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.
  • 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. Les autres entrées avec les règles en double seront annotées avec une erreur. Par exemple, si vous créez deux entrées avec les mêmes host et path, et qu'une entrée est TLS alors que l'autre est non-TLS et que kubernetes.io/ingress.allow-http est false, les deux règles seront créées sur des serveurs virtuels différents et ne seront pas en conflit entre elles. Toutefois, si kubernetes.io/ingress.allow-http est true, l'entrée qui est appliquée ultérieurement sera annotée avec une erreur. Pour plus d'informations, reportez-vous à la section ci-dessous.
  • 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. Pour plus d'informations, reportez-vous à la section ci-dessous.
  • Les règles sont appliquées dans l'ordre suivant :
    1. Règles avec host et path spécifiés, et sans correspondance d'expression régulière.
    2. Règles avec host et path spécifiés, et avec une correspondance d'expression régulière (d'abord avec le path d'entrée le plus long).
    3. Règles avec host ou path spécifié, et sans correspondance d'expression régulière.
    4. Règles avec host ou path spécifié, et avec une correspondance d'expression régulière (avec le path d'entrée le plus long).
  • (Cela s'applique si vous utilisez le mode de stratégie.) Si une entrée TLS est créée avec un serveur principal par défaut, il est recommandé de configurer le serveur principal par défaut pour répondre aux demandes HTTP et HTTPS, car :
    • L'équilibreur de charge arrête TLS et envoie des demandes HTTP au serveur principal par défaut s'il existe une entrée TLS (dans le cluster en cas d'utilisation de Kubernetes/PKS, ou dans le même espace de noms en cas d'utilisation du projet Pacifique) avec l'hôte qui correspond à l'hôte dans la demande.
    • L'équilibreur de charge rechiffre et envoie une demande HTTPS au serveur principal s'il n'y a pas d'entrée TLS (dans le cluster en cas d'utilisation de Kubernetes/PKS, ou dans le même espace de noms en cas d'utilisation du projet Pacifique) avec l'hôte qui correspond à l'hôte dans la demande.
  • La ressource IngressClass, l'attribut PathType et les caractères génériques Hostname ne sont pas pris en charge.

Annotations de fonctionnalités

Le tableau suivant répertorie les annotations prises en charge par NCP :
Annotation Description Valeurs prises en charge Valeur par défaut Version de NCP
kubernetes.io/ingress.allow-http Active les demandes HTTP en plus de HTTPS true, false true 2.5 et versions ultérieures
ncp/use-regex Active la correspondance du modèle de chemin true, false false 2.5.1 et versions ultérieures
ingress.kubernetes.io/rewrite-target Réécrit le chemin d'accès de la demande entrante
  • (NCP 2.5 et versions ultérieures) Chemin commençant par ‘/’
  • (NCP 2.5.1 et versions ultérieures, et NSX-T 2.5.1 et versions ultérieures) Chemin d'accès avec un espace réservé numéroté pour un groupe capturé dans une expression régulière, par exemple, /$1
Aucune valeur par défaut Voir la colonne Valeurs prises en charge
ncp/http-redirect Redirige les demandes HTTP vers HTTPS true, false false 2.5.1 et versions ultérieures
kubernetes.io/ingress.class Indique quel contrôleur d'entrée est responsable de cette entrée nsx, nginx, etc. nsx 2.5 et versions ultérieures
nsx/loadbalancer Place une entrée sur un équilibreur de charge dédié Nom d'un LoadBalancer CRD Aucune valeur par défaut 2.5.1 et versions ultérieures
ncp/whitelist-source-range Limite l'accès d'entrées par adresse IP source de la demande Liste de CIDR, d'adresses IP ou de plages d'adresses IP séparés par des virgules. Aucune valeur par défaut 3.0.0 et versions ultérieures
ncp/ssl-mode Sélectionne le mode SSL pour toutes les règles dans une entrée déchargement, rechiffrement, relais déchargement 3.0.1 et versions ultérieures
Détails à propos des annotations :
  • Correspondance Regex (expression régulière) de chemin d'accès
    • Pour NCP 2.5.0 et versions antérieures

      Dans NCP 2.5.0 et versions antérieures, toutes les correspondances de sous-chemins sont automatiquement activées à l'aide des caractères d'expression régulière '.' et '*'. Par exemple, le chemin d'accès /coffee/.* correspond à /coffee/ suivi d'un zéro, d'un ou plusieurs caractères, tels que /coffee/, /coffee/a et /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
    • Pour NCP 2.5.1 et versions ultérieures
      Vous pouvez activer ou désactiver la correspondance d'expression régulière du paramètre d'entrée path (mais pas host) à l'aide de l'annotation ncp/use-regex. Si cette valeur est définie sur false, la correspondance exacte du chemin d'accès sera effectuée en réalisant la correspondance equals. Si cette valeur est définie sur true, la correspondance d'expression régulière sera effectuée en ajoutant le début du caractère de chaîne (^) et la fin du caractère de chaîne ($) au chemin afin que l'URI de la demande complète corresponde au modèle. Notez que lorsque vous utilisez l'opérateur OR (|), spécifiez toujours l'étendue avec des parenthèses afin que ^ et $ s'appliquent à tous les opérandes. Par exemple, path: /(tea|coffee|milk). Exemple de spécification d'entrée :
      apiVersion: extensions/v1beta1
      kind: Ingress
      metadata:
        name: cafe-ingress
        annotations:
          kubernetes.io/ingress.class: "nsx"
          ncp/use-regex: "true"
      spec:
        rules:
        - host: cafe.example.com
          http:
            paths:
            - path: /tea/.*
              backend:
                serviceName: tea-svc
                servicePort: 80
    • Mise à jour des entrées avant la mise à niveau de NCP vers la version 2.5.1 ou versions supérieures
      Cela est requis uniquement si vous avez des entrées nécessitant une correspondance de tous les sous-chemins utilisant les caractères '.' et '*'.
      1. Mettez à jour les entrées pour inclure l'annotation ncp/use-regex: true.
      2. Pour toutes les correspondances de sous-chemins, si vous disposez de chemins d'accès tels que /coffee/* ou /*, modifiez-les en /coffee/.* et /.*.

        /coffee/.* correspondra à /coffee/, /coffee/a, /coffee/b, /coffee/a/b, etc. /.* correspondra à /coffee, /tea, /coffee/a, etc. L'omission du chemin d'accès produira le même comportement que path: /.*.

  • Exemple de l'annotation ingress.kubernetes.io/rewrite-target :
    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.

    À partir de NCP 2.5.1 et NSX-T 2.5.1, si path est spécifié à l'aide d'une expression régulière, les groupes capturés sont enregistrés dans des espaces réservés numérotés au format $1, $2, etc. Ces espaces réservés peuvent être utilisés comme paramètres dans l'annotation ingress.kubernetes.io/rewrite-target. Les groupes de capture et les espaces réservés nommés ne sont pas pris en charge. Par exemple,
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: cafe-ingress
      annotations:
        kubernetes.io/ingress.class: "nsx"
        ncp/use-regex: "true"
        #/tea/cup will be rewritten to /cup before sending request to endpoint
        ingress.kubernetes.io/rewrite-target: /$1
    spec:
      rules:
      - host: cafe.example.com
        http:
          paths:
          - path: /tea/(.*)
            backend:
              serviceName: tea-svc
              servicePort: 80
  • À propos de l'annotation kubernetes.io/ingress.allow-http :
    • Si l'annotation est définie sur false, des règles seront créées pour le serveur virtuel HTTPS.
    • Si l'annotation est définie sur true ou manquante, des règles seront créées pour les serveurs virtuels HTTP et HTTPS. Notez que les règles HTTPS sont également créées si la section TLS est présente dans la spécification d'entrée.
  • À propos de l'annotation ncp/http-redirect :
    • Si l'annotation est définie sur false, le trafic HTTP entrant (port 80) vers le serveur virtuel HTTP ne sera pas redirigé vers le serveur virtuel HTTPS.
    • Si l'annotation est définie sur true, le trafic HTTP entrant (port 80) vers le serveur virtuel HTTP sera redirigé vers le serveur virtuel HTTPS (port 443).

    Cette annotation n'est valide que si la section TLS est présente. Cette annotation est prioritaire sur kubernetes.io/ingress.allow-http. Lorsqu'elle est définie sur true, elle redirige le trafic HTTP vers HTTPS, quelle que soit la manière dont kubernetes.io/ingress.allow-http est défini.

  • À propos de l'annotation kubernetes.io/ingress.class :
    • Si la valeur est nsx, cette entrée sera gérée par NCP. Si une autre valeur est spécifiée, l'entrée sera ignorée par NCP. Pour plus d'informations, consultez la section Contrôleurs d'entrée tiers.
  • Pour plus d'informations sur l'annotation nsx/loadbalancer, consultez la section LoadBalancer CRD pour gérer la mise à l'échelle de l'entrée.
  • À propos de l'annotation ncp/whitelist-source-range :
    • Lorsque cette option est définie, une demande entrante sera acceptée uniquement si son adresse IP source est incluse dans cette annotation. Dans le cas contraire, le trafic sera abandonné.
    • Vous pouvez spécifier une combinaison de CIDR, d'adresses IP et de plages d'adresses IP. Par exemple, 1.1.1.1/24, 2.2.2.2, 3.3.3.3-4.4.4.4.
    • Exemple YAML :
      kind: Ingress
      metadata:
        name: cafe-ingress
        annotations:
          kubernetes.io/ingress.class: "nsx"
          ncp/whitelist-source-range: "192.168.128.0/17, 192.168.64.0-192.168.64.255, 192.168.16.32"
      spec:
        tls:
        - hosts:
          - cafe.example.com
        rules:
        - host: cafe.example.com
          http:
            paths:
            - path: /tea
              backend:
                serviceName: tea-svc
                servicePort: 80
  • À propos de l'annotation ncp/ssl-mode :
    • Cette annotation s'applique à toutes les règles dans une entrée et l'équilibreur de charge fonctionnera en mode SSL sélectionné pour ces règles.

      Remarque : cette annotation ne peut pas être définie sur passthrough si l'annotation ingress.kubernetes.io/rewrite-target, ncp/use-regex ou ncp/whitelist-source-range est définie.

Erreurs

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. Cette erreur se produira si (1) cette entrée est pour HTTP et qu'il existe une autre entrée pour HTTP avec un serveur principal par défaut, (2) cette entrée est pour HTTPS et une autre entrée pour HTTPS avec un serveur principal par défaut existe, ou (3) cette entrée est pour HTTP et HTTPS, et une autre entrée pour HTTP et HTTPS avec un serveur principal par défaut existe. 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. Les conflits sont déterminés uniquement pour les entrées avec la même stratégie de correspondance, c'est-à-dire la même valeur d'annotation ncp/use-regex.
    • L'annotation kubernetes.io/ingress.allow-http est définie sur false et l'entrée n'a pas de section TLS.
    • L'annotation ncp/http-redirect est définie sur true 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.