Cas d’utilisation du DRV — Utilisation du routage dynamique Citrix ADC avec Kubernetes

Acme Inc. Intégration de Route Health Injection (RHI) et BGP pour les applications Kubernetes

Acme Inc. est un client de longue date de Citrix qui possède une importante empreinte Citrix ADC. Citrix ADC est la principale solution d’équilibrage de charge et de continuité d’activité pour les applications Kubernetes critiques. Acme Inc. possède actuellement trois centres de données principaux.

Acme Inc. souhaite fournir une redondance et une haute disponibilité pour les applications Kubernetes critiques afin qu’elles puissent offrir une meilleure tolérance aux pannes parmi tous les racks de déploiement dans les trois centres de données.

En utilisant la fonctionnalité Route Health Injection sur Citrix ADC, la solution fournit une redondance pour les services Kubernetes auxquels on accède via la structure de routage BGP + ECMP existante.

Outre la fonctionnalité RHI, de nombreuses applications Kubernetes nécessitent que le serveur principal reçoive l’adresse IP réelle du client. L’équilibrage de charge traditionnel avec Citrix ADC source des paquets destinés aux serveurs back-end à partir de l’adresse IP du sous-réseau ADC. Pour les applications qui nécessitent la véritable adresse IP du client comme adresse source, Citrix ADC propose plusieurs méthodes. Ces méthodes incluent USIP (utiliser le mode IP source) et DSR (retour direct au serveur).

Les services informatiques d’Acme Inc. testent les instances Citrix ADC VPX avec des VIP de test pour les applications Kubernetes. Cet environnement de test est utilisé pour créer la solution RHI avec l’adresse IP client, et la tester complètement avant de la déployer dans l’environnement de production.

Exigences relatives au déploiement

Acme Inc. et Citrix ont identifié plusieurs exigences différentes :

• Unités Citrix ADC VPX dans chaque centre de données, avec connectivité au réseau de routage dynamique (3)
• Adresses IP d’un maximum de trois serveurs virtuels à configurer en tant que routes /32 dans le routage dynamique Acme Inc.

Environnement :

VIP de test Kubernetes

• L’adresse SNIP dans chaque centre de données à utiliser comme saut suivant pour le VIP RHI sur chaque unité Citrix ADC doit avoir sa propre adresse SNIP avec le routage dynamique activé. Il s’agit de la passerelle pour le VIP RHI annoncé.

Identifiez les informations Kubernetes, notamment :

• Pods Kubernetes dorsaux et VIP de test
• Ports et paramètres d’équilibrage de charge requis
• Certificats SSL (le cas échéant)

Configuration IP du client

• Les serveurs principaux doivent recevoir la véritable adresse IP du client
• Les différentes options disponibles sont abordées dans la section Options IP du client

Route Health Injection (RHI)

Routage dynamique Citrix ADC avec RHI

L’objectif principal du routage dynamique et de RHI dans Citrix ADC est de communiquer l’état ou la santé des VIP aux routeurs en amont. L’état d’un VIP dépend des serveurs virtuels qui lui sont associés et des services qui sont liés à ce VIP. La publicité d’un VIP via RHI est liée aux états des serveurs virtuels associés à l’adresse IP virtuelle.

La publicité doit être activée pour l’adresse IP virtuelle. Pour ce faire, définissez l’option -hostroute sur enabled sur l’adresse IP virtuelle. Par défaut, l’option -hostroute est définie sur disabled. L’option -hostroute peut être activée lorsque vous ajoutez une adresse IP avec la commande add ns ip ou en modifiant une adresse IP existante à l’aide de la commande set ns ip.

Surveillance de RHI

Une fois l’option hostRoute activée, le noyau NetScaler injecte la route hôte dans ZeBOS NSM (Network Services Module), en fonction de l’état des serveurs virtuels associés à l’adresse IP virtuelle. Le commutateur - vserverroute health injectionLevel contrôle la relation entre l’état des serveurs virtuels et la route hôte IP virtuelle qui est envoyée au module de services réseau (NSM).

Les trois options disponibles pour le niveau de RHI du serveur virtuel :

• ALL_VSERVERS — Une route hôte est injectée à NSM uniquement si tous les serveurs virtuels associés à l’adresse IP virtuelle sont actifs.
• ONE_VSERVER — Une route hôte est injectée à NSM uniquement si l’un des serveurs virtuels associés à l’adresse IP virtuelle est actif.
• NONE — Une route hôte est injectée au NSM quel que soit l’état des serveurs virtuels associés à l’adresse IP virtuelle.

Remarque :

Par défaut, —vServerRHILevel est défini sur ONE_VSERVER.

Le schéma suivant décrit la fonctionnalité RHI de base pour une adresse IP virtuelle associée à un serveur virtuel à charge équilibrée sur Citrix ADC :

Options RHI avec plusieurs centres de données

Ce qui suit décrit la configuration de RHI qui est sélectionnée pour chaque application, en fonction des exigences spécifiques de chaque application. Les options disponibles sont :

Actif : actif avec BGP déterminant la route la plus efficace pour chaque client (Anycast ou ECMP)

