Contrôleur d'entrée Citrix ADC

Solution d’entrée et d’équilibrage de charge multi-clusters utilisant le Citrix ingress controller

Vue d’ensemble

Pour garantir la haute disponibilité, l’équilibrage de charge basé sur la proximité et l’évolutivité, vous devrez peut-être déployer une application dans plusieurs clusters Kubernetes distribués. Lorsque la même application est déployée dans plusieurs clusters Kubernetes, une décision d’équilibrage de charge doit être prise entre les instances d’application dispersées entre les clusters.

Pour mettre en œuvre une solution d’équilibrage de charge pour les clusters Kubernetes distribués, la santé des applications entre les clusters doit être surveillée globalement. Vous devez surveiller la disponibilité et les performances des applications, mettre à jour l’état des applications entre les clusters, collecter des statistiques à partir des points de terminaison des centres de données et partager les statistiques entre les centres de données.

Citrix fournit une solution d’entrée et d’équilibrage de charge multi-clusters qui surveille globalement les applications, collecte et partage des métriques entre différents clusters, et fournit des décisions intelligentes en matière d’équilibrage de charge. Il garantit de meilleures performances et fiabilité pour vos services Kubernetes exposés à l’aide d’Ingress ou de type LoadBalancer.

Topologie de déploiement

Le diagramme suivant explique une topologie de déploiement pour la solution d’entrée et d’équilibrage de charge multi-clusters pour les clusters Kubernetes.

Remarque :

Les services de type LoadBalancer (disponibles pour les clusters bare metal utilisant Citrix ADC) sont également pris en charge.

Multi-cluster-deployment

Ce diagramme montre un exemple de topologie avec deux centres de données et chaque centre de données contient plusieurs clusters Kubernetes. Pour le centre de données 1, Citrix ADC CPX est déployé en tant qu’équilibreur de charge d’entrée dans chaque cluster Kubernetes. Pour le centre de données 2, HAProxy est déployé en tant qu’équilibreur de charge dans chaque cluster Kubernetes. Solution d’entrée et d’équilibrage de charge multi-clusters Citrix pour les équilibres de charge Kubernetes sur les entrées.

Remarque :

Toute solution d’entrée, y compris les solutions tierces telles que la passerelle d’entrée Istio ainsi que le Citrix ingress controller avec Citrix ADC MPX, VPX ou BLX, est prise en charge. Cette topologie n’est qu’un exemple de déploiement.

Un appareil Citrix Global Server Load Balancing (GSLB) est configuré pour chaque centre de données. Dans chaque Citrix ADC qui agit en tant qu’équilibreur de charge global, un site est configuré en tant que site local représentant le centre de données local. Les autres sites sont configurés en tant que sites distants pour chaque centre de données distant. Le Citrix ADC (MPX ou VPX) utilisé comme GSLB peut également être utilisé comme appliance Ingress avec le Citrix ingress controller.

L’option de synchronisation de la configuration de l’équilibrage de charge du serveur global (GSLB) de Citrix ADC est utilisée pour synchroniser la configuration entre les sites. L’appliance Citrix ADC à partir de laquelle vous utilisez la synchronisation est appelée nœud principal et le site sur lequel la configuration est copiée en tant que site subordonné.

Chaque cluster du déploiement exécute une instance du contrôleur Kubernetes GSLB. Le contrôleur GSLB est le module responsable de la configuration du périphérique GSLB Citrix ADC. Le contrôleur GSLB configure le dispositif maître GSLB pour les applications déployées dans leur cluster respectif. Le dispositif maître GSLB pousse la configuration GSLB vers les périphériques subordonnés GSLB restants à l’aide de la fonction de synchronisation GSLB. Lorsque vous synchronisez une configuration GSLB, les configurations de tous les sites GSLB participant à l’installation GSLB sont rendues similaires à la configuration sur le site maître.

La solution d’entrée et d’équilibrage de charge multi-clusters peut être appliquée à n’importe quel objet Kubernetes utilisé pour acheminer le trafic vers le cluster.

Les méthodes globales d’équilibrage de charge suivantes sont prises en charge :

