Citrix ADC Ingress Controller

Ingress- und Load-Balancing-Lösung mit mehreren Clustern mithilfe des Citrix Ingress Controller

Übersicht

Um Hochverfügbarkeit, näherungsbasierten Lastausgleich und Skalierbarkeit zu gewährleisten, müssen Sie möglicherweise eine Anwendung in mehreren verteilten Kubernetes-Clustern bereitstellen. Wenn dieselbe Anwendung in mehreren Kubernetes-Clustern bereitgestellt wird, muss eine Entscheidung über den Lastausgleich zwischen Anwendungsinstanzen getroffen werden, die über Cluster verteilt sind.

Für die Implementierung einer Load Balancing-Lösung für verteilte Kubernetes-Cluster muss die Integrität von Anwendungen über Cluster hinweg global überwacht werden. Sie müssen die Anwendungsverfügbarkeit und -leistung überwachen, den Anwendungsstatus über Cluster hinweg aktualisieren, Statistiken von Endpunkten in Rechenzentren sammeln und die Statistiken über Rechenzentren hinweg gemeinsam nutzen.

Citrix bietet eine Eingangs- und Lastausgleichslösung mit mehreren Clustern, die Anwendungen global überwacht, Metriken über verschiedene Cluster hinweg sammelt und gemeinsam nutzt und intelligente Entscheidungen für den Lastenausgleich bietet. Es gewährleistet eine bessere Leistung und Zuverlässigkeit für Ihre Kubernetes-Dienste, die mit Ingress oder dem Typ LoadBalancer verfügbar gemacht werden.

Topologie der Bereitstellung

Im folgenden Diagramm wird eine Bereitstellungstopologie für die Eingangs- und Lastausgleichslösung mit mehreren Clustern für Kubernetes-Cluster erläutert.

Hinweis:

Dienste vom Typ LoadBalancer (verfügbar für Bare-Metal-Cluster mit Citrix ADC) werden ebenfalls unterstützt.

Multi-cluster-deployment

Dieses Diagramm zeigt eine Beispieltopologie mit zwei Rechenzentren, wobei jedes Rechenzentrum mehrere Kubernetes-Cluster enthält. Für Rechenzentrum 1 wird Citrix ADC CPX als Ingress-Load Balancer in jedem Kubernetes-Cluster bereitgestellt. Für Rechenzentrum 2 wird HAProxy als Load Balancer in jedem Kubernetes-Cluster bereitgestellt. Citrix Multi-Cluster-Eingangs- und Lastausgleichslösung für Kubernetes-Lastenausgleich über die Ingresses hinweg.

Hinweis:

Jede Ingress-Lösung, einschließlich Lösungen von Drittanbietern wie Istio Ingress Gateway sowie der Citrix Ingress Controller mit Citrix ADC MPX, VPX oder BLX, wird unterstützt. Diese Topologie ist nur eine Beispielbereitstellung.

Für jedes Rechenzentrum ist ein Citrix Global Server Load Balancing (GSLB) -Gerät konfiguriert. In jedem Citrix ADC, der als globaler Load Balancer fungiert, wird ein Standort als lokaler Standort konfiguriert, der das lokale Rechenzentrum darstellt. Die anderen Standorte sind als Remote-Standorte für jedes Remote-Rechenzentrum konfiguriert. Der Citrix ADC (MPX oder VPX), der als GSLB verwendet wird, kann auch als Ingress-Appliance mit dem Citrix Ingress Controller verwendet werden.

Die Synchronisationsoption für den Global Server Load Balancing (GSLB) des Citrix ADC wird verwendet, um die Konfiguration über die Standorte hinweg zu synchronisieren. Die Citrix ADC Appliance, von der Sie die Synchronisierung verwenden, wird als Masterknoten und als Standort bezeichnet, an dem die Konfiguration als untergeordneter Standort kopiert wird.

