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.
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
- Erstellen Sie einen Namespace für die Bereitstellung.
oc create ns sml
-
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-->
-
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-->
-
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-->
-
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-->
-
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-->
-
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-->
-
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-->
-
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.
-
Pros
-
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.
-
Pros
-
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.
-
Pros
-
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.
-
Pros
-
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.
-
Pros
-
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.
-
Pros
Referenz-Materialien
Citrix GitHub: “OpenShift-Routen und Ingress”
Citrix Developer Docs: “Bereitstellungslösungen”
Citrix Blog: “OpenShift-Router-Sharding-Unterstützung mit Citrix ADC aktivieren”