VRD-Anwendungsfall — Verwenden von Citrix ADC Dynamic Routing mit Kubernetes

Acme Inc. Route Health Injection und BGP-Integration für Kubernetes-Anwendungen

Acme Inc. ist ein langjähriger Citrix-Kunde mit einer großen Citrix ADC Präsenz. Citrix ADC dient als Hauptlösung für den Lastausgleich und die Geschäftskontinuität für kritische Kubernetes-Anwendungen. Acme Inc. verfügt derzeit über drei Hauptrechenzentren.

Acme Inc. möchte Redundanz und Hochverfügbarkeit für kritische Kubernetes-Anwendungen bieten, damit sie eine größere Fehlertoleranz zwischen allen Bereitstellungs-Racks in den drei Rechenzentren bieten können.

Durch die Verwendung von Route Health Injection auf dem Citrix ADC bietet die Lösung Redundanz für Kubernetes-Dienste, auf die über die vorhandene BGP+ECMP-Routing-Fabric zugegriffen wird.

Zusätzlich zur Route Health Injection benötigen viele Kubernetes-Anwendungen den Backend-Server, um die echte Client-IP zu empfangen. Herkömmlicher Lastausgleich mit Citrix ADC-Quellpaketen, die für Back-End-Server von der ADC-Subnetz-IP-Adresse bestimmt sind. Für Anwendungen, die die echte Client-IP-Adresse als Quelladresse benötigen, bietet Citrix ADC mehrere Methoden. Zu diesen Methoden gehören USIP (Quell-IP-Modus verwenden) und DSR (Direct Server Return).

Die IT-Bestimmungen von Acme Inc. testen Citrix ADC VPX-Instanzen mit Test-VIPs für die Kubernetes-Anwendungen. Diese Testumgebung wird verwendet, um die Route Health Injection-Lösung mit Client-IP zu erstellen und sie vollständig zu testen, bevor sie in die Produktionsumgebung eingeführt wird.

Anforderungen an die Bereitstellung

Acme Inc. und Citrix identifizierten verschiedene Anforderungen:

• Citrix ADC VPX-Einheiten in jedem Rechenzentrum mit Konnektivität zum dynamischen Routing-Netzwerk (3)
• IP-Adressen für bis zu drei virtuelle Server, die als /32 Routen im dynamischen Routing von Acme Inc. konfiguriert werden

Umgebung:

Kubernetes testet VIP

• Die SNIP-Adresse in jedem Rechenzentrum, die als nächster Hop für die Route Health Injection-VIP auf jeder Citrix ADC-Einheit verwendet werden soll, muss über eine eigene SNIP-Adresse mit aktiviertem dynamischen Routing verfügen. Dies ist das Gateway für die angekündigte Route Health Injection-VIP

Identifizieren Sie Kubernetes-Informationen, darunter:

• Backend-Kubernetes Pods und Test-VIPs
• Erforderliche Ports und Load Balancing Parameter
• SSL-Zertifikate (falls zutreffend)

Client-IP-Konfiguration

• Backend-Server müssen echte Client-IP-Adresse erhalten
• Im Abschnitt IP-Optionen des Clients werden mehrere verfügbare Optionen beschrieben.

Route Health Injection (RHI)

Citrix ADC Dynamic Routing mit Route Health Injection

Der Hauptzweck von dynamischem Routing und Route Health Injection in Citrix ADC besteht darin, den Status oder die Integrität von VIPs an die Upstream-Router zu kommunizieren. Der Status eines VIP hängt von den virtuellen Servern ab, die mit ihm verknüpft sind, und von den Diensten, die an diese VIP gebunden sind. Die Ankündigung eines VIP durch Route Health Injection ist an die Zustände der virtuellen Server gebunden, die der virtuellen IP-Adresse zugeordnet sind.

Für die virtuelle IP-Adresse muss Werbung aktiviert sein. Dies wird erreicht, indem Sie die Option -hostroute auf enabled für die virtuelle IP-Adresse setzen. In der Standardeinstellung ist die Option -hostroute auf disabled eingestellt. Die Option -hostroute kann aktiviert werden, wenn Sie eine IP-Adresse mit dem Befehl add ns ip hinzufügen, oder indem Sie eine vorhandene IP-Adresse mit dem Befehl set ns ip ändern.

Überwachung der Injection-Route