Les types de déploiement suivants sont pris en charge :

  • Local d’abord : dans un premier déploiement local, lorsqu’une application souhaite communiquer avec une autre application, elle préfère une application locale dans le même cluster. Lorsque l’application n’est pas disponible localement, la demande est dirigée vers d’autres clusters ou régions.

  • Canary : La publication de Canary est une technique visant à réduire le risque d’introduction d’une nouvelle version logicielle en production en déployant d’abord la modification à un petit sous-ensemble d’utilisateurs. Dans cette solution, le déploiement Canary peut être utilisé lorsque vous souhaitez déployer de nouvelles versions de l’application sur des clusters sélectionnés avant de la déplacer en production.

  • Basculement : Un déploiement de basculement est utilisé lorsque vous souhaitez déployer des applications dans une configuration active/passive lorsqu’elles ne peuvent pas être déployées en mode actif/actif.

  • Temps aller-retour (RTT) : Dans un déploiement RTT, l’état en temps réel du réseau est surveillé et dirige dynamiquement la demande du client vers le centre de données ayant la valeur RTT la plus faible.

  • Proximité statique : Dans un déploiement de proximité statique, une base de données de proximité statique basée sur l’adresse IP est utilisée pour déterminer la proximité entre le serveur DNS local du client et les sites GSLB. Les demandes sont envoyées au site qui correspond le mieux aux critères de proximité.

  • Round Robin : Dans un déploiement Round Robin, le périphérique GSLB fait tourner en permanence une liste des services qui lui sont liés. Lorsqu’il reçoit une demande, il attribue la connexion au premier service de la liste, puis déplace ce service vers le bas de la liste.

Remarque :

Actuellement, IPv6 n’est pas pris en charge.

CRD pour la configuration de la solution d’entrée et d’équilibrage de charge multi-clusters pour les clusters Kubernetes

Les CRD suivants sont présentés pour prendre en charge la configuration Citrix ADC pour l’exécution de GSLB d’applications Kubernetes.

  • Politique de trafic mondial (GTP)
  • Entrée de service globale (GSE)

GTP CRD

GTP CRD accepte les paramètres de configuration GSLB sur Citrix ADC, y compris le type de déploiement (Canary, basculement, local d’abord), le domaine GSLB, le moniteur de santé pour l’entrée et le type de service.

La spécification GTP CRD est disponible dans le référentiel GitHub du Citrix ingress controller à l’adresse : grp-crd.yaml.

CRD GSE

Le CRD GSE dicte les informations de point de terminaison (tout objet Kubernetes qui achemine le trafic vers le cluster) de chaque cluster.

La spécification GSE CRD est disponible dans le référentiel GitHub du contrôleur d’entrée Citrix à l’adresse : gse-crd.yaml

Le CRD GSE est généré automatiquement pour un objet d’entrée si le service spécifié dans la ressource d’entrée est référencé dans l’instance de CRD GTP et si le champ status-loadbalancer-ip/hostname est déjà renseigné. Pour un service de type LoadBalancer, le CRD GSE est généré automatiquement si le service est référencé dans l’instance de CRD GTP et si le champ status-loadbalancer-ip/hostname est déjà renseigné.

Remarque : Pour la génération automatique de CRD GSE en cas d’entrée, le nom d’hôte doit correspondre exactement au nom d’hôte spécifié dans l’instance CRD GTP. Pour l’entrée et le service de type LoadBalancer, le CRD GSE est généré uniquement pour le premier port spécifié.

Déployer la solution d’entrée et d’équilibrage de charge multi-clusters Citrix

Les conditions préalables suivantes s’appliquent avant d’effectuer les étapes de déploiement de la solution d’équilibrage de charge globale Citrix :

  • Vous devez configurer les sites GSLB sur Citrix ADC qui agit en tant que périphérique GSLB.
  • Les fonctionnalités telles que la commutation de contenu et le protocole SSL doivent être activées dans l’appareil GSLB.
  • Pour la proximité statique, la base de données d’emplacements doit être appliquée en externe

