Citrix ADC Ingress Controller

Erweitertes Content-Routing für Kubernetes mit Citrix ADC

Kubernetes natives Ingress bietet grundlegendes host- und pfadbasiertes Routing. Andere erweiterte Routing-Techniken wie Routing basierend auf Header-Werten oder Abfragezeichenfolgen werden in der Ingress-Struktur jedoch nicht unterstützt. Sie können diese Funktionen im Kubernetes Ingress über Ingress-Anmerkungen verfügbar machen, aber die Verwaltung und Validierung von Anmerkungen ist komplex.

Sie können die erweiterten Funktionen des Inhaltsroutings von Citrix ADC als API für benutzerdefinierte Ressourcendefinitionen (CRD) für Kubernetes bereitstellen.

Mithilfe von CRDs für das Content-Routing können Sie den Datenverkehr basierend auf den folgenden Parametern weiterleiten:

  • Hostname
  • URL-Pfad
  • HTTP-Header
  • Cookie
  • Parameter abfragen
  • HTTP-Methode
  • Citrix ADC-Richtlinienausdruck

Hinweis:

Eine Ingress-Ressource und CRDs für das Inhaltsrouting können nicht für denselben Endpunkt (IP-Adresse und Port) koexistieren. Die Verwendung von CRDs für das Content-Routing mit Ingress wird nicht unterstützt.

Die erweiterte Funktion zum Weiterleiten von Inhalten wird in Kubernetes mit den folgenden CRDs verfügbar gemacht:

  • Hörer
  • Httproute

CRDs für Inhaltsrouting

Hörer-CRD

Ein Listener-CRD-Objekt repräsentiert die Endpunktinformationen wie virtuelle IP-Adresse, Port, Zertifikate und andere Front-End-Konfigurationen. Es definiert auch die Standardaktionen wie das Senden des Standarddatenverkehrs an ein Backend oder das Umleiten des Datenverkehrs. Ein Listener-CRD-Objekt kann sich auf HttpRoute-CRD-Objekte beziehen, die die HTTP-Routinglogik für die eingehende HTTP-Anforderung darstellen.

Die vollständige CRD-Definition finden Sie im Listener-CRD. Vollständige Informationen zu allen Attributen der Listener-CRD finden Sie in der Listener-CRD-Dokumentation.

Listener-CRD unterstützt HTTP-, SSL- und TCP-Profile. Mithilfe dieser Profile können Sie das Standardprotokollverhalten anpassen. Listener CRD unterstützt auch das Analyseprofil, mit dem Citrix ADC die Art der Transaktionen oder Daten an verschiedene Endpunkte exportieren kann. Weitere Informationen zur Profilunterstützung für Listener-CRD finden Sie in der Profilunterstützung für die Listener-CRD.

Bereitstellen der Listener-CRD

  1. Laden Sie die Listener-CRDherunter.

  2. Stellen Sie die Listener-CRD mit dem folgenden Befehl bereit.

    Kubectl create -f  Listener.yaml
    

    Beispiel:

    root@k8smaster:# kubectl create -f Listener.yaml
    customresourcedefinition.apiextensions.k8s.io/listeners.citrix.com created
    

Wie schreibt man Listener-CRD-Objekte

Nachdem Sie die von Citrix bereitgestellte CRD im Kubernetes-Cluster bereitgestellt haben, können Sie die Listener-Konfiguration in einer YAML-Datei definieren. Verwenden Sie in der YAML-Datei Listener im Feld “Art” und fügen Sie im Abschnitt “Spezifikationen” die Listener-CRD-Attribute basierend auf Ihren Anforderungen für die Listener-Konfiguration hinzu. Nachdem Sie die YAML-Datei bereitgestellt haben, wendet der Citrix Ingress Controller die Listener-Konfiguration auf dem Ingress Citrix ADC-Gerät an.

Es folgt ein Beispiel für eine Listener-CRD-Objektdefinition mit dem Namen Listener-crd.yaml.

apiVersion: citrix.com/v1
kind: Listener
metadata:
  name: my-listener
  namespace: default