Nachdem die Option hostRoute aktiviert wurde, fügt der NetScaler-Kernel die Hostroute in ZebOS NSM (Network Services Module) ein, basierend auf dem Status der virtuellen Server, die der virtuellen IP-Adresse zugeordnet sind. Der Switch - vserverroute health injectionLevel steuert die Beziehung zwischen dem Status virtueller Server und der virtuellen IP-Hostroute, die an das Network Services Module (NSM) gesendet wird.

Die drei verfügbaren Optionen für die Route Health Injection des virtuellen Servers:

• ALL_VSERVERS — Eine Hostroute wird nur in NSM eingefügt, wenn alle virtuellen Server, die der virtuellen IP zugeordnet sind, UP sind.
• ONE_VSERVER — Eine Hostroute wird nur in NSM eingefügt, wenn einer der virtuellen IP zugeordneten virtuellen Server UP ist.
• NONE — Eine Hostroute wird dem NSM unabhängig vom Status der virtuellen Server, die der virtuellen IP zugeordnet sind, eingefügt.

Hinweis:

Standardmäßig ist –vserverRHILevel auf ONE_VSERVER gesetzt.

Das folgende Diagramm zeigt die grundlegende Route Health Injection für eine virtuelle IP-Adresse, die einem virtuellen Server mit Lastausgleich auf Citrix ADC zugeordnet ist:

Route-Health-Injection-Optionen mit mehreren Rechenzentren

Im Folgenden wird die Route Health Injection-Konfiguration beschrieben, die pro Anwendung ausgewählt wird, abhängig von den spezifischen Anforderungen für jede Anwendung. Es gibt folgende Optionen:

Aktiv — Aktiv mit BGP zur Bestimmung der effizientesten Route für jeden Client (Anycast oder ECMP)

Route Health Injection Aktiv — Aktiv: Anycast oder ECMP

Route Health Injection aktiv/aktiv ist Anycast oder ECMP. Dies ist eine echte Aktiv-Aktiv-Alternative. In diesem Szenario wird die /32-Route für die Route Health Injection-VIP in allen Rechenzentren angekündigt, ohne dass BGP Kosten oder lokale Präferenz präsentiert werden. Dem Netzwerk werden drei Routen mit der für jedes Rechenzentrum spezifischen SNIP-Adresse des Citrix ADC präsentiert, die als Gateway für den Zugriff auf jede VIP fungiert. Die dynamische Routing-Umgebung von Acme Inc. leitet Kundenanfragen zu gleichen Kosten für die Verkehrsverteilung an das Rechenzentrum weiter. Falls Dienste in einem der drei Rechenzentren ausfallen, fallen die an die Dienste mit Lastausgleich gebundenen Monitore den virtuellen Server aus. Dadurch wird wiederum die Routenankündigung für das Rechenzentrum mit dem Ausfall entfernt. Alle Kundenverbindungen arbeiten weiterhin mit den verbleibenden Rechenzentren zusammen.

Wichtige Überlegungen zur Aktiv-Aktiv-Konfiguration der Route Health Injection:

1. Route Health Injection mit ECMP wird für TCP- und UDP-basierte Dienste empfohlen und erfordert eine BGP-Konfiguration durch das Netzwerkteam von Acme Inc.. Route Health Injection mit ECMP hat eine Begrenzung für die Anzahl der Routen, die Upstream-Router unterstützen können (64).
2. Route Health Injection mit Anycast unterstützt UDP-basierte Dienste und wird für TCP-basierte Dienste nicht empfohlen.

Das folgende Diagramm beschreibt das aktiv-aktive Anycast/ECMP-Szenario:

Citrix ADC- und Client-IP-Optionen

Eine der wichtigen Anforderungen, die Acme Inc. für eine große Anzahl seiner Kubernetes-Anwendungen stellt, besteht darin, dass Back-End-Server die echte Client-IP-Adresse für Dienste erhalten, die von Citrix ADC ausgeglichen werden. Ein typischer Lastausgleich auf Citrix ADC bezieht den gesamten Datenverkehr, der für Backend-Server bestimmt ist, von einer SNIP-Adresse (Subnetz-IP), die dem NetScaler gehört. Für einige Anwendungen ist die echte Client-IP erforderlich. Bei den meisten Anwendungen, die Route Health Injection verwenden, muss auch die echte Client-IP an den Backend-Server gesendet werden.

Citrix ADC verfügt über eine Funktion namens “Use Source IP” (USIP), die entweder global oder einzeln an jeden Dienst gebunden werden kann, der die Client-IP an den Back-End-Server erfordert. Das Problem dabei ist, dass, sobald der Client das Paket mit einer anderen Quell-IP empfängt, ein asymmetrisches Routing stattfindet und das Paket verworfen wird. Aus diesem Grund müssen andere Überlegungen bewertet werden, und auf den Backend-Servern ist eine zusätzliche Konfiguration erforderlich, damit USIP ordnungsgemäß funktioniert.