Effectuez les étapes suivantes pour déployer la solution d’équilibrage de charge globale Citrix pour les clusters Kubernetes distribués géographiquement.

  1. Créez les autorisations RBAC requises pour déployer le contrôleur GSLB à l’aide du fichier gslb-rbac.yaml .

    kubectl apply -f gslb-rbac.yaml
    
  2. Créez les secrets nécessaires pour que le contrôleur GSLB se connecte aux périphériques GSLB et transmettez la configuration à partir du contrôleur GSLB.

    kubectl create secret generic secret-1 --from-literal=username=<username for gslb device1> --from-literal=password=<password for gslb device1>
    kubectl create secret generic secret-2 --from-literal=username=<username for gslb device2> --from-literal=password=<password for gslb device2>
    

    Remarque :

    Ces secrets sont utilisés dans le fichier YAML du contrôleur GSLB pour les sites respectifs. Le username et password de la commande spécifie le nom d’utilisateur et le mot de passe du Citrix GSLB ADC.

  3. Téléchargez le fichier YAML du contrôleur GSLB gslb-controller.yaml.

  4. Modifiez le fichier YAML du contrôleur GSLB et mettez à jour les valeurs suivantes selon les exigences de chaque cluster.

    • LOCAL_REGION et LOCAL_CLUSTER : spécifiez la région et le nom du cluster où ce contrôleur est déployé.
    • SITENAMES : Fournissez les noms de sites séparés par des virgules et la configuration doit être la même que celle du site configuré sur les appareils GSLB.
    • L’adresse IP, la région, le nom d’utilisateur et le mot de passe de chaque site doivent commencer par le nom du site correspondant. Par exemple : pour site1 dans SITENAMES, les champs doivent être site1_ip, site1_region, site1_username, et site1_password.
    • La section argument de la spécification doit inclure --config-interface et gslb-endpoint.

    Voici un extrait du fichier YAML permettant de déployer le contrôleur GSLB.

    env:
     - name: "LOCAL_REGION"
       value: "east"
     - name: "LOCAL_CLUSTER"
       value: "cluster1"
     - name: "SITENAMES"
       value: "site1,site2"
     - name: "site1_ip"
       value: "x.x.x.x"
     - name: "site1_region"
       value: "east"
     - name: "site1_username"
       valueFrom:
         secretKeyRef:
           name: secret-1
           key: username
     - name: "site1_password"
       valueFrom:
         secretKeyRef:
           name: secret-1
           key: password
     - name: "site2_ip"
       value: "x.x.x.x"
     - name: "site2_region"
       value: "west"
     - name: "site2_username"
       valueFrom:
         secretKeyRef:
           name: secret-2
           key: username
     - name: "site2_password"
       valueFrom:
         secretKeyRef:
           name: secret-2
           key: password
    args:
    - --config-interface
        gslb-endpoints
    

    Remarque :

    L’ordre des informations du site GSLB doit être le même dans tous les clusters. Le premier site de la commande est considéré comme le site maître pour la transmission de la configuration. Lorsque ce site maître tombe en panne, le site suivant de la liste sera le nouveau site principal. Par conséquent, l’ordre des sites doit être le même dans tous les clusters Kubernetes. Par exemple, si l’ordre des sites est site1 suivi par site2 dans cluster1, tous les autres clusters doivent suivre le même ordre.

  5. Déployez le fichier YAML du contrôleur GSLB modifié spécifique à chaque cluster sur le cluster correspondant.

    kubectl apply -f gslb-controller.yaml
    
  6. Déployez le fichier YAML de définition de CRD GTP à l’aide de la commande suivante.

    kubectl create -f  gtp-crd.yaml
    
  7. Déployez le fichier YAML de définition CRD GSE à l’aide de la commande suivante.

    kubectl create -f  gse-crd.yaml
    
  8. Définissez les GTP de votre domaine sous forme de fichiers YAML et appliquez des instances GTP.

    kubectl create -f  gtp-example.yaml
    

    Remarque :

    Le CRD GTP doit être appliqué à tous les clusters ayant la même configuration pour le même domaine.

    Voici un exemple de configuration de stratégie de trafic globale dans laquelle la stratégie de trafic est spécifiée en tant que stratégie locale en premier pour le domaine app2.com. Lorsque votre application préfère les services locaux, vous pouvez utiliser cette option. Le CIDR du cluster local (cluster1) est spécifié à l’aide du champ CIDR. Le champ weight est utilisé pour diriger plus de demandes client vers un cluster particulier que les autres clusters lorsque la décision GSLB est prise par Citrix ADC. La méthode d’équilibrage de charge est spécifiée en utilisant le champ secLbMethod en tant que round robin.

    Remarque :

    Vous pouvez spécifier la méthode d’équilibrage de charge pour les déploiements locaux d’abord, Canary et de basculement.

    apiVersion: "citrix.com/v1beta1"
    kind: globaltrafficpolicy
    metadata:
      name: gtp1
      namespace: default
    spec:
      serviceType: 'HTTP'
      hosts:
      - host: 'app2.com'
        policy:
          trafficPolicy: 'LOCAL-FIRST'
          secLbMethod: 'ROUNDROBIN'
          targets:
          - destination: 'app2.default.east.cluster1'
            CIDR: '10.102.217.69/24'
            weight: 1
          - destination: 'app2.default.west.cluster2'
            weight: 1
          monitor:
          - monType: tcp
            uri: ''
            respCode: 200
    

    Pour plus d’informations sur les autres options de déploiement GTP telles que Canary et le basculement, consultez Exemples : déploiements de stratégie de trafic globale.

  9. Appliquez les instances GSE manuellement pour le GSLB d’entrée.

    kubectl create -f  gse-example.yaml
    

    Remarque :

    Le CRD GSE est appliqué dans un cluster spécifique en fonction des informations de point de terminaison du cluster. Le nom d’entrée de service global doit être le même que le nom de la destination cible dans la stratégie de trafic globale.

    Voici un exemple d’entrée de service globale.

    apiVersion: "citrix.com/v1beta1"
    kind: globalserviceentry
    metadata:
      name: 'app2.default.east.cluster1'
      namespace: default
    spec:
      endpoint:
        ipv4address: 10.102.217.70
        monitorPort: 33036
    

    Dans cet exemple, le nom d’entrée de service global app2.default.east.cluster1 est l’un des noms de destination cibles dans la stratégie de trafic globale créée à l’étape 8.

  10. Appliquer le service YAML pour GSLB de services de type LoadBalancer.

     kubectl create -f  service-example.yaml
    

    Voici un exemple de service.

     apiVersion: v1
     kind: Service
     metadata:
       name: cold
       namespace: default
     spec:
       type: LoadBalancer
       ports:
       - name: port-8080
         port: 8090
         targetPort: 8080
       selector:
         dep: citrixapp
     status:
       loadBalancer:
         ingress:
         - ip: 10.102.217.72
    

Pour obtenir un exemple de configuration de solution d’entrée et d’équilibrage de charge multicloud pour les clusters Amazon EKS et Microsoft AKS à l’aide de Citrix ADC, consultez la solution d’entrée et d’équilibrage de charge multicloud et multi-clusters avec des clusters Amazon EKS et Microsoft AKS.

Comment diriger la résolution DNS des espaces vers Citrix GSLB ADC

Remarque :

Cette procédure est facultative et nécessaire uniquement si les espaces du cluster doivent résoudre le DNS via Citrix GSLB ADC.

Lorsque les espaces se trouvent dans le cluster Kubernetes

Lorsque vous souhaitez que les espaces d’un cluster Kubernetes utilisent la solution GSLB, la ConfigMap du fournisseur DNS doit être mise à jour pour transférer la demande d’un domaine (pour lequel GSLB est requis) à Citrix GSLB ADC.

L’exemple suivant montre comment mettre à jour le ConfigMap si le fournisseur DNS est CoreDNS.

  # kubectl edit configmap coredns -n kube-system

    apiVersion: v1
    data:
      Corefile: |
        cluster.local:53 {
              errors
              health
              kubernetes cluster.local in-addr.arpa ip6.arpa {
                  pods insecure
                  upstream
                  fallthrough in-addr.arpa ip6.arpa
                  ttl 60
              }
              prometheus :9153
              forward . /etc/resolv.conf
              cache 90
              loop
              reload
              loadbalance
        }
        app2.com.:53 {
            errors
            cache 30
            forward . 10.102.217.149
        }
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-08-30T10:59:36Z"
      name: coredns
      namespace: kube-system
      resourceVersion: "43569751"
      selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
      uid: ac1d92e4-260f-45bd-8708-5f8194482885

Comme indiqué dans l’exemple, vous devez ajouter la configuration requise pour votre domaine si vous souhaitez qu’un espace ait une décision GSLB pour les applications hébergées derrière un domaine. Ici, le nom de domaine est app2.com.

  app2.com.:53 {
      errors
      cache 30
      forward . 10.102.217.149
  }

L’adresse IP spécifiée (forward . 10.102.217.149) est un service DNS configuré dans Citrix GSLB ADC. Vous pouvez spécifier les adresses IP multiples de différents sites GSLB en les séparant par des espaces, comme indiqué ci-dessous.

  forward . ip1 ip2 ip3

Lorsque les espaces se trouvent dans le cluster OpenShift

