Citrix Cloud Native Networking für Red Hat OpenShift 3.11 validiertes Referenzdesign

Der Citrix ADC Stack erfüllt die grundlegenden Anforderungen für Anwendungsverfügbarkeitsfunktionen (ADC), Trennung von Sicherheitsfunktionen (WAF), Skalierung agiler Anwendungstopologien (SSL und GSLB) und proaktive Beobachtbarkeit (Service Graph) in einer stark orchestrierten Cloud Native Era-Umgebung.

Die digitale Transformation verstärkt die Notwendigkeit, moderne Anwendungsbereitstellungen auf Microservice-basierte Architekturen umzustellen. Diese Cloud Native-Architekturen nutzen Anwendungscontainer, Microservices und Kubernetes.

Der Cloud-Native-Ansatz für moderne Anwendungen veränderte auch den Entwicklungslebenszyklus, einschließlich agiler Workflows, Toolsets für die Automatisierungsbereitstellung sowie Entwicklungssprachen und -plattformen.

Die neue Ära der modernen Anwendungsbereitstellung hat auch die traditionellen Geschäftsmodelldisziplinen von Rechenzentren verändert, darunter monatliche und jährliche Softwareversionen und -verträge, Silo-Rechenressourcen und -budgets sowie das Modell des Anbieterverbrauchs.

Und während all diese Modernisierungen im Ökosystem stattfinden, gibt es immer noch grundlegende Anforderungen an Anwendungsverfügbarkeitsfunktionen (ADC), Trennung von Sicherheitsfunktionen (WAF), Skalierung agiler Anwendungstopologien (SSL und GSLB) und proaktive Beobachtbarkeit (Service Graph) in einem hoch orchestrierten Umgebung.

Warum Citrix für moderne Anwendungsbereitstellung

Der Citrix-Softwareansatz für die moderne Anwendungsbereitstellung erfordert die Integration eines agilen Workflows in vielen Teams innerhalb des Unternehmens. Einer der Vorteile der agilen Anwendungsentwicklung und -bereitstellung ist das als CI/CD bekannte Framework.

CI/CD ist eine Möglichkeit, Geschwindigkeit, Sicherheit und Zuverlässigkeit für den modernen Anwendungslebenszyklus zu bieten.

Continuous Integration (CI) ermöglicht eine gemeinsame Codebasis, die mehrmals täglich in Echtzeit aktualisiert und in eine automatisierte Build-Plattform integriert werden kann. Die drei Phasen der kontinuierlichen Integration sind Push, Test, Fix.

Continuous Delivery (CD) integriert die Deployment-Pipeline direkt in den CI-Entwicklungsprozess und optimiert und verbessert so das Softwarebereitstellungsmodell für moderne Anwendungen.

Citrix ADCs sind durch die Implementierung automatisierter progressiver Rollouts für Canary-Analysen in den kontinuierlichen Bereitstellungsprozess eingebunden.

Eine Lösung für alle Stakeholder

Citrix hat eine dedizierte softwarebasierte Lösung entwickelt, die die funktionsübergreifenden Anforderungen bei der Bereitstellung moderner Anwendungen berücksichtigt und die verschiedenen Komponenten von Observability Stack, Sicherheitsframework und CI/CD-Infrastruktur integriert.

Traditionelle Unternehmen, die CI/CD-Techniken für die Bereitstellung moderner Anwendungen anwenden, haben erkannt, dass allen an CI/CD beteiligten Mitgliedern ein gemeinsames Bereitstellungs- und Verfügbarkeitsframework zur Verfügung gestellt werden muss. Diese Ressourcen werden im Allgemeinen als “Stakeholder” der Geschäftseinheit definiert, und während jeder Stakeholder In den Gesamterfolg der Organisation investiert, hat jeder Stakeholder im Allgemeinen unterschiedliche Anforderungen und Unterschiede.

Einige gängige Beispiele für Stakeholder in der modernen Lieferaktivität sind:

  • Plattformteam — Bereitstellung der Rechenzentrumsinfrastruktur wie IaaS, PaaS, SDN, ADC, WAF
  • DevOps- und Engineering-Team — Entwicklung und Wartung des einheitlichen Code-Repositorys, der Automatisierungstools
  • Service Reliability Engineering (SRE) -Team — Reduzierung organisatorischer Silos, Fehlermanagement, Bereitstellungsautomatisierung und Messungen
  • Security Operations Team — Proaktive Sicherheitsrichtlinien, Incident Management, Patch-Bereitstellung, Portfolio-Hardening

Der Citrix Software Stack erklärt

Single Code Base — es ist alles der gleiche Code für Sie — Lokale Bereitstellungen, Public Cloud-Bereitstellungen, Private Cloud-Bereitstellungen, GOV Cloud-Bereitstellungen

  • Plattformauswahl - um allen agilen Anforderungen gerecht zu werden, wählen Sie ein beliebiges Citrix ADC-Modell

    • CPX — der Citrix ADC CPX ist ein Citrix ADC, der als Container geliefert wird
    • VPX — Das Citrix ADC VPX-Produkt ist eine virtuelle Appliance, die auf einer Vielzahl von Virtualisierungs- und Cloud-Plattformen gehostet werden kann und eine Leistung von 10 MB/s bis 100 Gb/s bietet.
    • MPX — Die Citrix ADC MPX ist eine hardwarebasierte Appliance zur Anwendungsbereitstellung, die eine Leistung von 500 MB/s bis 200 Gb/s bietet.
    • SDX — Die Citrix ADC SDX-Appliance ist eine mandantenfähige Plattform, auf der Sie mehrere virtuelle Citrix ADC-Maschinen (Instanzen) bereitstellen und verwalten können.
    • BLX — Die Citrix ADC BLX-Appliance ist ein Softwareformfaktor von Citrix ADC. Es ist für die native Ausführung auf Bare-Metal-Linux auf kommerziellen Standardservern (COTS) konzipiert Containerisierte Umgebungen - Erstellen Sie Overlays und konfigurieren Sie automatisch Ihren Citrix ADC
    • Citrix Ingress Controller - basiert auf Kubernetes Ingress und konfiguriert automatisch einen oder mehrere Citrix ADC basierend auf der Ingress-Ressourcenkonfiguration
    • Citrix Node Controller — Erstellen Sie ein VXLAN-basiertes Overlay-Netzwerk zwischen den Kubernetes-Knoten und dem Ingress Citrix ADC
    • Citrix IPAM Controller - weisen Sie den virtuellen Lastausgleichsserver auf einem Citrix ADC automatisch mit einer IP-Adresse (virtuelle IP-Adresse oder VIP) zu Pooled Capacity Lizenzierung — eine globale Lizenz — Der allgegenwärtige globale Lizenzpool entkoppelt Plattformen und Lizenzen für vollständige Flexibilität bei Design und Leistung Application Delivery Manger — das zentrale Fenster — Verwaltung der Flotte, Orchestrierung von Richtlinien und Anwendungen, Überwachung und Fehlerbehebung in Echtzeit
      Flexible Topologien — herkömmliche Rechenzentren oder moderne Clouds — Single Tier, Two-Tier und Service Mesh Lite

Der Citrix ADC Wert

  • Integration von Kubernetes und CNCF Open Source Tools
  • Der Perfect Proxy — ein bewährter Layer7 Application Delivery Controller für moderne Apps
    • Hochleistungs-ADC-Container in einer Pod- oder Sidecar-Bereitstellung
    • Zugriff mit geringer Latenz auf den Kubernetes-Cluster mithilfe mehrerer Optionen
  • Funktionsreiche API — einfache Implementierung und Orchestrierung von Sicherheitsfunktionen ohne Einschränkungen
  • Erweiterte Verkehrssteuerung und Canary-Bereitstellung für CI/CD
  • Bewährte Sicherheit durch TLS/SSL-, WAF-, DoS- und API-Schutz
  • Umfangreiche Layer 7-Funktionen
  • Integrierte Überwachung für Legacy- und moderne Anwendungsbereitstellungen
  • Umsetzbare Einblicke und Servicediagramme für mehr Sichtbarkeit

Die Vorteile von Citrix ADC

  • Verschieben Sie ältere Apps, ohne sie neu schreiben zu müssen
  • Entwickler können Apps mit Citrix ADC-Richtlinien mithilfe von Kubernetes-APIs sichern (CRDs verwenden — entwicklerfreundlich)
  • Bereitstellung leistungsfähiger Microservices für North-South und Service Mesh
  • Verwenden Sie ein Application Service Graph für alle Microservices
  • Schnellere Behebung von Microservices-Problemen über TCP, UDP, HTTP/S, SSL
  • APIs sichern und mithilfe von Kubernetes-APIs konfigurieren
  • Verbessern Sie den CICD-Prozess für Canary-Bereitstellungen

Architektur-Komponenten

Citrix Lösungsportfolio für Cloud-native Anwendungen

Der Vorteil der Citrix ADC Suite

