Concepts avancés

Modèle de conception validé de Citrix Cloud Native Networking pour Red Hat OpenShift 3.11

La pile Citrix ADC 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 mise à l’échelle des topologies d’applications agiles (SSL et GSLB) et d’observabilité proactive (Service Graph) dans un environnement Cloud Native hautement orchestré.

La transformation numérique alimente 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, y compris des workflows agiles, des jeux d’outils de déploiement d’automatisation et des langages et plates-formes de développement.

La nouvelle ère du déploiement d’applications modernes a également changé les disciplines traditionnelles du modèle commercial des datacenters, notamment les versions mensuelles et annuelles de logiciels et les contrats, les ressources de calcul en silo et le budget, ainsi que le modèle de consommation des fournisseurs.

Et bien que toute cette modernisation se produise dans l’écosystème, il existe encore des exigences de base pour les fonctionnalités de disponibilité des applications (ADC), la ségrégation des fonctionnalités de sécurité (WAF), la mise à l’échelle des topologies d’applications agiles (SSL et GSLB) et l’observabilité proactive (Service Graph) en un environnement.

Pourquoi Citrix for Modern Application Delivery

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.

CI/CD est un moyen de fournir vitesse, sécurité et fiabilité dans le cycle de vie moderne des applications.

L’intégration continue (CI) permet une base de code commune qui peut être mise à jour en temps réel plusieurs fois par jour et s’intégrer dans une plate-forme de construction automatisée. Les trois phases de l’intégration continue sont Push, Test, Fix.

Continuous Delivery (CD) intègre le pipeline de déploiement directement dans le processus de développement CI, optimisant ainsi et améliorant le modèle de livraison 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 d’intervenants dans l’activité moderne de prestation de services :

  • Équipe plates-formes : déployez une infrastructure de datacenter comme IaaS, PaaS, SDN, ADC, WAF
  • DevOps et équipe d’ingénierie : développez et maintenez le référentiel de code unifié, les outils d’automatisation et l’architecture logicielle
  • Équipe d’ingénierie de fiabilité des services (SRE) : réduisez les silos organisationnels, la gestion des erreurs, l’automatisation du déploiement et les mesures
  • Équipe des opérations de sécurité : stratégies de sécurité proactives, gestion des incidents, déploiement des 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 multilocataire sur laquelle vous pouvez provisionner et gérer plusieurs machines Citrix ADC (instances) virtuelles.
    • 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é

Avantages de Citrix ADC

  • Déplacer les applications héritées sans avoir à les réécrire
  • Les développeurs peuvent sécuriser des applications avec des stratégies Citrix ADC à l’aide des API Kubernetes (Utilisation de CRD — conviviale pour les développeurs)
  • Déployer des microservices hautes performances pour le réseau Nord-Sud et Service Mesh
  • Utiliser un graphique Application Service pour tous les microservices
  • Résoudre les problèmes de microservices plus rapidement sur TCP, UDP, HTTP/S, SSL
  • Sécurisez les API et configurez à l’aide des API Kubernetes
  • Améliorer le processus CICD pour les déploiements Canary

Composants d’architecture

Portefeuille de solutions Citrix pour les applications natives dans le cloud

L’avantage de Citrix ADC Suite

Citrix est synonyme de 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 dans le cloud pour les plates-formes et outils cloud basés sur abonnement, nous permettons de diriger et d’orchestration du trafic vers votre cluster Kubernetes sur site grâce à l’orchestration facile du Controller d’entrée, et nous traitons les architectures Service Mesh de simple à 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 entre les équipes DevOps, SecOps et Plateformes.

Citrix est agile et moderne. Créez une architecture de base permettant aux clients d’utiliser les nouvelles fonctionnalités de Citrix Cloud Native Stack avec leurs ADC existants 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 les outils OpenSource CNCF et les produits Citrix de qualité entreprise.

Ecosystème partenaire

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.

Citrix Ingress Controller est pris en charge sur les plates-formes suivantes :

  • Kubernetes v1.10 sur métal nu 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 des mesures, des alertes et des informations
  • Grafana — une plateforme d’analyse et de suivi
  • Spinnaker — un outil pour la livraison continue multi-cloud et Canary - analytics
  • Elasticsearch — un service de recherche d’application ou de site
  • Kibana — un outil de visualisation pour les données de recherche élastique et un outil de navigation de pile élastique
  • Fluentd — un outil de collecte de données