Route Health Injection active — Active : Anycast ou ECMP

Route health injection active/active est Anycast ou ECMP. Il s’agit d’une véritable alternative actif-actif. Dans ce scénario, la route /32 pour le VIP RHI est annoncée dans tous les centres de données sans que le coût ou la préférence locale ne soient présentés à BGP. Trois routes sont présentées au réseau avec l’adresse SNIP du Citrix ADC spécifique à chaque centre de données agissant comme une passerelle pour accéder à chaque VIP. L’environnement de routage dynamique d’Acme Inc. dirige les demandes des clients vers le centre de données sur une base de coût égal pour la distribution du trafic. En cas de défaillance des services dans l’un des trois centres de données, les moniteurs liés aux services d’équilibrage de charge mettent le serveur virtuel hors service. Cela supprime à son tour l’annonce d’itinéraire pour le centre de données concerné par la panne. Toutes les connexions client continuent de fonctionner avec les autres centres de données.

Considérations importantes pour la configuration active-active de RHI :

1. RHI avec ECMP est recommandée pour les services basés sur TCP et UDP et nécessite une configuration BGP par l’équipe réseau d’Acme Inc. RHI avec ECMP a une limite sur le nombre de routes que les routeurs en amont peuvent prendre en charge (64).
2. RHI avec Anycast prend en charge les services basés sur UDP et n’est pas recommandée pour les services basés sur TCP.

Le schéma suivant décrit le scénario AnyCast/ECMP actif :

Options Citrix ADC et IP client

L’une des exigences importantes demandées par Acme Inc. pour une grande partie de ses applications Kubernetes est que les serveurs back-end reçoivent la véritable adresse IP du client pour les services équilibrés de charge par Citrix ADC. L’équilibrage de charge typique sur Citrix ADC génère tout le trafic destiné aux serveurs principaux à partir d’une adresse SNIP (IP de sous-réseau) appartenant à NetScaler. Pour certaines applications, l’adresse IP réelle du client est requise. La plupart des applications qui utilisent RHI nécessitent également que la véritable adresse IP du client soit envoyée au serveur principal.

Citrix ADC possède une fonctionnalité appelée « Use Source IP » (USIP) qui peut être liée globalement ou individuellement à chaque service nécessitant une adresse IP client vers le serveur principal. Le problème est qu’une fois que le client reçoit le paquet avec une adresse IP source différente, un routage asymétrique se produit et le paquet est abandonné. C’est pour cette raison que d’autres considérations doivent être prises en compte et qu’une configuration supplémentaire est requise sur les serveurs principaux pour que USIP fonctionne correctement.

Lors de la mise en œuvre de l’utilisation du mode IP source sur Citrix ADC, il est important de noter que le mode de protection contre les surtensions doit être désactivé dans les modes Citrix ADC. Vous trouverez plus d’informations sur le mode USIP avec protection contre les surtensions dans l’article Citrix ici.

Citrix ADC propose plusieurs méthodes pour y parvenir, qui sont décrites dans la section suivante. Les options disponibles sont les suivantes :

• Mode USIP avec Citrix ADC SNIP comme passerelle par défaut
• Direct Server Return Layer 3
  • Tunneling IP
  • Insertion IP du client sur l’en-tête TOS
• Direct Server Return Layer 2
• Insertion IP client pour l’en-tête TCP

Mode USIP avec Citrix ADC SNIP comme passerelle par défaut

Au cours de plusieurs réunions avec le service informatique d’Acme Inc., il a été déterminé que cette méthode est préférée pour la plupart des services d’équilibrage de charge nécessitant une adresse IP client. Cette méthode implique de modifier la passerelle par défaut pour chaque serveur back-end en cours d’équilibrage de charge et de la définir sur l’adresse SNIP de l’unité Citrix ADC hébergeant le VIP d’équilibrage de charge. Cette option prend en charge toutes les fonctionnalités de Citrix ADC, contrairement aux options de retour Direct Server, où Citrix ADC gère uniquement les demandes des clients entrants. Cette option nécessite également la plus grande quantité de bande passante sur les unités ADC. Cette méthode répond aux exigences de base suivantes :

• Citrix ADC doit avoir une adresse SNIP dans le même sous-réseau L2 que tous les serveurs back-end en cours d’équilibrage de charge.
• L’adresse SNIP est configurée comme passerelle par défaut pour tous les serveurs principaux. Plusieurs adresses SNIP peuvent être utilisées pour les serveurs principaux dans différents sous-réseaux L2.
• Le mode USIP doit être activé sur les services qui pointent vers des serveurs principaux.

Remarque :

USIP peut également être activé globalement sur les unités Citrix ADC, mais USIP ne s’appliquera qu’aux services créés après l’activation du mode USIP.

Citrix recommande d’ajouter davantage d’interfaces réseau aux serveurs principaux et de configurer des routes statiques pour le trafic non client.

• Les routines de sauvegarde et les autres processus qui nécessitent de la bande passante n’ont pas à traverser l’unité Citrix ADC.

Retour direct au serveur : options de couche 3

