Contrôleur d'entrée Citrix ADC

Topologies de déploiement

Les Citrix ADC peuvent être combinés dans des topologies puissantes et flexibles qui complètent les limites organisationnelles. Les déploiements à deux niveaux utilisent du matériel haute capacité ou des Citrix ADC virtualisés (Citrix ADC MPX et VPX) dans le premier niveau pour décharger les fonctions de sécurité et mettre en œuvre des politiques organisationnelles relativement statiques tout en segmentant le contrôle entre les opérateurs réseau et les opérateurs Kubernetes.

Dans les déploiements à deux niveaux, le deuxième niveau se trouve au sein du cluster Kubernetes (à l’aide du Citrix ADC CPX) et est sous le contrôle des propriétaires de services. Cette configuration fournit de la stabilité aux opérateurs réseau, tout en permettant aux utilisateurs de Kubernetes de mettre en œuvre des changements à grande vitesse. Les topologies à un niveau sont adaptées aux organisations qui doivent gérer des taux de changement élevés.

Topologie à un niveau

Dans une topologie à un niveau, les appareils Citrix ADC MPX ou VPX envoient par proxy le trafic (nord-sud) des clients vers les microservices au sein du cluster. Le Citrix ingress controller est déployé en tant qu’espace autonome dans le cluster Kubernetes. Le contrôleur automatise la configuration des Citrix ADC (MPX ou VPX) en fonction des modifications apportées aux microservices ou aux ressources d’entrée.

Single-tier

Topologie à deux niveaux

Dans la topologie à deux niveaux, les appareils Citrix ADC MPX ou VPX de niveau 1 proxy le trafic (nord-sud) du client vers les Citrix ADC CPX de niveau 2. Le Citrix ADC CPX de niveau 2 achemine ensuite le trafic vers les microservices du cluster Kubernetes. Le Citrix ingress controller déployé en tant qu’espace autonome configure les appareils de niveau 1. De plus, le contrôleur latéral d’un ou de plusieurs espaces Citrix ADC CPX configure le Citrix ADC CPX associé dans le même espace.

Double niveau

Topologie Cloud

Les clusters Kubernetes dans les clouds publics tels qu’ Amazon Web Services (AWS), Google Cloudet Microsoft Azure peuvent utiliser leurs services d’équilibrage de charge natifs tels qu’ AWS Elastic Load Balancing, Google Cloud Load Balancinget NLB Microsoft Azure en tant que premier niveau (relativement statique) d’équilibrage de charge à un deuxième niveau de Citrix ADC CPX. Citrix ADC CPX fonctionne à l’intérieur du cluster Kubernetes avec le contrôleur d’entrée sidecar. Les clusters Kubernetes peuvent être auto-hébergés ou gérés par le fournisseur de cloud (par exemple, AWS EKS, Google GKE et Azure AKS) tout en utilisant Citrix ADC CPX comme entrée. Si le cluster Kubernetes basé sur le cloud est auto-hébergé ou autogéré, Citrix ADC VPX peut être utilisé comme premier niveau dans une topologie à deux niveaux.

Déploiement cloud avec Citrix ADC (VPX) au niveau 1 : déploiement cloud avec VPX au niveau 1

Déploiement dans le cloud avec Cloud LB au niveau 1 : déploiement cloud avec CLB au niveau 1

Service mesh lite

Une solution d’entrée (matérielle ou virtualisée ou conteneurisée) exécute généralement des fonctions proxy L7 pour le trafic nord-sud (N-S). L’architecture Service Mesh Lite utilise la même solution d’entrée pour gérer également le trafic est-ouest.

Dans un déploiement Kubernetes standard, le trafic est-ouest (E-W) traverse le KubeProxy intégré déployé dans chaque nœud. Leproxy Kube étant un proxy L4 ne peut effectuer que l’équilibrage de charge basé sur TCP/UDP sans les avantages du proxy L7.

Citrix ADC (MPX, VPX ou CPX) peut fournir de tels avantages pour le trafic E-W tels que :

  • Déchargement mutuel TLS ou SSL
  • Routage basé sur le contenu, autoriser ou bloquer le trafic en fonction des paramètres d’en-tête HTTP ou HTTPS
  • Algorithmes avancés d’équilibrage de charge (par exemple, le moins de connexions, le moins de temps de réponse, etc.)
  • Observabilité du trafic est-ouest grâce à la mesure des signaux d’or (erreurs, latences, saturation ou volume de trafic). Service Graphde Citrix ADM est une solution d’observabilité pour surveiller et déboguer les microservices.

Pour plus d’informations, consultez la section Service mesh lite.

Dual-tier-Hairpin-mode

Services de type LoadBalancer

Les services de type LoadBalancer dans Kubernetes vous permettent d’exposer directement des services au monde extérieur sans utiliser de ressource d’entrée. Il est mis à disposition uniquement par les fournisseurs de cloud, qui mettent en place leurs propres équilibreurs de charge cloud natifs et attribuent une adresse IP externe via laquelle le service est accessible. Cela vous permet de déployer facilement des microservices et de les exposer en dehors du cluster Kubernetes.

Par défaut, dans un cluster Kubernetes bare metal, le service de type expose LoadBalancer simplement NodePorts pour le service. De plus, il ne configure pas les équilibreurs de charge externes.

Le Citrix ingress controller prend en charge les services de type LoadBalancer. Vous pouvez créer un service de type LoadBalancer et l’exposer à l’aide de l’entrée Citrix ADC au niveau 1. L’entrée Citrix ADC fournit un équilibreur de charge pour le service et une adresse IP externe est attribuée au service. Le Citrix ingress controller alloue l’adresse IP à l’aide du contrôleur IPAM Citrix.

Pour plus d’informations, consultez la section Expose des services de type LoadBalancer.

Service de type LoadBalancer

Services de type NodePort

Par défaut, les services Kubernetes sont accessibles à l’aide de l’adresse IP du cluster . L’adresse IP du cluster est une adresse IP interne accessible dans le cluster Kubernetes. Pour rendre le service accessible depuis l’extérieur du cluster Kubernetes, vous pouvez créer un service de ce type NodePort.

Le Citrix ingress controller prend en charge les services de type NodePort. À l’aide du Citrix ADC et du Citrix ingress controller Ingress, vous pouvez exposer le service de type NodePort au monde extérieur.

Pour plus d’informations, consultez la section Expose des services de type NodePort.

Services de type NodePort

Déploiement en utilisant les graphiques Helm et le générateur de déploiement Citrix

Pour déployer des topologies natives Citrix Cloud, différentes options sont disponibles à l’aide des graphiques YAML et Helm. Les graphiques en barre constituent l’un des moyens les plus simples de déploiement dans un environnement Kubernetes. Lorsque vous déployez à l’aide des graphiques Helm, vous pouvez utiliser un fichier values.yaml pour spécifier les valeurs des paramètres configurables au lieu de fournir chaque paramètre en tant qu’argument.

Vous pouvez générer le fichier values.yaml pour les déploiements natifs Citrix Cloud à l’aide du générateur de déploiement Citrix, qui est une interface graphique.

Les topologies suivantes sont prises en charge par le générateur de déploiement Citrix :

  • Niveau unique

    • Entrée

    • Type de service LoadBalancer

  • Double niveau

    • Citrix ADC CPX en tant que NodePort

    • Citrix ADC CPX en tant que service de type LoadBalancer

  • Entrée multi-clusters

  • Service mesh

Pour plus d’informations sur l’utilisation du générateur de déploiement Citrix, consultez le blog Citrix Deployment Builder.

Topologies de déploiement