Citrix ist Choice. Unabhängig davon, ob Sie mit Legacy-Rechenzentren und -Komponenten leben oder eine neue Cloud-native moderne Anwendung auf den Markt gebracht haben, Citrix ADC lässt sich nahtlos in alle Plattformanforderungen integrieren, die Sie möglicherweise haben. Wir bieten Cloud-native ADC-Funktionalität für abonnementbasierte Cloud-Plattformen und -Tools, ermöglichen die Leitung und Orchestrierung des Datenverkehrs in Ihren Kubernetes-Cluster on-premises mit einfacher Ingress-Controller-Orchestrierung und adressieren die Service Mesh-Architekturen von einfach bis komplex.

Citrix ist validiert. Validierte Entwurfsvorlagen und Beispielanwendungen ermöglichen eine einfache Referenz für einen gewünschten Status und eine Geschäftsanforderung, die schnell und vollständig erfüllt werden kann. Wir haben Konfigurationsbeispiele an einem zentralen Ort dokumentiert und veröffentlicht, um die Übersicht über DevOps-, SecOps- und Platforms-Teams hinweg zu erleichtern.

Citrix ist agil und modern. Erstellen Sie eine grundlegende Architektur, mit der Kunden neue Funktionen des Citrix Cloud Native Stack mit ihrem vorhandenen ADC und neuen Modulen (CNC, IPAM usw.) nutzen können

Citrix ist Open. Helfen Sie Kunden, unsere Integration mit Partnerökosystemen zu verstehen. In diesem Dokument verwenden wir sowohl OpenSource CNCF-Tools als auch Citrix Enterprise-Grade-Produkte.

Partner-Ökosystem

Dieses Thema enthält Details zu verschiedenen Kubernetes-Plattformen, Bereitstellungstopologien, Funktionen und CNIs, die in Cloud-nativen Bereitstellungen unterstützt werden, darunter Citrix ADC und Citrix Ingress Controller.

Der Citrix Ingress Controller wird auf den folgenden Plattformen unterstützt:

  • Kubernetes v1.10 auf Bare Metal oder selbst gehostet in öffentlichen Clouds wie AWS, GCP oder Azure.
  • Google Kubernetes Engine (GKE)
  • Elastic Kubernetes-Dienst (EKS)
  • Azure Kubernetes-Dienst (AKS)
  • Red Hat OpenShift Version 3.11 und höher
  • Pivotal-Containerdienst (PKS)
  • Diamanti Enterprise Kubernetes-Plattform

Unser Partner-Ökosystem umfasst auch Folgendes:

  • Prometheus — Überwachungstool für Metriken, Alerting und Erkenntnisse
  • Grafana — eine Plattform für Analytik und Monitoring
  • Spinnaker — ein Tool für Continuous Delivery mit mehreren Clouds und Canary - Analytics
  • Elasticsearch — ein Dienst für die Suche nach Anwendungen oder Websites
  • Kibana — ein Visualisierungstool für elastische Suchdaten und ein Elastic Stack-Navigationstool
  • Fluentd — ein Datensammler-Tool

Der Schwerpunkt dieses nächsten Abschnitts liegt auf Design/Architektur mit OpenShift.

OpenShift Überblick

Red Hat OpenShift ist eine Kubernetes-Plattform für Bereitstellungen mit Schwerpunkt auf der Verwendung von Microservices und Containern, um Anwendungen schneller zu erstellen und zu skalieren. Durch die Automatisierung, Installation, Aktualisierung und Verwaltung des Container-Stacks rationalisiert OpenShift Kubernetes und erleichtert alltägliche DevOps-Aufgaben.

  • Entwickler stellen Anwendungen Zugriff auf validierte Lösungen und Partner bereit, die über optimierte Workflows in die Produktion gebracht werden.
  • Der Betrieb kann die Umgebung mithilfe der Web-Konsole und der integrierten Protokollierung und Überwachung verwalten und skalieren.

Abbildung 1-6: OpenShift-High-Level-Architektur.

Weitere Vorteile und Komponenten von OpenShift sind:

  • Wahl der Infrastruktur
  • Master- und Workerknoten
  • Image-Registrierung
  • Routing- und Service-Layer
  • Entwicklerbetrieb (eingeführt, aber außerhalb des Rahmens dieses Dokuments)

Anwendungsfälle für die Integration von Red Hat OpenShift in den Citrix Native Stack sind:

  • Unterstützung älterer Anwendungen
  • Als APIs bereitgestellte Rewrite/Responder-Richtlinien
  • Fehlerbehebung bei Microservices
  • Täglicher Betrieb mit Sicherheitspatches und Funktionserweiterungen

In diesem Dokument behandeln wir, wie Citric ADC eine solide Routing-/Service-Layer-Integration bietet.

OpenShift-Projekte

Das erste neue Konzept, das OpenShift hinzufügt, ist project, das effektiv einen Namespace umschließt, wobei der Zugriff auf den Namespace über das Projekt gesteuert wird. Der Zugriff wird durch ein Authentifizierungs- und Autorisierungsmodell gesteuert, das auf Benutzern und Gruppen basiert Projekte in OpenShift stellen daher die Wände zwischen Namespaces bereit und stellen sicher, dass Benutzer oder Anwendungen nur sehen und darauf zugreifen können, was ihnen erlaubt ist.

OpenShift-Namespaces

Das primäre Gruppierungskonzept in Kubernetes ist der Namespace. Namespaces sind auch eine Möglichkeit, Clusterressourcen auf mehrere Benutzer aufzuteilen. Abgesehen davon gibt es in Kubernetes keine Sicherheit zwischen Namespaces. Wenn Sie ein “Benutzer” in einem Kubernetes-Cluster sind, können Sie all die verschiedenen Namespaces und die darin definierten Ressourcen sehen.

Beispiel für eine YAML-Datei, die einen Namespace mit dem Namen "tier-2-adc" erstellt.

OpenShift Software Defined Networking (SDN)

OpenShift Container Platform verwendet einen SDN-Ansatz (Software Defined Networking), um ein einheitliches Clusternetzwerk bereitzustellen, das die Kommunikation zwischen Pods im OpenShift Container Platform-Cluster ermöglicht. Dieses Pod-Netzwerk wird vom OpenShift SDN eingerichtet und verwaltet, das ein Overlay-Netzwerk mithilfe von Open vSwitch (OVS) konfiguriert.

OpenShift SDN bietet drei SDN-Plug-Ins für die Konfiguration des Pod-Netzwerks:

  • Das ovs-Subnetz-Plug-In ist das ursprüngliche Plug-In, das ein “flaches” Pod-Netzwerk bereitstellt, in dem jeder Pod mit jedem anderen Pod und Dienst kommunizieren kann.
  • Das ovs-multitenant-Plug-In bietet Isolierung auf Projektebene für Pods und Dienste. Jedes Projekt erhält eine eindeutige virtuelle Netzwerk-ID (VNID), die den Datenverkehr von den dem Projekt zugewiesenen Pods identifiziert. Pods aus verschiedenen Projekten können keine Pakete an Pods und Dienste eines anderen Projekts senden oder Pakete von diesen empfangen.
  • Projekte, die VNID 0 erhalten, sind jedoch privilegierter, da sie mit allen anderen Pods kommunizieren dürfen und alle anderen Pods mit ihnen kommunizieren können. In OpenShift Container Platform-Clustern hat das Standardprojekt die VNID 0.Dies erleichtert bestimmten Diensten, wie dem Load Balancer, die Kommunikation mit allen anderen Pods im Cluster und umgekehrt.
  • Das ovs-networkpolicy Plug-In ermöglicht es Projektadministratoren, ihre eigenen Isolationsrichtlinien mithilfe von NetworkPolicy-Objekten zu konfigurieren.

OpenShift Routing und Plug-Ins

Ein OpenShift-Administrator kannRouter in einem OpenShift-Cluster bereitstellen, sodass von Entwicklern erstellte Routenvon externen Clients verwendet werden können. Die Routing-Schicht in OpenShift ist steckbar, und zwei verfügbareRouter-Plug-inswerden standardmäßig bereitgestellt und unterstützt.

OpenShift-Router bieten externe Hostnamenzuordnung und Lastausgleich fürDiensteüber Protokolle, die Unterscheidungsinformationen direkt an den Router weitergeben. Der Hostname muss im Protokoll enthalten sein, damit der Router bestimmen kann, wohin er gesendet werden soll.

Router-Plug-Ins gehen davon aus, dass sie an die Hostports 80 und 443 gebunden werden können. Dadurch kann externer Datenverkehr zum Host und anschließend durch den Router geleitet werden. Router gehen auch davon aus, dass das Netzwerk so konfiguriert ist, dass es auf alle Pods im Cluster zugreifen kann.

DerOpenShift-Routerist der Eingangspunkt für den gesamten externen Datenverkehr, der fürDienstein Ihrer OpenShift-Installation bestimmt ist.OpenShift bietet und unterstützt die folgenden Router-Plug-ins:

  • DerHAProxy-Template-Routerist das Standard-Plug-in. Es verwendet das openshift3/ose-haproxy-routerimage, um eine HAProxy-Instanz neben dem Template-Router-Plug-in in einem Container auf OpenShift auszuführen. Es unterstützt derzeit HTTP (S) -Verkehr und TLS-fähigen Datenverkehr über SNI. Der Container des Routers hört auf der Host-Netzwerkschnittstelle, im Gegensatz zu den meisten Containern, die nur auf privaten IPs hören. Der Router leitet externe Anfragen nach Routennamen an die IPs der tatsächlichen Pods weiter, die vom mit der Route verknüpften Dienst identifiziert wurden.
  • Der Citrix Ingress Controller kann als Router-Plug-In im OpenShift-Cluster bereitgestellt werden, um ihn in Citrix ADCs zu integrieren, die in Ihrer Umgebung bereitgestellt werden. Mit dem Citrix Ingress Controller können Sie die erweiterten Lastausgleichs- und Verkehrsverwaltungsfunktionen von Citrix ADC mit Ihrem OpenShift-Cluster verwenden. Siehe Bereitstellen des Citrix Ingress Controller als Router-Plug-In in einem OpenShift-Cluster.

OpenShift Routen und Ingress Methoden

In einem OpenShift-Cluster benötigen externe Clients eine Möglichkeit, auf die von PODS bereitgestellten Dienste zuzugreifen. OpenShift bietet zwei Ressourcen für die Kommunikation mit Diensten, die im Cluster ausgeführt werden:RoutesundIngress.

Routen

In einem OpenShift-Cluster macht eine Route einen Dienst für einen bestimmten Domainnamen verfügbar oder verknüpft einen Domainnamen mit einem Dienst. OpenShift-Router leiten externe Anforderungen an Dienste innerhalb des OpenShift-Clusters gemäß den in Routen festgelegten Regeln weiter. Wenn Sie den OpenShift-Router verwenden, müssen Sie auch das externe DNS konfigurieren, um sicherzustellen, dass der Verkehr auf dem Router landet.

Der Citrix Ingress Controller kann als Router-Plug-In im OpenShift-Cluster bereitgestellt werden, um ihn in Citrix ADCs zu integrieren, die in Ihrer Umgebung bereitgestellt werden. Mit dem Citrix Ingress Controller können Sie die erweiterten Lastausgleichs- und Verkehrsverwaltungsfunktionen von Citrix ADC mit Ihrem OpenShift-Cluster verwenden. OpenShift-Strecken können gesichert oder ungesichert sein. Gesicherte Routen geben die TLS-Terminierung der Route an.

Der Citrix Ingress Controller unterstützt die folgenden OpenShift-Routen:

  • Ungesicherte Routen: Für ungesicherte Routen ist der HTTP-Verkehr nicht verschlüsselt.
  • Edge-Terminierung: Für den Edge-Abschluss wird TLS am Router abgeschlossen. Der Datenverkehr vom Router zu den Endpunkten über das interne Netzwerk ist nicht verschlüsselt.
  • Passthrough-Terminierung: Bei der Passthrough-Terminierung ist der Router nicht am TLS-Offloading beteiligt und verschlüsselter Datenverkehr wird direkt zum Ziel gesendet.
  • Beendigung der erneuten Verschlüsselung: Bei der Beendigung der erneuten Verschlüsselung beendet der Router die TLS-Verbindung, baut dann aber eine weitere TLS-Verbindung zum Endpunkt auf.

Je nachdem, wie Sie Citrix ADC verwenden möchten, gibt es zwei Möglichkeiten, den Citrix Ingress Controller als Router-Plug-in im OpenShift-Cluster bereitzustellen: als Citrix ADC CPX innerhalb des Clusters oder als Citrix ADC MPX/VPX außerhalb des Clusters.

Bereitstellen von Citrix ADC CPX als Router innerhalb des OpenShift-Clusters

Der Citrix Ingress-Controller wird als Beiwagen neben dem Citrix ADC CPX-Container im selben Pod bereitgestellt. In diesem Modus konfiguriert der Citrix Ingress Controller den Citrix ADC CPX. Weitere Informationen finden Sie unter Bereitstellen von Citrix ADC CPX als Router innerhalb des OpenShift-Clusters.

Stellen Sie Citrix ADC MPX/VPX als Router außerhalb des OpenShift-Clusters bereit

Der Citrix Ingress Controller wird als eigenständiger Pod bereitgestellt und ermöglicht es Ihnen, die Citrix ADC MPX- oder VPX-Appliance von außerhalb des OpenShift-Clusters zu steuern. Weitere Informationen finden Sie unter Bereitstellen von Citrix ADC MPX/VPX als Router außerhalb des OpenShift-Clusters.

Ingress

KubernetesIngress bietet Ihnen die Möglichkeit, Anfragen basierend auf dem Anforderungshost oder -Pfad an Dienste weiterzuleiten und eine Reihe von Diensten in einem einzigen Einstiegspunkt zu zentralisieren.

Der Citrix Ingress Controller basiert auf Kubernetes Ingress und konfiguriert automatisch eine oder mehrere Citrix ADC-Appliances basierend auf der Ingress-Ressource.

Routing mit Ingress kann wie folgt durchgeführt werden:

  • Hostname basiertes Routing
  • Pfad basiertes Routing
  • Wildcard-basiertes Routing
  • Exakte Pfadübereinstimmung
  • Nicht-Hostnamen-Routing
  • Standard-Backend

Beispiele und weitere Informationen finden Sie unter Ingress-Konfigurationen .

Stellen Sie den Citrix Ingress Controller als OpenShift-Router-Plug-in bereit

Je nachdem, wie Sie Citrix ADC verwenden möchten, gibt es zwei Möglichkeiten, den Citrix Ingress Controller als Router-Plug-In im OpenShift-Cluster bereitzustellen:

Empfohlene Architekturen

Wir empfehlen Kunden beim Entwerfen ihrer Microservices-Architekturen die folgenden Architekturen:

  • Citrix Unified Ingress
  • Citrix 2-stufiges Ingress
  • Citrix Service Mesh Lite

Abbildung 1-2: Die Architektur reicht von relativ einfach bis komplexer und funktionsreicher.

Citrix Unified Ingress

In einer Unified Ingress-Bereitstellung leiten Citrix ADC MPX- oder VPX-Geräte Nord-Süd-Datenverkehr von den Clients zu den Anwendungen der Enterprise-Klasse, die als Microservices innerhalb des Clusters bereitgestellt werden. Der Citrix Ingress Controller wird als Pod oder Sidecar im Kubernetes-Cluster bereitgestellt, um die Konfiguration von Citrix ADC-Geräten (MPX oder VPX) basierend auf den Änderungen an den Microservices oder den Ingress-Ressourcen zu automatisieren.

Sie können mit der Implementierung des Unified Ingress-Modells beginnen, während Ihre Anwendung noch ein Monolith ist. Positionieren Sie den Citrix ADC einfach als Reverse-Proxy vor Ihrem Anwendungsserver und implementieren Sie die später beschriebenen Funktionen. Sie sind dann in einer guten Position, um Ihre Anwendung auf Microservices umzustellen.

Die Kommunikation zwischen den Microservices erfolgt über einen Mechanismus Ihrer Wahl (Kube-Proxy, IPVS usw.).

Einheitliches Ingress-Diagramm mit einem Citrix ADC VPX/MPX

Funktionen in verschiedenen Kategorien

Die Funktionen der Unified Ingress-Architektur lassen sich in drei Gruppen einteilen.

Die Funktionen der ersten Gruppe optimieren die Leistung:

  • Lastausgleich
  • Konnektivität mit niedriger Latenz
  • Hohe Verfügbarkeit

Die Funktionen in der zweiten Gruppe verbessern die Sicherheit und erleichtern das Anwendungsmanagement:

  • Ratenlimit
  • SSL/TLS-Terminierung
  • HTTP/2-Unterstützung
  • Integritätsprüfungen

Die Funktionen in der letzten Gruppe sind spezifisch für Microservices:

  • Zentraler Kommunikationspunkt für Dienste
  • API Gateway-Funktion

Zusammenfassung

Zu den Funktionen des Unified Ingress-Modells gehören ein robuster Lastausgleich für Dienste, ein zentraler Kommunikationspunkt, Dynamic Service Discovery, Konnektivität mit niedriger Latenz, Hochverfügbarkeit, Ratenbegrenzung, SSL/TLS-Terminierung, HTTP/2 und mehr.

Das Unified Ingress-Modell erleichtert die Verwaltung des Datenverkehrs, den Lastausgleich von Anforderungen und die dynamische Reaktion auf Änderungen in der Back-End-Microservices-Anwendung.

Zu den Vorteilen gehören:

  • Nord-Süd-Verkehrsflüsse sind gut skalierbar, für Beobachtung und Überwachung sichtbar und bieten kontinuierliche Bereitstellung mit Tools wie Spinnaker und Citrix ADM
  • Eine einzige Ebene vereint das Infrastrukturteam, das die Netzwerk- und Plattformdienste verwaltet, und reduziert Hops, um die Latenz zu verringern
  • Geeignet für interne Anwendungen, die keine Web App Firewall und SSL Offload benötigen, aber später hinzugefügt werden können

Zu den Nachteilen gehören:

  • Keine Ost-West-Sicherheit mit Kube-Proxy, kann aber Calico für L4-Segmentierung hinzufügen
  • Kube-Proxy-Skalierbarkeit ist unbekannt
  • Die Sichtbarkeit des Ost-West-Verkehrs ist auf keine oder nur begrenzt beschränkt, da kube-proxy keine Sichtbarkeit, Kontrolle oder Protokolle bietet, was die Integration offener Tools und die kontinuierliche Bereitstellung beeinträchtigt
  • Das Plattformteam muss auch netzwerkversiert sein

Citrix 2-stufiges Ingress

Das 2-Tier-Ingress-Architekturmodell ist eine großartige Lösung für Cloud Native Novices. In diesem Modell verwaltet der Citrix ADC in Tier 1 eingehenden Datenverkehr, sendet jedoch Anforderungen an den von Entwicklern verwalteten 2-Tier-ADC und nicht direkt an die Dienstinstanzen. Das Tier-2-Ingress-Modell wendet Richtlinien, die vom Plattform- und Entwicklerteam verfasst wurden, nur auf eingehenden Datenverkehr an und ermöglicht Cloud-Skalierung und Mandantenfähigkeit.

Abbildung 1-4: Diagramm des Citrix 2-Tier Ingress-Modells mit einem Tier-1 Citrix ADC VPX/MPX und Tier-2 Citrix ADC CPX-Containern.

Von Tier-1 bereitgestellte Funktionalität

Der ADC der ersten Stufe, der vom traditionellen Netzwerkteam verwaltet wird, bietet L4-Lastausgleich, Citrix Web App Firewall, SSL-Offload und Reverse-Proxy-Dienste. Die Citrix ADC MPX- oder VPX-Geräte in Tier-1 leiten den Datenverkehr (Nord-Süd) vom Client zu Citrix ADC CPXs in Tier-2.

Standardmäßig programmiert der Citrix Ingress Controller die folgenden Konfigurationen auf Tier-1:

  • Reverse-Proxy von Anwendungen für Benutzer:
  • Virtuelle Content Switching Server
  • Virtueller Server (Frontend, benutzerorientiert)
  • Service-Gruppen
  • SSL-Offload
  • NetScaler Protokollierung/Debugging
  • Gesundheitsüberwachung von Dienstleistungen

Von Tier-2 bereitgestellte Funktionalität

Während der ADC der ersten Stufe Reverse-Proxy-Dienste bereitstellt, dient der ADC der zweiten Stufe, der vom Plattformteam verwaltet wird, als Kommunikationspunkt für Microservices und bietet:

  • Dynamische Serviceerkennung
  • Lastausgleich
  • Sichtbarkeit und umfangreiche Metriken

Der Tier-2-Citrix ADC CPX leitet den Datenverkehr dann an die Microservices im Kubernetes-Cluster weiter. Der Citrix Ingress Controller, der als eigenständiger Pod bereitgestellt wird, konfiguriert die Tier-1-Geräte. Und der Sidecar-Controller in einem oder mehreren Citrix ADC CPX-Pods konfiguriert den zugehörigen Citrix ADC CPX im selben Pod.

Zusammenfassung

Die Netzwerkarchitektur für Microservices im 2-Tier-Modell verwendet zwei ADCs, die für verschiedene Rollen konfiguriert sind. Der Tier-1-ADC fungiert als benutzerorientierter Proxyserver und der Tier-2-ADC als Proxy für die Microservices.

Die Aufteilung verschiedener Funktionstypen auf zwei verschiedene Ebenen bietet Geschwindigkeit, Kontrolle und Optimierungsmöglichkeiten für die Sicherheit. In der zweiten Ebene ist der Lastausgleich schnell, robust und konfigurierbar.

Bei diesem Modell gibt es eine klare Trennung zwischen dem ADC-Administrator und dem Entwickler. Es ist BYOL für Entwickler.

Zu den Vorteilen gehören:

  • Nord-Süd-Verkehrsflüsse sind gut skalierbar, für Beobachtung und Überwachung sichtbar und bieten kontinuierliche Bereitstellung mit Tools wie Spinnaker und Citrix ADM
  • Einfachste und schnellere Bereitstellung für Cloud-Native-Neulinge mit begrenzten neuen Lernmöglichkeiten für Netzwerk- und Plattformteams

Zu den Nachteilen gehören:

  • Keine Ost-West-Sicherheit mit Kube-Proxy, kann aber Calico für L4-Segmentierung hinzufügen
  • Kube-Proxy-Skalierbarkeit ist unbekannt
  • Die Sichtbarkeit des Ost-West-Verkehrs ist nicht oder nur beschränkt vorhanden, da kube-proxy keine Sichtbarkeit, Kontrolle oder Protokolle bietet, was die Integration offener Tools und die kontinuierliche Bereitstellung beeinträchtigt.

Citrix Service Mesh Lite

Das Service Mesh Lite ist das funktionsreichste der drei Modelle. Es ist intern sicher, schnell, effizient und belastbar und kann verwendet werden, um Richtlinien für eingehenden und intercontainerübergreifenden Datenverkehr durchzusetzen.

Das Service Mesh Lite-Modell eignet sich für verschiedene Anwendungsfälle, darunter:

  • Gesundheits- und Finanz-Apps — Regulierungs- und Benutzeranforderungen erfordern eine Kombination aus Sicherheit und Geschwindigkeit für Finanz- und Gesundheits-Apps, wobei finanzielle und Reputationswerte in Milliardenhöhe auf dem Spiel stehen.
  • E-Commerce-Apps - Das Vertrauen der Benutzer ist ein großes Problem für den E-Commerce, und Geschwindigkeit ist ein wichtiges Unterscheidungsmerkmal im Wettbewerb. Daher ist die Kombination von Geschwindigkeit und Sicherheit von entscheidender Bedeutung.

Diagramm des Citrix Service Mesh Lite-Modells mit einem Tier-1 Citrix ADC VPX/MPX und Tier-2 Citrix ADC CPX-Container für den Ost-West-Proxy.

Zusammenfassung

Zu den Vorteilen gehören:

  • Ein robusterer Netzwerkansatz mit einem Load Balancer CPX wendet Richtlinien auf eingehenden und intercontainerübergreifenden Datenverkehr an und stellt vollständige L7-Richtlinien bereit
  • Umfassendere Beobachtbarkeit, Analytik, kontinuierliche Bereitstellung und Sicherheit für Nord-Süd- und Ost-West-Verkehr
  • Canary für jeden Container mit einem eingebetteten Citrix ADC
  • Eine einzige Ebene vereint das Infrastrukturteam, das die Netzwerk- und Plattformdienste verwaltet, und reduziert Hops, um die Latenz zu verringern

Zu den Nachteilen gehören:

  • Komplexeres Modell zur Bereitstellung
  • Plattformteam muss netzwerkversiert sein

Beschreibung von Architects Choices

Citrix Unified Ingress

  • Nord-Süd-Anwendungsdatenverkehr (NS) - Ein Citrix ADC ist für den L4- und L7-NS-Datenverkehr, die Sicherheit und den externen Lastausgleich außerhalb des K8s-Clusters verantwortlich.

  • Ost-West (EW) Application Traffic - kube-proxy ist für den L4 EW-Verkehr verantwortlich.

  • Sicherheit - Der ADC ist für die Sicherung des NS-Datenverkehrs und die Authentifizierung von Benutzern verantwortlich. KUBE-Proxy ist für den L4 EW-Verkehr verantwortlich.

  • Skalierbarkeit und Leistung - NS-Datenverkehr ist gut skalierbar, und Clustering ist eine Option.EW-Datenverkehr und Kube-Proxy-Skalierbarkeit sind unbekannt.

  • Beobachtbarkeit - Der ADC bietet eine hervorragende Beobachtbarkeit für NS-Verkehr, aber es gibt keine Beobachtbarkeit für EW-Verkehr.

Citrix 2-stufiges Ingress

  • Nord-Süd-Anwendungsdatenverkehr (NS) - Der Tier-1-ADC ist für SSL-Offload, Web App Firewall und L4 NS-Verkehr verantwortlich. Es wird sowohl für Monolith- als auch für CN-Anwendungen verwendet. Das Tier-2-CPX verwaltet schnelle Änderungen des k8s- und L7-NS-Datenverkehrs.

  • Ost-West (EW) Application Traffic - kube-proxy ist für den L4 EW-Verkehr verantwortlich.

  • Sicherheit - Der Tier-1-ADC ist für die Sicherung des NS-Datenverkehrs verantwortlich. Die Authentifizierung kann bei beiden ADC erfolgen. EW-Verkehr ist nicht mit Kube-Proxy.Add Calico für L4-Segmentierung gesichert.

  • Skalierbarkeit und Leistung - NS-Datenverkehr ist gut skalierbar, und Clustering ist eine Option.EW-Datenverkehr und Kube-Proxy-Skalierbarkeit sind unbekannt.

  • Beobachtbarkeit - Der Tier-1-ADC bietet eine hervorragende Beobachtbarkeit für NS-Verkehr, aber es gibt keine Beobachtbarkeit für EW-Verkehr.

Citrix Service Mesh Lite

  • Nord-Süd-Anwendungsdatenverkehr (NS) - Der Tier-1-ADC ist für SSL-Offload, Web App Firewall und L4 NS-Verkehr verantwortlich. Es wird sowohl für Monolith- als auch für CN-Anwendungen verwendet. Das Tier-2-CPX verwaltet schnelle Änderungen des k8s- und L7-NS-Datenverkehrs.

  • Ost-West (EW) -Anwendungsdatenverkehr - der Tier-2-CPX oder ein beliebiger Open-Source-Proxy ist für den L4 EW-Verkehr verantwortlich. Kunden können auswählen, welche Anwendungen den CPX und welche den Kube-Proxy verwenden.

  • Sicherheit - Der Tier-1-ADC ist für die Sicherung des NS-Datenverkehrs verantwortlich. Die Authentifizierung kann bei beiden ADC erfolgen. Das Citrix CPX ist für die Authentifizierung, SSL-Offload und die Sicherung des EW-Datenverkehrs verantwortlich. Die Verschlüsselung kann auf Anwendungsebene angewendet werden.

  • Skalierbarkeit und Leistung - NS- und EW-Datenverkehr ist gut skalierbar, fügt jedoch 1 Inline-Hop hinzu.

  • Beobachtbarkeit - Der Tier-1-ADC bietet eine hervorragende Beobachtbarkeit des NS-Verkehrs. Die CPX in Tier-2 bietet Beobachtbarkeit des EW-Datenverkehrs, kann jedoch deaktiviert werden, um den CPX-Speicher oder den CPU-Footprint zu reduzieren.

Wie man es bereitstellt

Citrix Unified Ingress

Verwenden Sie zum Validieren einer Citrix Unified Ingress-Bereitstellung mit OpenShift eine Beispielanwendung “hello-world” mit einem Citrix ADC VPX oder MPX. Der Standardnamespace für OpenShift, “default”, wird für diese Bereitstellung verwendet.

  1. Eine Citrix ADC Instanz wird von Hand erstellt und mit einem NSIP/SNIP konfiguriert. Die Installation von Citrix ADC auf XenServer finden Sie hier.

  2. Kopieren Sie das folgende YAML-Dateibeispiel in ein OpenShift-Verzeichnis und benennen Sie es application.yaml.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: hello-world
    spec:
      selector:
        matchLabels:
          run: load-balancer-example
      replicas: 2
      template:
        metadata:
          labels:
            run: load-balancer-example
        spec:
          containers:
            -  name: hello-world
              image: gcr.io/google-samples/node-hello:1.0
              ports:
                -  containerPort: 8080
                  protocol: TCP
    <!--NeedCopy-->
    
  3. Stellen Sie die Anwendung bereit. oc apply -f application.yaml

  4. Stelle sicher, dass die Pods laufen oc get pods

  5. Kopieren Sie das folgende YAML-Dateibeispiel in ein OpenShift-Verzeichnis und nennen Sie es service.yaml.

    apiVersion: v1
    kind: Service
    metadata:
      name: hello-world-service
    spec:
      type: NodePort
      ports:
      -  port: 80
        targetPort: 8080
      selector:
        run: load-balancer-example
    <!--NeedCopy-->
    
  6. Stellen Sie die Anwendung über NodePort mit einem Dienst bereit. oc apply -f service.yaml

  7. Stellen Sie sicher, dass der Dienst erstellt wurde. oc get service

  8. Kopieren Sie das folgende YAML-Dateibeispiel in ein OpenShift-Verzeichnis und nennen Sie es ingress.yaml.Sie müssen die Annotation “ingress.citrix.com/frontend-ip” in eine freie IP-Adresse ändern, um zum VIP auf dem Citrix ADC gemacht zu werden.

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: hello-world-ingress
      annotations:
       kubernetes.io/ingress.class: "vpx"
       ingress.citrix.com/insecure-termination: "redirect"
       ingress.citrix.com/frontend-ip: "10.217.101.183"
    spec:
      rules:
      -  host:  helloworld.com
        http:
          paths:
          -  path:
            backend:
              serviceName: hello-world-service
              servicePort: 80
    <!--NeedCopy-->
    
  9. Stellen Sie die Ingress-YAML-Datei bereit. oc apply -f ingress.yaml

  10. Jetzt gibt es Anwendungs-Pods, die wir mithilfe eines Dienstes verfügbar gemacht haben und die den Datenverkehr mithilfe von Ingress an sie weiterleiten können. Installieren Sie den Citrix Ingress Controller (CIC), um diese Konfigurationen auf unsere Tier 1 ADC VPX.Stellen Sie vor der Bereitstellung des CIC eine RBAC-Datei bereit, die dem CIC die richtigen Ausführungsberechtigungen erteilt.

    Hinweis:

    Die Datei rbac yaml gibt den Namespace an und muss geändert werden, bis welcher Namespace verwendet wird.

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    rules:
      -  apiGroups: [""]
        resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"]
        verbs: ["\*"]
      -  apiGroups: ["extensions"]
        resources: ["ingresses", "ingresses/status"]
        verbs: ["\*"]
      -  apiGroups: ["citrix.com"]
        resources: ["rewritepolicies"]
        verbs: ["\*"]
      -  apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["\*"]
    
    <!--NeedCopy-->
    
    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: default
    
    <!--NeedCopy-->
    
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: cpx
      namespace: default
    <!--NeedCopy-->
    
  11. Stellen Sie die RBAC-Datei bereit. oc apply -f rbac.yaml

  12. Bevor Sie das CIC bereitstellen, bearbeiten Sie die YAML-Datei. Fügen Sie unter Spezifikation entweder den NSIP oder den SNIP hinzu, solange die Verwaltung auf dem SNIP des Tier 1 ADC aktiviert ist. Beachten Sie, dass das Argument “ingress-classes” mit der in der Ingress-YAML-Datei angegebenen Ingress-Klassenanmerkung identisch ist.

    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-world-cic
      labels:
        app: hello-world-cic
    spec:
      serviceAccountName: cpx
      containers:
      -  name: hello-world-cic
        image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
        env:
         # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
         -  name: "NS_IP"
           value: "10.217.101.193"
         # Set username for Nitro
         # Set log level
         -  name: "NS_ENABLE_MONITORING"
           value: "NO"
         -  name: "NS_USER"
           value: "nsroot"
         -  name: "NS_PASSWORD"
           value: "nsroot"
         -  name: "EULA"
           value: "yes"
         -  name: "LOGLEVEL"
           value: "DEBUG"
        args:
          -  --ingress-classes
            vpx
          -  --feature-node-watch
            false
        imagePullPolicy: IfNotPresent
    <!--NeedCopy-->
    
  13. Stellen Sie CIC bereit. oc apply -f cic.yaml

  14. Überprüfen Sie, ob alle Pods ausgeführt werden oc get pods

  15. Bearbeiten Sie die Hosts-Datei auf Ihrem lokalen Computer mit einem Eintrag für helloworld.com und dem VIP auf dem Citrix ADC, der in der Ingress-YAML-Datei angegeben ist.

  16. Navigieren Sie in einem Browser zu helloworld.com. “Hallo Kubernetes! “sollte erscheinen.

Hinweis: Im Folgenden sind Löschbefehle aufgeführt

  • oc delete pods (pod name) -n (namespace name)
  • oc delete deployment (deployment name) -n (namespace name)
  • oc delete service (service name) -n (namespace name)
  • oc delete ingress (ingress name) -n (namespace name)
  • oc delete serviceaccounts (serviceaccounts name) -n (namespace name)

Citrix 2-stufiges Ingress

Verwenden Sie zum Validieren einer Citrix 2-Tier Ingress-Bereitstellung mit OpenShift eine Beispielanwendung “hello-world” mit einem Citrix ADC VPX oder MPX. Der Standard-Namespace “Tier-2-adc” wird für diese Bereitstellung verwendet.**Hinweis: Bei der Bereitstellung von Pods, Services und Ingress muss der Namespace mit dem Parameter “-n (Namespace-Name)” angegeben werden.

  1. Eine Citrix ADC Instanz wird von Hand erstellt und mit einem NSIP/SNIP konfiguriert.Die Installation von Citrix ADC auf XenServer finden Sie [hier. Wenn die Instanz bereits konfiguriert war, löschen Sie alle virtuellen Server im Load Balancing oder Content Switching, die an den ADC übertragen wurden, von der Bereitstellung von hello-world als Unified Ingress.

  2. Erstellen Sie einen Namespace namens “tier-2-adc”. oc create namespace tier-2-adc

  3. Kopieren Sie das folgende YAML-Dateibeispiel in ein OpenShift-Verzeichnis und benennen Sie es application-2t.yaml.

    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: hello-world
    spec:
      selector:
        matchLabels:
          run: load-balancer-example
      replicas: 2
      template:
        metadata:
          labels:
            run: load-balancer-example
        spec:
          containers:
            -  name: hello-world
              image: gcr.io/google-samples/node-hello:1.0
              ports:
                -  containerPort: 8080
                  protocol: TCP
    
    <!--NeedCopy-->
    
  4. Stellen Sie die Anwendung im Namespace bereit. oc apply -f application-2t.yaml -n tier-2-adc

  5. Stelle sicher, dass die Pods laufen oc get pods

  6. Kopieren Sie das folgende YAML-Dateibeispiel in ein OpenShift-Verzeichnis und benennen Sie es service-2t.yaml.

    
    apiVersion: v1
    kind: Service
    metadata:
      name: hello-world-service-2
    spec:
      type: NodePort
      ports:
    
      -port: 80
        targetPort: 8080
      selector:
        run: load-balancer-example
    
    <!--NeedCopy-->
    
  7. Stellen Sie die Anwendung über NodePort mit einem Dienst bereit. oc apply -f service-2t.yaml -n tier-2-adc

  8. Stellen Sie sicher, dass der Dienst erstellt wurde. oc get service -n tier-2-adc

  9. Kopieren Sie das folgende YAML-Dateibeispiel in ein OpenShift-Verzeichnis und benennen Sie es ingress-2t.yaml.

    
        apiVersion: extensions/v1beta1
        kind: Ingress
        metadata:
          name: hello-world-ingress-2
          annotations:
           kubernetes.io/ingress.class: "cpx"
        spec:
          backend:
            serviceName: hello-world-service-2
            servicePort: 80
    
    <!--NeedCopy-->
    
  10. Stellen Sie die Ingress-YAML-Datei bereit. oc apply -f ingress-2t.yaml -n tier-2-adc

  11. Stellen Sie eine RBAC-Datei bereit, die CIC und CPX die richtigen Berechtigungen zur Ausführung erteilt.

    Hinweis:

    Die Datei rbac yaml gibt den Namespace an und muss geändert werden, bis welcher Namespace verwendet wird.

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    rules:
      -apiGroups: [""]
        resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"]
        verbs: ["\*"]
      -apiGroups: ["extensions"]
        resources: ["ingresses", "ingresses/status"]
        verbs: ["\*"]
      -apiGroups: ["citrix.com"]
        resources: ["rewritepolicies"]
        verbs: ["\*"]
      -apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["\*"]
    ---
    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: tier-2-adc
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: cpx
      namespace: tier-2-adc
    <!--NeedCopy-->
    
  12. Stellen Sie die RBAC-Datei bereit. oc apply -f rbac-2t.yaml

  13. Das Dienstkonto benötigt erhöhte Berechtigungen, um eine CPX zu erstellen. oc adm policy add-scc-to-user privileged system:serviceaccount:tier-2-adc:cpx

  14. Bearbeiten Sie die CPX-YAML-Datei und rufen Sie sie auf cpx-2t.yaml. Dadurch werden die CPX und der Dienst, der sie verfügbar macht, bereitgestellt. Beachten Sie, dass das Argument für Ingress Class mit der Anmerkung in der Datei ingress-2t.yaml übereinstimmt.

        apiVersion: extensions/v1beta1
        kind: Deployment
        metadata:
          name: hello-world-cpx-2
        spec:
          replicas: 1
          template:
            metadata:
              name: hello-world-cpx-2
              labels:
                app: hello-world-cpx-2
                app1: exporter
              annotations:
                NETSCALER_AS_APP: "True"
            spec:
              serviceAccountName: cpx
              containers:
                -  name: hello-world-cpx-2
                  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: ""
                  imagePullPolicy: Always
            # Add cic as a sidecar
                -  name: cic
                  image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
                  env:
                  -  name: "EULA"
                    value: "yes"
                  -  name: "NS_IP"
                    value: "127.0.0.1"
                  -  name: "NS_PROTOCOL"
                    value: "HTTP"
                  -  name: "NS_PORT"
                    value: "80"
                  -  name: "NS_DEPLOYMENT_MODE"
                    value: "SIDECAR"
                  -  name: "NS_ENABLE_MONITORING"
                    value: "YES"
                  -  name: POD_NAME
                    valueFrom:
                      fieldRef:
                        apiVersion: v1
                        fieldPath: metadata.name
                  -  name: POD_NAMESPACE
                    valueFrom:
                      fieldRef:
                        apiVersion: v1
                        fieldPath: metadata.namespace
                  args:
                    -  --ingress-classes
                      cpx
                  imagePullPolicy: Always
            apiVersion: v1
            kind: Service
            metadata:
              name: lb-service-cpx
              labels:
                app: lb-service-cpx
            spec:
              type: NodePort
              ports:
              -  port: 80
                protocol: TCP
                name: http
                targetPort: 80
              selector:
                app: hello-world-cpx-2
    
    <!--NeedCopy-->
    
  15. Stellen Sie das CPX bereit. oc apply -f cpx-2t.yaml -n tier-2-adc

  16. Stellen Sie sicher, dass der Pod ausgeführt wird und der Dienst erstellt wurde. oc get pods -n tier-2-adc oc get service -n tier-2-adc

  17. Erstellen Sie einen Ingress, um vom VPX zum CPX zu leiten. Die Front-End-IP sollte eine freie IP auf dem ADC sein. Geben Sie der Datei einen Namen: ingress-cpx-2t.yaml.

    
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: hello-world-ingress-vpx-2
      annotations:
       kubernetes.io/ingress.class: "helloworld"
       ingress.citrix.com/insecure-termination: "redirect"
       ingress.citrix.com/frontend-ip: "10.217.101.183"
    spec:
      rules:
        -  host:  helloworld.com
    
        http:
          paths:
          -  path:
            backend:
              serviceName: lb-service-cpx
              servicePort: 80
    <!--NeedCopy-->
    
  18. Stellen Sie den Ingress bereit. oc apply -f ingress-cpx-2t.yaml -n tier-2-adc

  19. Bevor Sie das CIC bereitstellen, bearbeiten Sie die YAML-Datei. Fügen Sie unter Spezifikation entweder den NSIP oder den SNIP hinzu, solange die Verwaltung auf dem SNIP des Tier 1 ADC aktiviert ist.

    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-world-cic
      labels:
        app: hello-world-cic
    spec:
          serviceAccountName: cpx
          containers:
          -  name: hello-world-cic
            image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
            env:
             # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
             -  name: "NS_IP"
           value: "10.217.101.176"
         # Set username for Nitro
         # Set log level
         -  name: "NS_ENABLE_MONITORING"
           value: "NO"
         -  name: "NS_USER"
           value: "nsroot"
         -  name: "NS_PASSWORD"
           value: "nsroot"
         -  name: "EULA"
           value: "yes"
         -  name: "LOGLEVEL"
           value: "DEBUG"
        args:
          -  --ingress-classes
            helloworld
          -  --feature-node-watch
            false
        imagePullPolicy: IfNotPresent
    <!--NeedCopy-->
    
  20. Stellen Sie CIC bereit. oc apply -f cic-2t.yaml -n tier-2-adc

  21. Überprüfen Sie, ob alle Pods ausgeführt werden oc get pods -n tier-2-adc

  22. Bearbeiten Sie die Hosts-Datei auf Ihrem lokalen Computer mit einem Eintrag für helloworld.com und dem VIP auf dem Citrix ADC, der in der Ingress-YAML-Datei angegeben ist, die vom VPX zum CPX weiterleitet.

  23. Navigieren Sie in einem Browser zu helloworld.com. “Hallo Kubernetes! “sollte erscheinen.

Citrix Service Mesh Lite

Service Mesh Lite ermöglicht die Einführung von CPX (oder anderen Citrix ADC-Appliances) als Ersatz für die integrierten HAProxy-Funktionalitäten. Auf diese Weise können wir unsere N/S-Funktionen in Kubernetes erweitern und auch Lastausgleich, Routing und Beobachtbarkeit des E/W-Datenverkehrs bereitstellen. Citrix ADC (MPX, VPX oder CPX) kann folgende Vorteile für den E-W-Verkehr bieten, z. B.:

  • Gegenseitiges TLS- oder SSL-Offload
  • Inhaltsbasiertes Routing, um Datenverkehr basierend auf HTTP- oder HTTPS-Header-Parametern zuzulassen
  • Fortschrittliche Load Balancing-Algorithmen (z. B. geringste Verbindungen, geringste Reaktionszeit usw.)
  • Beobachtbarkeit des Ost-West-Verkehrs durch Messung goldener Signale (Fehler, Latenzen, Sättigung oder Verkehrsaufkommen) .Der Service Graph von Citrix ADM ist eine Beobachtbarkeitslösung zum Überwachen und Debuggen von Microservices.
  • In diesem Bereitstellungsszenario stellen wir die Bookinfo-Anwendung bereit und beobachten, wie sie standardmäßig funktioniert. Anschließend rippen und ersetzen wir die Standard-Kubernetes-Dienste und verwenden CPX und VPX als Proxy für unseren E/W-Datenverkehr.

Citrix Service Mesh Lite mit einem CPX

Verwenden Sie zum Validieren einer Citrix Unified Ingress-Bereitstellung mit OpenShift eine Beispielanwendung “hello-world” mit einem Citrix ADC VPX oder MPX. Der Standardnamespace für OpenShift, “default”, wird für diese Bereitstellung verwendet.

  1. Eine Citrix ADC Instanz wird von Hand erstellt und mit einem NSIP/SNIP konfiguriert. Die Installation von Citrix ADC auf XenServer finden Sie hier.

  2. Erstellen Sie einen Namespace für diese Bereitstellung. In diesem Beispiel wird sml verwendet. oc create namespace sml

  3. Kopieren Sie die folgende YAML, um die Bereitstellung und Dienste für Bookinfo zu erstellen. Nennen Sie es 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:
       -  name: details
         image: docker.io/maistra/examples-bookinfo-details-v1:0.12.0
         imagePullPolicy: IfNotPresent
         ports:
         -  containerPort: 9080
 ---
 ##################################################################################################
 # Ratings service
 ##################################################################################################
 apiVersion: v1
 kind: Service
 metadata:
   name: ratings
   labels:
     app: ratings
     service: ratings
 spec:
   ports:
   -  port: 9080
     name: http
   selector:
     app: ratings
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
   name: ratings-v1
   labels:
     app: ratings
     version: v1
 spec:
   replicas: 1
   template:
     metadata:
       annotations:
         sidecar.istio.io/inject: "false"
       labels:
         app: ratings
         version: v1
     spec:
       containers:
       -  name: ratings
         image: docker.io/maistra/examples-bookinfo-ratings-v1:0.12.0
         imagePullPolicy: IfNotPresent
         ports:
         -  containerPort: 9080
 ---
 ##################################################################################################
 # Reviews service
 ##################################################################################################
 apiVersion: v1
 kind: Service
 metadata:
   name: reviews
   labels:
     app: reviews
     service: reviews
 spec:
   ports:
   -  port: 9080
     name: http
   selector:
     app: reviews
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
   name: reviews-v1
   labels:
     app: reviews
     version: v1
 spec:
   replicas: 1
   template:
     metadata:
       annotations:
         sidecar.istio.io/inject: "false"
       labels:
         app: reviews
         version: v1
     spec:
       containers:
       -  name: reviews
         image: docker.io/maistra/examples-bookinfo-reviews-v1:0.12.0
         imagePullPolicy: IfNotPresent
         ports:
         -  containerPort: 9080
 ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: reviews-v2
      labels:
        app: reviews
        version: v2
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: reviews
            version: v2
        spec:
          containers:
          -  name: reviews
            image: docker.io/maistra/examples-bookinfo-reviews-v2:0.12.0
            imagePullPolicy: IfNotPresent
            ports:
            -  containerPort: 9080
 ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: reviews-v3
      labels:
        app: reviews
        version: v3
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: reviews
            version: v3
        spec:
          containers:
          -  name: reviews
            image: docker.io/maistra/examples-bookinfo-reviews-v3:0.12.0
            imagePullPolicy: IfNotPresent
            ports:
            -  containerPort: 9080
    ---
    ##################################################################################################
    # Productpage services
    ##################################################################################################
    apiVersion: v1
    kind: Service
    metadata:
      name: productpage-service
    spec:
      type: NodePort
      ports:
      -  port: 80
        targetPort: 9080
      selector:
        app: productpage
    ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: productpage-v1
      labels:
        app: productpage
        version: v1
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: productpage
            version: v1
        spec:
          containers:
          -  name: productpage
            image: docker.io/maistra/examples-bookinfo-productpage-v1:0.12.0
            imagePullPolicy: IfNotPresent
            ports:
            -  containerPort: 9080
    ---
<!--NeedCopy-->
  1. Stellen Sie die Datei bookinfo.yaml im SML-Namespace bereit. oc apply -f bookinfo.yaml -n sml

  2. Kopieren Sie die Eingangsdatei, die dem Produktseitenservice zugeordnet ist, und stellen Sie sie bereit. Diese Datei kann benannt werden ingress-productpage.yaml. Die Front-End-IP sollte eine kostenlose VIP auf dem Citrix ADC VPX/MPX sein.

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: productpage-ingress
      annotations:
       kubernetes.io/ingress.class: "bookinfo"
       ingress.citrix.com/insecure-termination: "redirect"
       ingress.citrix.com/frontend-ip: "10.217.101.182"
    spec:
      rules:
      -  host: bookinfo.com
        http:
          paths:
          -  path:
            backend:
              serviceName: productpage-service
              servicePort: 80
    <!--NeedCopy-->
    

oc apply -f ingress-productpage.yaml -n sml

  1. Kopieren Sie die folgende YAML für die RBAC-Datei in den SML-Namespace und stellen Sie sie bereit. Benennen Sie die Datei rbac-cic-pp.yaml so, wie sie für das CIC verwendet wird, vor der Produktseite microservice.

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    rules:
      -  apiGroups: [""]
        resources: ["services", "endpoints", "ingresses", "pods", "secrets", "routes", "routes/status", "nodes", "namespaces"]
        verbs: ["\*"]
      -  apiGroups: ["extensions"]
        resources: ["ingresses", "ingresses/status"]
        verbs: ["\*"]
      -  apiGroups: ["citrix.com"]
        resources: ["rewritepolicies", "vips"]
        verbs: ["\*"]
      -  apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["\*"]
      -  apiGroups: ["apiextensions.k8s.io"]
        resources: ["customresourcedefinitions"]
        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: rbac.authorization.k8s.io/v1
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: cpx
      namespace: sml
    <!--NeedCopy-->
    

oc apply -f rbac-cic-pp.yaml -n sml

  1. Erhöhen Sie die Dienstkontoberechtigungen für die Bereitstellung von CIC und CPX. oc adm policy add-scc-to-user privileged system:serviceaccount:sml:cpx

  2. Bearbeiten Sie die Hosts-Datei auf dem lokalen Computer, wobei bookinfo.com der in angegebenen Front-End-IP zugeordnet ist ingress-productpage.yaml.

  3. Kopieren Sie die Produktseite und stellen Sie sie mit einem CIC bereit. Nennen Sie cic-productpage.yamldie Datei. Die NS_IP sollte die NS_IP des Tier 1 ADC sein.

    apiVersion: v1
    kind: Pod
    metadata:
      name: productpage-cic
      labels:
        app: productpage-cic
    spec:
          serviceAccountName: cpx
          containers:
          -  name: productpage-cic
            image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
            env:
             # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
             -  name: "NS_IP"
               value: "10.217.101.176"
             # Set username for Nitro
             # Set log level
             -  name: "NS_ENABLE_MONITORING"
               value: "NO"
             -  name: "NS_USER"
               value: "nsroot"
             -  name: "NS_PASSWORD"
               value: "nsroot"
             -  name: "EULA"
               value: "yes"
             -  name: "LOGLEVEL"
               value: "DEBUG"
             -  name: "NS_APPS_NAME_PREFIX"
               value: "BI-"
            args:
              -  --ingress-classes
                bookinfo
              -  --feature-node-watch
                false
            imagePullPolicy: IfNotPresent
    <!--NeedCopy-->
    

oc apply -f cic-productpage.yaml -n sml

  1. Navigieren Sie zu bookinfo.com und klicken Sie auf Normaler Benutzer. Auf der Produktseite sollten Details, Bewertungen und Bewertungen abgerufen werden, bei denen es sich um andere Microservices handelt. HAProxy ist verantwortlich für die Weiterleitung des Datenverkehrs zwischen Microservices (Ost-West).

  2. Löschen Sie den Dienst vor den Details. Aktualisieren Sie die Bookinfo-Webseite und stellen Sie fest, dass die Produktseite den Microservice nicht für Details aufrufen konnte. oc delete service details -n sml

  3. Kopieren Sie einen Headless-Service und stellen Sie ihn bereit, sodass der Datenverkehr von der Produktseite zu den Details über eine CPX geleitet wird. Nennen Sie diese Datei detailsheadless.yaml.

    apiVersion: v1
    kind: Service
    metadata:
      name: details
    spec:
      ports:
      -  port: 9080
        name: http
      selector:
        app: cpx
    <!--NeedCopy-->
    

oc apply -f detailsheadless.yaml -n sml

  1. Kopieren Sie einen neuen Details-Dienst, der den Namen detailsservice.yaml haben sollte, und stellen Sie ihn bereit, um vor dem Details-Microservice zu sitzen.

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

oc apply -f detailsservice.yaml -n sml

  1. Stellen Sie den Details-Service mit einem Eintrag bereit und stellen Sie ihn bereit. Nennen Sie diese Datei detailsingress.yaml.

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: details-ingress
      annotations:
       kubernetes.io/ingress.class: "cpx"
       ingress.citrix.com/insecure-port: "9080"
    spec:
      rules:
      -  host: details
        http:
          paths:
          -  path:
            backend:
              serviceName: details-service
              servicePort: 9080
    <!--NeedCopy-->
    

oc apply -f detailsingress.yaml -n sml

  1. Kopieren Sie die Datei CPXEastWest.yaml und stellen Sie sie bereit.

    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: reviews-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
              imagePullPolicy: Always
            # Add cic as a sidecar
            -  name: cic
              image: "quay.io/citrix/citrix-k8s-ingress-controller:1.2.0"
              env:
              -  name: "EULA"
                value: "yes"
              -  name: "NS_IP"
                value: "127.0.0.1"
              -  name: "NS_PROTOCOL"
                value: "HTTP"
              -  name: "NS_PORT"
                value: "80"
              -  name: "NS_DEPLOYMENT_MODE"
                value: "SIDECAR"
              -  name: "NS_ENABLE_MONITORING"
                value: "YES"
              -  name: POD_NAME
                valueFrom:
                  fieldRef:
                    apiVersion: v1
                    fieldPath: metadata.name
              -  name: POD_NAMESPACE
                valueFrom:
                  fieldRef:
                    apiVersion: v1
                    fieldPath: metadata.namespace
              args:
                -  --ingress-classes
                  cpx
              imagePullPolicy: Always
    <!--NeedCopy-->
    

oc apply -f CPXEastWest.yaml -n sml

  1. Aktualisieren Sie bookinfo.com und die Details sollten aus dem Detail-Microservice abgerufen werden. Ein CPX wurde erfolgreich bereitgestellt, um als Proxy für den EW-Datenverkehr zu dienen.

Citrix Service Mesh Lite mit einem VPX/MPX

  1. Führen Sie die folgenden Befehle aus, um die als EW-Proxy verwendete CPX zu löschen. Eine neue Datei wird bereitgestellt, um den VPX als EW-Proxy zwischen der Produktseite und den Detail-Microservices zu konfigurieren. oc delete -f detailsheadless.yaml -n sml oc delete -f detailsservice.yaml -n sml oc delete -f detailsingress.yaml -n sml oc delete -f CPXEastWest.yaml -n sml

  2. Kopieren und implementieren Sie einen Dienst, nennen Sie die Datei detailstoVPX.yaml, um den Datenverkehr von der Produktseite zurück an die VPX zu senden. Der IP-Parameter sollte eine kostenlose VIP auf dem Citrix ADC VPX/MPX sein.

    ---
    kind: "Service"
    apiVersion: "v1"
    metadata:
      name: "details"
    spec:
      ports:
        -
          name: "details"
          protocol: "TCP"
          port: 9080
    ---
    kind: "Endpoints"
    apiVersion: "v1"
    metadata:
      name: "details"
    subsets:
      -
        addresses:
          -
            ip: "10.217.101.182" # Ingress IP in MPX
        ports:
          -
            port: 9080
            name: "details"
    <!--NeedCopy-->
    

oc apply -f detailstoVPX.yaml -n sml

  1. Stellen Sie detailsservice.yaml erneut vor dem Details-Microservice bereit. oc apply -f detailsservice.yaml -n sml

  2. Kopieren Sie den Ingress und stellen Sie ihn bereit, um den Detail-Microservice für die VPX bereitzustellen. Der Name ist detailsVPXingress.yaml. Die Frontend-IP sollte mit der VIP auf dem Tier 1 ADC übereinstimmen.

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: details-ingress
      annotations:
       kubernetes.io/ingress.class: "vpx"
       ingress.citrix.com/insecure-port: "9080"
       ingress.citrix.com/frontend-ip: "10.217.101.182"
    spec:
      rules:
      -  host: details
        http:
          paths:
          -  path:
            backend:
              serviceName: details-service
              servicePort: 9080
    <!--NeedCopy-->
    

oc apply -f detailsVPXingress.yaml

  1. Aktualisieren Sie bookinfo.com und die Details sollten aus dem Details-Microservice abgerufen werden. Ein VPX wurde erfolgreich für den Proxy-EW-Datenverkehr bereitgestellt.

Service-Migration zu Citrix ADC mithilfe von Routes oder Ingress-Klassen in Openshift

Servicemigration mit Route Sharding

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 bis hin 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 nach Plug-In (Pod)
  • CPX Router in Openshift (Sidecar)

Beide Methoden werden unten zusammen mit Migrationsbeispielen beschrieben.

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 zu Citrix CNC, 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 stören.

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

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.

Bereitstellungsbeispiel #1: CIC wird als OpenShift-Router-Plug-In bereitgestellt

Für Routes verwenden wir Route-Sharding-Konzepte. Hier fungiert der CIC als Router und leitet den Datenverkehr an verschiedene Pods um, um den eingehenden Verkehr auf verschiedene verfügbare Pods zu verteilen. Das CIC wird als Router-Plug-in für Citrix ADC MPX oder VPX installiert und außerhalb des Clusters bereitgestellt.

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.

Beispiel für YAML-Dateiparameter für Routen-Shards:

Citrix Openshift-Quelldateien befinden sich hier in Github

  1. Fügen Sie die folgenden Umgebungsvariablen, ROUTE_LABELS und NAMESPACE_LABELS, mit dem Wert im Kubernetes-Labelformat hinzu. Die Route-Sharding-Ausdrücke in CIC, NAMESPACE_LABELS, sind ein optionales Feld. Falls verwendet, muss es mit den Namespace-Bezeichnungen übereinstimmen, die in der Datei route.yaml erwähnt werden.

    env:
     - name: "ROUTE_LABELS"
       value: "name=apache-web"
     - name: "NAMESPACE_LABELS"
       value: "app=hellogalaxy"
    
  2. Die Routen, die über route.yaml erstellt werden, haben Beschriftungen, die den Routen-Sharding-Ausdrücken im CIC entsprechen, werden konfiguriert.

    metadata:
        name: apache-route
        namespace: hellogalaxy
        labels:
            name: apache-web
    
  3. Stellen Sie den Dienst mit service.yaml bereit.

    metadata:
        name: apache-service
    spec:
    type: NodePort
    #type=LoadBalancer
    ports:
        - port: 80
    targetPort: 80
    selector:
        app: apache
    
  4. Stellen Sie eine einfache Webanwendung mit einem Selektor-Label bereit, das der in service.yaml entspricht.

Bereitstellungsbeispiel #2: Citrix ADC CPX wird als OpenShift-Router bereitgestellt

Citrix ADC CPX kann zusammen mit dem Citrix Ingress Controller im Cluster als OpenShift-Router bereitgestellt werden. Weitere Schritte zur Bereitstellung eines CPX oder CIC als Router im Cluster finden Sie unter Aktivieren der OpenShift-Routing-Sharding-Unterstützung mit Citrix ADC.

Citrix-Komponenten:

  • VPX - Der Ingress-ADC, der die Cluster-Dienste für DNS präsentiert.
  • CIC - stellt dem externen Citrix ADC die ROUTE_LABELS und NAMESPACE_LABELS zur Verfügung, um die Route-Shards zu definieren.
  • CNC — bietet die automatische Routenkonfiguration für Shards an den externen Load Balancer.
  • CPX — bietet Openshift-Routing innerhalb des Openshift-Clusters.

Anmerkung zur Servicemigration mit Ingress-Klassen

Ingress Classes Annotations verwendet das Annotationskonzept für Ingressklassen. Wir fügen Ingress Anmerkungen mit Ingress-Klasseninformationen hinzu. Dies hilft dabei, den Datenverkehr vom externen ADC zu einem bestimmten Pod/Knoten umzuleiten.

Beispiel für YAML-Dateiparameter für Eingangsklassen:**

Citrix Ingress-Quelldateien befinden sich hier in Github

env:
    args:
      - --ingress-classes
        vpx

Die Ingress-Konfigurationsdatei sollte auch ein kubernetes.io/ingress.class-Annotationsfeld innerhalb von Metadaten enthalten, das zum Zeitpunkt der Erstellung mit dem CIC-Args-Feld ingress-classes abgeglichen wird.

Beispiel für eine Ingress VPX-Bereitstellung mit dem Beispiel “ingress.classes”**

    kind: Ingress
        metadata:
            name: ingress-vpx
            annotations:
                kubernetes.io/ingress.class: "vpx"

Citrix Metrics Exporter

Sie können den Citrix ADC Metrik-Exporteur und Prometheus Operator verwenden, um Citrix ADC VPX- oder CPX-Eingangsgeräte und Citrix ADC CPX-Geräte (Ost-West) zu überwachen. Weitere Informationen finden Sie unter Anzeigen von Metriken von Citrix ADCs mit Prometheus und Grafana.

Citrix Cloud Native Networking für Red Hat OpenShift 3.11 validiertes Referenzdesign