Le thème de cette section suivante est la conception/architecture avec OpenShift.

Présentation d’OpenShift

Red Hat OpenShift est une plate-forme Kubernetes destinée aux déploiements axés sur l’utilisation de microservices et de conteneurs pour créer et mettre à l’échelle des applications plus rapidement. Automatisation, installation, mise à niveau et gestion de la pile de conteneurs, OpenShift rationalise Kubernetes et facilite les tâches quotidiennes de DevOps.

  • Les développeurs mettent à disposition des applications l’accès à des solutions validées et à des partenaires qui sont poussés à la production via des flux de travail rationalisés.
  • Les opérations peuvent gérer et mettre à l’échelle 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 OpenShift.

Avantages et composants d’OpenShift supplémentaires :

  • Choix de l’infrastructure
  • Nœuds maître et travailleur
  • Registre d’images
  • Couche de routage et de service
  • Fonctionnement du développeur (introduit mais dépasse le champ d’application de ce document)

Les cas d’utilisation pour intégrer Red Hat OpenShift à Citrix Native Stack sont les suivants :

  • Prise en charge des applications héritées
  • Stratégies de réécriture/répondeur déployées en tant qu’API
  • Dépannage des microservices
  • Opérations quotidiennes avec correctifs de sécurité et améliorations des fonctionnalités

Dans ce document, nous décrivons comment Citric ADC fournit une intégration solide de la couche Routing/Service.

Projets OpenShift

Le premier nouveau concept OpenShift ajoute est le projet, qui enveloppe efficacement un espace de noms, avec 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 fournissent donc des murs entre les espaces de noms, ce qui garantit que les utilisateurs, ou les applications, ne peuvent voir et accéder que ce à quoi ils sont autorisés.

Espaces de noms OpenShift

Le concept de regroupement principal dans Kubernetes est l’espace de noms. Les espaces de noms sont également un moyen de diviser les ressources de cluster entre plusieurs utilisations. Cela étant dit, il n’y a pas de 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.

Exemple de fichier YAML créant un espace de noms nommé « tier-2-adc ».

Réseau SDN (Software Defined Networking) OpenShift

OpenShift Container Platform utilise une approche SDN (Software-defined Networking) pour fournir un réseau de cluster unifié qui permet la communication entre les modules à travers le cluster OpenShift Container Platform. Ce réseau de modules est établi et géré par le SDN OpenShift, qui configure un réseau de superposition à l’aide d’Open vSwitch (OVS).

OpenShift SDN fournit trois plug-ins SDN pour configurer le réseau de modules :

  • Le plug-in ovs-subnet est le plug-in d’origine, qui fournit un réseau de pod « plat » où chaque pod peut communiquer avec tous les autres modules et services.
  • Le plug-in ovs-multitenant fournit une isolation au niveau du projet pour les modules 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 provenant de différents projets ne peuvent pas envoyer ou recevoir des paquets provenant de pods et de services d’un projet différent.
  • Cependant, les projets qui reçoivent VNID 0 sont plus privilégiés en ce qu’ils sont autorisés à communiquer avec tous les autres pods, et tous les autres pods peuvent communiquer avec eux. Dans les clusters OpenShift Container Platform, le projet par défaut a VNID 0.Cela facilite certains services, tels que l’équilibreur de charge, à communiquer avec tous les autres modules du cluster et vice versa.
  • Le plug-in ovs-networkpolicy permet aux administrateurs de projet de configurer leurs propres stratégies d’isolement à 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. Ceci permet au trafic externe d’acheminer vers l’hôte et par la suite 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 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 transfert via proxy les demandes externes de noms de routage vers les 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 routes OpenShift peuvent être sécurisées ou non sécurisées. 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 fait par :

  • Routage basé sur le nom d’hôte
  • Routage basé sur le chemin
  • Routage basé sur des caractères génériques
  • 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 :

Architectures recommandées

Nous recommandons les architectures suivantes pour les clients lors de la conception de leurs architectures de microservices :

  • Citrix Unified Ingress
  • Citrix 2-Tier Ingress
  • Citrix Service Mesh Lite

Figure 1-2 : L’architecture varie de relativement simple à plus complexe et riche en fonctionnalités.

Citrix Unified Ingress

Dans un déploiement Unified Ingress, les périphériques Citrix ADC MPX ou VPX transfèrent le trafic Nord-Sud des clients vers les applications professionnelles déployées en tant que microservices à l’intérieur du cluster. Le Controller d’entrée Citrix est déployé en tant que pod ou sidecar dans le cluster Kubernetes pour automatiser la configuration des périphériques 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ée lorsque votre application est toujours un monolithe. Placez simplement le Citrix ADC en tant que proxy inverse devant votre serveur d’applications et implémentez les fonctionnalités décrites plus loin. Vous êtes alors en bonne position 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.).

Diagramme d'entrée unifiée avec un Citrix ADC VPX/MPX

Fonctionnalités fournies dans différentes catégories

Les capacité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 deuxième groupe améliorent la sécurité et facilitent la gestion des applications :

  • Limitation de débit
  • Terminaison SSL/TLS
  • Prise en charge HTTP/2
  • Contrôles d’intégrité

Les caractéristiques du groupe final sont spécifiques aux microservices :

  • Point central de communication pour les services
  • Fonctionnalité de Gateway API

Résumé

Les fonctionnalités du modèle d’entrée unifiée incluent un équilibrage de charge robuste pour les services, un point de communication central, la découverte dynamique des services, la connectivité à faible latence, la haute disponibilité, la limitation du débit, la terminaison SSL/TLS, HTTP/2, et bien plus encore.

Le modèle Unified Ingress facilite la gestion du trafic, des demandes d’équilibrage de charge et la réponse dynamique aux modifications apportées à l’application de microservices back-end.

Les avantages comprennent :

  • Les flux de trafic Nord-Sud offrent une bonne scalabilité, sont visibles pour l’observation et la surveillance, et fournissent une livraison continue avec des outils tels que Spinnaker et Citrix ADM
  • Un niveau unique unifie l’équipe d’infrastructure qui gère les services réseau et de plate-forme, et réduit les sauts pour réduire la latence
  • Convient pour les applications internes qui n’ont pas besoin de Web App Firewall et de déchargement SSL, mais peuvent être ajoutées ultérieurement

Les inconvénients comprennent :

  • Pas de sécurité Est-Ouest avec kube-proxy, mais possibilité d’ajouter Calico pour la segmentation L4
  • La scalabilité Kube-proxy est inconnue
  • Il n’y a que peu de visibilité du trafic Est-Ouest puisque kube-proxy ne donne pas de visibilité, de contrôle ou de journaux, ce qui réduit l’intégration des outils ouverts et la livraison continue
  • L’équipe de la plateforme doit également être avisé du réseau

Citrix 2-Tier Ingress

Le modèle architectural Ingress à 2 niveaux est une excellente solution pour les novices Cloud Native. Dans ce modèle, Citrix ADC de niveau 1 gère le trafic entrant, mais envoie les demandes au ADC à 2 niveaux géré par les développeurs plutôt que directement aux instances de service. Le modèle Ingress de niveau 2 applique des stratégies écrites par l’équipe Platform and Developers uniquement au trafic entrant, et permet l’évolutivité et la multilocation du Cloud.

Figure 1-4 : Diagramme du modèle d’entrée Citrix à 2 niveaux avec un conteneur Citrix ADC VPX/MPX de niveau 1 et Citrix ADC CPX de niveau 2.

Fonctionnalités fournies par le niveau 1

L’ADC de premier niveau, géré par l’équipe réseau traditionnelle, fournit l’équilibrage de charge L4, le Citrix Web App Firewall, le déchargement SSL et les services proxy inversé. Les périphériques Citrix ADC MPX ou VPX de niveau 1 transfèrent le trafic (Nord-Sud) entre le client et Citrix ADC CPX dans niveau 2.

Par défaut, Citrix Ingress Controller programmera les configurations suivantes sur le niveau 1 :

  • Proxy inverse des applications aux utilisateurs :
  • Serveurs virtuels de commutation de contenu
  • Serveur virtuel (frontal, présenté à l’utilisateur)
  • Groupes de services
  • Déchargement SSL
  • Journalisation NetScaler/débogage
  • Surveillance sanitaire des services

Fonctionnalités fournies par le niveau 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 pour les microservices, fournissant :

  • Découverte dynamique des services
  • Équilibrage de charge
  • Visibilité et mesures enrichies

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 de mise en 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 comme un serveur proxy orienté utilisateur et l’ADC de niveau 2 comme proxy pour les microservices.

