Documentation produit
Citrix Tech Zone
Voir PDF

Migration de service vers Citrix ADC à l’aide de routes dans la conception de référence validée par Open

September 26, 2022
Author:  Luis Ugarte, Beth Pollack

Routes statiques et automatiques dans un cluster OpenShift

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 Node Controller (CNC), Citrix ingress controller (CIC) et CPX lors de la migration des 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
<!--NeedCopy-->

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 en utilisant TLS.

En savoir plus sur les différents types d’itinéraires dans les solutions de déploiement du Citrix ingress controller.

Déployer le Ingress Controller Citrix avec prise en charge du partitionnement de routeur OpenShift

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 :

  • Plug-in de routeur CIC (Pod)
  • Routeur CPX dans OpenShift (Sidecar)

Les deux méthodes sont décrites ci-dessous avec des exemples de migration.

Lepartitionnement de routeur OpenShift permet de distribuer un ensemble d’itinéraires entre plusieurs routeurs OpenShift. Par défaut, un routeur OpenShift sélectionne toutes les routes de tous les espaces de noms. Dans le partitionnement de routeur, des étiquettes sont ajoutées aux itinéraires ou aux espaces de noms et des sélecteurs d’étiquettes aux routeurs pour filtrer les itinéraires. Chaque partition de routeur sélectionne uniquement des itinéraires avec des étiquettes spécifiques qui correspondent à ses paramètres de sélection d’étiquettes.

Pour configurer le partitionnement de routeur pour un déploiement Citrix ADC sur OpenShift, une instance de Citrix ingress controller est requise par partition. L’instance du Citrix ingress controller est déployée avec des étiquettes d’itinéraire ou d’espace de noms ou les deux en tant que variables d’environnement en fonction des critères requis pour le partitionnement. Lorsque le Citrix ingress controller traite un itinéraire, il compare les étiquettes de l’itinéraire ou les étiquettes d’espace de noms de l’itinéraire avec les critères de sélection configurés sur celui-ci. Si l’itinéraire répond aux critères, la configuration appropriée est appliquée à Citrix ADC, sinon elle n’applique pas la configuration.

Dans le partitionnement de routeur, la sélection d’un sous-ensemble d’itinéraires dans l’ensemble du pool d’itinéraires est basée sur des expressions de sélection. Les expressions de sélection sont une combinaison de plusieurs valeurs et opérations. Pour en savoir plus sur les expressions, les valeurs et les opérations, consultez ce blog Citrix.

déploiement Bookinfo

L’architecture de l’application Bookinfo est illustrée dans la figure ci-dessous. Un CIC est déployé en tant que plug-in de routeur OpenShift au premier niveau, configurant le Citrix ADC VPX pour acheminer le trafic nord-sud vers la page produit. Dans le deuxième niveau, un Citrix ADC CPX est déployé en tant que routeur OpenShift, acheminant le trafic Est-Ouest entre le microservice Page Détails et Page produit, tandis que le trafic Est-Ouest entre les microservices Page produit, Avis et Évaluations est acheminé via le routeur HAProxy par défaut.

Schéma de partitionnement d'itinéraire de l'application Bookinfo déployée en tant qu'architecture Service Mesh Lite

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.
  • CPX : fournit le routage OpenShift au sein du cluster OpenShift.

Étapes de déploiement

  1. Créez un espace de nommage pour le déploiement. oc create ns sml

  2. Déployez l’application Bookinfo dans l’espace de nommage. oc apply -f 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:
"bookinfo.yaml" 224L, 5120C

<!--NeedCopy-->

  3. Déployez le fichier d’itinéraire qui correspond à notre service de page produit. Spécifier frontend-ip (Il s’agit du VIP de commutation de contenu sur l’ADC de niveau 1) oc apply -f routes-productpage.yaml

    apiVersion: v1
kind: Route
metadata:
   name: productpage-route
   namespace: sml
   annotations:
    ingress.citrix.com/frontend-ip: "X.X.X.X"
   labels:
    name: productpage
spec:
   host: bookinfo.com
   path: /
   port:
     targetPort: 80
   to:
     kind: Service
     name: productpage-service