Eine wichtige Überlegung bei der Implementierung des Use Source IP-Modus auf Citrix ADC ist, dass der Überlastungsschutzmodus in den Citrix ADC-Modi ausgeschaltet werden muss. Weitere Informationen zum USIP-Modus mit Überlastungsschutz finden Sie im Citrix-Artikel hier.

Citrix ADC bietet mehrere Methoden, um dies zu erreichen, die im folgenden Abschnitt beschrieben werden. Die verfügbaren Optionen sind:

• USIP-Modus mit Citrix ADC SNIP als Standardgateway
• Direkte Serverrückgabe Layer 3
  • IP-Tunneln
  • Client-IP-Einfügung in TOS-Header
• Direkte Serverrückgabe Layer 2
• Client-IP-Einfügung für TCP-Header

USIP-Modus mit Citrix ADC SNIP als Standardgateway

Bei mehreren Besprechungen mit der IT von Acme Inc. wurde festgestellt, dass diese Methode für die meisten Lastausgleichsdienste, die Client-IP erfordern, bevorzugt wird. Bei dieser Methode wird das Standardgateway für jeden Backend-Server geändert, für den ein Lastausgleich durchgeführt wird, und es auf die SNIP-Adresse der Citrix ADC-Einheit festgelegt, die die VIP mit Lastausgleich hostet. Diese Option unterstützt alle Citrix ADC-Funktionen im Gegensatz zu Direct Server-Rückgabeoptionen, bei denen der Citrix ADC nur eingehende Clientanforderungen verwaltet. Diese Option erfordert auch die meiste Bandbreite auf den ADC-Einheiten. Diese Methode hat die folgenden grundlegenden Anforderungen:

• Der Citrix ADC muss eine SNIP-Adresse im selben L2-Subnetz haben wie alle Back-End-Server, die einen Lastausgleich haben.
• Die SNIP-Adresse ist als Standardgateway für alle Backend-Server konfiguriert. Für Backend-Server in verschiedenen L2-Subnetzen können mehrere SNIP-Adressen verwendet werden.
• Der USIP-Modus muss für die Dienste aktiviert sein, die auf Backend-Server verweisen.

Hinweis:

USIP kann auch global auf Citrix ADC-Einheiten aktiviert werden. USIP gilt jedoch nur für Dienste, die nach dem Aktivieren des USIP-Modus erstellt wurden.

Citrix empfiehlt, mehr Netzwerkschnittstellen zu Backend-Servern hinzuzufügen und statische Routen für Nicht-Client-Verkehr zu konfigurieren.

• Backuproutinen und andere Prozesse, die Bandbreite benötigen, müssen die Citrix ADC-Einheit nicht durchlaufen.

Direkte Serverrückgabe: Layer-3-Optionen

Die direkte Serverrückgabe mit Citrix ADC ist eine weitere Konfigurationsoption zum Abrufen der Client-IP-Adressen auf den Backend-Servern in einer Load Balancing-Konfiguration. Die direkte Serverrückgabe kann im Layer-3-Modus konfiguriert werden, sodass Backend-Server auf anderen L3-VLANs verwendet werden können, im Gegensatz zu USIP, das L2-Konnektivität vom ADC zu den Backend-Servern erfordert. Die Konfiguration der direkten Serverrückgabe unterstützt bestimmte Citrix ADC-Funktionen nicht, da der Antwortverkehr die Citrix ADC-Einheit nicht durchquert. Diese Option erfordert den geringsten Durchsatz auf den Citrix ADC-Einheiten.

Bei der direkten Serverrückgabe sind komplexere Konfigurationen für Backend-Server erforderlich, da sie in der Lage sein müssen, die Client-IP zu extrahieren und den TCP-Header neu zu schreiben, um direkt auf den Client zu reagieren. Citrix unterstützt derzeit zwei verschiedene Methoden zur Konfiguration von Layer 3 DSR:

• DSR-Modus mit IP-Tunneling (IP over IP)
• DSR-Modus mit TOS (Typ des Dienstes TCP-Headerfeld) Layer 3

DSR hat die folgenden grundlegenden Anforderungen:

• Der Citrix ADC muss mit USIP im Dienst konfiguriert sein.
• Die Backend-Server haben eine Loopback-Adresse, die mit der Citrix ADC VIP-Adresse konfiguriert ist.
• Der Backend-Server muss speziell für jede Methode konfiguriert werden:
  • IP-Tunneling: Der Backend-Server muss die Pakete aus dem ADC entkapseln und die Client-IP extrahieren, um direkt auf den Client reagieren zu können.
  • TOS (Type of Service): Der Backend-Server muss in der Lage sein, den TOS-Header des TCP-Pakets zu lesen und diese Informationen zu verwenden, um dem Client direkt zu antworten.
  • Beide Methoden erfordern möglicherweise benutzerdefinierte Konfigurationen auf Backend-Servern und die Verwendung einer Drittanbieteranwendung.

Layer-3-DSR erfordert möglicherweise die Konfiguration von Ausnahmen auf Firewalls und Sicherheitsgeräten.

Weitere Informationen zur Direct Server Return mit Layer 3 finden Sie hier:

DSR-Modus bei Verwendung von TOS konfigurieren - DSR mit TOS

• DSR mit IP-Tunneling

Dienste vom Typ “LoadBalancer” verfügbar machen

Services des Typs LoadBalancer werden nativ in Kubernetes-Bereitstellungen in Public Clouds wie AWS, GCP oder Azure unterstützt. Wenn Sie in Cloud-Bereitstellungen einen Dienst vom Typ LoadBalancer erstellen, wird dem Dienst ein in der Cloud verwalteter Load Balancer zugewiesen. Der Dienst wird dann mithilfe des Load Balancers verfügbar gemacht.

Für on-premises, Bare-Metal- oder Public-Cloud-Bereitstellungen von Kubernetes können Sie einen Citrix ADC außerhalb des Clusters verwenden, um den eingehenden Datenverkehr auszugleichen. Der Citrix Ingress Controller bietet eine flexible IP-Adressverwaltung, die Mandantenfähigkeit für Citrix ADCs ermöglicht. Mit dem Citrix Ingress Controller können Sie mehrere Dienste mit einem einzigen ADC ausgleichen und verschiedene Ingress-Funktionen kombinieren. Durch die Verwendung des Citrix ADC mit dem Citrix Ingress Controller können Sie die Auslastung der Load Balancer-Ressourcen für Ihre Public Cloud maximieren und Ihre Betriebskosten erheblich reduzieren.

Der Citrix Ingress Controller unterstützt die Dienste des Typs LoadBalancer, wenn sich der Citrix ADC außerhalb des Kubernetes-Clusters (Tier-1) befindet. Wenn ein Dienst vom Typ LoadBalancer erstellt, aktualisiert oder gelöscht wird, konfiguriert der Citrix Ingress Controller den Citrix ADC mit einem virtuellen Lastausgleichsserver.

Der virtuelle Lastausgleichsserver ist mit einer IP-Adresse (virtuelle IP-Adresse oder VIP) konfiguriert, die auf eine der folgenden Arten abgerufen wird: ​

1. Durch automatisches Zuweisen einer virtuellen IP-Adresse zum Dienst mithilfe des von Citrix bereitgestellten IPAM-Controllers. Die Lösung ist so konzipiert, dass Sie die Lösung problemlos in externe DNS-Anbieter wie Infoblox integrieren können. Weitere Informationen finden Sie unter Interoperabilität mit ExternalDNS. ​

2. Geben Sie eine IP-Adresse mithilfe des Felds spec.loadBalancerIP in Ihrer Dienstdefinition an. Der Citrix Ingress Controller verwendet die im Feld spec.loadBalancerIP angegebene IP-Adresse als IP-Adresse für den virtuellen Lastausgleichsserver, der dem Dienst entspricht.

   apiVersion: v1
   kind: Service
   metadata:
       name: hello-world-service
   spec:
       type: LoadBalancer
       loadBalancerIP: ""
   ports:
   - port: 80
       targetPort: 8080
   selector:
       run: load-balancer-example
   <!--NeedCopy-->
   

Eine detailliertere Referenz finden Sie unter Expose services des Typs LoadBalancer.

IPAM-Voraussetzung

Als Voraussetzung für Citrix ADC Dynamic Routing with Kubernetes muss IP Address Management (IPAM) konfiguriert werden. IPAM wird verwendet, um IP-Adressen in von ADM verwalteten Bereitstellungen automatisch zuzuweisen und freizugeben. Eine detailliertere Referenz finden Sie unter Konfigurieren der IP-Adressverwaltung.