Produktdokumentation
Citrix Tech Zone
PDF anzeigen

Service-Migration zu Citrix ADC mithilfe von Routen in OpenShift Validated Reference Design

September 29, 2022
Author:  Luis Ugarte, Beth Pollack

Statische und automatische Routen in einem OpenShift-Cluster

Statische Routen (Standard) - ordnet das OpenShift HostSubnet über eine statische Route dem externen ADC zu

Statische Routen sind in älteren OpenShift-Bereitstellungen, die HAProxy verwenden, üblich. Die statischen Routen können parallel mit Citrix Node Controller (CNC), Citrix Ingress Controller (CIC) und CPX verwendet werden, wenn Dienste von einem Service Proxy zu einem anderen migriert werden, ohne die bereitgestellten Namespaces in einem funktionierenden Cluster zu unterbrechen.

Beispiel für eine statische Routenkonfiguration für 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-->

Auto Routes - verwendet die CNC (Citrix Node Controller), um die externen Routen zu den definierten Routen-Shards zu automatisieren

Sie können Citrix ADC auf zwei Arten in OpenShift integrieren, die beide OpenShift-Router-Sharding unterstützen.

Routen-Typen

  • ungesichert - externer Load Balancer zum CIC-Router, HTTP-Verkehr wird nicht verschlüsselt.
  • secured-edge - externer Load Balancer zum CIC-Router, der TLS beendet.
  • Secured-Passthrough - externer Load Balancer zum Ziel, der TLS beendet
  • secured reencrypt - externer Load Balancer zum CIC-Router, der TLS beendet. CIC-Router verschlüsselt das Ziel mithilfe von TLS.

Weitere Informationen zu den verschiedenen Routentypen finden Sie in den Bereitstellungslösungen für Citrix Ingress Controller.

Bereitstellen des Citrix Ingress Controller mit OpenShift-Router-Sharding-Unterstützung

Der Citrix Ingress Controller (CIC) fungiert als Router und leitet den Datenverkehr an verschiedene Pods um, um den eingehenden Datenverkehr auf verschiedene verfügbare Pods zu verteilen.

Dieser Migrationsprozess kann auch Teil eines Cluster-Upgrade-Prozesses von älteren OpenShift-Topologien zu automatisierten Bereitstellungen mit Citrix CNC-, CIC- und CPX-Komponenten für Clustermigration und Upgrade-Verfahren sein.

Diese Lösung kann auf zwei Arten erreicht werden:

  • CIC Router-Plug-In (Pod)
  • CPX Router in OpenShift (Sidecar)

Beide Methoden werden unten zusammen mit Migrationsbeispielen beschrieben.

OpenShift-Router-Sharding ermöglicht die Verteilung einer Reihe von Routen auf mehrere OpenShift-Router. Standardmäßig wählt ein OpenShift-Router alle Routen aus allen Namespaces aus. Beim Router-Sharding werden Beschriftungen zu Routen oder Namespaces und Label-Selektoren zu Routern zum Filtern von Routen hinzugefügt. Jeder Router-Shard wählt nur Routen mit bestimmten Beschriftungen aus, die den Auswahlparametern der Beschriftung entsprechen.

Um Router-Sharding für eine Citrix ADC-Bereitstellung auf OpenShift zu konfigurieren, ist pro Shard eine Citrix Ingress Controller-Instanz erforderlich. Die Citrix Ingress Controller-Instanz wird je nach den für das Sharding erforderlichen Kriterien mit Route- oder Namespace-Labels oder beiden als Umgebungsvariablen bereitgestellt. Wenn der Citrix Ingress Controller eine Route verarbeitet, vergleicht er die Beschriftungen der Route oder die Namespace-Labels der Route mit den darauf konfigurierten Auswahlkriterien. Wenn die Route die Kriterien erfüllt, wird die entsprechende Konfiguration auf Citrix ADC angewendet, andernfalls wird die Konfiguration nicht angewendet.

