Citrix ADC Ingress Controller

Erweiterungen für den Kubernetes-Dienst vom Typ LoadBalancer-Unterstützung im Citrix Ingress Controller

Der Kubernetes-Dienst vom Typ LoadBalancer-Unterstützung im Citrix Ingress Controller wurde um die folgenden Funktionen erweitert:

  • Unterstützung der BGP Route Health Injection (RHI)
  • Ankündigen oder Abrufen von Load Balancer-IP-Adressen (VIPs) basierend auf der Verfügbarkeit der Pods des Dienstes in einer Reihe von Knoten (Zonen), die durch die Bezeichnungen des Knotens definiert sind

Unterstützung für die automatische Konfiguration von BGP RHI auf Citrix ADC

Route Health Injection (RHI) ermöglicht es Citrix ADC, die Verfügbarkeit eines VIP als Host-Route im gesamten Netzwerk mithilfe von BGP anzukündigen. Sie mussten die Konfiguration jedoch manuell auf Citrix ADC durchführen, um RHI zu unterstützen. Mit Citrix Ingress Controllern, die in einer Kubernetes-Umgebung bereitgestellt werden, können Sie die Konfiguration auf Citrix ADCs automatisieren, um VIPs anzukündigen.

Wenn ein Dienst des Typs LoadBalancer erstellt wird, konfiguriert der Citrix Ingress Controller einen VIP auf dem Citrix ADC für den Dienst. Wenn die BGP RHI-Unterstützung für den Citrix Ingress Controller aktiviert ist, konfiguriert er automatisch Citrix ADC, um den VIP an das BGP-Netzwerk anzukündigen.

Werben und rufen Sie VIPs basierend auf der Verfügbarkeit von Pods ab

In der Topologie, wie im folgenden Diagramm dargestellt, sind Knoten in einem Kubernetes-Cluster physisch auf drei verschiedene Racks verteilt. Sie sind logisch in drei Zonen unterteilt. Jede Zone verfügt über einen Citrix ADC MPX als Tier-1-ADC und einen Citrix Ingress Controller auf demselben im Kubernetes-Cluster. Citrix Ingress-Controller in allen Zonen hören denselben Kubernetes-API-Server. Wenn also ein Dienst des Typs LoadBalancer erstellt wird, kündigen alle Citrix ADCs im Cluster dieselbe IP-Adresse an die BGP-Fabric an. Selbst wenn in einer Zone keine Arbeitslast vorhanden ist, gibt der Citrix ADC in dieser Zone immer noch die IP-Adresse bekannt.

Beispiel für Topologie

Citrix bietet eine Lösung zum Ankündigen oder Abrufen des VIP basierend auf der Verfügbarkeit von Pods in einer Zone. Sie müssen die Knoten in jeder Zone beschriften, damit der Citrix Ingress Controller Knoten identifizieren kann, die zu derselben Zone gehören. Der Citrix Ingress Controller in jeder Zone überprüft, ob sich Pods auf Knoten in der Zone befinden. Wenn sich Pods auf Knoten in der Zone befinden, wird der VIP beworben. Andernfalls wird die Ankündigung von VIP vom Citrix ADC in der Zone widerrufen.

Konfigurieren von BGP RHI auf Citrix ADCs mithilfe des Citrix Ingress Controller

Dieses Thema enthält Informationen zum Konfigurieren von BGP RHI auf Citrix ADCs mithilfe des Citrix Ingress Controller basierend auf einer Beispieltopologie. In dieser Topologie werden Knoten in einem Kubernetes-Cluster über zwei Zonen verteilt. Jede Zone verfügt über einen Citrix ADC VPX oder MPX als Tier-1-ADC und einen Citrix Ingress Controller zum Konfigurieren von ADC im Kubernetes-Cluster. Die ADCs werden mithilfe von BGP mit dem Upstream-Router gepeert.

Beispiel-Topologie der BGP RHI-Konfiguration

Voraussetzungen

  • Sie müssen Citrix ADC MPX oder VPX als BGP-Peer mit den Upstream-Routern konfigurieren.

Führen Sie die folgenden Schritte aus, um die BGP-RHI-Unterstützung basierend auf der Beispieltopologie zu konfigurieren.

  1. Beschriften Sie Knoten in jeder Zone mit dem folgenden Befehl:

    Für Zone 1:

    kubectl label nodes node1 rack=rack-1
    kubectl label nodes node2 rack=rack-1
    

    Für Zone 2:

    kubectl label nodes node3 rack=rack-2
    kubectl label nodes node4 rack=rack-2
    
  2. Konfigurieren Sie die folgenden Umgebungsvariablen in den YAML-Dateien der Citrix Ingress Controller-Konfiguration wie folgt:

    Für Zone 1:

    - name: "NODE_LABELS"
      value: "rack-1"
    - name: "BGP_ADVERTISEMENT"
      value: "True"
    

    Für Zone 2:

     - name: "NODE_LABELS"
       value: "rack-2"
     - name: "BGP_ADVERTISEMENT"
       value: "True"
    

    Eine Beispieldatei cic.yaml für die Bereitstellung des Citrix Ingress Controller auf Zone 1 wird wie folgt bereitgestellt:

    apiVersion: v1
    kind: Pod
    metadata:
      name: cic-k8s-ingress-controller-1
      labels:
        app: cic-k8s-ingress-controller-1
    spec:
      serviceAccountName: cic-k8s-role
      containers:
      - name: cic-k8s-ingress-controller
        image: "quay.io/citrix/citrix-k8s-ingress-controller:1.26.7"
    
        env:
        # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
        - name: "NS_IP"
          value: "10.217.212.24"
       # Set username for Nitro
        - name: "NS_USER"
          valueFrom:
            secretKeyRef:
              name: nslogin
              key: username
       # Set user password for Nitro
        - name: "NS_PASSWORD"
          valueFrom:
            secretKeyRef:
            name: nslogin
            key: password        
        - name: "EULA"
          value: "yes"
        - name: "NODE_LABELS"
          value: "rack=rack-1"
        - name: "BGP_ADVERTISEMENT"
          value: "True"
    args:
      - --ipam 
        citrix-ipam-controller
    imagePullPolicy: Always
    
  3. Stellen Sie den Citrix Ingress Controller mit dem folgenden Befehl bereit.

    Hinweis:

    Sie müssen den Citrix Ingress Controller auf beiden Racks (pro Zone) bereitstellen.

    Kubectl create -f cic.yaml
    
  4. Stellen Sie mit der Datei web-frontend-lb.yaml eine Beispielanwendung bereit.

    Kubectl erstellt -f web-frontend-lb.yaml

    Der Inhalt von web-frontend-lb.yaml ist wie folgt:

    apiVersion: v1
    kind: Deployment
    metadata:
      name: web-frontend
    spec:
      selector:
        matchLabels:
          app: web-frontend
      replicas: 4
      template:
        metadata:
          labels:
            app: web-frontend
        spec:
          containers:
          - name: web-frontend
            image: 10.217.6.101:5000/web-test:latest
            ports:
              - containerPort: 80
            imagePullPolicy: Always
    
  5. Erstellen Sie einen Dienst des Typs LoadBalancer, um die Anwendung verfügbar zu machen.

    Kubectl create -f web-frontend-lb-service.yaml
    

    Der Inhalt von web-frontend-lb-service.yaml ist wie folgt:

    apiVersion: v1
    kind: Service
    metadata:
      name: web-frontend
      labels:
        app: web-frontend
    spec:
      type: LoadBalancer
      ports:
      - port: 80
        protocol: TCP
        name: http
      selector:
        app: web-frontend
    
  6. Überprüfen Sie die Erstellung der Dienstgruppe auf Citrix ADCs mit dem folgenden Befehl.

    show servicegroup <service-group-name>
    

    Es folgt ein Beispiel für die Ausgabe des Befehls.

    #  show servicegroup k8s-web-frontend_default_80_svc_k8s-web-frontend_default_80_svc
       
    k8s-web-frontend_default_80_svc_k8s-web-frontend_default_80_svc - TCP
    State: ENABLED Effective State: UP Monitor Threshold : 0
    Max Conn: 0 Max Req: 0 Max Bandwidth: 0 kbits
    Use Source IP: NO
    Client Keepalive(CKA): NO
    TCP Buffering(TCPB): NO
    HTTP Compression(CMP): NO
    Idle timeout: Client: 9000 sec Server: 9000 sec
    Client IP: DISABLED 
    Cacheable: NO
    SC: OFF
    SP: OFF
    Down state flush: ENABLED
    Monitor Connection Close : NONE
    Appflow logging: ENABLED
    ContentInspection profile name: ???
    Process Local: DISABLED
    Traffic Domain: 0
    
    
    1)   10.217.212.23:30126 State: UP Server Name: 10.217.212.23 Server ID: None Weight: 1
      Last state change was at Wed Jan 22 23:35:11 2020 
      Time since last state change: 5 days, 00:45:09.760
    
      Monitor Name: tcp-default  State: UP Passive: 0
      Probes: 86941 Failed [Total: 0 Current: 0]
      Last response: Success - TCP syn+ack received.
      Response Time: 0 millisec
    
    2)   10.217.212.22:30126 State: UP Server Name: 10.217.212.22 Server ID: None Weight: 1
      Last state change was at Wed Jan 22 23:35:11 2020 
      Time since last state change: 5 days, 00:45:09.790
    
      Monitor Name: tcp-default State: UP Passive: 0
      Probes: 86941 Failed [Total: 0 Current: 0]
      Last response: Success - TCP syn+ack received.
    
  7. Überprüfen Sie die VIP-Ankündigung auf dem BGP-Router mit dem folgenden Befehl.

     >VTYSH
    # show ip route bgp
      B       172.29.46.78/32   [200/0] via 2.2.2.100, vlan20, 1d00h35m
                                [200/0] via 2.2.2.101, vlan20, 1d00h35m
      Gateway of last resort is not set
    
Erweiterungen für den Kubernetes-Dienst vom Typ LoadBalancer-Unterstützung im Citrix Ingress Controller