Contrôleur d'entrée Citrix ADC

Améliorations du service Kubernetes de type LoadBalancer prise en charge dans le Citrix ingress controller

Le service Kubernetes de type LoadBalancer pris en charge dans le Citrix ingress controller est amélioré avec les fonctionnalités suivantes :

  • Prise en charge de l’injection de santé par voie BGP (RHI)
  • Publier ou rappeler des adresses IP d’équilibrage de charge (VIP) en fonction de la disponibilité des espaces du service dans un ensemble de nœuds (zones) définis par les étiquettes des nœuds

Prise en charge de la configuration automatique de BGP RHI sur Citrix ADC

L’injection d’intégrité d’itinéraire (RHI) permet à Citrix ADC d’annoncer la disponibilité d’un VIP en tant que route hôte sur l’ensemble du réseau à l’aide de BGP. Cependant, vous deviez effectuer manuellement la configuration sur Citrix ADC pour prendre en charge RHI. À l’aide de contrôleurs d’entrée Citrix déployés dans un environnement Kubernetes, vous pouvez automatiser la configuration sur Citrix ADC pour annoncer des adresses IP virtuelles.

Lorsqu’un service de type LoadBalancer est créé, le Citrix ingress controller configure un VIP sur Citrix ADC pour le service. Si la prise en charge BGP RHI est activée pour le Citrix ingress controller, elle configure automatiquement Citrix ADC pour annoncer l’adresse IP virtuelle sur le réseau BGP.

Annoncer et rappeler des VIP en fonction de la disponibilité des capsules

Dans la topologie illustrée dans le diagramme suivant, les nœuds d’un cluster Kubernetes sont physiquement répartis sur trois racks différents. Ils sont logiquement regroupés en trois zones. Chaque zone possède un Citrix ADC MPX en tant qu’ADC de niveau 1 et un Citrix ingress controller sur la même zone dans le cluster Kubernetes. Les contrôleurs d’entrée Citrix dans toutes les zones écoutent le même serveur d’API Kubernetes. Ainsi, chaque fois qu’un service de type LoadBalancer est créé, tous les Citrix ADC du cluster annoncent la même adresse IP au fabric BGP. Même s’il n’y a aucune charge de travail sur une zone, Citrix ADC de cette zone annonce toujours l’adresse IP.

Topologie d'exemple

Citrix fournit une solution pour annoncer ou rappeler l’adresse IP virtuelle en fonction de la disponibilité des espaces dans une zone. Vous devez étiqueter les nœuds de chaque zone afin que le Citrix ingress controller puisse identifier les nœuds appartenant à la même zone. Le Citrix ingress controller de chaque zone vérifie s’il existe des espaces sur les nœuds de la zone. S’il y a des espaces sur des nœuds dans la zone, le VIP est annoncé. Dans le cas contraire, il révoque la publication de l’adresse IP virtuelle de Citrix ADC sur la zone.

Configuration de BGP RHI sur Citrix ADC à l’aide du Citrix ingress controller

Cette rubrique fournit des informations sur la façon de configurer BGP RHI sur Citrix ADC à l’aide du Citrix ingress controller sur la base d’un exemple de topologie. Dans cette topologie, les nœuds d’un cluster Kubernetes sont déployés sur deux zones. Chaque zone possède un Citrix ADC VPX ou MPX en tant qu’ADC de niveau 1 et un Citrix ingress controller pour configurer ADC dans le cluster Kubernetes. Les ADC sont appairés à l’aide de BGP avec le routeur en amont.

Exemple de topologie de configuration BGP RHI

Conditions préalables

  • Vous devez configurer Citrix ADC MPX ou VPX en tant qu’homologue BGP avec les routeurs en amont.

Effectuez les étapes suivantes pour configurer la prise en charge BGP RHI en fonction de l’exemple de topologie.

  1. Étiquetez les nœuds de chaque zone à l’aide de la commande suivante :

    Pour la zone 1 :

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

    Pour la zone 2 :

    kubectl label nodes node3 rack=rack-2
    kubectl label nodes node4 rack=rack-2
    
  2. Configurez les variables d’environnement suivantes dans les fichiers YAML de configuration du Citrix ingress controller comme suit :

    Pour la zone 1 :

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

    Pour la zone 2 :

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

    Un exemple de fichier cic.yaml pour déployer le Citrix ingress controller sur la zone 1 est fourni comme suit :

    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. Déployez le Citrix ingress controller à l’aide de la commande suivante.

    Remarque :

    Vous devez déployer le Citrix ingress controller sur les deux racks (par zone).

    Kubectl create -f cic.yaml
    
  4. Déployez un exemple d’application à l’aide du fichier web-frontend-lb.yaml.

    Kubectl crée -f web-frontend-lb.yaml

    Le contenu du fichier web-frontend-lb.yaml est le suivant :

    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. Créez un service de type LoadBalancer pour exposer l’application.

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

    Le contenu du fichier web-frontend-lb-service.yaml est le suivant :

    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. Vérifiez la création du groupe de services sur Citrix ADC à l’aide de la commande suivante.

    show servicegroup <service-group-name>
    

    Voici un exemple de sortie pour la commande.

    #  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. Vérifiez l’annonce VIP sur le routeur BGP à l’aide de la commande suivante.

     >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
    
Améliorations du service Kubernetes de type LoadBalancer prise en charge dans le Citrix ingress controller