Jeder Cluster in der Bereitstellung führt eine Instanz des GSLB Kubernetes-Controllers aus. Der GSLB-Controller ist das Modul, das für die Konfiguration des Citrix ADC GSLB-Geräts verantwortlich ist. Der GSLB-Controller konfiguriert das GSLB-Mastergerät für die Anwendungen, die in ihrem jeweiligen Cluster bereitgestellt werden. Das GSLB-Mastergerät überträgt die GSLB-Konfiguration mithilfe der GSLB-Synchronisierungsfunktion an die verbleibenden untergeordneten GSLB-Geräte. Wenn Sie eine GSLB-Konfiguration synchronisieren, werden die Konfigurationen auf allen GSLB-Sites, die am GSLB-Setup teilnehmen, ähnlich der Konfiguration auf der Master-Site vorgenommen.

Die Eingangs- und Lastausgleichslösung mit mehreren Clustern kann für jedes Kubernetes-Objekt angewendet werden, das zum Weiterleiten des Datenverkehrs in den Cluster verwendet wird.

Die folgenden globalen Load Balancing-Methoden werden unterstützt:

Die folgenden Bereitstellungstypen werden unterstützt:

  • Lokal zuerst: Wenn eine Anwendung in einer lokalen ersten Bereitstellung mit einer anderen Anwendung kommunizieren möchte, bevorzugt sie eine lokale Anwendung im selben Cluster. Wenn die Anwendung lokal nicht verfügbar ist, wird die Anforderung an andere Cluster oder Regionen weitergeleitet.

  • Canary: Canary Release ist eine Technik, um das Risiko der Einführung einer neuen Softwareversion in der Produktion zu verringern, indem die Änderung zunächst für eine kleine Untergruppe von Benutzern eingeführt wird. In dieser Lösung kann Canary Deployment verwendet werden, wenn Sie neue Versionen der Anwendung in ausgewählten Clustern bereitstellen möchten, bevor Sie sie in die Produktion verschieben.

  • Failover: Eine Failover-Bereitstellung wird verwendet, wenn Sie Anwendungen in einer aktiven/passiven Konfiguration bereitstellen möchten, wenn sie nicht im aktiven/aktiven Modus bereitgestellt werden können.

  • Round-Trip-Zeit (RTT): In einer RTT-Bereitstellung wird der Echtzeitstatus des Netzwerks überwacht und leitet die Clientanfrage dynamisch an das Rechenzentrum mit dem niedrigsten RTT-Wert weiter.

  • Statische Nähe: In einer statischen Näherungsbereitstellung wird eine auf IP-Adressen basierende statische Näherungsdatenbank verwendet, um die Nähe zwischen dem lokalen DNS-Server des Clients und den GSLB-Standorten zu bestimmen. Die Anfragen werden an den Standort gesendet, der den Näherungskriterien am besten entspricht.

  • Roundrobin: In einer Round-Robin-Bereitstellung dreht das GSLB-Gerät kontinuierlich eine Liste der Dienste, die an es gebunden sind. Wenn es eine Anforderung erhält, weist es die Verbindung dem ersten Dienst in der Liste zu und verschiebt diesen Dienst dann an das Ende der Liste.

Hinweis:

Derzeit wird IPv6 nicht unterstützt.

CRDs zum Konfigurieren der Multi-Cluster-Eingangs- und Lastausgleichslösung für Kubernetes-Cluster

Die folgenden CRDs werden eingeführt, um die Citrix ADC-Konfiguration für die Ausführung von GSLB von Kubernetes-Anwendungen zu unterstützen.

  • Globale Verkehrsrichtlinie (GTP)
  • Globaler Serviceeintrag (GSE)

GTP-CRD

GTP CRD akzeptiert die Parameter für die Konfiguration von GSLB auf dem Citrix ADC, einschließlich Bereitstellungstyp (Canary, Failover, lokal zuerst), GSLB-Domäne, Integritätsmonitor für den Ingress und Diensttyp.

Die GTP-CRD-Spezifikation ist im GitHub-Repo des Citrix Ingress Controller verfügbar unter: grp-crd.yaml.

GSE-CRD

GSE CRD diktiert die Endpunktinformationen (jedes Kubernetes-Objekt, das den Datenverkehr in den Cluster leitet) in jedem Cluster.

Die GSE CRD-Spezifikation ist im GitHub-Repo des Citrix Ingress Controllers verfügbar unter: gse-crd.yaml

Die GSE-CRD wird automatisch für ein Ingress-Objekt generiert, wenn der in der Ingress-Ressource angegebene Dienst in der GTP-CRD-Instanz referenziert wird und das Feld status-loadbalancer-ip/hostname bereits ausgefüllt ist. Für einen Dienst vom Typ LoadBalancer wird die GSE-CRD automatisch generiert, wenn der Dienst in der GTP-CRD-Instanz referenziert wird und das Feld status-loadbalancer-ip/hostname bereits ausgefüllt ist.

Hinweis: Für die automatische Generierung von GSE CRD im Fall von Ingress sollte der Hostname genau mit dem in der GTP-CRD-Instanz angegebenen Hostnamen übereinstimmen. Sowohl für Ingress als auch für Service vom Typ LoadBalancerwird die GSE-CRD nur für den ersten angegebenen Port generiert.

Bereitstellen der Citrix Multicluster-Eingangs- und Lastausgleichslösung

Die folgenden Voraussetzungen gelten, bevor Sie die Schritte zum Bereitstellen der globalen Lastausgleichslösung von Citrix ausführen:

  • Sie sollten GSLB-Sites auf dem Citrix ADC konfigurieren, der als GSLB-Gerät fungiert.
  • Funktionen wie Content Switching und SSL sollten im GSLB-Gerät aktiviert sein
  • Für statische Nähe muss die Standortdatenbank extern angewendet werden