spec:
  certificates:
  - secret:
      name: my-secret
    # Secret named 'my-secret' in current namespace bound as default certificate
    default: true
  - secret:
      # Secret 'other-secret' in demo namespace bound as SNI certificate
      name: other-secret
      namespace: demo
  - preconfigured: second-secret
    # preconfigured certkey name in ADC
  vip: '192.168.0.1' # Virtual IP address to be used, not required when CPX is used as ingress device
  port: 443
  protocol: https
  redirectPort: 80
  secondaryVips:
  - "10.0.0.1"
  - "1.1.1.1"
  policies:
    httpprofile:
      config:
        websocket: "ENABLED"
    tcpprofile:
      config:
        sack: "ENABLED"
    sslprofile:
      config:
        ssl3: "ENABLED"
    sslciphers:
    - SECURE
    - MEDIUM
    analyticsprofile:
      config:
      - type: webinsight
        parameters:
           allhttpheaders: "ENABLED"
    csvserverConfig:
      rhistate: 'ACTIVE'
  routes:
    # Attach the policies from the below Routes
  - name: domain1-route
    namespace: default
  - name: domain2-route
    namespace: default
  - labelSelector:
      # Attach all HTTPRoutes with label route=my-route
      route: my-route
  # Default action when traffic matches none of the policies in the HTTPRoute
  defaultAction:
    backend:
      kube:
        namespace: default
        port: 80
        service: default-service
        backendConfig:
          lbConfig:
            # Use round robin LB method for default service
            lbmethod: ROUNDROBIN
          servicegroupConfig:
            # Client timeout of 20 seconds
            clttimeout: "20"
<!--NeedCopy-->

In diesem Beispiel macht ein Listener einen HTTPS-Endpunkt verfügbar. Im Abschnitt Zertifikate werden SSL-Zertifikate für den Endpunkt mit Kubernetes-Geheimnissen my-secretother-secret und einem vorkonfigurierten ADC-Standardzertifikat mit certkey konfiguriert second-secret. Die Standardaktion für den Listener ist als Kubernetes-Dienst konfiguriert. Routen werden mit dem Listener sowohl über Label-Selektoren als auch über einzelne Routenreferenzen mithilfe von Name und Namespace angehängt.

Nachdem Sie das Listener-CRD-Objekt in der YAML-Datei definiert haben, stellen Sie die YAML-Datei mit dem folgenden Befehl bereit. In diesem Beispiel ist Listener-crd.yaml die YAML-Definition.

Kubectl create -f  Listener-crd.yaml

HttpRoute-CRD

Ein HttpRoute-CRD-Objekt repräsentiert die HTTP-Routinglogik für die eingehenden HTTP-Anforderungen. Sie können eine Kombination verschiedener HTTP-Parameter wie Hostname, Pfad, Header, Abfrageparameter und Cookies verwenden, um den eingehenden Datenverkehr an einen Back-End-Dienst weiterzuleiten. Ein HttpRoute-Objekt kann an ein oder mehrere Listener-Objekte angehängt werden, die die Endpunktinformationen darstellen. Sie können eine oder mehrere Regeln in einem HttpRoute-Objekt haben, wobei jede Regel eine damit verknüpfte Aktion angibt. Die Reihenfolge der Auswertung der Regeln innerhalb eines HttpRoute-Objekts entspricht der im Objekt angegebenen Reihenfolge. Wenn es beispielsweise zwei Regeln mit der Reihenfolge Regel1 und Regel2 gibt, wobei Regel1 vor Regel2 geschrieben wird, wird Regel1 zuerst vor Regel2 ausgewertet.

Die HttpRoute-CRD-Definition ist unter Httproute.YAMLverfügbar. Vollständige Informationen zu den Attributen für die HTTP-Route-CRD-Dokumentation finden Sie in der HttpRoute CRD-Dokumentation.

Citrix unterstützt jetzt die Konfiguration der CRD-Ressource für die HTTP-Route als Ressourcen-Backend in der Version Ingress with Kubernetes Ingress. networking.k8s.io/v1Mit dieser Funktion können Sie erweiterte Funktionen für das Content-Routing auf Ingress erweitern. Weitere Informationen finden Sie unter Erweitertes Inhaltsrouting für Kubernetes Ingress mithilfe der HttpRoute-CRD.

Bereitstellen der HttpRoute-CRD

Führen Sie Folgendes aus, um die HttpRoute-CRD bereitzustellen:

  1. Laden Sie die Httproute.YAMLherunter.

  2. Wenden Sie die HttpRoute-CRD mit dem folgenden Befehl in Ihrem Cluster an.

    Kubectl apply -f HTTPRoute.yaml

    Beispiel:

    root@k8smaster:# kubectl create -f HTTPRoute.yaml
    customresourcedefinition.apiextensions.k8s.io/httproutes.citrix.com configured
    