Beim Router-Sharding basiert die Auswahl einer Teilmenge von Routen aus dem gesamten Routenpool auf Auswahlausdrücken. Auswahlausdrücke sind eine Kombination aus mehreren Werten und Operationen. Weitere Informationen zu den Ausdrücken, Werten und Vorgängen finden Sie in diesem Citrix-Blog.

Bookinfo-Bereitstellung

Die Architektur für die Bookinfo-Anwendung ist in der folgenden Abbildung dargestellt. Ein CIC wird als OpenShift-Router-Plug-In in der ersten Ebene bereitgestellt und konfiguriert den Citrix ADC VPX so, dass der Nord-Süd-Verkehr zur Produktseite weitergeleitet wird. In der zweiten Ebene wird ein Citrix ADC CPX als OpenShift-Router bereitgestellt, der den Ost-West-Verkehr zwischen dem Mikroservice “Details” und “Produktseite” leitet, während der Ost-West-Verkehr zwischen den Microservices Produktseite, Bewertungen und Ratings über den Standard-HAProxy-Router geroutet wird.

Routen-Sharding-Diagramm der als Service Mesh Lite-Architektur bereitgestellten Bookinfo-App

Citrix Komponenten

  • VPX - Der Ingress-ADC, der die Cluster-Dienste für DNS präsentiert.
  • CIC - stellt die ROUTE_LABELS und NAMESPACE_LABELS dem externen Citrix ADC über die CNC-Route zur Verfügung.
  • CPX — bietet OpenShift-Routing innerhalb des OpenShift-Clusters.

Schritte für die Bereitstellung

  1. Erstellen Sie einen Namespace für die Bereitstellung. oc create ns sml

  2. Stellen Sie die Bookinfo-Anwendung im Namespace bereit. 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. Stellen Sie die Routendatei bereit, die unserem Produktseiten-Service zugeordnet ist. Geben Sie frontend-ip an (Dies ist die Content Switching-VIP auf dem Tier 1 ADC) 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. Stellen Sie die RBAC-Datei für den sml-Namespace bereit, der dem CIC die erforderlichen Berechtigungen zum Ausführen erteilt. Die RBAC-Datei hat bereits einen Namensraum. 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. Stellen Sie Ihr CIC bereit, um die Routenkonfigurationen zu Ihrem VPX zu übertragen. Ordnen Sie den Parameter ROUTE_LABELS der in angegebenen Bezeichnung zu route-productpage.yaml. Weitere Informationen zur Syntax von ROUTE_LABELS finden Sie in diesem 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. Jetzt müssen wir einen Headless-Service erstellen, der Benutzer, die nach Details suchen, mithilfe der DNS-Pods in unserem Cluster zu unserem CPX weiterleitet. 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. Stellen Sie einen neuen Dienst bereit, um den Detailcontainer verfügbar zu machen. 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. Stellen Sie eine neue Routendefinition bereit, die sich vor dem von uns erstellten Detailservice befindet. Beachten Sie, dass die Bezeichnung “Name: Details” lautet. 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. Stellen Sie CPX für E/W-Verkehr bereit. Ein CIC wird als Beiwagen bereitgestellt und mit einem ROUTE_LABEL-Parameter konfiguriert, um der Bezeichnung in detailsroutes.yaml zu entsprechen. 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-->

Kontinuierliche Bereitstellungsoptionen in einer Microservices-Umgebung

Continuous Integration (CI) ist eine Entwicklungspraxis, bei der Entwickler mehrmals täglich Code in ein gemeinsam genutztes Repository integrieren müssen.

Continuous Delivery (CD) ist die natürliche Erweiterung von Continuous Integration: ein Ansatz, bei dem Teams sicherstellen, dass jede Änderung am System lösbar ist und dass wir jede Version auf Knopfdruck veröffentlichen können.

