Contrôleurs d'entrée tiers

Vous pouvez configurer NCP afin qu'il prenne en charge les contrôleurs d'entrée tiers.

Modification du fichier ncp.ini

Vous devez modifier le fichier de configuration /var/vcap/data/jobs/ncp/xxxxxxxx/config/ncp.ini (où xxxxxxxx est l'ID de déploiement BOSH). Ce fichier sera ensuite copié dans rootfs et utilisé par NCP chaque fois qu'il redémarre. Vous devez modifier le fichier sur chaque nœud master.

Important : Les modifications apportées à ncp.ini ne sont pas persistantes à travers les mises à jour du cluster TKGI. En cas de modifications via la vignette TKGI et de mise à jour du déploiement de TKGI, les modifications effectuées dans ncp.ini seront perdues.

Les options appropriées se trouvent dans la section nsx_v3.

• use_native_loadbalancer : si défini sur Faux, NCP ne traitera aucune entrée ni service des mises à jour de type LoadBalancer, indépendamment de ses annotations. Ce paramètre s'applique à l'ensemble du cluster TKGI. La valeur par défaut est Vrai.
• default_ingress_class_nsx : si défini sur Vrai, NCP devient le contrôleur d'entrée par défaut et traitera les entrées annotées avec kubernetes.io/ingress.class: "nsx" et celles sans annotation. Si défini sur Faux, NCP ne traitera que les entrées annotées avec kubernetes.io/ingress.class: "nsx". La valeur par défaut est Vrai.
  À partir de NCP 3.2.1, default_ingress_class_nsx est obsolète. NCP examinera les éléments suivants lors de la résolution de la classe d'entrée :

  • annotations
  • ingressClass objets
  • Si aucune annotation n'est spécifiée et que use_native_loadbalancer est défini sur True, NSX-LB gère l'entrée. Sinon, NSX-LB ne la gérera pas.

Pour que NCP attribue une adresse IP flottante à l'espace du contrôleur NGINX et mette à jour l'état des entrées avec ce type d'adresse, procédez comme suit :

• Dans la section k8s de ncp.ini, définissez ingress_mode=nat.
• Ajoutez l'annotation ncp/ingress-controller: "True" à l'espace du contrôleur d'entrée NGINX.

NCP mettra à jour l'état des entrées comportant l'annotation kubernetes.io/ingress.class: "nginx" avec l'adresse IP flottante de l'espace du contrôleur d'entrée NGINX. Si default_ingress_class_nsx=False, NCP mettra également à jour l'état des entrées sans l'annotation kubernetes.io/ingress.class avec l'adresse IP flottante de l'espace du contrôleur d'entrée NGINX.

Remarque : même si l'espace du contrôleur d'entrée NGINX ne comporte pas l'annotation ncp/ingress-controller: "True", NCP mettra à jour l'état des entrées mentionné ci-dessus sur loadBalancer: {}. Les entrées peuvent alors être bloquées dans une boucle dans laquelle le contrôleur NGINX met à jour l'état de l'entrée sur loadBalancer: {ingress: [{ip: <IP>}]} et NCP met à jour l'état de l'entrée sur loadBalancer: {}. Pour éviter cette situation, suivez les étapes décrites ci-dessous :

• Si le contrôleur d'entrée provient de https://github.com/kubernetes/ingress-nginx,
  • Dans le contrôleur d'entrée, remplacez ingress-class par une valeur autre que "nginx".
  • S'il existe une entrée avec l'annotation kubernetes.io/ingress-class: "nginx", remplacez celle-ci par une autre valeur.
  • Pour plus d'informations, reportez-vous à la section https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress.
• Si le contrôleur d'entrée provient de https://github.com/nginxinc/kubernetes-ingress,
  • Dans le contrôleur d'entrée, remplacez ingress-class par une valeur autre que "nginx".
  • S'il existe une entrée avec l'annotation kubernetes.io/ingress-class: "nginx", remplacez celle-ci par une autre valeur.
  • Dans l'espace du contrôleur d'entrée, définissez use-ingress-class-only sur Vrai. Cela empêchera le contrôleur de mettre à jour les entrées sans l'annotation kubernetes.io/ingress-class.
  • Pour plus d'informations, reportez-vous à la section https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/multiple-ingress.md.

Pour les contrôleurs d'entrée tiers déployés en mode NAT, vous pouvez modifier les paramètres http_ingress_port et https_ingress_port dans la section k8s pour spécifier des ports personnalisés pour les règles NAT exposées pour le contrôleur d'entrée.

Scénario 1 : NCP traite les entrées, mais n'est pas le contrôleur d'entrée par défaut.

Suivez cette procédure pour permettre à NCP de traiter les entrées de classe nsx.

1. Modifiez la section nsx_v3 dans ncp.ini sur chaque nœud master.
   1. Définissez default_ingress_class_nsx sur Faux.
   2. Laissez use_native_loadbalancer défini sur Vrai, la valeur par défaut.
2. Redémarrez NCP sur chaque nœud master. Cela peut entraîner un basculement du maître.
3. Annotez toutes les entrées que vous souhaitez que NCP gère avec kubernetes.io/ingress.class: "nsx".

Scénario 2 : NCP est le contrôleur d'entrée par défaut.

Suivez cette procédure :

1. Il n'est pas nécessaire de modifier ncp.ini, mais veillez à ce que chaque entrée soit annotée.
2. Les entrées devant être traitées par NCP doivent être annotées avec kubernetes.io/ingress.class : « nsx ».

   Bien que NCP gère les entrées sans l'annotation kubernetes.io/ingress.class, dans le cas de plusieurs contrôleurs d'entrée, il est recommandé de toujours disposer de l'annotation kubernetes.io/ingress.class et non de s'appuyer sur le comportement par défaut du contrôleur d'entrée.

3. Les entrées devant être traitées par des contrôleurs d'entrée tiers doivent être annotées avec la valeur requise par ces contrôleurs d'entrée.

Important : Sauf si l'objectif est de faire de NGINX le contrôleur d'entrée par défaut, n'utilisez pas nginx comme contrôleur d'entrée NGINX, car cela fera de lui le contrôleur d'entrée par défaut.

Scénario 3 : NCP ne traite aucune entrée, indépendamment de son annotation.

Suivez cette procédure :

1. Modifiez la section nsx_v3 dans ncp.ini sur chaque nœud master.
   1. Définissez use_native_loadbalancer sur Faux. La valeur de default_ingress_class_nsx est désormais impertinente.
2. Redémarrez NCP sur chaque nœud master. Cela peut entraîner un basculement du maître.

Notez que NCP ne traitera pas non plus les services de type LoadBalancer