Wie schreibt man Httproute CRD-Objekte

Nachdem Sie die HttpRoute-CRD bereitgestellt haben, können Sie die HTTP-Routenkonfiguration in einer YAML-Datei definieren. Verwenden Sie in der YAML-Datei HTTPRoute im Feld “Art” und fügen Sie im Abschnitt “Spezifikationen” die CRD-Attribute hinzu, die auf Ihren Anforderungen für die HTTP-Routenkonfiguration basieren.

Es folgt ein Beispiel für eine HttpRoute CRD-Objektdefinition mit dem Namen Route-crd.yaml.

apiVersion: citrix.com/v1
kind: HTTPRoute
metadata:
   name: test-route
spec:
  hostname:
  - host1.com
  rules:
  - name: header-routing
    match:
    - headers:
      - headerName:
          exact: my-header
    action:
      backend:
        kube:
          service: mobile-app
          port: 80
          backendConfig:
            secureBackend: true
            lbConfig:
              lbmethod: ROUNDROBIN
  - name: path-routing
    match:
    - path:
        prefix: /
    action:
      backend:
        kube:
          service: default-app
          port: 80
<!--NeedCopy-->

In diesem Beispiel my-header wird jede Anforderung mit einem übereinstimmenden Header-Namen an den Mobile-App-Dienst weitergeleitet, und der gesamte andere Datenverkehr wird an den Standard-App-Dienst weitergeleitet. Ausführliche Erklärungen und API-Spezifikationen von HttpRoute finden Sie unter HttpRoute CRD.

Nachdem Sie die HTTP-Routen in der YAML-Datei definiert haben, stellen Sie die YAML-Datei für das CRD-Objekt HttpRoute mit dem folgenden Befehl bereit. In diesem Beispiel ist Route-crd.yaml die YAML-Definition.

Kubectl create -f  Route-crd.yaml

Sobald Sie die YAML-Datei bereitgestellt haben, wendet der Citrix Ingress Controller die HTTP-Routenkonfiguration auf dem Ingress Citrix ADC-Gerät an.

Anhängen von HttpRoute-CRD-Objekten an ein Listener-CRD-Objekt

Sie können HttpRoute-CRD-Objekte auf zwei Arten an ein Listener-CRD-Objekt anhängen:

  • Name und Namespace verwenden
  • Verwenden von Labels und Selektor

Anhängen von HttpRoute-CRD-Objekten mit Name und Namespace

Bei diesem Ansatz bezieht sich ein Listener-CRD-Objekt explizit auf ein oder mehrere HttpRoute-Objekte, indem es den Namen und den Namespace im routes Abschnitt angibt. Die Reihenfolge der Auswertung von HttpRoute-Objekten entspricht der Reihenfolge, die im Listener-CRD-Objekt angegeben ist, wobei das erste HttpRoute-Objekt zuerst ausgewertet wird und so weiter.

Ein Snippet des Listener-CRD-Objekts wird beispielsweise wie folgt angezeigt.

routes:
 - name: route-1
   namespace: default
 - name: route-2
   namespace: default

In diesem Beispiel wird das CRD-Objekt HttpRoute mit dem Namen route1 vor der Httroute mit dem Namen route2 ausgewertet.

Anhängen eines Httproute-CRD-Objekts mithilfe von Labels und Selektor

Sie können Httroute-Objekte auch mithilfe von Labels und Selektor an ein Listener-Objekt anhängen. Sie können ein oder mehrere Labels im Listener-CRD-Objekt angeben. Alle HttpRoute-Objekte, die den Labels entsprechen, werden automatisch mit dem Listener-Objekt verknüpft, und die Regeln werden in Citrix ADC erstellt. Wenn Sie diesen Ansatz verwenden, gibt es keine bestimmte Reihenfolge der Auswertung zwischen mehreren HttpRoute-Objekten. Die einzige Ausnahme ist ein HttpRoute-Objekt mit einer Standardroute (eine Route mit nur einem Hostnamen oder einem ‘/’ -Pfad), die als letztes Objekt ausgewertet wird.

Das Snippet einer Listener-Ressource lautet beispielsweise wie folgt:

routes:
- labelSelector:
    team: team1
Erweitertes Content-Routing für Kubernetes mit Citrix ADC