Lorsque vous souhaitez que les espaces d’un cluster OpenShift utilisent la solution GSLB, l’opérateur DNS doit être mis à jour pour transférer la demande d’un domaine (pour lequel GSLB est requis) à Citrix GSLB ADC.

  # oc edit dns.operator/default

  apiVersion: operator.openshift.io/v1
  kind: DNS
  metadata:
    name: default
  spec:
    servers:
      - name: gslb-app2
        zones:
          - app2.com
        forwardPlugin:
          upstreams:
            - 10.102.217.149
            - 10.102.218.129:5353

Comme indiqué dans l’exemple, vous devez ajouter la configuration requise pour votre domaine si vous souhaitez qu’un espace ait une décision GSLB pour les applications hébergées derrière un domaine. Ici, le nom de domaine est app2.com.

  servers:
      - name: gslb-app2
        zones:
          - app2.com
        forwardPlugin:
          upstreams:
            - 10.102.217.149
            - 10.102.218.129:5353

Les adresses IP spécifiées (10.102.217.149 et 10.102.218.129:5353) sont des services DNS configurés dans Citrix GSLB ADC.

Cette configuration peut être vérifiée à l’aide de la commande suivante :

  # oc get configmap/dns-default -n openshift-dns -o yaml

  apiVersion: v1
  kind: ConfigMap
  metadata:
    labels:
      dns.operator.openshift.io/owning-dns: default
      manager: dns-operator
    name: dns-default
    namespace: openshift-dns
  data:
    Corefile: |
      # gslb-app2
      app2.com:5353 {
          forward . 10.102.217.149 10.102.218.129:5353
          errors
          bufsize 512
      }
      .:5353 {
          bufsize 512
          errors
          health {
              lameduck 20s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
              pods insecure
              fallthrough in-addr.arpa ip6.arpa
          }
          prometheus 127.0.0.1:9153
          forward . /etc/resolv.conf {
              policy sequential
          }
          cache 900 {
              denial 9984 30
          }
          reload
      }

Définition de la CRD GTP

La définition du CRD GTP est disponible sur gtp-crd.yaml)

Le tableau suivant explique les attributs CRD GTP.

Champ Description
ipType Spécifie le type d’enregistrement DNS en tant que A ou AAAA. Actuellement, seul le type d’enregistrement A est pris en charge
serviceType: Spécifie le protocole auquel la prise en charge de plusieurs clusters est appliquée.
host Spécifie le domaine pour lequel la prise en charge de plusieurs clusters est appliquée.
trafficPolicy Spécifie la stratégie de distribution du trafic prise en charge dans un déploiement multi-clusters.
sourceIpPersistenceId Spécifie l’ID de persistance de l’adresse IP source unique. Cet attribut active la persistance en fonction de l’adresse IP source pour les paquets entrants. L’attribut sourceIpPersistenceId doit être un multiple de 100 et doit être unique. Pour obtenir un exemple de configuration, consultez Exemple : persistance de l’adresse IP source.
secLbMethod Spécifie la stratégie de distribution du trafic prise en charge parmi les clusters d’un groupe en mode local d’abord, Canary ou basculement.
destination Spécifie le point de terminaison du service Ingress ou LoadBalancer dans chaque cluster. Le nom de la destination doit correspondre au nom de GSE.
weight Spécifie la proportion du trafic à distribuer entre les clusters. Pour le déploiement Canary, la proportion est spécifiée en pourcentage.
CIDR Spécifie le CIDR à utiliser en mode local d’abord pour déterminer la portée de la localité.
primary Spécifie si la destination est un cluster principal ou un cluster de sauvegarde dans le déploiement de basculement.
monType Spécifie le type de sonde pour déterminer la santé du point de terminaison multi-cluster. Lorsque le type de moniteur est HTTPS, SNI est activé par défaut lors de la prise de contact TLS.
uri Spécifie le chemin d’accès à examiner pour déterminer la santé du point de terminaison multicluster pour HTTP et HTTPS.
respCode Spécifie le code de réponse attendu pour marquer le point de terminaison multicluster comme étant sain pour HTTP et HTTPS.

Définition GSE CRD

La définition du CRD GSE est disponible sur gse-crd.yaml

Exemples : déploiements de stratégie de trafic globale

Déploiement Canary

Vous pouvez utiliser le déploiement Canary lorsque vous souhaitez déployer de nouvelles versions de l’application sur des clusters sélectionnés avant de la déplacer en production.

Cette section explique un exemple de stratégie de trafic globale avec le déploiement Canary, dans lequel vous devez déployer une version plus récente d’une application par étapes avant de la déployer en production.