Führen Sie die folgenden Schritte aus, um die globale Lastausgleichslösung von Citrix für geografisch verteilte Kubernetes-Cluster bereitzustellen.

  1. Erstellen Sie die für die Bereitstellung des GSLB-Controllers erforderlichen RBAC-Berechtigungen mithilfe der Datei gslb-rbac.yaml .

    kubectl apply -f gslb-rbac.yaml
    
  2. Erstellen Sie die für den GSLB-Controller erforderlichen Secrets, um eine Verbindung zu GSLB-Geräten herzustellen, und übertragen Sie die Konfiguration vom GSLB-Controller aus.

    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>
    

    Hinweis:

    Diese Geheimnisse werden in der YAML-Datei des GSLB-Controllers für die jeweiligen Sites verwendet. username und password im Befehl geben den Benutzernamen und das Kennwort des Citrix GSLB ADC an.

  3. Laden Sie die GSLB-Controller-YAML-Datei herunter gslb-controller.yaml.

  4. Bearbeiten Sie die GSLB-Controller-YAML-Datei und aktualisieren Sie die folgenden Werte gemäß den Anforderungen jedes Clusters.

    • LOCAL_REGION und LOCAL_CLUSTER: Geben Sie die Region und den Clusternamen an, in denen dieser Controller bereitgestellt wird.
    • SITENAMES: Geben Sie durch Kommas getrennte Site-Namen an. Die Konfiguration sollte mit der auf GSLB-Geräten konfigurierten Site übereinstimmen.
    • Die IP-Adresse, die Region, der Benutzername und das Kennwort für jede Site sollten mit dem entsprechenden Site-Namen beginnen. Beispiel: Für Site1 in sollten die Felder SITENAMESsite1_ip, site1_regionsite1_username, und lauten site1_password.
    • Argumentabschnitt in der Spezifikation sollte --config-interface und gslb-endpoint enthalten.

    Im Folgenden finden Sie ein Snippet der YAML-Datei für die Bereitstellung des GSLB-Controllers.

    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
    

    Hinweis:

    Die Reihenfolge der GSLB-Site-Informationen sollte in allen Clustern gleich sein. Der erste Standort in der Bestellung wird als Master-Site für das Pushen der Konfiguration betrachtet. Wenn diese Master-Site ausfällt, ist die nächste Site in der Liste der neue Master. Daher sollte die Reihenfolge der Sites in allen Kubernetes-Clustern gleich sein. Wenn beispielsweise in Cluster1 die Reihenfolge der Sites site1 und site2 ist, sollten alle anderen Cluster derselben Reihenfolge folgen.

  5. Stellen Sie die modifizierte GSLB-Controller-YAML-Datei für jeden Cluster auf dem entsprechenden Cluster bereit.

    kubectl apply -f gslb-controller.yaml
    
  6. Stellen Sie die GTP-CRD-Definitions-YAML mit dem folgenden Befehl bereit.

    kubectl create -f  gtp-crd.yaml
    
  7. Stellen Sie die GSE CRD-Definitions-YAML mit dem folgenden Befehl bereit.

    kubectl create -f  gse-crd.yaml
    
  8. Definieren Sie die GTPs für Ihre Domain als YAML-Dateien und wenden Sie GTP-Instanzen an.

    kubectl create -f  gtp-example.yaml
    

    Hinweis:

    GTP-CRD sollte auf alle Cluster mit derselben Konfiguration für dieselbe Domäne angewendet werden.

    Es folgt ein Beispiel für eine globale Datenverkehrsrichtlinienkonfiguration, bei der die Verkehrsrichtlinie zuerst als lokal für die Domäne angegeben wird app2.com. Wenn Ihre Anwendung lokale Dienste bevorzugt, können Sie diese Option verwenden. Der CIDR des lokalen Clusters (cluster1) wird mit dem Feld CIDR angegeben. Das Feld weight wird verwendet, um mehr Clientanforderungen an einen bestimmten Cluster als an andere Cluster zu leiten, wenn die GSLB-Entscheidung vom Citrix ADC getroffen wird. Die Lastausgleichsmethode wird mit dem Feld secLbMethod als Round-Robin angegeben.

    Hinweis:

    Sie können die Lastausgleichsmethode für lokale First-, Canary- und Failover-Bereitstellungen angeben.

    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
    

    Weitere Informationen zu anderen GTP-Bereitstellungsoptionen wie Canary und Failover finden Sie unter Beispiele: Globale Bereitstellung von Verkehrsrichtlinien.

  9. Wenden Sie GSE-Instanzen manuell für GSLB von Ingress an.

    kubectl create -f  gse-example.yaml
    

    Hinweis:

    Die GSE-CRD wird basierend auf den Cluster-Endpunktinformationen in einem bestimmten Cluster angewendet. Der Name des globalen Diensteintrags sollte mit dem Zielzielnamen in der globalen Verkehrsrichtlinie übereinstimmen.

    Es folgt ein Beispiel für einen globalen Serviceeintrag.

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

    In diesem Beispiel ist app2.default.east.cluster1 der Name des globalen Diensteintrags einer der Zielzielnamen in der in Schritt 8 erstellten globalen Verkehrsrichtlinie.

  10. Wenden Sie den Dienst YAML für GSLB von Diensten des Typs LoadBalancer an.

     kubectl create -f  service-example.yaml
    

    Es folgt ein Musterservice.

     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
    

Eine Beispielkonfiguration einer Multi-Cloud-Lösung für Ingress und Load Balancing für Amazon EKS- und Microsoft AKS-Cluster unter Verwendung von Citrix ADC finden Sie in der Multi-Cloud- und Multi-Cluster-Ingress- und Load-Balancing-Lösung mit Amazon EKS- und

So leiten Sie die DNS-Auflösung von Pods an Citrix GSLB ADC

Hinweis:

Dieses Verfahren ist optional und nur erforderlich, wenn die Pods innerhalb des Clusters das DNS über den Citrix GSLB ADC auflösen müssen.

Wenn sich Pods innerhalb des Kubernetes-Clusters befinden

Wenn die Pods in einem Kubernetes-Cluster die GSLB-Lösung verwenden sollen, sollte die ConfigMap des DNS-Anbieters aktualisiert werden, um die Anforderung für eine Domäne (für die GSLB erforderlich ist) an Citrix GSLB ADC weiterzuleiten.

Das folgende Beispiel zeigt, wie die ConfigMap aktualisiert wird, wenn der DNS-Anbieter CoreDNS ist.

  # 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