Le partage de différents types de fonctions entre deux niveaux différents offre vitesse, contrôle et opportunités 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 ADC et le développeur. C’est BYOL pour les développeurs.

Les avantages comprennent :

  • Les flux de trafic Nord-Sud offrent une bonne scalabilité, sont visibles pour l’observation et la surveillance, et fournissent une livraison continue avec des outils tels que Spinnaker et Citrix ADM
  • Déploiement le plus simple et plus rapide pour un Cloud Native Novice avec un apprentissage limité pour les équipes Network et Platform

Les inconvénients comprennent :

  • Pas de sécurité Est-Ouest avec kube-proxy, mais possibilité d’ajouter Calico pour la segmentation L4
  • La scalabilité Kube-proxy est inconnue
  • Il n’y a que peu de visibilité du trafic Est-Ouest puisque kube-proxy ne donne pas de visibilité, de contrôle ou de journaux, ce qui réduit l’intégration des outils ouverts et la livraison continue.

Citrix Service Mesh Lite

Le Service Mesh Lite est la plus riche en fonctionnalités des trois modèles. Il est sécurisé, rapide, efficace et résilient en interne et peut être utilisé pour appliquer des stratégies pour le trafic entrant et inter-conteneurs.

Le modèle Service Mesh Lite est adapté à plusieurs cas d’utilisation, notamment :

  • Applications de santé et de finances — Les exigences réglementaires et des utilisateurs exigent une combinaison de sécurité et de rapidité pour les applications financières et de santé, avec des milliards de dollars de valeur financière et de réputation en jeu.
  • Applications de commerce électronique — La confiance des utilisateurs est un problème énorme pour le commerce électronique et la vitesse est un facteur de différenciation concurrentiel clé. La combinaison de vitesse et de sécurité est donc cruciale.

Diagramme du modèle Citrix Service Mesh Lite avec un conteneur Citrix ADC VPX/MPX de niveau 1 et Citrix ADC CPX de niveau 2 pour proxy Est-Ouest.

Résumé

Les avantages comprennent :

  • Une approche plus robuste de la mise en réseau, avec un équilibreur de charge CPX applique des stratégies au trafic entrant et inter-conteneurs, en déployant des stratégies L7 complètes
  • Une observabilité, des analyses, une livraison continue et une sécurité plus riches 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 réseau et de plate-forme, et réduit les sauts pour réduire la latence

Les inconvénients comprennent :

  • Modèle plus complexe à déployer
  • L’équipe de la plateforme doit être avisé du réseau

Résumé de Architecture Choices

Citrix Unified Ingress

  • Trafic d’applications Nord-Sud (NS) - un Citrix ADC est responsable du trafic L4 et L7 NS, de la sécurité et de l’équilibrage de charge externe en dehors du cluster K8s.

  • Trafic d’application Est-Ouest (EW) - kube-proxy est responsable du trafic EW L4.

  • Sécurité - L’ADC est responsable de la sécurisation du trafic NS et de l’authentification des utilisateurs. Kube-proxy est responsable du trafic L4 EW.

  • Scalabilité et performances - Le trafic NS offre une bonne scalabilité, et le clustering est une option. Le trafic EW et la scalabilité kube-proxy sont inconnus.

  • Observabilité - l’ADC offre une excellente observabilité pour le trafic NS, mais il n’y a pas d’observabilité pour le trafic EW.

Citrix 2-Tier Ingress

  • Trafic d’applications Nord-Sud (NS) - ADC de niveau 1 est responsable du déchargement SSL, de Web App Firewall et du trafic L4 NS. Il est utilisé pour les applications monolithe et CN. Le CPX de niveau 2 gère le changement rapide du trafic k8s et L7 NS.

  • Trafic d’application Est-Ouest (EW) - kube-proxy est responsable du trafic EW L4.

  • Sécurité - L’ADC de niveau 1 est responsable de la sécurisation du trafic NS. L’authentification peut se produire sur l’un ou l’autre des ADC. Le trafic EW n’est pas sécurisé avec Kube-proxy.Add Calico pour la segmentation L4.

  • Scalabilité et performances - Le trafic NS offre une bonne scalabilité, et le clustering est une option. Le trafic EW et la scalabilité kube-proxy sont inconnus.

  • Observabilité - L’ADC de niveau 1 offre une excellente observabilité pour le trafic NS, mais il n’y a pas d’observabilité pour le trafic EW.

