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
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.
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:
- Als Beiwagen-Container neben Citrix ADC CPX im selben Pod: 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.
- Als eigenständiger Pod im OpenShift-Cluster: In diesem Modus können Sie die Citrix ADC MPX- oder VPX-Appliance steuern, die außerhalb des Clusters bereitgestellt wird. Weitere Informationen finden Sie unter Bereitstellen von Citrix ADC MPX/VPX als Router außerhalb des OpenShift-Clusters.
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.).
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.
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.
-
Eine Citrix ADC Instanz wird von Hand erstellt und mit einem NSIP/SNIP konfiguriert. Die Installation von Citrix ADC auf XenServer finden Sie hier.
-
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--> -
Stellen Sie die Anwendung bereit.
oc apply -f application.yaml -
Stelle sicher, dass die Pods laufen
oc get pods -
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--> -
Stellen Sie die Anwendung über NodePort mit einem Dienst bereit.
oc apply -f service.yaml -
Stellen Sie sicher, dass der Dienst erstellt wurde.
oc get service -
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--> -
Stellen Sie die Ingress-YAML-Datei bereit.
oc apply -f ingress.yaml -
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--> -
Stellen Sie die RBAC-Datei bereit.
oc apply -f rbac.yaml -
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--> -
Stellen Sie CIC bereit.
oc apply -f cic.yaml -
Überprüfen Sie, ob alle Pods ausgeführt werden
oc get pods -
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.
-
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.
-
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.
-
Erstellen Sie einen Namespace namens “tier-2-adc”.
oc create namespace tier-2-adc -
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--> -
Stellen Sie die Anwendung im Namespace bereit.
oc apply -f application-2t.yaml -n tier-2-adc -
Stelle sicher, dass die Pods laufen
oc get pods -
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--> -
Stellen Sie die Anwendung über NodePort mit einem Dienst bereit.
oc apply -f service-2t.yaml -n tier-2-adc -
Stellen Sie sicher, dass der Dienst erstellt wurde.
oc get service -n tier-2-adc -
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--> -
Stellen Sie die Ingress-YAML-Datei bereit.
oc apply -f ingress-2t.yaml -n tier-2-adc -
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--> -
Stellen Sie die RBAC-Datei bereit.
oc apply -f rbac-2t.yaml -
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 -
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 Dateiingress-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--> -
Stellen Sie das CPX bereit.
oc apply -f cpx-2t.yaml -n tier-2-adc -
Stellen Sie sicher, dass der Pod ausgeführt wird und der Dienst erstellt wurde.
oc get pods -n tier-2-adcoc get service -n tier-2-adc -
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--> -
Stellen Sie den Ingress bereit.
oc apply -f ingress-cpx-2t.yaml -n tier-2-adc -
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--> -
Stellen Sie CIC bereit.
oc apply -f cic-2t.yaml -n tier-2-adc -
Überprüfen Sie, ob alle Pods ausgeführt werden
oc get pods -n tier-2-adc -
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.
-
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.
-
Eine Citrix ADC Instanz wird von Hand erstellt und mit einem NSIP/SNIP konfiguriert. Die Installation von Citrix ADC auf XenServer finden Sie hier.
-
Erstellen Sie einen Namespace für diese Bereitstellung. In diesem Beispiel wird
smlverwendet.oc create namespace sml -
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-->
-
Stellen Sie die Datei bookinfo.yaml im SML-Namespace bereit.
oc apply -f bookinfo.yaml -n sml -
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
-
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.yamlso, 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
-
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 -
Bearbeiten Sie die Hosts-Datei auf dem lokalen Computer, wobei bookinfo.com der in angegebenen Front-End-IP zugeordnet ist
ingress-productpage.yaml. -
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
-
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).
-
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 -
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
-
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
-
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
-
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
- 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
-
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 smloc delete -f detailsservice.yaml -n smloc delete -f detailsingress.yaml -n smloc delete -f CPXEastWest.yaml -n sml -
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
-
Stellen Sie detailsservice.yaml erneut vor dem Details-Microservice bereit.
oc apply -f detailsservice.yaml -n sml -
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
- 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
-
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" -
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 -
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 -
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.
In diesem Artikel
- Warum Citrix für moderne Anwendungsbereitstellung
- Eine Lösung für alle Stakeholder
- Der Citrix Software Stack erklärt
- Der Citrix ADC Wert
- Die Vorteile von Citrix ADC
- Der Vorteil der Citrix ADC Suite
- Partner-Ökosystem
-
OpenShift Überblick
- OpenShift-Projekte
- OpenShift-Namespaces
- OpenShift Software Defined Networking (SDN)
- OpenShift Routing und Plug-Ins
- OpenShift Routen und Ingress Methoden
- 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
- Stellen Sie den Citrix Ingress Controller als OpenShift-Router-Plug-in bereit
- Empfohlene Architekturen
- Wie man es bereitstellt
- Service-Migration zu Citrix ADC mithilfe von Routes oder Ingress-Klassen in Openshift
- Citrix Metrics Exporter