Wie im Beispiel gezeigt, müssen Sie die erforderliche Konfiguration für Ihre Domäne hinzufügen, wenn ein Pod eine GSLB-Entscheidung für Anwendungen haben soll, die hinter einer Domäne gehostet werden. Hier ist der Domainname app2.com.

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

Die angegebene IP-Adresse (forward . 10.102.217.149) ist ein DNS-Dienst, der im Citrix GSLB ADC konfiguriert ist. Sie können die mehreren IP-Adressen verschiedener GSLB-Sites angeben, indem Sie sie wie folgt durch Leerzeichen trennen.

  forward . ip1 ip2 ip3

Wenn sich Pods innerhalb des OpenShift-Clusters befinden

Wenn Sie möchten, dass die Pods in einem OpenShift-Cluster die GSLB-Lösung verwenden, sollte der DNS-Operator aktualisiert werden, um die Anforderung für eine Domäne (für die GSLB erforderlich ist) an Citrix GSLB ADC weiterzuleiten.

  # 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

Wie im Beispiel gezeigt, müssen Sie die erforderliche Konfiguration für Ihre Domäne hinzufügen, wenn ein Pod eine GSLB-Entscheidung für Anwendungen haben soll, die hinter einer Domäne gehostet werden. Hier ist der Domainname app2.com.

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

Die angegebenen IP-Adressen (10.102.217.149 und 10.102.218.129:5353) sind DNS-Dienste, die im Citrix GSLB ADC konfiguriert sind.

Diese Konfiguration kann mit dem folgenden Befehl überprüft werden:

  # 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
      }

GTP CRD-Definition

GTP CRD-Definition ist unter gtp-crd.yamlverfügbar)

In der folgenden Tabelle werden die GTP-CRD-Attribute erläutert.

Feld Beschreibung
ipType Gibt den DNS-Datensatztyp als A oder AAAA an. Derzeit wird nur der A Datensatztyp unterstützt
serviceType: Gibt das Protokoll an, auf das die Multi-Cluster-Unterstützung angewendet wird.
host Gibt die Domäne an, für die Multi-Cluster-Unterstützung angewendet wird.
trafficPolicy Gibt die in einer Multi-Cluster-Bereitstellung unterstützte Verkehrsverteilungsrichtlinie an.
sourceIpPersistenceId Gibt die eindeutige Quell-IP-Persistenz-ID an. Dieses Attribut ermöglicht Persistenz basierend auf der Quell-IP-Adresse für die eingehenden Pakete. Das Attribut sourceIpPersistenceId sollte ein Vielfaches von 100 sein und eindeutig sein. Eine Beispielkonfiguration finden Sie unter Beispiel: Quell-IP-Persistenz.
secLbMethod Gibt die Verkehrsverteilungsrichtlinie an, die von Clustern unter einer Gruppe in Local-First, Canary oder Failover unterstützt wird.
destination Gibt den Ingress- oder LoadBalancer-Dienstendpunkt in jedem Cluster an. Der Zielname sollte mit dem Namen von GSE übereinstimmen.
weight Gibt den Anteil des Datenverkehrs an, der über Cluster verteilt werden soll. Für die Canary-Bereitstellung wird der Anteil in Prozent angegeben.
CIDR Gibt den CIDR an, der in local-first verwendet werden soll, um den Umfang der Lokalität zu bestimmen.
primary Gibt an, ob das Ziel ein primärer Cluster oder ein Backupcluster in der Failoverbereitstellung ist.
monType Gibt den Typ der Prüfung an, mit der die Integrität des Endpunkts mit mehreren Clustern bestimmt werden soll. Wenn der Monitortyp HTTPS ist, ist SNI während des TLS-Handshakes standardmäßig aktiviert.
uri Gibt den Pfad an, der auf die Integrität des Multicluster-Endpunkts für HTTP und HTTPS geprüft werden soll.
respCode Gibt den Antwortcode an, der den Multicluster-Endpunkt als fehlerfrei für HTTP und HTTPS kennzeichnen soll.

GSE CRD-Definition

Die GSE-CRD-Definition ist unter gse-crd.yamlverfügbar