<!--NeedCopy-->

  4. Déployez le fichier RBAC pour l’espace de noms sml qui donne au CIC les autorisations nécessaires pour s’exécuter. Le fichier RBAC est déjà doté d’un espace de noms. oc apply -f rbac.yaml

     kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: cpx
rules:
  - apiGroups: [""]
    resources: ["endpoints", "ingresses", "services", "pods", "secrets", "nodes", "routes", "namespaces","tokenreviews","subjectaccessreview"]
    verbs: ["get", "list", "watch"]
  # services/status is needed to update the loadbalancer IP in service status for integrating
  # service of type LoadBalancer with external-dns
  - apiGroups: [""]
    resources: ["services/status"]
    verbs: ["patch"]
  - apiGroups: ["extensions"]
    resources: ["ingresses", "ingresses/status"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apiextensions.k8s.io"]
    resources: ["customresourcedefinitions"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["citrix.com"]
    resources: ["rewritepolicies", "canarycrds", "authpolicies", "ratelimits"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["citrix.com"]
    resources: ["vips"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: ["route.openshift.io"]
    resources: ["routes"]
    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: v1
kind: ServiceAccount
metadata:
"rbac.yaml" 51L, 1513C
 <!--NeedCopy-->

  5. Déployez votre CIC pour envoyer les configurations de route vers votre VPX. Faites correspondre le paramètre ROUTE_LABELS à l’étiquette spécifiée dans le route-productpage.yaml. Pour plus d’informations sur la syntaxe de ROUTE_LABELS, consultez ce blog. oc apply -f cic-productpage-v2.yaml

    apiVersion: v1
kind: Pod
metadata:
  name: cic
  labels:
    app: cic
spec:
  serviceAccount: cpx
  containers:
  - name: cic
    image: "quay.io/citrix/citrix-k8s-ingress-controller:1.7.6"
    securityContext:
       privileged: true
    env:
    - name: "EULA"
      value: "yes"
    # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
    - name: "NS_IP"
      value: "X.X.X.X"
    # Set NetScaler VIP that receives the traffic
#    - name: "NS_VIP"
#      value: "X.X.X.X"
    - name: "NS_USER"
      value: "nsroot"
    - name: "NS_PASSWORD"
      value: "nsroot"
    - name: "NS_APPS_NAME_PREFIX"
      value: "BOOK"
    - name: "ROUTE_LABELS"
      value: "name in (productpage)"
#    - name: "NAMESPACE_LABELS"
#      value: "app=hellogalaxy"
    # Set username for Nitro
#    - name: "NS_USER"
#      valueFrom:
#       secretKeyRef:
#        name: nslogin
#        key: nsroot
#    # Set user password for Nitro
#    - name: "NS_PASSWORD"
#      valueFrom:
#       secretKeyRef:
#        name: nslogin
#        key: nsroot
    args:
#    - --default-ssl-certificate
#      default/default-cert
    imagePullPolicy: Always
~
"cic-productpage-v2.yaml" 48L, 1165C
<!--NeedCopy-->

  6. Nous devons maintenant créer un service headless qui dirige les utilisateurs à la recherche de détails vers notre CPX à l’aide des pods DNS de notre cluster. oc apply -f detailsheadless.yaml

    ##################################################################################################
# Details service
##################################################################################################
apiVersion: v1
kind: Service
metadata:
  name: details
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: cpx
<!--NeedCopy-->

  7. Déployez un nouveau service pour exposer le conteneur de détails. oc apply -f detailsservice.yaml

    ##################################################################################################
# Details service
##################################################################################################
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-->

  8. Déployez une nouvelle définition d’itinéraire qui se trouve devant le service de détails que nous avons créé. Notez que l’étiquette est « nom : détails ». oc apply -f detailsroutes.yaml

    apiVersion: v1
kind: Route
metadata:
   name: details-route
   namespace: sml
   annotations:
    ingress.citrix.com/insecure-port: "9080"
   labels:
    name: details
spec:
   host: details
   path: /
   port:
      targetPort: 9080
   to:
     kind: Service
     name: details-service
<!--NeedCopy-->

  9. Déployez CPX pour le trafic E/W. Un CIC est déployé en tant que sidecar et est configuré avec un paramètre ROUTE_LABEL pour correspondre à l’étiquette dans detailsroutes.yaml. oc apply -f cpx.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: 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
# readiness probe?
          imagePullPolicy: Always
        # Add cic as a sidecar
        - name: cic
          image: "quay.io/citrix/citrix-k8s-ingress-controller:1.7.6"
          env:
          - name: "EULA"
            value: "yes"
          - name: "NS_IP"
"cpx.yaml" 75L, 1939C
<!--NeedCopy-->

Choix de livraison continue dans un environnement de microservices

L’intégration continue (CI) est une pratique de développement qui oblige les développeurs à intégrer du code dans un référentiel partagé plusieurs fois par jour.

La livraison continue (CD) est le prolongement naturel de l’intégration continue : une approche dans laquelle les équipes s’assurent que chaque modification apportée au système est libérable et que nous pouvons publier n’importe quelle version en appuyant simplement sur un bouton.

Les différents choix de CD, ainsi que leurs avantages et leurs inconvénients, sont les suivants :

  • Recréer - La version 1 (V1) est terminée, puis la version 2 (V2) est déployée.
    • Pros
      • Facile à installer.
      • L’état de l’application est entièrement renouvelé.
    • Les inconvénients
      • Impact élevé sur l’utilisateur. Attendez-vous à des temps d’arrêt qui dépendent à la fois de la durée d’arrêt
  • Mise à jour Ramped/Rolling - La V2 est lentement déployée et remplace la V1.
    • Pros
      • Facile à installer.
      • La version est publiée lentement entre les instances.
      • Pratique pour les applications avec état capables de gérer le rééquilibrage des données.
    • Les inconvénients
      • Le déploiement/retour arrière peut prendre du temps.
      • Il est difficile de prendre en charge plusieurs API.
      • Peu de contrôle de la circulation.
  • Blue Green - V2 est libéré aux côtés de V1, puis le trafic passe à V2.
    • Pros
      • Déploiement/retour arrière instantané.
      • Évitez les problèmes de version puisque l’ensemble de l’application est modifié en une seule fois.
    • Les inconvénients
      • Coûteux car il nécessite deux fois plus de ressources.
      • Un test approprié de l’ensemble de la plate-forme doit être effectué avant la mise en production.
      • La gestion de plusieurs applications avec état peut s’avérer difficile.
  • Canary - V2 est disponible pour un sous-ensemble d’utilisateurs, puis passe à un déploiement complet.
    • Pros
      • Version publiée pour un sous-ensemble d’utilisateurs.
      • Pratique pour la surveillance du taux d’erreur et des performances.
      • Rollback rapide.
    • Les inconvénients
      • Déploiement lent.
      • La gestion de plusieurs applications avec état peut s’avérer difficile.
  • A/B Testing - V2 est disponible pour un sous-ensemble d’utilisateurs dans des conditions spécifiques.
    • Pros
      • Plusieurs versions fonctionnent en parallèle.
      • Contrôle total de la distribution du trafic.
    • Les inconvénients
      • Nécessite un équilibreur de charge intelligent
      • Il est difficile de résoudre les erreurs pour une session donnée. Le suivi distribué devient donc obligatoire.
  • Shadow - V2 reçoit le trafic réel en même temps que V11 et n’a aucun impact sur la réponse.
    • Pros
      • Test des performances de l’application avec le trafic de production.
      • Aucun impact sur l’utilisateur.
      • Aucun déploiement n’est possible tant que la stabilité et les performances de l’application ne satisfont pas aux exigences.
    • Les inconvénients
      • Coûteux car il nécessite deux fois plus de ressources.
      • Il ne s’agit pas d’un véritable test utilisateur et peut être trompeur.
      • Complexe à mettre en place.
      • Nécessite un service de simulation dans certains cas.

Matériaux de référence

Citrix GitHub : « Routes et entrées OpenShift »

Documentation pour les Citrix Developer : « Solutions de déploiement »

Blog Citrix : « Activer la prise en charge du partitionnement du routeur OpenShift avec Citrix ADC »

Documentation d’OpenShift Route :

Migration de service vers Citrix ADC à l’aide de routes dans la conception de référence validée par Open
September 26, 2022
Author:  Luis Ugarte, Beth Pollack
September 26, 2022
Author:  Luis Ugarte, Beth Pollack

Dans cet article

Commentaires sur le site | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.