Citrix Service Mesh Lite

  • Trafic d’applications Nord-Sud (NS) - ADC de niveau 1 est responsable du déchargement SSL, de Web App Firewall et du trafic L4 NS. Il est utilisé pour les applications monolithe et CN. Le CPX de niveau 2 gère le changement rapide du trafic k8s et L7 NS.

  • Trafic d’application Est-Ouest (EW) - le CPX de niveau 2 ou tout proxy open source est responsable du trafic L4 EW. Les clients peuvent sélectionner les applications qui utilisent le CPX et celles qui utilisent kube-proxy.

  • Sécurité - L’ADC de niveau 1 est responsable de la sécurisation du trafic NS. L’authentification peut se produire sur l’un ou l’autre des ADC. 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 1 saut en ligne.

  • Observabilité - L’ADC de niveau 1 offre 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 l’encombrement CPX ou CPU.

Comment déployer

Citrix Unified Ingress

Pour valider un déploiement 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.

  1. 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.

  2. 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-->
    
  3. Déployez l’application. oc apply -f application.yaml

  4. Assurez-vous que les pods sont en cours d’exécution. oc get pods

  5. 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-->
    
  6. Exposez l’application via NodePort avec un service. oc apply -f service.yaml

  7. Vérifiez que le service a été créé. oc get service

  8. Copiez l’exemple de fichier YAML suivant dans un répertoire OpenShift et nommez-le Ingress.yaml.Vous devez changer l’annotation « ingress.citrix.com/frontend-ip » en une adresse IP libre pour être transformé en 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-->
    
  9. Déployez le fichier Ingress YAML. oc apply -f ingress.yaml

  10. Maintenant, il y a des pods d’application que nous avons exposés en utilisant un service, et peuvent acheminer le trafic vers eux en utilisant Ingress. Installez Citrix Ingress Controller (CIC) pour pousser ces configurations vers notre VPX ADC de niveau 1. Avant de déployer le CIC, déployez un fichier RBAC qui donne au CIC les autorisations appropriées pour s’exécuter.

    Note :

    Le fichier rbac yaml spécifie l’espace de noms et il devra être modifié, en attendant quel espace de noms est 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-->
    
  11. Déployez le fichier RBAC. oc apply -f rbac.yaml

  12. Avant de déployer le CIC, modifiez le fichier YAML. Sous spec, ajoutez le NSIP ou le SNIP tant que la gestion est activée sur le SNIP, du ADC de niveau 1. Notez que l’argument « ingress-classes » est le même que 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-->
    
  13. Déployez le CIC. oc apply -f cic.yaml

  14. Vérifiez que tous les pods sont en cours d’exécution. oc get pods

  15. 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.

  16. Accédez à helloworld.com dans un navigateur.”Hello Kubernetes!” devrait apparaître.

Remarque : Ce qui suit sont des commandes de suppression

  • 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)

Citrix 2-Tier Ingress

Pour valider un déploiement Citrix Ingress à 2 niveaux 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) ».

  1. Une instance de Citrix ADC est créée manuellement 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, effacez tous les serveurs virtuels dans l’équilibrage de charge ou la commutation de contenu qui ont été transmis à ADC afin de ne pas déployer hello-world en tant qu’entrée unifiée.

  2. Créez un espace de noms appelé “tier-2-adc”. oc create namespace tier-2-adc

  3. 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-->
    
  4. Déployez l’application dans l’espace de noms. oc apply -f application-2t.yaml -n tier-2-adc

  5. Assurez-vous que les pods sont en cours d’exécution. oc get pods

  6. 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-->
    
  7. Exposez l’application via NodePort avec un service. oc apply -f service-2t.yaml -n tier-2-adc

  8. Vérifiez que le service a été créé. oc get service -n tier-2-adc

  9. 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-->
    
  10. Déployez le fichier Ingress YAML. oc apply -f ingress-2t.yaml -n tier-2-adc

  11. Déployez un fichier RBAC qui donne au CIC et CPX les autorisations correctes à exécuter.

    Remarque :

    Le fichier rbac yaml spécifie l’espace de noms et il devra être modifié, en attendant quel espace de noms est 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-->
    
  12. Déployez le fichier RBAC. oc apply -f rbac-2t.yaml

  13. 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

  14. 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 classe Ingress correspond à l’annotation dans le fichier ingress-2t.yaml.

        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-->
    
  15. Déployez le CPX. oc apply -f cpx-2t.yaml -n tier-2-adc

  16. Vérifiez que le module est en cours d’exécution et que le service a été créé. oc get pods -n tier-2-adc oc get service -n tier-2-adc

  17. Créez une entrée pour acheminer du VPX vers le CPX. L’adresse IP frontale doit être une adresse IP libre sur l’ADC. Donnez au fichier un nom :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-->
    
  18. Déployez l’entrée. oc apply -f ingress-cpx-2t.yaml -n tier-2-adc

  19. Avant de déployer le CIC, modifiez le fichier YAML. Sous spec, ajoutez le NSIP ou le SNIP tant que la gestion est activée sur le SNIP, du 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-->
    
  20. Déployez le CIC. oc apply -f cic-2t.yaml -n tier-2-adc

  21. Vérifiez que tous les pods sont en cours d’exécution. oc get pods -n tier-2-adc

  22. 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 roule du VPX au CPX.

  23. Accédez à helloworld.com dans un navigateur.”Hello 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 capacités N/S à Kubernetes et de fournir l’équilibrage de la charge de trafic E/W, le routage et l’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 basé sur les 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 dorés (erreurs, latences, saturation ou volume de trafic) .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 passons à extraire et remplacer les services Kubernetes par défaut et utilisons CPX et VPX pour proxy notre trafic E/W.

