Modèle de conception validé de Citrix Cloud Native Networking pour Red Hat OpenShift 3.11
Citrix ADC Stack répond aux exigences de base en matière de fonctionnalités de disponibilité des applications (ADC), de ségrégation des fonctionnalités de sécurité (WAF), de dimensionnement des topologies d’applications agiles (SSL et GSLB) et d’observabilité proactive (Service Graph) dans un environnement Cloud Native Era hautement orchestré.
La transformation numérique accentue la nécessité de déplacer les déploiements d’applications modernes vers des architectures basées sur des microservices. Ces architectures Cloud Native tirent parti des conteneurs d’applications, des microservices et de Kubernetes.
L’approche Cloud Native des applications modernes a également transformé le cycle de vie du développement, notamment les flux de travail agiles, les outils de déploiement d’automatisation et les langages et plateformes de développement.
La nouvelle ère du déploiement d’applications modernes a également modifié les disciplines du modèle commercial traditionnel des centres de données, notamment les versions et les contrats de logiciels mensuels et annuels, les ressources et le budget de calcul en silo, ainsi que le modèle de consommation des fournisseurs.
Et tandis que toute cette modernisation se produit dans l’écosystème, des exigences de base subsistent en matière de fonctionnalités de disponibilité des applications (ADC), de ségrégation des fonctionnalités de sécurité (WAF), de mise à l’échelle de topologies d’applications agiles (SSL et GSLB) et d’observabilité proactive (Service Graph) dans un environnement hautement orchestré environnement.
Pourquoi choisir Citrix pour une diffusion d’applications modernes
L’approche logicielle Citrix du déploiement d’applications modernes nécessite l’intégration d’un flux de travail agile au sein de nombreuses équipes au sein de l’entreprise. L’un des avantages du développement et de la diffusion d’applications agiles est le framework connu sous le nom de CI/CD.
La technologie CI/CD permet d’apporter rapidité, sécurité et fiabilité au cycle de vie des applications modernes.
L’intégration continue (CI) permet de créer une base de code commune qui peut être mise à jour en temps réel plusieurs fois par jour et intégrée à une plateforme de génération automatisée. Les trois phases de l’intégration continue sont les suivantes : Push, Test, Fix.
Continuous Delivery (CD) intègre le pipeline de déploiement directement dans le processus de développement de CI, optimisant et améliorant ainsi le modèle de fourniture de logiciels pour les applications modernes.
Les Citrix ADC s’intègrent au processus de livraison continue par la mise en œuvre de déploiements progressifs automatisés d’analyse Canary.
Une solution pour toutes les parties prenantes
Citrix a créé une solution logicielle dédiée qui répond aux exigences interfonctionnelles lors du déploiement d’applications modernes et intègre les différents composants de la pile d’observabilité, du cadre de sécurité et de l’infrastructure CI/CD.
Les organisations traditionnelles qui adoptent des techniques CI/CD pour le déploiement d’applications modernes ont reconnu la nécessité de fournir un cadre de livraison et de disponibilité commun à tous les membres impliqués dans le CI/CD, ces ressources sont généralement définies comme les « parties prenantes » de l’unité opérationnelle, et alors que chaque partie prenante est investie dans le succès global de l’organisation, chaque partie prenante a généralement des exigences et des différences distinctes.
Voici quelques exemples courants de parties prenantes participant à l’activité de prestation moderne :
- Équipe chargée des plateformes : déployez une infrastructure de centre de données telle que IaaS, PaaS, SDN, ADC, WAF
- Équipe DevOps et ingénierie : développement et maintenance du référentiel de code unifié, des outils d’automatisation et de l’architecture logicielle
- Équipe d’ingénierie de la fiabilité des services (SRE) : réduction des silos organisationnels, gestion des erreurs, automatisation des déploiements et mesures
- Équipe des opérations de sécurité : politiques de sécurité proactives, gestion des incidents, déploiement de correctifs, renforcement du portefeuille
Explication de la pile logicielle Citrix
Base de code unique - c’est le même code pour vous - Déploiements sur site, déploiements de cloud public, déploiements de cloud privé, déploiements de cloud gouvernemental
-
Choix de plateformes : pour répondre à toutes les exigences en matière d’agilité, choisissez n’importe quel modèle Citrix ADC
- CPX — le Citrix ADC CPX est un Citrix ADC livré sous forme de conteneur
- VPX — le produit Citrix ADC VPX est une appliance virtuelle qui peut être hébergée sur une grande variété de plateformes de virtualisation et de cloud offrant des performances allant de 10 Mo/s à 100 Gbit/s.
- MPX : Citrix ADC MPX est une appliance de mise à disposition d’applications basée sur le matériel offrant des performances allant de 500 Mo/s à 200 Gbit/s.
- SDX : l’appliance Citrix ADC SDX est une plate-forme mutualisée sur laquelle vous pouvez provisionner et gérer plusieurs machines virtuelles Citrix ADC (instances).
- BLX — L’appliance Citrix ADC BLX est un facteur de forme logiciel de Citrix ADC. Il est conçu pour fonctionner nativement sur Linux bare-metal sur des serveurs commerciaux prêts à l’emploi (COTS) Environnements conteneurisés - créez des superpositions et configurez automatiquement votre Citrix ADC
- Citrix Ingress Controller - construit autour de Kubernetes Ingress et configure automatiquement un ou plusieurs Citrix ADC en fonction de la configuration des ressources d’entrée
- Citrix Node Controller — créez un réseau superposé basé sur VxLAN entre les nœuds Kubernetes et l’entrée Citrix ADC
-
Citrix IPAM Controller — attribuez automatiquement le serveur virtuel d’équilibrage de charge sur un Citrix ADC avec une adresse IP (adresse IP virtuelle ou VIP)
Capacité groupée Licences — une licence globale
- Un pool de licences mondial omniprésent découple les plateformes et les licences pour une flexibilité totale en matière de conception et de performance
Application Delivery Manager — une interface unique
- Gérez le parc, orchestrez les stratégies et applications, surveillez et dépannez en temps réel des topologies
flexibles : centre de données traditionnel ou clouds modernes - niveau unique, double niveau et service mesh lite
La valeur de Citrix ADC
- Intégration de Kubernetes et des outils Open Source de la CNCF
- The Perfect Proxy : un contrôleur de mise à disposition d’applications Layer7 éprouvé pour les applications modernes
- Conteneur ADC hautes performances dans un déploiement Pod ou Sidecar
- Accès à faible latence au cluster Kubernetes à l’aide de plusieurs options
- API riche en fonctionnalités : implémentez et orchestrez facilement des fonctionnalités de sécurité sans limite
- Advanced Traffic Steering et déploiement Canary pour CI/CD
- Sécurité éprouvée grâce à la protection TLS/SSL, WAF, DoS et API
- Capacités riches de couche 7
- Surveillance intégrée pour les déploiements d’applications héritées et modernes
- Informations exploitables et graphiques de service pour une meilleure visibilité
Les avantages de Citrix ADC
- Déplacez les applications existantes sans avoir à les réécrire
- Les développeurs peuvent sécuriser les applications à l’aide des politiques Citrix ADC à l’aide des API Kubernetes (à l’aide de CRD, faciles à utiliser)
- Déployez des microservices hautement performants pour le Nord-Sud et le Service Mesh
- Utiliser un graphique de service d’application pour tous les microservices
- Résolvez plus rapidement les problèmes de microservices via TCP, UDP, HTTP/S, SSL
- Sécurisation des API et configuration à l’aide des API Kubernetes
- Améliorez le processus CICD pour les déploiements Canary
Composants de l’architecture
L’avantage de la suite Citrix ADC
Citrix, c’est le choix. Que vous viviez avec des centres de données et des composants hérités, ou que vous ayez lancé une nouvelle application moderne native dans le cloud, Citrix ADC s’intègre parfaitement à toutes les exigences de plate-forme que vous pouvez avoir. Nous fournissons des fonctionnalités ADC natives au cloud pour les plateformes et outils cloud basés sur des abonnements, nous permettons de diriger et d’orchestrer le trafic vers votre cluster Kubernetes sur site grâce à une orchestration aisée des contrôleurs d’entrée, et nous abordons les architectures Service Mesh de la plus simple à la plus complexe.
Citrix est validé. Les modèles de conception validés et les exemples d’applications permettent de référencer facilement un état souhaité et de répondre rapidement et complètement aux exigences de l’entreprise. Nous avons documenté et publié des exemples de configuration dans un emplacement central pour faciliter la consultation par les équipes DevOps, SecOps et Platforms.
Citrix est agile et moderne. Créez une architecture de base permettant aux clients de profiter des nouvelles fonctionnalités de Citrix Cloud Native Stack avec leur ADC existant et de nouveaux modules (CNC, IPAM, etc.)
Citrix est ouvert. Aidez les clients à comprendre notre intégration avec les écosystèmes partenaires. Dans ce document, nous utilisons à la fois des outils OpenSource CNCF et des produits Citrix destinés aux entreprises.
Ecosystème de partenaires
Cette rubrique fournit des informations sur les différentes plates-formes Kubernetes, les topologies de déploiement, les fonctionnalités et les CNI pris en charge dans les déploiements Cloud-Native qui incluent Citrix ADC et Citrix ingress controller.
Le Citrix Ingress Controller est pris en charge sur les plateformes suivantes :
- Kubernetes v1.10 sur du matériel vierge ou auto-hébergé sur des clouds publics tels que AWS, GCP ou Azure.
- Google Kubernetes Engine (GKE)
- Elastic Kubernetes Service (EKS)
- Azure Kubernetes Service (AKS)
- Red Hat OpenShift versions 3.11 et ultérieures
- Pivotal Container Service (PKS)
- Diamanti Enterprise Kubernetes Platform
Notre écosystème de partenaires comprend également les éléments suivants :
- Prometheus — outil de surveillance pour les métriques, les alertes et les informations
- Grafana — une plateforme d’analyse et de surveillance
- Spinnaker — un outil pour la livraison continue multi-cloud et Canary - analytics
- Elasticsearch : un service de recherche d’applications ou de sites
- Kibana : un outil de visualisation pour les données de recherche élastiques et un outil de navigation Elastic Stack
- Fluentd — un outil de collecte de données
La section suivante se concentre sur la conception et l’architecture avec OpenShift.
Présentation d’OpenShift
Red Hat OpenShift est une plateforme Kubernetes destinée aux déploiements qui se concentre sur l’utilisation de microservices et de conteneurs pour créer et faire évoluer des applications plus rapidement. En automatisant, installant, mettant à niveau et gérant la pile de conteneurs, OpenShift rationalise Kubernetes et facilite les tâches DevOps quotidiennes.
- Les développeurs fournissent des applications avec accès à des solutions validées et à des partenaires qui sont mis en production via des flux de travail rationalisés.
- Les opérations peuvent gérer et faire évoluer l’environnement à l’aide de la console Web et de la journalisation et de la surveillance intégrées
Figure 1-6 : Architecture de haut niveau d’OpenShift.
Parmi les autres avantages et composants d’OpenShift, citons :
- Choix de l’infrastructure
- Nœuds principaux et nœuds de
- Registre d’images
- Couche de routage et de service
- Fonctionnement du développeur (introduit mais dépasse le cadre de ce document)
Les cas d’utilisation de l’intégration de Red Hat OpenShift à Citrix Native Stack incluent :
- Support pour les applications existantes
- Politiques de réécriture/de réponse déployées sous forme d’API
- Dépannage des microservices
- Opérations quotidiennes avec correctifs de sécurité et améliorations des fonctionnalités
Dans ce document, nous expliquons comment Citric ADC fournit une intégration solide de la couche de routage/service.
Projets OpenShift
Le premier nouveau concept ajouté par OpenShift est le projet, qui enveloppe efficacement un espace de noms, l’accès à l’espace de noms étant contrôlé via le projet. L’accès est contrôlé par un modèle d’authentification et d’autorisation basé sur les utilisateurs et les groupes. Les projets dans OpenShift constituent donc des barrières entre les espaces de noms, garantissant ainsi que les utilisateurs, ou les applications, ne peuvent voir et accéder que ce à quoi ils sont autorisés.
Espaces de noms OpenShift
Le principal concept de regroupement dans Kubernetes est l’espace de noms. Les espaces de noms permettent également de répartir les ressources du cluster entre plusieurs utilisations. Cela étant dit, il n’existe aucune sécurité entre les espaces de noms dans Kubernetes. Si vous êtes un « utilisateur » dans un cluster Kubernetes, vous pouvez voir tous les différents espaces de noms et les ressources qui y sont définies.
Réseau défini par logiciel (SDN) OpenShift
OpenShift Container Platform utilise une approche de mise en réseau définie par logiciel (SDN) pour fournir un réseau de clusters unifié qui permet la communication entre les pods au sein du cluster OpenShift Container Platform. Ce réseau de pods est établi et maintenu par le SDN OpenShift, qui configure un réseau superposé à l’aide d’Open vSwitch (OVS).
OpenShift SDN fournit trois plug-ins SDN pour configurer le réseau de pods :
- Le plug-in ovs-subnet est le plug-in d’origine, qui fournit un réseau de pods « plat » dans lequel chaque pod peut communiquer avec tous les autres pods et services.
- Le plug-in ovs-multitenant fournit une isolation au niveau du projet pour les pods et les services. Chaque projet reçoit un identifiant de réseau virtuel (VNID) unique qui identifie le trafic provenant des pods affectés au projet. Les pods de différents projets ne peuvent pas envoyer de paquets vers ou recevoir de paquets depuis des pods et des services d’un autre projet.
- Toutefois, les projets qui reçoivent le VNID 0 sont plus privilégiés dans la mesure où ils sont autorisés à communiquer avec tous les autres espaces, et tous les autres espaces peuvent communiquer avec eux. Dans les clusters OpenShift Container Platform, le projet par défaut possède VNID 0. Cela permet à certains services, tels que l’équilibreur de charge, de communiquer avec tous les autres pods du cluster et vice versa.
- Le plug-in ovs-networkpolicy permet aux administrateurs de projet de configurer leurs propres politiques d’isolation à l’aide d’objets NetworkPolicy.
Routage OpenShift et plug-ins
Un administrateur OpenShift peutdéployer des routeursdans un cluster OpenShift, ce qui permet aux routescréées par des développeurs d’être utilisées par des clients externes. La couche de routage dans OpenShift est enfichable, et deuxplug-ins de routeurdisponibles sont fournis et pris en charge par défaut.
Les routeurs OpenShift fournissent un mappage de nom d’hôte externe et un équilibrage de charge auxservicesvia des protocoles qui transmettent des informations distinctives directement au routeur ; le nom d’hôte doit être présent dans le protocole afin que le routeur puisse déterminer où l’envoyer.
Les plug-ins de routeur supposent qu’ils peuvent se lier aux ports d’hôte 80 et 443. Cela permet au trafic externe d’être acheminé vers l’hôte, puis via le routeur. Les routeurs supposent également que la mise en réseau est configurée de manière à pouvoir accéder à tous les modules du cluster.
LerouteurOpenShift est le point d’entrée pour tout le trafic externe destiné auxservicesde votre installation OpenShift. OpenShift fournit et prend en charge les plug-ins de routeur suivants :
- Lerouteur modèle HAProxyest le plug-in par défaut. Il utilise openshift3/ose-haproxy-routerimage pour exécuter une instance HAProxy à côté du plug-in de routeur modèle dans un conteneur sur OpenShift. Il prend actuellement en charge le trafic HTTP (S) et le trafic compatible TLS via SNI. Le conteneur du routeur écoute sur l’interface réseau hôte, contrairement à la plupart des conteneurs qui écoutent uniquement sur des adresses IP privées. Le routeur transmet les demandes externes de noms de route aux adresses IP des pods réels identifiés par le service associé à l’itinéraire.
- Le Citrix ingress controller peut être déployé en tant que plug-in de routeur dans le cluster OpenShift pour s’intégrer aux Citrix ADC déployés dans votre environnement. Le Citrix ingress controller vous permet d’utiliser les fonctionnalités avancées d’équilibrage de charge et de gestion du trafic de Citrix ADC avec votre cluster OpenShift. Reportez-vous à la section Déployer le Citrix ingress controller en tant que plug-in de routeur dans un cluster OpenShift.
Routes OpenShift et méthodes d’entrée
Dans un cluster OpenShift, les clients externes ont besoin d’un moyen d’accéder aux services fournis par POD.OpenShift fournit deux ressources pour communiquer avec les services exécutés dans le cluster :les routesetl’entrée.
Itinéraires
Dans un cluster OpenShift, un itinéraire expose un service sur un nom de domaine donné ou associe un nom de domaine à un service. Les routeurs OpenShift acheminent les demandes externes vers des services au sein du cluster OpenShift conformément aux règles spécifiées dans les itinéraires. Lorsque vous utilisez le routeur OpenShift, vous devez également configurer le DNS externe pour vous assurer que le trafic arrive sur le routeur.
Le Citrix ingress controller peut être déployé en tant que plug-in de routeur dans le cluster OpenShift pour s’intégrer aux Citrix ADC déployés dans votre environnement. Le Citrix ingress controller vous permet d’utiliser les fonctionnalités avancées d’équilibrage de charge et de gestion du trafic de Citrix ADC avec votre cluster OpenShift. Les itinéraires OpenShift peuvent être sécurisés ou non sécurisés. Les itinéraires sécurisés spécifient la terminaison TLS de l’itinéraire.
Le Citrix ingress controller prend en charge les itinéraires OpenShift suivants :
- Routes non sécurisées : pour les itinéraires non sécurisés, le trafic HTTP n’est pas chiffré.
- Terminaison Edge : Pour la terminaison Edge, TLS est terminé au niveau du routeur. Le trafic entre le routeur et les points de terminaison sur le réseau interne n’est pas chiffré.
- Terminaison passthrough : Avec la terminaison de relais, le routeur n’est pas impliqué dans le déchargement TLS et le trafic crypté est envoyé directement à la destination.
- Fin du rechiffrement : Lors de la fin du rechiffrement, le routeur met fin à la connexion TLS, mais établit ensuite une autre connexion TLS avec le point final.
Selon la façon dont vous souhaitez utiliser Citrix ADC, il existe deux manières de déployer le Ingress Controller Citrix en tant que plug-in de routeur dans le cluster OpenShift : en tant que Citrix ADC CPX dans le cluster ou en tant que Citrix ADC MPX/VPX en dehors du cluster.
Déployer Citrix ADC CPX en tant que routeur au sein du cluster OpenShift
Le contrôleur Citrix Ingress est déployé en tant que side-car aux côtés du conteneur Citrix ADC CPX dans le même espace. Dans ce mode, le Citrix ingress controller configure le Citrix ADC CPX. Reportez-vous à la section Déployer Citrix ADC CPX en tant que routeur dans le cluster OpenShift.
Déployer Citrix ADC MPX/VPX en tant que routeur en dehors du cluster OpenShift
Le Citrix ingress controller est déployé en tant qu’espace autonome et vous permet de contrôler l’appliance Citrix ADC MPX ou VPX depuis l’extérieur du cluster OpenShift. Reportez-vous à la section Déployer Citrix ADC MPX/VPX en tant que routeur en dehors du cluster OpenShift.
Entrée
KubernetesIngress vous permet d’acheminer les demandes vers les services en fonction de l’hôte ou du chemin de requête, en centralisant un certain nombre de services dans un point d’entrée unique.
Le contrôleur Citrix Ingress est construit autour de Kubernetes Ingress, configurant automatiquement un ou plusieurs appliances Citrix ADC en fonction de la ressource Ingress.
Le routage avec Ingress peut être effectué par :
- Routage basé sur le nom d’hôte
- Routage basé sur le chemin
- Routage basé sur les caractères
- Correspondance de chemin
- Routage sans nom d’hôte
- Backend par défaut
Voir Configurations d’entrée pour obtenir des exemples et plus d’informations.
Déployer le Citrix ingress controller en tant que plug-in de routeur OpenShift
Selon la façon dont vous souhaitez utiliser Citrix ADC, il existe deux manières de déployer Citrix Ingress Controller en tant que plug-in de routeur dans le cluster OpenShift :
- En tant que conteneur sidecar à côté de Citrix ADC CPX dans le même conteneur : dans ce mode, le Controller d’entrée Citrix configure le Citrix ADC CPX. Reportez-vous à la section Déployer Citrix ADC CPX en tant que routeur dans le cluster OpenShift.
- En tant qu’espace autonome dans le cluster OpenShift : dans ce mode, vous pouvez contrôler l’appliance Citrix ADC MPX ou VPX déployée en dehors du cluster. Reportez-vous à la section Déployer Citrix ADC MPX/VPX en tant que routeur en dehors du cluster OpenShift.
Architectures recommandées
Nous recommandons les architectures suivantes aux clients lors de la conception de leurs architectures de microservices :
- Entrée unifiée Citrix
- Entrée Citrix à 2 niveaux
- Citrix Service Mesh Lite
Figure 1-2 : L’architecture varie d’une architecture relativement simple à une architecture plus complexe et riche en fonctionnalités.
Entrée unifiée Citrix
Dans un déploiement Unified Ingress, les appareils Citrix ADC MPX ou VPX transitent par proxy le trafic Nord-Sud des clients vers les applications d’entreprise déployées sous forme de microservices au sein du cluster. Le Citrix ingress controller est déployé en tant qu’espace ou sidecar dans le cluster Kubernetes pour automatiser la configuration des appareils Citrix ADC (MPX ou VPX) en fonction des modifications apportées aux microservices ou aux ressources Ingress.
Vous pouvez commencer à implémenter le modèle d’entrée unifié alors que votre application est encore monolithe. Il vous suffit de positionner Citrix ADC en tant que proxy inverse devant votre serveur d’applications et de mettre en œuvre les fonctionnalités décrites plus loin. Vous êtes alors bien placé pour convertir votre application en microservices.
La communication entre les microservices est gérée par un mécanisme de votre choix (kube-proxy, IPVS, etc.).
Fonctionnalités fournies dans différentes catégories
Les fonctionnalités de l’architecture Unified Ingress se répartissent en trois groupes.
Les fonctionnalités du premier groupe optimisent les performances :
- Équilibrage de charge
- Connectivité à faible latence
- Haute disponibilité
Les fonctionnalités du second groupe améliorent la sécurité et facilitent la gestion des applications :
- Limitation de débit
- Terminaison SSL/TLS
- Support HTTP/2
- Contrôles d’intégrité
Les fonctionnalités du dernier groupe sont spécifiques aux microservices :
- Point de communication central pour les services
- Capacité de passerelle d’API
Résumé
Les fonctionnalités du modèle d’entrée unifiée incluent un équilibrage robuste de la charge des services, un point de communication central, une découverte dynamique des services, une connectivité à faible latence, une haute disponibilité, une limitation du débit, une terminaison SSL/TLS, HTTP/2, etc.
Le modèle Unified Ingress permet de gérer facilement le trafic, d’équilibrer la charge des demandes et de répondre de manière dynamique aux modifications de l’application de microservices dorsale.
Les avantages incluent :
- Les flux de trafic nord-sud sont bien évolutifs, visibles à des fins d’observation et de surveillance, et fournissent une livraison continue grâce à des outils tels que Spinnaker et Citrix ADM
- Un niveau unique unifie l’équipe d’infrastructure qui gère les services du réseau et de la plate-forme, et réduit les sauts pour réduire la latence
- Convient aux applications internes qui n’ont pas besoin de Web App Firewall et de SSL Offload, mais qui peuvent être ajoutées ultérieurement
Les inconvénients incluent :
- Pas de sécurité Est-Ouest avec kube-proxy, mais possibilité d’ajouter Calico pour la segmentation L4
- L’évolutivité du proxy Kube est inconnue
- La visibilité du trafic est-ouest est limitée, voire nulle, car kube-proxy ne fournit pas de visibilité, de contrôle ou de journalisation, ce qui limite l’intégration d’outils ouverts et la livraison continue
- L’équipe de la plateforme doit également maîtriser le réseau
Entrée Citrix à 2 niveaux
Le modèle architectural d’entrée à deux niveaux est une excellente solution pour les novices de Cloud Native. Dans ce modèle, le Citrix ADC de niveau 1 gère le trafic entrant, mais envoie des demandes à l’ADC à 2 niveaux géré par les développeurs plutôt que directement aux instances de service. Le modèle d’entrée de niveau 2 applique des politiques, rédigées par l’équipe de la plateforme et des développeurs, au trafic entrant uniquement, et permet l’évolutivité du cloud et la mutualisation.
Figure 1-4 : Schéma du modèle d’entrée Citrix à 2 niveaux avec des conteneurs Citrix ADC VPX/MPX de niveau 1 et Citrix ADC CPX de niveau 2.
Fonctionnalité fournie par Tier-1
L’ADC de premier niveau, géré par l’équipe réseau traditionnelle, fournit un équilibrage de charge L4, Citrix Web App Firewall, un déchargement SSL et des services de proxy inverse. Les appareils Citrix ADC MPX ou VPX de niveau 1 transmettent le trafic (nord-sud) du client vers les CPX Citrix ADC de niveau 2.
Par défaut, le Citrix Ingress Controller programmera les configurations suivantes sur le niveau 1 :
- Proxy inverse des applications pour les utilisateurs :
- Serveurs virtuels de commutation de contenu
- Serveur virtuel (front-end, face à l’utilisateur)
- Groupes de services
- Déchargement SSL
- Journalisation/débogage de NetScaler
- Surveillance sanitaire des services
Fonctionnalité fournie par Tier-2
Alors que l’ADC de premier niveau fournit des services de proxy inverse, l’ADC de deuxième niveau, géré par l’équipe de la plateforme, sert de point de communication aux microservices, fournissant :
- Découverte dynamique des services
- Équilibrage de charge
- Visibilité et indicateurs complets
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.
Résumé
L’architecture réseau pour les microservices dans le modèle à deux niveaux utilise deux ADC configurés pour des rôles différents. L’ADC de niveau 1 agit en tant que serveur proxy destiné à l’utilisateur et l’ADC de niveau 2 en tant que proxy pour les microservices.
La division de différents types de fonctions entre deux niveaux différents permet de gagner en rapidité, en contrôle et d’optimiser la sécurité. Dans le deuxième niveau, l’équilibrage de charge est rapide, robuste et configurable.
Avec ce modèle, il existe une séparation claire entre l’administrateur de l’ADC et le développeur. C’est du BYOL pour les développeurs.
Les avantages incluent :
- Les flux de trafic nord-sud sont bien évolutifs, visibles à des fins d’observation et de surveillance, et fournissent une livraison continue grâce à des outils tels que Spinnaker et Citrix ADM
- Déploiement le plus simple et le plus rapide pour un novice en matière de cloud, avec de nouvelles formations limitées pour les équipes réseau
Les inconvénients incluent :
- Pas de sécurité Est-Ouest avec kube-proxy, mais possibilité d’ajouter Calico pour la segmentation L4
- L’évolutivité du proxy Kube est inconnue
- La visibilité du trafic est-ouest est limitée, voire nulle, car kube-proxy ne fournit pas de visibilité, de contrôle ou de journalisation, ce qui limite l’intégration d’outils ouverts et la livraison continue.
Citrix Service Mesh Lite
Le Service Mesh Lite est le plus riche en fonctionnalités des trois modèles. Il est sécurisé en interne, rapide, efficace et résilient, et il peut être utilisé pour appliquer des politiques pour le trafic entrant et inter-conteneurs.
Le modèle Service Mesh Lite convient à plusieurs cas d’utilisation, notamment :
- Applications liées à la santé et à la finance : les exigences réglementaires et celles des utilisateurs imposent de combiner sécurité et rapidité pour les applications financières et de santé, ce qui met en jeu des milliards de dollars de valeur financière et de réputation.
- Applications de commerce électronique — La confiance des utilisateurs est un problème majeur pour le commerce électronique et la rapidité est un facteur de différenciation concurrentiel clé. Il est donc crucial de combiner vitesse et sécurité.
Résumé
Les avantages incluent :
- Une approche plus robuste de la mise en réseau, avec un équilibreur de charge, CPX applique des politiques au trafic entrant et inter-conteneurs, en déployant des politiques L7 complètes.
- Observabilité, analyses, livraison continue et sécurité améliorées pour le trafic Nord-Sud et Est-Ouest
- Canary pour chaque conteneur avec un Citrix ADC intégré
- Un niveau unique unifie l’équipe d’infrastructure qui gère les services du réseau et de la plate-forme, et réduit les sauts pour réduire la latence
Les inconvénients incluent :
- Modèle plus complexe à déployer
- L’équipe de la plateforme doit maîtriser le réseau
Résumé des choix architecturaux
Entrée unifiée Citrix
-
Trafic applicatif Nord-Sud (NS) : un Citrix ADC est responsable du trafic NS L4 et L7, de la sécurité et de l’équilibrage de charge externe en dehors du cluster K8s.
-
Trafic applicatif Est-Ouest (EW) : kube-proxy est responsable du trafic L4 EW.
-
Sécurité : l’ADC est chargé de sécuriser le trafic NS et d’authentifier les utilisateurs. Kube-proxy est responsable du trafic L4 EW.
-
Évolutivité et performances : le trafic NS est bien évolutif et le clustering est une option. L’évolutivité du nouveau trafic et du kube-proxy est inconnue.
-
Observabilité : l’ADC fournit une excellente observabilité pour le trafic NS, mais aucune observabilité pour le trafic EW.
Entrée Citrix à 2 niveaux
-
Trafic applicatif Nord-Sud (NS) : l’ADC de niveau 1 est responsable du déchargement SSL, du Web App Firewall et du trafic NS L4. Il est utilisé à la fois pour les applications monolithes et CN. Le CPX de niveau 2 gère les changements rapides du trafic K8 et L7 NS.
-
Trafic applicatif Est-Ouest (EW) : kube-proxy est responsable du trafic L4 EW.
-
Sécurité : l’ADC de niveau 1 est chargé de sécuriser le trafic NS. L’authentification peut avoir lieu sur l’un ou l’autre ADC Le trafic EW n’est pas sécurisé avec Kube-Proxy.Ajoutez Calico pour la segmentation L4.
-
Évolutivité et performances : le trafic NS est bien évolutif et le clustering est une option. L’évolutivité du nouveau trafic et du kube-proxy est inconnue.
-
Observabilité : l’ADC de niveau 1 fournit une excellente observabilité pour le trafic NS, mais aucune observabilité pour le trafic EW.
Citrix Service Mesh Lite
-
Trafic applicatif Nord-Sud (NS) : l’ADC de niveau 1 est responsable du déchargement SSL, du Web App Firewall et du trafic NS L4. Il est utilisé à la fois pour les applications monolithes et CN. Le CPX de niveau 2 gère les changements rapides du trafic K8 et L7 NS.
-
Trafic applicatif Est-Ouest (EW) : le CPX de niveau 2 ou tout autre proxy open source est responsable du trafic EW L4. Les clients peuvent sélectionner les applications qui utilisent le CPX et celles qui utilisent le kube-proxy.
-
Sécurité : l’ADC de niveau 1 est chargé de sécuriser le trafic NS. L’authentification peut avoir lieu sur l’un ou l’autre ADC Le Citrix CPX est responsable de l’authentification, du déchargement SSL et de la sécurisation du trafic EW. Le chiffrement peut être appliqué au niveau de l’application.
-
Évolutivité et performances : le trafic NS et EW est bien évolutif, mais il ajoute un saut en ligne.
-
Observabilité : l’ADC de niveau 1 fournit une excellente observabilité du trafic NS. Le CPX de niveau 2 permet d’observer le trafic EW, mais il peut être désactivé pour réduire la mémoire CPX ou l’encombrement du processeur.
Comment déployer
Entrée unifiée Citrix
Pour valider un déploiement de Citrix Unified Ingress avec OpenShift, utilisez un exemple d’application « hello-world » avec un Citrix ADC VPX ou MPX. L’espace de noms par défaut d’OpenShift, « default », est utilisé pour ce déploiement.
-
Une instance Citrix ADC est créée à la main et configurée avec un NSIP/SNIP.L’installation de Citrix ADC sur XenServer est disponible ici.
-
Copiez l’exemple de fichier YAML suivant dans un répertoire OpenShift et nommez-le application.yaml.
apiVersion: apps/v1 kind: Deployment metadata: name: hello-world spec: selector: matchLabels: run: load-balancer-example replicas: 2 template: metadata: labels: run: load-balancer-example spec: containers: - name: hello-world image: gcr.io/google-samples/node-hello:1.0 ports: - containerPort: 8080 protocol: TCP <!--NeedCopy--> -
Déployez l’application.
oc apply -f application.yaml -
Assurez-vous que les pods fonctionnent.
oc get pods -
Copiez l’exemple de fichier YAML suivant dans un répertoire OpenShift et nommez-le service.yaml.
apiVersion: v1 kind: Service metadata: name: hello-world-service spec: type: NodePort ports: - port: 80 targetPort: 8080 selector: run: load-balancer-example <!--NeedCopy--> -
Exposez l’application via NodePort avec un service.
oc apply -f service.yaml -
Vérifiez que le service a été créé.
oc get service -
Copiez l’exemple de fichier YAML suivant dans un répertoire OpenShift et nommez-le Ingress.yaml.Vous devez remplacer l’annotation « ingress.citrix.com/frontend-ip » par une adresse IP libre à définir comme VIP sur Citrix ADC.
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: hello-world-ingress annotations: kubernetes.io/ingress.class: "vpx" ingress.citrix.com/insecure-termination: "redirect" ingress.citrix.com/frontend-ip: "10.217.101.183" spec: rules: - host: helloworld.com http: paths: - path: backend: serviceName: hello-world-service servicePort: 80 <!--NeedCopy--> -
Déployez le fichier YAML Ingress.
oc apply -f ingress.yaml -
Il existe maintenant des modules d’application que nous avons exposés à l’aide d’un service et que nous pouvons acheminer le trafic vers eux à l’aide d’Ingress. Installez le Citrix Ingress Controller (CIC) pour transférer ces configurations vers notre VPN ADC de niveau 1. Avant de déployer le CIC, déployez un fichier RBAC qui donne au CIC les autorisations d’exécution correctes.
Remarque :
Le fichier yaml rbac spécifie l’espace de noms et il devra être modifié, en fonction de l’espace de noms utilisé.
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx rules: - apiGroups: [""] resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"] verbs: ["\*"] - apiGroups: ["extensions"] resources: ["ingresses", "ingresses/status"] verbs: ["\*"] - apiGroups: ["citrix.com"] resources: ["rewritepolicies"] verbs: ["\*"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["\*"] <!--NeedCopy-->kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cpx subjects: - kind: ServiceAccount name: cpx namespace: default <!--NeedCopy-->apiVersion: v1 kind: ServiceAccount metadata: name: cpx namespace: default <!--NeedCopy--> -
Déployez le fichier RBAC.
oc apply -f rbac.yaml -
Avant de déployer le CIC, modifiez le fichier YAML. Selon les spécifications, ajoutez le NSIP ou le SNIP tant que la gestion est activée sur le SNIP, de l’ADC de niveau 1. Notez que l’argument « ingress-classes » est identique à l’annotation de classe d’entrée spécifiée dans le fichier Ingress YAML.
apiVersion: v1 kind: Pod metadata: name: hello-world-cic labels: app: hello-world-cic spec: serviceAccountName: cpx containers: - name: hello-world-cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3" env: # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled) - name: "NS_IP" value: "10.217.101.193" # Set username for Nitro # Set log level - name: "NS_ENABLE_MONITORING" value: "NO" - name: "NS_USER" value: "nsroot" - name: "NS_PASSWORD" value: "nsroot" - name: "EULA" value: "yes" - name: "LOGLEVEL" value: "DEBUG" args: - --ingress-classes vpx - --feature-node-watch false imagePullPolicy: IfNotPresent <!--NeedCopy--> -
Déployez le CIC.
oc apply -f cic.yaml -
Vérifiez que tous les pods fonctionnent.
oc get pods -
Modifiez le fichier hosts sur votre machine locale avec une entrée pour helloworld.com et le VIP sur Citrix ADC spécifié dans le fichier YAML Ingress.
-
Accédez à helloworld.com dans un navigateur. « Bonjour Kubernetes ! « devrait apparaître.
Remarque : Les commandes de suppression sont les suivantes
oc delete pods (pod name) -n (namespace name)oc delete deployment (deployment name) -n (namespace name)oc delete service (service name) -n (namespace name)oc delete ingress (ingress name) -n (namespace name)oc delete serviceaccounts (serviceaccounts name) -n (namespace name)
Entrée Citrix à 2 niveaux
Pour valider un déploiement d’entrée à 2 niveaux de Citrix avec OpenShift, utilisez un exemple d’application « hello-world » avec un Citrix ADC VPX ou MPX. L’espace de noms par défaut « tier-2-adc » est utilisé pour ce déploiement.**Remarque : Lors du déploiement de pods, de services et d’Ingress, l’espace de noms doit être spécifié à l’aide du paramètre « -n (nom de l’espace de noms) ».
-
Une instance Citrix ADC est construite à la main et configurée avec un NSIP/SNIP. L’installation de Citrix ADC sur XenServer peut être trouvée [ici. Si l’instance était déjà configurée, supprimez tous les serveurs virtuels dans Load Balancing ou Content Switching qui ont été transférés vers l’ADC du déploiement de hello-world en tant qu’entrée unifiée.
-
Créez un espace de noms appelé « tier-2-adc ».
oc create namespace tier-2-adc -
Copiez l’exemple de fichier YAML suivant dans un répertoire OpenShift et nommez-le
application-2t.yaml.apiVersion: apps/v1 kind: Deployment metadata: name: hello-world spec: selector: matchLabels: run: load-balancer-example replicas: 2 template: metadata: labels: run: load-balancer-example spec: containers: - name: hello-world image: gcr.io/google-samples/node-hello:1.0 ports: - containerPort: 8080 protocol: TCP <!--NeedCopy--> -
Déployez l’application dans l’espace de noms.
oc apply -f application-2t.yaml -n tier-2-adc -
Assurez-vous que les pods fonctionnent.
oc get pods -
Copiez l’exemple de fichier YAML suivant dans un répertoire OpenShift et nommez-le
service-2t.yaml.apiVersion: v1 kind: Service metadata: name: hello-world-service-2 spec: type: NodePort ports: -port: 80 targetPort: 8080 selector: run: load-balancer-example <!--NeedCopy--> -
Exposez l’application via NodePort avec un service.
oc apply -f service-2t.yaml -n tier-2-adc -
Vérifiez que le service a été créé.
oc get service -n tier-2-adc -
Copiez l’exemple de fichier YAML suivant dans un répertoire OpenShift et nommez-le
ingress-2t.yaml.apiVersion: extensions/v1beta1 kind: Ingress metadata: name: hello-world-ingress-2 annotations: kubernetes.io/ingress.class: "cpx" spec: backend: serviceName: hello-world-service-2 servicePort: 80 <!--NeedCopy--> -
Déployez le fichier YAML Ingress.
oc apply -f ingress-2t.yaml -n tier-2-adc -
Déployez un fichier RBAC qui donne au CIC et au CPX les autorisations d’exécution correctes.
Remarque :
Le fichier yaml rbac spécifie l’espace de noms et il devra être modifié, en fonction de l’espace de noms utilisé.
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx rules: -apiGroups: [""] resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"] verbs: ["\*"] -apiGroups: ["extensions"] resources: ["ingresses", "ingresses/status"] verbs: ["\*"] -apiGroups: ["citrix.com"] resources: ["rewritepolicies"] verbs: ["\*"] -apiGroups: ["apps"] resources: ["deployments"] verbs: ["\*"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cpx subjects: - kind: ServiceAccount name: cpx namespace: tier-2-adc --- apiVersion: v1 kind: ServiceAccount metadata: name: cpx namespace: tier-2-adc <!--NeedCopy--> -
Déployez le fichier RBAC.
oc apply -f rbac-2t.yaml -
Le compte de service a besoin d’autorisations élevées pour créer un CPX.
oc adm policy add-scc-to-user privileged system:serviceaccount:tier-2-adc:cpx -
Modifiez le fichier CPX YAML et appelez-le
cpx-2t.yaml. Cela déploie le CPX et le service qui l’expose. Notez que l’argument de Ingress Class correspond à l’annotation duingress-2t.yamlfichier.apiVersion: extensions/v1beta1 kind: Deployment metadata: name: hello-world-cpx-2 spec: replicas: 1 template: metadata: name: hello-world-cpx-2 labels: app: hello-world-cpx-2 app1: exporter annotations: NETSCALER_AS_APP: "True" spec: serviceAccountName: cpx containers: - name: hello-world-cpx-2 image: "quay.io/citrix/citrix-k8s-cpx-ingress:13.0-36.28" securityContext: privileged: true env: - name: "EULA" value: "yes" - name: "KUBERNETES_TASK_ID" value: "" imagePullPolicy: Always # Add cic as a sidecar - name: cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3" env: - name: "EULA" value: "yes" - name: "NS_IP" value: "127.0.0.1" - name: "NS_PROTOCOL" value: "HTTP" - name: "NS_PORT" value: "80" - name: "NS_DEPLOYMENT_MODE" value: "SIDECAR" - name: "NS_ENABLE_MONITORING" value: "YES" - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace args: - --ingress-classes cpx imagePullPolicy: Always apiVersion: v1 kind: Service metadata: name: lb-service-cpx labels: app: lb-service-cpx spec: type: NodePort ports: - port: 80 protocol: TCP name: http targetPort: 80 selector: app: hello-world-cpx-2 <!--NeedCopy--> -
Déployez le CPX.
oc apply -f cpx-2t.yaml -n tier-2-adc -
Vérifiez que le pod est en cours d’exécution et que le service a été créé.
oc get pods -n tier-2-adcoc get service -n tier-2-adc -
Créez une entrée pour router du VPX au CPX. L’adresse IP du front-end doit être une adresse IP libre sur l’ADC. Donnez un nom au fichier :
ingress-cpx-2t.yaml.apiVersion: extensions/v1beta1 kind: Ingress metadata: name: hello-world-ingress-vpx-2 annotations: kubernetes.io/ingress.class: "helloworld" ingress.citrix.com/insecure-termination: "redirect" ingress.citrix.com/frontend-ip: "10.217.101.183" spec: rules: - host: helloworld.com http: paths: - path: backend: serviceName: lb-service-cpx servicePort: 80 <!--NeedCopy--> -
Déployez l’Ingress.
oc apply -f ingress-cpx-2t.yaml -n tier-2-adc -
Avant de déployer le CIC, modifiez le fichier YAML. Selon les spécifications, ajoutez le NSIP ou le SNIP tant que la gestion est activée sur le SNIP, de l’ADC de niveau 1.
apiVersion: v1 kind: Pod metadata: name: hello-world-cic labels: app: hello-world-cic spec: serviceAccountName: cpx containers: - name: hello-world-cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3" env: # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled) - name: "NS_IP" value: "10.217.101.176" # Set username for Nitro # Set log level - name: "NS_ENABLE_MONITORING" value: "NO" - name: "NS_USER" value: "nsroot" - name: "NS_PASSWORD" value: "nsroot" - name: "EULA" value: "yes" - name: "LOGLEVEL" value: "DEBUG" args: - --ingress-classes helloworld - --feature-node-watch false imagePullPolicy: IfNotPresent <!--NeedCopy--> -
Déployez le CIC.
oc apply -f cic-2t.yaml -n tier-2-adc -
Vérifiez que tous les pods fonctionnent.
oc get pods -n tier-2-adc -
Modifiez le fichier hosts sur votre machine locale avec une entrée pour helloworld.com et le VIP sur Citrix ADC spécifié dans le fichier YAML Ingress qui achemine du VPX au CPX.
-
Accédez à helloworld.com dans un navigateur. « Bonjour Kubernetes ! « devrait apparaître.
Citrix Service Mesh Lite
Service Mesh Lite permet l’introduction de CPX (ou d’autres appliances Citrix ADC) en remplacement des fonctionnalités HAProxy intégrées. Cela nous permet d’étendre nos fonctionnalités N/S dans Kubernetes et de fournir également un équilibrage de charge du trafic E/W, un routage et une observabilité. 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 pour 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 de signaux dorés (erreurs, latences, saturation ou volume de trafic). Le Service Graph de Citrix ADM est une solution d’observabilité permettant de surveiller et de déboguer les microservices.
- Dans ce scénario de déploiement, nous déployons l’application Bookinfo et observons son fonctionnement par défaut. Ensuite, nous extrayons et remplaçons les services Kubernetes par défaut et utilisons CPX et VPX pour transmettre notre trafic E/W par proxy.
Citrix Service Mesh Lite avec un CPX
Pour valider un déploiement de Citrix Unified Ingress avec OpenShift, utilisez un exemple d’application « hello-world » avec un Citrix ADC VPX ou MPX. L’espace de noms par défaut pour OpenShift, « default », est utilisé pour ce déploiement.
-
Une instance Citrix ADC est créée à la main et configurée avec un NSIP/SNIP.L’installation de Citrix ADC sur XenServer est disponible ici.
-
Créez un espace de noms pour ce déploiement. Dans cet exemple,
smlest utilisé.oc create namespace sml -
Copiez le fichier YAML suivant pour créer le déploiement et les services pour Bookinfo. Nommez-le bookinfo.yaml.
##################################################################################################
# Details service
##################################################################################################
apiVersion: v1
kind: Service
metadata:
name: details
labels:
app: details
service: details
spec:
ports:
- port: 9080
name: http
selector:
app: details
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: details-v1
labels:
app: details
version: v1
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: details
version: v1
spec:
containers:
- name: details
image: docker.io/maistra/examples-bookinfo-details-v1:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
##################################################################################################
# Ratings service
##################################################################################################
apiVersion: v1
kind: Service
metadata:
name: ratings
labels:
app: ratings
service: ratings
spec:
ports:
- port: 9080
name: http
selector:
app: ratings
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: ratings-v1
labels:
app: ratings
version: v1
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: ratings
version: v1
spec:
containers:
- name: ratings
image: docker.io/maistra/examples-bookinfo-ratings-v1:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
##################################################################################################
# Reviews service
##################################################################################################
apiVersion: v1
kind: Service
metadata:
name: reviews
labels:
app: reviews
service: reviews
spec:
ports:
- port: 9080
name: http
selector:
app: reviews
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: reviews-v1
labels:
app: reviews
version: v1
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: reviews
version: v1
spec:
containers:
- name: reviews
image: docker.io/maistra/examples-bookinfo-reviews-v1:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: reviews-v2
labels:
app: reviews
version: v2
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: reviews
version: v2
spec:
containers:
- name: reviews
image: docker.io/maistra/examples-bookinfo-reviews-v2:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: reviews-v3
labels:
app: reviews
version: v3
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: reviews
version: v3
spec:
containers:
- name: reviews
image: docker.io/maistra/examples-bookinfo-reviews-v3:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
##################################################################################################
# Productpage services
##################################################################################################
apiVersion: v1
kind: Service
metadata:
name: productpage-service
spec:
type: NodePort
ports:
- port: 80
targetPort: 9080
selector:
app: productpage
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: productpage-v1
labels:
app: productpage
version: v1
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "false"
labels:
app: productpage
version: v1
spec:
containers:
- name: productpage
image: docker.io/maistra/examples-bookinfo-productpage-v1:0.12.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9080
---
<!--NeedCopy-->
-
Déployez le fichier bookinfo.yaml dans l’espace de noms sml.
oc apply -f bookinfo.yaml -n sml -
Copiez et déployez le fichier Ingress qui correspond au service de page produit. Ce fichier peut être nommé
ingress-productpage.yaml. L’adresse IP du front-end doit être un VIP gratuit sur le Citrix ADC VPX/MPX.apiVersion: extensions/v1beta1 kind: Ingress metadata: name: productpage-ingress annotations: kubernetes.io/ingress.class: "bookinfo" ingress.citrix.com/insecure-termination: "redirect" ingress.citrix.com/frontend-ip: "10.217.101.182" spec: rules: - host: bookinfo.com http: paths: - path: backend: serviceName: productpage-service servicePort: 80 <!--NeedCopy-->
oc apply -f ingress-productpage.yaml -n sml
-
Copiez le fichier YAML suivant pour le fichier RBAC dans l’espace de noms sml et déployez-le. Nommez le fichier
rbac-cic-pp.yamltel qu’il est utilisé pour le CIC devant le microservice de la page produit.kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx rules: - apiGroups: [""] resources: ["services", "endpoints", "ingresses", "pods", "secrets", "routes", "routes/status", "nodes", "namespaces"] verbs: ["\*"] - apiGroups: ["extensions"] resources: ["ingresses", "ingresses/status"] verbs: ["\*"] - apiGroups: ["citrix.com"] resources: ["rewritepolicies", "vips"] verbs: ["\*"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["\*"] - apiGroups: ["apiextensions.k8s.io"] resources: ["customresourcedefinitions"] verbs: ["get", "list", "watch"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cpx subjects: - kind: ServiceAccount name: cpx namespace: sml apiVersion: rbac.authorization.k8s.io/v1 --- apiVersion: v1 kind: ServiceAccount metadata: name: cpx namespace: sml <!--NeedCopy-->
oc apply -f rbac-cic-pp.yaml -n sml
-
Élevez les privilèges du compte de service pour déployer le CIC et le CPX.
oc adm policy add-scc-to-user privileged system:serviceaccount:sml:cpx -
Modifiez le fichier hosts sur la machine locale avec bookinfo.com mappé à l’adresse IP du front-end spécifiée dans le
ingress-productpage.yaml. -
Copiez et déployez la page du produit avec un CIC. Nommez le fichier
cic-productpage.yaml. Le NS_IP doit être le NS_IP de l’ADC de niveau 1.apiVersion: v1 kind: Pod metadata: name: productpage-cic labels: app: productpage-cic spec: serviceAccountName: cpx containers: - name: productpage-cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3" env: # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled) - name: "NS_IP" value: "10.217.101.176" # Set username for Nitro # Set log level - name: "NS_ENABLE_MONITORING" value: "NO" - name: "NS_USER" value: "nsroot" - name: "NS_PASSWORD" value: "nsroot" - name: "EULA" value: "yes" - name: "LOGLEVEL" value: "DEBUG" - name: "NS_APPS_NAME_PREFIX" value: "BI-" args: - --ingress-classes bookinfo - --feature-node-watch false imagePullPolicy: IfNotPresent <!--NeedCopy-->
oc apply -f cic-productpage.yaml -n sml
-
Accédez à bookinfo.com et cliquez sur utilisateur normal. La page du produit doit afficher les détails, les avis et les évaluations, qui sont d’autres microservices. HAProxy est responsable du routage du trafic entre les microservices (Est-Ouest).
-
Supprimez le service devant les détails. Actualisez la page Web Bookinfo et remarquez que la page du produit n’a pas pu extraire le microservice pour plus de détails.
oc delete service details -n sml -
Copiez et déployez un service headless afin que le trafic provenant de la page produit vers les détails passe par un CPX. Appelez ce fichier detailsheadless.yaml.
apiVersion: v1 kind: Service metadata: name: details spec: ports: - port: 9080 name: http selector: app: cpx <!--NeedCopy-->
oc apply -f detailsheadless.yaml -n sml
-
Copiez et déployez un nouveau service de détails, qui doit s’appeler detailsservice.yaml, devant le microservice de détails.
apiVersion: v1 kind: Service metadata: name: details-service labels: app: details-service service: details-service spec: clusterIP: None ports: - port: 9080 name: http selector: app: details <!--NeedCopy-->
oc apply -f detailsservice.yaml -n sml
-
Exposez le service de détails avec une entrée et déployez-le. Appelez ce fichier detailsingress.yaml.
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: details-ingress annotations: kubernetes.io/ingress.class: "cpx" ingress.citrix.com/insecure-port: "9080" spec: rules: - host: details http: paths: - path: backend: serviceName: details-service servicePort: 9080 <!--NeedCopy-->
oc apply -f detailsingress.yaml -n sml
-
Copiez et déployez le fichier CPXEastWest.yaml.
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: cpx labels: app: cpx service: cpx spec: replicas: 1 template: metadata: name: cpx labels: app: cpx service: cpx annotations: NETSCALER_AS_APP: "True" spec: serviceAccountName: cpx containers: - name: reviews-cpx image: "quay.io/citrix/citrix-k8s-cpx-ingress:13.0-36.28" securityContext: privileged: true env: - name: "EULA" value: "yes" - name: "KUBERNETES_TASK_ID" value: "" - name: "MGMT_HTTP_PORT" value: "9081" ports: - name: http containerPort: 9080 - name: https containerPort: 443 - name: nitro-http containerPort: 9081 - name: nitro-https containerPort: 9443 imagePullPolicy: Always # Add cic as a sidecar - name: cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.2.0" env: - name: "EULA" value: "yes" - name: "NS_IP" value: "127.0.0.1" - name: "NS_PROTOCOL" value: "HTTP" - name: "NS_PORT" value: "80" - name: "NS_DEPLOYMENT_MODE" value: "SIDECAR" - name: "NS_ENABLE_MONITORING" value: "YES" - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace args: - --ingress-classes cpx imagePullPolicy: Always <!--NeedCopy-->
oc apply -f CPXEastWest.yaml -n sml
- Actualisez bookinfo.com et les détails devraient être extraits de Details MicroService.Un CPX a été déployé avec succès pour proxy du trafic EW.
Citrix Service Mesh Lite avec un VPX/MPX
-
Exécutez les commandes suivantes pour supprimer le CPX utilisé comme proxy EW. Un nouveau fichier est déployé pour configurer le VPX en tant que proxy EW entre la page du produit et les microservices de détails.
oc delete -f detailsheadless.yaml -n smloc delete -f detailsservice.yaml -n smloc delete -f detailsingress.yaml -n smloc delete -f CPXEastWest.yaml -n sml -
Copiez et déployez un service, nommez le fichier DetailsVPX.yaml, pour renvoyer le trafic de la page produit vers le VPX. Le paramètre IP doit être un VIP gratuit sur le Citrix ADC VPX/MPX.
--- kind: "Service" apiVersion: "v1" metadata: name: "details" spec: ports: - name: "details" protocol: "TCP" port: 9080 --- kind: "Endpoints" apiVersion: "v1" metadata: name: "details" subsets: - addresses: - ip: "10.217.101.182" # Ingress IP in MPX ports: - port: 9080 name: "details" <!--NeedCopy-->
oc apply -f detailstoVPX.yaml -n sml
-
Redéployez le fichier detailsservice.yaml devant le microservice de détails.
oc apply -f detailsservice.yaml -n sml -
Copiez et déployez l’Ingress pour exposer les détails du microservice au VPX. C’est nommé
detailsVPXingress.yaml. L’adresse IP du front-end doit correspondre à celle du VIP sur l’ADC de niveau 1.apiVersion: extensions/v1beta1 kind: Ingress metadata: name: details-ingress annotations: kubernetes.io/ingress.class: "vpx" ingress.citrix.com/insecure-port: "9080" ingress.citrix.com/frontend-ip: "10.217.101.182" spec: rules: - host: details http: paths: - path: backend: serviceName: details-service servicePort: 9080 <!--NeedCopy-->
oc apply -f detailsVPXingress.yaml
- Actualisez bookinfo.com et les informations devraient être extraites du microservice Details. Un VPX a été déployé avec succès pour transmettre le trafic EW par proxy.
Migration de service vers Citrix ADC à l’aide de routes ou de classes d’entrée dans Openshift
Migration de service avec partitionnement de route
Le Citrix Ingress Controller (CIC) agit comme un routeur et redirige le trafic vers divers espaces afin de répartir le trafic entrant entre les différents espaces disponibles.
Ce processus de migration peut également faire partie d’un processus de mise à niveau de cluster à partir de topologies Openshift héritées vers des déploiements automatisés avec des composants Citrix CNC, CIC et CPX pour les procédures de migration et de mise à niveau du cluster.
Cette solution peut être obtenue par deux méthodes :
- Routeur CIC par plug-in (Pod)
- Routeur CPX à l’intérieur d’Openshift (Sidecar)
Les deux méthodes sont décrites ci-dessous avec des exemples de migration.
Static Routes (par défaut) : mappe le sous-réseau hôte Openshift avec l’ADC externe via une route statique.
Les routes statiques sont courantes dans les déploiements Openshift hérités utilisant HAProxy. Les routes statiques peuvent être utilisées en parallèle avec Citrix CNC, CIC et CPX lors de la migration de services d’un service proxy vers un autre sans perturber les espaces de noms déployés dans un cluster fonctionnel.
Exemple de configuration d’itinéraire statique pour Citrix ADC :
oc get hostsubnet (Openshift Cluster) snippet
oc311-master.example.com 10.x.x.x 10.128.0.0/23
oc311-node1.example.com 10.x.x.x 10.130.0.0/23
oc311-node2.example.com 10.x.x.x 10.129.0.0/23
show route (external Citrix VPX) snippet
10.128.0.0 255.255.254.0 10.x.x.x STATIC
10.129.0.0 255.255.254.0 10.x.x.x STATIC
10.130.0.0 255.255.254.0 10.x.x.x STATIC
Routes automatiques : utilise le CNC (Citrix Node Controller) pour automatiser les routes externes vers les partitions d’itinéraires définies.
Vous pouvez intégrer Citrix ADC à OpenShift de deux manières, toutes deux prenant en charge le partitionnement du routeur OpenShift.
Types d’itinéraires
- unsecure - équilibreur de charge externe vers le routeur CIC, le trafic HTTP n’est pas crypté.
- secured-edge - équilibreur de charge externe vers le routeur CIC mettant fin à TLS.
- secured-passthrough - équilibreur de charge externe vers la destination terminant TLS
- secure reencrypt - équilibreur de charge externe vers le routeur CIC mettant fin à TLS. Chiffrement du routeur CIC vers la destination à l’aide de TLS.
Exemple de déploiement #1 : CIC déployé en tant que plug-in de routeur OpenShift
Pour les itinéraires, nous utilisons les concepts de partitionnement d’itinéraires. Ici, le CIC agit comme un routeur et redirige le trafic vers divers pods afin de répartir le trafic entrant entre les différents pods disponibles. Le CIC est installé en tant que plug-in de routeur pour Citrix ADC MPX ou VPX, déployé en dehors du cluster.
Composants Citrix :
- VPX - L’ADC d’entrée qui présente les services de cluster au DNS.
- CIC - fournit les ROUTE_LABELS et NAMESPACE_LABELS au Citrix ADC externe via la route CNC.
Exemples de paramètres de fichier YAML pour les partitions de route :
Les fichiers sources de Citrix Openshift se trouvent dans Github ici
-
Ajoutez les variables d’environnement suivantes, ROUTE_LABELS et NAMESPACE_LABELS, avec la valeur au format d’étiquette kubernetes. Les expressions de partitionnement d’itinéraire dans CIC, NAMESPACE_LABELS, sont un champ facultatif. S’il est utilisé, il doit correspondre aux étiquettes d’espace de noms mentionnées dans le fichier route.yaml.
env: - name: "ROUTE_LABELS" value: "name=apache-web" - name: "NAMESPACE_LABELS" value: "app=hellogalaxy" -
Les routes créées via route.yaml auront des étiquettes qui correspondent aux expressions de partitionnement d’itinéraire dans le CIC qui sera configuré.
metadata: name: apache-route namespace: hellogalaxy labels: name: apache-web -
Exposez le service avec service.yaml.
metadata: name: apache-service spec: type: NodePort #type=LoadBalancer ports: - port: 80 targetPort: 80 selector: app: apache -
Déployez une application Web simple avec une étiquette de sélection correspondant à celle du fichier service.yaml.
Exemple de déploiement #2 : Citrix ADC CPX déployé en tant que routeur OpenShift
Citrix ADC CPX peut être déployé en tant que routeur OpenShift, avec le Ingress Controller Citrix au sein du cluster. Pour plus d’informations sur le déploiement d’un CPX ou d’un CIC en tant que routeur dans le cluster, voir Activer la prise en charge du partitionnement de routage OpenShift avec Citrix ADC.
Composants Citrix :
- VPX - L’ADC d’entrée qui présente les services de cluster au DNS.
- CIC - fournit ROUTE_LABELS et NAMESPACE_LABELS au Citrix ADC externe pour définir les partitions de route.
- CNC - fournit la configuration de routage automatique pour les partitions vers l’équilibreur de charge externe.
- CPX - fournit le routage Openshift au sein du cluster Openshift.
Migration de services avec annotation de classes d’entrée
Ingress Classes Annotations utilise le concept d’annotation des classes d’entrée, nous ajoutons des annotations à Ingress avec des informations de classe d’entrée, cela aidera à rediriger le trafic vers un pod/nœud particulier à partir de l’ADC externe.
Exemples de paramètres de fichier YAML pour les classes d’entrée :**
Les fichiers sources de Citrix Ingress se trouvent dans Github ici
env:
args:
- --ingress-classes
vpx
Le fichier de configuration Ingress doit également avoir un champ d’annotations kubernetes.io/ingress.class à l’intérieur des métadonnées qui sera mis en correspondance avec le champ args de classes d’entrée CIC, au moment de la création.
Exemple de déploiement Ingress VPX avec l’exemple « ingress.classes »**
kind: Ingress
metadata:
name: ingress-vpx
annotations:
kubernetes.io/ingress.class: "vpx"
Exportateur de métriques
Vous pouvez utiliser l’ exportateur de métriques Citrix ADC et Prometheus-Operator pour surveiller les appareils d’entrée Citrix ADC VPX ou CPX et les appareils Citrix ADC CPX (est-ouest). Consultez Afficher les métriques des Citrix ADC à l’aide de Prometheus et Grafana.
Dans cet article
- Pourquoi choisir Citrix pour une diffusion d’applications modernes
- Une solution pour toutes les parties prenantes
- Explication de la pile logicielle Citrix
- La valeur de Citrix ADC
- Les avantages de Citrix ADC
- L’avantage de la suite Citrix ADC
- Ecosystème de partenaires
-
Présentation d’OpenShift
- Projets OpenShift
- Espaces de noms OpenShift
- Réseau défini par logiciel (SDN) OpenShift
- Routage OpenShift et plug-ins
- Routes OpenShift et méthodes d’entrée
- Déployer Citrix ADC CPX en tant que routeur au sein du cluster OpenShift
- Déployer Citrix ADC MPX/VPX en tant que routeur en dehors du cluster OpenShift
- Déployer le Citrix ingress controller en tant que plug-in de routeur OpenShift
- Architectures recommandées
- Comment déployer
- Migration de service vers Citrix ADC à l’aide de routes ou de classes d’entrée dans Openshift
- Exportateur de métriques