Beispiele: Globale Bereitstellung von Verkehrsrichtlinien

Canary-Bereitstellung

Sie können die Canary-Bereitstellung verwenden, wenn Sie neue Versionen der Anwendung in ausgewählten Clustern bereitstellen möchten, bevor Sie sie in die Produktion verschieben.

In diesem Abschnitt wird ein Beispiel für eine globale Verkehrsrichtlinie mit Canary-Bereitstellung erläutert, bei der Sie schrittweise eine neuere Version einer Anwendung einführen müssen, bevor Sie sie in der Produktion bereitstellen.

In diesem Beispiel wird eine stabile Version einer Anwendung in einem Cluster cluster2 in der Region west bereitgestellt. Eine neue Version der Anwendung wird in cluster1 der Region east bereitgestellt. Mit dem Feld weight können Sie angeben, wie viel Verkehr zu jedem Cluster umgeleitet wird. Hier weight wird mit 40 Prozent angegeben. Daher sind nur 40 Prozent des Traffics auf die neue Version gerichtet. Wenn das Feld weight nicht für ein Ziel erwähnt wird, wird es als Teil der Produktion betrachtet, die den meisten Verkehr benötigt. Wenn die neuere Version der Anwendung als stabil befunden wird, kann die neue Version auch in anderen Clustern bereitgestellt werden.

  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

Failover-Bereitstellung

Sie können die Failover-Bereitstellung verwenden, wenn Sie Anwendungen in einer aktiven/passiven Konfiguration bereitstellen möchten.

In einer Failover-Bereitstellung wird die Anwendung in mehreren Clustern bereitgestellt, und diese Cluster werden in eine aktive Clustergruppe (Gruppe1) und eine passive Clustergruppe (Gruppe2) gruppiert. Zu jeder Zeit ist nur ein Satz von Clustern aktiv, während der andere Satz passiv bleibt. Wenn alle Cluster in Gruppe1 nicht verfügbar sind, werden die Cluster in Gruppe2 in den aktiven Zustand versetzt. Wenn einer der Cluster in Gruppe1 zu einem späteren Zeitpunkt verfügbar wird, wechselt Gruppe1 in den aktiven Zustand und Gruppe2 wechselt in den passiven Zustand.

Das folgende Beispiel zeigt ein Beispiel für eine GTP-Konfiguration für ein Failover. Über das Feld primary können Sie angeben, welcher Cluster zur aktiven Gruppe gehört und welcher Cluster zur passiven Gruppe gehört. Der Standardwert für das Feld True gibt an, dass der Cluster zur aktiven Gruppe gehört. Sie können das Feld weight verwenden, um mehr Clientanforderungen an einen bestimmten Cluster innerhalb einer Gruppe zu leiten als die anderen Cluster, wenn die konfigurierte Methode Round-Robin ist. Der Parameter monitor in der globalen Verkehrsrichtlinie wird verwendet, um den Monitor im Citrix ADC zu konfigurieren. Der Monitor kann an Endpunkte in jedem Cluster gebunden werden, um deren Integrität zu überprüfen.

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

RTT-Bereitstellung

Es folgt ein Beispiel für eine globale Verkehrsrichtlinie für die Bereitstellung von Hin- und Rückflugzeiten

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

Rund-Robin-Einsatz

Es folgt ein Beispiel für eine Verkehrsrichtlinie für die Round-Robin-Bereitstellung. Sie können diese Bereitstellung verwenden, wenn Sie den Datenverkehr gleichmäßig auf die Cluster verteilen müssen.

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

Statische Nähe

Es folgt ein Beispiel für eine Verkehrsrichtlinie für die statische Näherungsbereitstellung.

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

Beispiel: Quell-IP-Persistenz

Die folgende Verkehrsrichtlinie ist ein Beispiel für die Aktivierung der Quell-IP-Persistenzunterstützung. Quell-IP-Persistenz kann durch Angabe des Parameters aktiviert werden sourceIpPersistenceId. Das Quell-IP-Persistenzattribut kann mit den unterstützten Verkehrsrichtlinien aktiviert werden.

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