Contrôleur d'entrée Citrix ADC

Prise en charge du routage basé sur des règles pour plusieurs clusters Kubernetes

Lorsque vous utilisez un seul Citrix ADC pour équilibrer la charge de plusieurs clusters Kubernetes, le Citrix ingress controller ajoute des réseaux CIDR d’espace via des itinéraires statiques. Ces itinéraires établissent une connectivité réseau entre les espaces Kubernetes et Citrix ADC. Toutefois, lorsque les CIDR de l’espace se chevauchent, il peut y avoir des conflits d’itinéraire. Citrix ADC prend en charge le routage basé sur des stratégies (PBR) pour résoudre les conflits réseau dans de tels scénarios. Dans PBR, les décisions sont prises en fonction des critères que vous spécifiez. En règle générale, un saut suivant est spécifié où vous envoyez les paquets sélectionnés. Dans un environnement Kubernetes à plusieurs clusters, le PBR est mis en œuvre en réservant une adresse IP de sous-réseau (SNIP) pour chaque cluster Kubernetes ou le Citrix Ingress Controller. À l’aide du profil réseau, le SNIP est lié à tous les groupes de services créés par le même Citrix ingress controller. Pour tout le trafic généré à partir de groupes de services appartenant au même cluster, l’adresse IP source est le même SNIP.

Voici un exemple de topologie où PBR est configuré pour deux clusters Kubernetes dont la charge est équilibrée à l’aide d’un VPX ou d’un MPX Citrix ADC.

Configuration du PBR

Configurez le PBR à l’aide du Citrix ingress controller

Pour configurer le PBR, vous avez besoin d’un ou plusieurs SNIP par cluster Kubernetes. Vous pouvez fournir des valeurs SNIP soit à l’aide de la variable d’environnement dans le fichier YAML de déploiement du Citrix ingress controller pendant le démarrage, soit à l’aide de ConfigMap.

Effectuez les étapes suivantes pour déployer le Citrix ingress controller et configurer PBR à l’aide de ConfigMap.

  1. Téléchargez citrix-k8s-ingress-controller.yaml à l’aide de la commande suivante :

    wget  https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/deployment/baremetal/citrix-k8s-ingress-controller.yaml
    
  2. Modifiez le fichier YAML du Citrix ingress controller :

      - Specify the values of the environment variables as per your requirements. For more information on specifying the environment variables, see the [Deploy Citrix ingress controller](/en-us/citrix-k8s-ingress-controller/cic-yaml.html) documentation.
    
  3. Déployez le Citrix ingress controller à l’aide du fichier YAML modifié avec la commande suivante sur chaque cluster.

    kubectl create -f citrix-k8s-ingress-controller.yaml
    
  4. Créez un fichier YAML cic-configmap.yaml avec les valeurs SNIP requises dans ConfigMap.

    Voici un exemple de ConfigMap avec les valeurs SNIP :

    apiVersion: v1
    kind: ConfigMap
    metadata:
        name: pbr-test
        namespace: default
    data:
        NS_SNIPS: '["192.0.2.2", "192.0.2.1"]'
    
  5. Appliquez le ConfigMap.

     kubectl create -f cic-configmap.yaml
    

Vous pouvez également spécifier les SNIP à l’aide de la variable d’environnement NS_SNIPS dans le fichier YAML de déploiement du Citrix ingress controller.

     - name: "NS_SNIPS"
        value: '["192.0.2.2", "192.0.2.1"]'

Voici les consignes d’utilisation lors de l’utilisation de ConfigMap pour configurer SNIP :

  • Seuls les SNIP peuvent être ajoutés ou supprimés via ConfigMap. L’argument feature-node-watch ne peut être activé que lors du démarrage.

  • Lorsque vous ajoutez un ConfigMap :

    • Si les SNIP sont déjà fournis à l’aide de la variable d’environnement pendant le démarrage et que vous souhaitez les conserver, ces SNIP doivent être spécifiés dans ConfigMap avec les nouveaux SNIP.
  • Lorsque vous supprimez ConfigMap :

    • Tous les PBR générés par les SNIP ConfigMap sont supprimés. Si des SNIP sont fournis via la variable d’environnement, le PBR pour ces adresses IP est ajouté.

    • Si les SNIP ne sont pas fournis à l’aide de la variable d’environnement NS_SNIPS, des routes statiques sont ajoutées car feature-node-watch est activé.

Valider la configuration PBR sur un Citrix ADC après avoir déployé le Citrix ingress controller

Cet exemple de validation utilise un cluster Kubernetes à deux nœuds avec le Citrix ingress controller déployé avec la ConfigMap suivante avec deux SNIP.

Image