Die verschiedenen CD-Optionen, zusammen mit ihren Vor- und Nachteilen, sind:

  • Neu erstellen — Version 1 (V1) wird beendet und dann wird Version 2 (V2) eingeführt.
    • Pros
      • Einfach einzurichten.
      • Der Antragsstatus wird vollständig erneuert.
    • Cons
      • Hohe Auswirkung auf den Benutzer. Erwarten Sie Ausfallzeiten, die von der Shutdown- und Startdauer abhängen.
  • Ramped/Rolling Update - V2 wird langsam ausgerollt und ersetzt V1.
    • Pros
      • Einfach einzurichten.
      • Die Version wird langsam über alle Instanzen hinweg veröffentlicht.
      • Praktisch für zustandsbehaftete Anwendungen, die das Rebalancing der Daten bewältigen können.
    • Cons
      • Rollout/Rollback kann einige Zeit in Anspruch nehmen.
      • Die Unterstützung mehrerer APIs ist schwierig.
      • Wenig Kontrolle über den Verkehr.
  • Blaugrün - V2 wird neben V1 freigegeben, dann wird der Verkehr auf V2 umgeschaltet.
    • Pros
      • Sofortiger Rollout/Rollback.
      • Vermeiden Sie Versionsprobleme, da die gesamte Anwendung auf einmal geändert wird.
    • Cons
      • Teuer, da es doppelt so viele Ressourcen benötigt.
      • Vor der Freigabe für die Produktion sollte die gesamte Plattform ordnungsgemäß getestet werden.
      • Die Handhabung mehrerer zustandsbehafteter Anwendungen kann schwierig sein.
  • Canary - V2 wird für eine Untergruppe von Benutzern freigegeben und fährt dann mit einem vollständigen Rollout fort.
    • Pros
      • Version für eine Untergruppe von Benutzern veröffentlicht.
      • Praktisch für die Überwachung von Fehlerraten und Leistung.
      • Schneller Rollback.
    • Cons
      • Langsamer Rollout.
      • Die Handhabung mehrerer zustandsbehafteter Anwendungen kann schwierig sein.
  • A/B-Tests — V2 wird unter bestimmten Bedingungen für eine Untergruppe von Benutzern freigegeben.
    • Pros
      • Es laufen mehrere Versionen parallel.
      • Volle Kontrolle über die Traffic-Verteilung.
    • Cons
      • Erfordert einen intelligenten Load Balancer.
      • Es ist schwierig, Fehler für eine bestimmte Sitzung zu beheben, sodass verteilte Ablaufverfolgung obligatorisch wird.
  • Shadow — V2 empfängt realen Verkehr neben V11 und hat keinen Einfluss auf die Reaktion.
    • Pros
      • Leistungstests der Anwendung mit Produktionsverkehr.
      • Keine Auswirkung auf den Benutzer.
      • Kein Rollout, bis die Stabilität und Leistung der Anwendung die Anforderungen erfüllen.
    • Cons
      • Teuer, da es doppelt so viele Ressourcen benötigt.
      • Kein echter Benutzertest und kann irreführend sein.
      • Komplex einzurichten.
      • Erfordert für bestimmte Fälle einen Spottservice.

Referenz-Materialien

Citrix GitHub: “OpenShift-Routen und Ingress”

Citrix Developer Docs: “Bereitstellungslösungen”

Citrix Blog: “OpenShift-Router-Sharding-Unterstützung mit Citrix ADC aktivieren”

OpenShift Routen-Dokumentation:

Service-Migration zu Citrix ADC mithilfe von Routen in OpenShift Validated Reference Design
September 29, 2022
Author:  Luis Ugarte, Beth Pollack
September 29, 2022
Author:  Luis Ugarte, Beth Pollack

In diesem Artikel

Feedback zur Site | Datenschutz und rechtliche Bestimmungen | Cookie-Einstellungen | Einstellungen für die Zustimmung | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.