Dans cet exemple, une version stable d’une application est déployée dans un cluster cluster2 de la west région. Une nouvelle version de l’application est en cours cluster1 de déploiement dans la east région. À l’aide du champ weight, vous pouvez spécifier le volume de trafic redirigé vers chaque cluster. Ici, weight est spécifié comme 40 pour cent. Par conséquent, seulement 40 % du trafic est dirigé vers la nouvelle version. Si le champ weight n’est pas mentionné pour une destination, il est considéré comme faisant partie de la production qui prend la majorité du trafic. Lorsque la nouvelle version de l’application est jugée stable, la nouvelle version peut également être déployée sur d’autres clusters.

  apiVersion: "citrix.com/v1beta1"
  kind: globaltrafficpolicy
  metadata:
    name: gtp1
    namespace: default
  spec:
    serviceType: 'HTTP'
    hosts:
    - host: 'app1.com'
      policy:
        trafficPolicy: 'CANARY'
        secLbMethod: 'ROUNDROBIN'
        targets:
        - destination: 'app1.default.east.cluster1'
          weight: 40
        - destination: 'app1.default.west.cluster2'
        monitor:
        - monType: http
          uri: ''
          respCode: 200

Déploiement avec basculement

Vous pouvez utiliser le déploiement de basculement lorsque vous souhaitez déployer des applications dans une configuration active/passive.

Dans un déploiement avec basculement, l’application est déployée dans plusieurs clusters et ces clusters sont regroupés en un groupe de clusters actif (groupe1) et un groupe de clusters passif (groupe2). À tout moment, un seul ensemble de clusters est actif tandis que l’autre reste passif. Lorsque tous les clusters du groupe1 ne sont pas disponibles, les clusters du groupe2 passent à l’état actif. Lorsque l’un des clusters du groupe1 devient disponible ultérieurement, le groupe1 passe à l’état actif et le groupe2 passe à l’état passif.

L’exemple suivant montre un exemple de configuration GTP pour le basculement. À l’aide du champ primary, vous pouvez spécifier quel cluster appartient au groupe actif et quel cluster appartient au groupe passif. La valeur par défaut du champ True indique que le cluster appartient au groupe actif. Vous pouvez utiliser le champ weight pour diriger plus de demandes client vers un cluster spécifique au sein d’un groupe que les autres clusters si la méthode configurée est Round Robin. Le paramètre monitor de la stratégie de trafic global est utilisé pour configurer le moniteur dans Citrix ADC. Le moniteur peut être lié à des points de terminaison de chaque cluster pour en vérifier l’état.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'FAILOVER'
      secLbMethod: 'ROUNDROBIN'
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 1
      - destination: 'app1.default.west.cluster2'
        primary: false
        weight: 1
      monitor:
      - monType: http
        uri: ''
        respCode: 200

Déploiement RTT

Voici un exemple de stratégie de trafic globale pour le déploiement aller-retour.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'RTT'
      targets:
      - destination: 'app1.default.east.cluster1'
      - destination: 'app1.default.west.cluster2'
      monitor:
      - monType: tcp

Déploiement Round Robin

Voici un exemple de stratégie de trafic pour le déploiement Round Robin. Vous pouvez utiliser ce déploiement lorsque vous devez répartir le trafic uniformément entre les clusters.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'ROUNDROBIN'
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 2
      - destination: 'app1.default.west.cluster2'
        weight: 5
      monitor:
      - monType: tcp
        uri: ''
        respCode: 200

Proximité statique

Voici un exemple de stratégie de trafic pour le déploiement de proximité statique.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'STATICPROXIMITY'
      targets:
      - destination: 'app1.default.east.cluster1'
      - destination: 'app1.default.west.cluster2'
      monitor:
      - monType: http
        uri: ''
        respCode: 200

Exemple : persistance de l’adresse IP source

La stratégie de trafic suivante fournit un exemple pour activer la prise en charge de la persistance de l’IP source. La persistance de l’adresse IP source peut être activée en fournissant le paramètre sourceIpPersistenceId. L’attribut de persistance de l’adresse IP source peut être activé avec les stratégies de trafic prises en charge.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app2.com'
    policy:
      trafficPolicy: 'ROUNDROBIN'
      sourceIpPersistenceId: 300
      targets:
      - destination: 'app2.default.east.cluster1'
        weight: 2
      - destination: 'app2.default.west.cluster2'
        weight: 5
      monitor:
      - monType: tcp
        uri: ''
        respCode: 200