Le retour direct du serveur avec Citrix ADC est une autre option de configuration permettant d’obtenir les adresses IP des clients sur les serveurs principaux dans une configuration d’équilibrage de charge. Le retour direct du serveur peut être configuré en mode Layer 3, permettant ainsi l’utilisation de serveurs back-end sur d’autres VLAN L3, par opposition à USIP qui nécessite une connectivité L2 entre l’ADC et les serveurs back-end. La configuration de retour direct du serveur ne prend pas en charge certaines fonctionnalités de Citrix ADC en raison du fait que le trafic de réponse ne traverse pas l’unité Citrix ADC. Cette option nécessite le débit le plus faible sur les unités Citrix ADC.

Le retour direct du serveur présente des configurations plus complexes requises pour les serveurs principaux, car ils doivent être capables d’extraire l’adresse IP du client et de réécrire l’en-tête TCP pour répondre directement au client. Citrix prend actuellement en charge deux méthodes différentes pour configurer le DSR de couche 3 :

• Mode DSR avec tunnel IP (IP over IP)
• Mode DSR avec TOS (champ d’en-tête TCP du type de service) Couche 3

DSR répond aux exigences de base suivantes :

• Le Citrix ADC doit être configuré avec USIP sur le service.
• Les serveurs principaux ont une adresse de bouclage configurée avec l’adresse VIP Citrix ADC.
• Le serveur principal doit être configuré spécifiquement pour chaque méthode :
  • Tunneling IP : le serveur principal doit décapsuler les paquets de l’ADC et extraire l’adresse IP du client pour une réponse directe au client.
  • TOS (Type of Service) : le serveur principal doit être capable de lire l’en-tête TOS du paquet TCP et d’utiliser ces informations pour répondre directement au client.
  • L’une ou l’autre méthode peut nécessiter des configurations personnalisées sur les serveurs principaux et l’utilisation d’une application tierce.

Le DSR de couche 3 peut nécessiter la configuration d’exceptions sur les pare-feu et les dispositifs de sécurité.

Vous trouverez plus d’informations sur le retour direct du serveur avec la couche 3 ici :

Configuration du mode DSR lors de l’utilisation de TOS - DSR avec TOS

• DSR avec tunnel IP

Exposer les services de type « LoadBalancer »

Les services de type LoadBalancer sont pris en charge de manière native dans les déploiements Kubernetes sur des clouds publics tels que AWS, GCP ou Azure. Dans les déploiements cloud, lorsque vous créez un service de type LoadBalancer, un équilibreur de charge géré dans le cloud est affecté au service. Le service est ensuite exposé à l’aide de l’équilibreur de charge.

Pour les déploiements locaux, bare metal ou dans le cloud public de Kubernetes, vous pouvez utiliser un Citrix ADC en dehors du cluster pour équilibrer la charge du trafic entrant. Le Citrix ingress controller fournit une gestion flexible des adresses IP qui permet l’architecture mutualisée pour les Citrix ADC. Le Citrix ingress controller vous permet d’équilibrer la charge de plusieurs services à l’aide d’un seul ADC et combine également diverses fonctions d’entrée. En utilisant Citrix ADC avec le Citrix ingress controller, vous pouvez optimiser l’utilisation des ressources de l’équilibreur de charge pour votre cloud public et réduire considérablement vos dépenses opérationnelles.

Le Citrix ingress controller prend en charge les services de type LoadBalancer lorsque Citrix ADC se trouve en dehors du cluster Kubernetes (niveau 1). Lorsqu’un service de type LoadBalancer est créé, mis à jour ou supprimé, le Citrix ingress controller configure Citrix ADC avec un serveur virtuel d’équilibrage de charge.

Le serveur virtuel d’équilibrage de charge est configuré avec une adresse IP (adresse IP virtuelle ou VIP) qui est obtenue de l’une des manières suivantes : ​

1. En attribuant automatiquement une adresse IP virtuelle au service à l’aide du contrôleur IPAM fourni par Citrix. La solution est conçue de telle sorte que vous pouvez facilement intégrer la solution à des fournisseurs DNS externes tels qu’Infoblox. Pour plus d’informations, consultez Interopérabilité avec ExternalDNS. ​

2. En spécifiant une adresse IP à l’aide du champ SPEC.LoadBalanceRip dans la définition de votre service. Le Citrix ingress controller utilise l’adresse IP fournie dans le champ SPEC.LoadBalanceRip comme adresse IP du serveur virtuel d’équilibrage de charge qui correspond au service.

   apiVersion: v1
   kind: Service
   metadata:
       name: hello-world-service
   spec:
       type: LoadBalancer
       loadBalancerIP: ""
   ports:
   - port: 80
       targetPort: 8080
   selector:
       run: load-balancer-example
   <!--NeedCopy-->
   

Pour une référence plus détaillée, voir Expose services de type LoadBalancer.

Prérequis IPAM

La gestion des adresses IP (IPAM) doit être configurée comme condition préalable au routage dynamique Citrix ADC avec Kubernetes. IPAM est utilisé pour attribuer et libérer automatiquement des adresses IP dans les déploiements gérés par ADM. Pour une référence plus détaillée, voir Configurer la gestion des adresses IP.