Vous pouvez vérifier que le Citrix ingress controller ajoute les configurations suivantes à l’ADC :

  1. Un IPset de tous les NS_SNIPs éléments fournis par le ConfigMap est ajouté.

    Image

  2. Un profil net est ajouté avec l’ensemble SrcIP à IPset.

    Image

  3. Le groupe de services ajouté par le Citrix ingress controller contient le jeu de profils réseau.

    Image

  4. Enfin, le Citrix ingress controller ajoute des PBR.

    Image

    Ici :

    • Le nombre de PBR est équivalent à (nombre de SNIP) * (nombre de nœuds Kubernetes). Dans ce cas, il ajoute quatre (2* 2) PBR.
    • Le srcIP du PBR est NS_SNIPS fourni au Citrix ingress controller par ConfigMap. destIP Il s’agit de la plage de sous-réseaux de superposition CNI du nœud Kubernetes.
    • NextHop est l’adresse IP du nœud Kubernetes.
  5. Vous pouvez également utiliser les journaux du Citrix ingress controller pour valider la configuration.

    journaux

Configurez PBR à l’aide du contrôleur de nœud Citrix

Vous pouvez configurer PBR à l’aide du contrôleur de nœud Citrix pour plusieurs clusters Kubernetes. Lorsque vous utilisez un seul Citrix ADC pour équilibrer la charge de plusieurs clusters Kubernetes avec le contrôleur de nœud Citrix pour la mise en réseau, les routes statiques qu’il ajoute pour transférer des paquets à l’adresse IP de l’interface du tunnel VXLAN peuvent provoquer des conflits de route. Pour prendre en charge PBR, le contrôleur de nœud Citrix doit fonctionner conjointement avec le Citrix ingress controller pour lier le profil réseau au groupe de services.

Effectuez les étapes suivantes pour configurer le PBR à l’aide du contrôleur de nœud Citrix :

  1. Lors du démarrage du contrôleur de nœud Citrix, fournissez la variable d’environnement CLUSTER_NAME en tant que variable d’environnement. La spécification de cette variable indique qu’il s’agit d’un déploiement multi-clusters et que le contrôleur de nœud Citrix configure PBR au lieu d’itinéraires statiques.

    Exemple :

    - name: CLUSTER_NAME 
      value: "dev-cluster"
    
  2. Lors du déploiement du Citrix ingress controller, fournissez la variable d’environnement CLUSTER_NAME en tant que variable d’environnement. Cette valeur doit être la même que celle fournie dans le contrôleur de nœud Citrix.

    Exemple :

    - name: CLUSTER_NAME  
      value: "dev-cluster "
    
  3. Spécifiez l’argument --enable-cnc-pbr comme True dans la section arguments du fichier YAML de déploiement du Citrix ingress controller. Lorsque vous spécifiez cet argument, le Citrix ingress controller est conscient que le contrôleur de nœud Citrix configure PBR sur Citrix ADC.

    Exemple :

    args: 
     - --enable-cnc-pbr True          
    

Remarque :

  • La valeur fournie CLUSTER_NAME dans les fichiers de déploiement du contrôleur de nœud Citrix et du Citrix ingress controller doit correspondre lorsqu’ils sont déployés dans le même cluster Kubernetes.

  • Le CLUSTER_NAME est utilisé lors de la création de l’entité de profil réseau et de sa liaison à des groupes de services sur Citrix ADC VPX ou MPX.

Valider la configuration PBR sur un Citrix ADC après avoir déployé le contrôleur de nœud Citrix

Cet exemple de validation utilise un cluster Kubernetes à deux nœuds avec un contrôleur de nœud Citrix et un Citrix ingress controller déployés.

Vous pouvez vérifier que les configurations suivantes sont ajoutées à l’ADC par le contrôleur de nœud Citrix :

  1. Un profil réseau est ajouté, avec la valeur srcIP définie sur le SNIP ajoutée par le contrôleur de nœud Citrix lors de la création du réseau de tunnel VXLAN entre les nœuds Citrix ADC et Kubernetes.

    Image

  2. Le Citrix ingress controller lie le profil réseau aux groupes de services qu’il crée.

    Image

  3. Enfin, le contrôleur de nœud Citrix ajoute des PBR.

    Image

    Ici :

    • Le nombre de PBR est égal au nombre de nœuds Kuberntes. Dans ce cas, il ajoute deux PBR.
    • Le PBR est le contrôleur srcIP de nœud Citrix SNIP ajouté dans le réseau de tunnel. destIP Il s’agit de la plage de sous-réseaux de superposition CNI du nœud Kubernete. NextHop Il s’agit de l’adresse IP de l’interface du tunnel VXLAN du nœud Kubernetes.

      Remarque :

      Le contrôleur de nœud Citrix ajoute des PBR au lieu d’itinéraires statiques. Le reste de la configuration du VXLAN et de la table de pont reste identique. Pour plus d’informations, consultez la configuration du contrôleur de nœud Citrix.

Prise en charge du routage basé sur des règles pour plusieurs clusters Kubernetes