Citrix Service Mesh Lite avec CPX

Pour valider un déploiement 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.

  1. 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.

  2. Créez un espace de noms pour ce déploiement. Dans cet exemple, sml est utilisé. oc create namespace sml

  3. Copiez le 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-->
  1. Déployez le bookinfo.yaml dans l’espace de noms sml. oc apply -f bookinfo.yaml -n sml

  2. Copiez et déployez le fichier d’entrée qui correspond au service de page de produit. Ce fichier peut être nommé ingress-productpage.yaml. L’IP frontale doit être un VIP gratuit sur 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

  1. 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.yaml tel 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

  1. Élevez les privilèges du compte de service pour déployer CIC et CPX. oc adm policy add-scc-to-user privileged system:serviceaccount:sml:cpx

  2. Modifiez le fichier hosts sur la machine locale avec bookinfo.com mappé à l’adresse IP frontale spécifiée dans ingress-productpage.yaml.

  3. Copiez et déployez la page produit avec un CIC. Nommez le fichier cic-productpage.yaml.Le NS_IP doit être le NS_IP du 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

  1. 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 de l’acheminement du trafic entre les microservices (Est-Ouest).

  2. Supprimez le service devant les détails. Actualisez la page Web Bookinfo et notez que la page du produit n’a pas pu extraire le microservice pour plus de détails. oc delete service details -n sml

  3. Copiez et déployez un service sans tête afin que le trafic provenant de la page du 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

  1. Copiez et déployez un nouveau service de détails, qui devrait être des noms detailsservice.yaml, pour s’asseoir 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

  1. Exposer le service de détails avec une entrée et le déployer. 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

  1. 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

  1. Actualisez bookinfo.com et les détails doivent être tirés des détails MicroService.Un CPX a été déployé avec succès pour le trafic EW proxy.

Citrix Service Mesh Lite avec un VPX/MPX

  1. 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 produit et les microservices de détails. oc delete -f detailsheadless.yaml -n sml oc delete -f detailsservice.yaml -n sml oc delete -f detailsingress.yaml -n sml oc delete -f CPXEastWest.yaml -n sml

  2. Copiez et déployez un service, nommez le fichier DetailsToVPX.yaml, pour renvoyer le trafic depuis la page du produit vers le VPX. Le paramètre IP doit être un VIP gratuit sur 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

  1. Redéployez le detailsservice.yaml devant le microservice de détails. oc apply -f detailsservice.yaml -n sml

  2. Copiez et déployez l’entrée pour exposer le microservice de détails au VPX. Son nom est detailsVPXingress.yaml. L’IP frontale doit correspondre au 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

  1. Actualiser bookinfo.com et les détails doivent être tirés du microservice de détails. Un VPX a été déployé avec succès sur le trafic EW 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

  1. 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"
    
  2. 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
    
  3. Exposez le service avec service.yaml.

    metadata:
        name: apache-service
    spec:
    type: NodePort
    #type=LoadBalancer
    ports:
        - port: 80
    targetPort: 80
    selector:
        app: apache
    
  4. 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 mesures Citrix

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.