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

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: