Contrôleur d'entrée Citrix ADC

Déployer le Citrix ingress controller pour Citrix ADC avec des partitions d’administration

Le Citrix ingress controller est utilisé pour configurer automatiquement un ou plusieurs Citrix ADC en fonction de la configuration de la ressource Ingress. L’appliance Citrix ADC d’entrée (MPX ou VPX) peut être partitionnée en entités logiques appelées partitions d’administration, où chaque partition peut être configurée et utilisée en tant qu’appliance Citrix ADC distincte. Pour plus d’informations, consultez Partition d’administration. Le Citrix ingress controller peut également être déployé pour configurer Citrix ADC avec des partitions d’administration.

Pour Citrix ADC avec partitions d’administration, vous devez déployer une instance unique de Citrix ingress controller pour chaque partition. De plus, la partition doit être associée à un utilisateur de partition spécifique à l’instance du Citrix ingress controller.

Conditions préalables

Assurez-vous que :

  • Les partitions d’administration sont configurées sur l’appliance Citrix ADC. Pour obtenir des instructions, consultez Configurer les partitions d’administration.
  • Créez un utilisateur de partition spécifiquement pour le Citrix ingress controller. Le Citrix ingress controller configure Citrix ADC à l’aide de ce compte d’utilisateur de partition. Assurez-vous de ne pas associer cet utilisateur de partition à d’autres partitions de l’appliance Citrix ADC.

    Remarque :

    Pour les cas d’utilisation liés à SSL dans la partition d’administration, assurez-vous d’utiliser Citrix ADC versions 12.0-56.8 et supérieures.

Pour déployer le Citrix ingress controller pour Citrix ADC avec des partitions d’administration

  1. Téléchargez le fichier 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 citrix-k8s-ingress-controller.yaml et entrez les valeurs des variables environnementales suivantes :

    Variable d’environnement Obligatoire ou facultatif Description
    NS_IP Obligatoire L’adresse IP de l’appliance Citrix ADC. Pour plus de détails, consultez la section Prérequis.
    NS_USER et NS_PASSWORD Obligatoire Le nom d’utilisateur et le mot de passe de l’utilisateur de partition que vous avez créé pour le Citrix ingress controller. Pour plus de détails, consultez la section Prérequis.
    NS_VIP Obligatoire Le Citrix ingress controller utilise l’adresse IP fournie dans cette variable d’environnement pour configurer une adresse IP virtuelle pour Citrix ADC qui reçoit le trafic entrant. Remarque : NS_VIP agit en tant que solution de secours lorsque l’annotation frontend-ip n’est pas fournie dans Ingress yaml. Pris en charge uniquement pour l’entrée.
    NS_SNIPS Facultatif Spécifie les adresses SNIP sur l’appliance Citrix ADC ou les adresses SNIP sur une partition d’administration spécifique de l’appliance Citrix ADC.
    NS_ENABLE_MONITORING Obligatoire Définissez la valeur Yes pour surveiller Citrix ADC. Remarque : Assurez-vous de désactiver la surveillance Citrix ADC pour Citrix ADC avec des partitions d’administration. Définissez la valeur sur No.
    CONTRAT DE LICENCE Obligatoire Le contrat de licence de l’utilisateur final. Spécifiez la valeur comme Yes.
    Kubernetes_URL Facultatif L’URL du serveur kube-api que le Citrix ingress controller utilise pour enregistrer les événements. Si la valeur n’est pas spécifiée, le Citrix ingress controller utilise l’ adresse IP interne kube-apiserver.
    NIVEAU DE JOURNAL Facultatif Les niveaux de journal pour contrôler les journaux générés par le Citrix ingress controller. Par défaut, la valeur est définie sur DEBUG. Les valeurs prises en charge sont : CRITICAL, ERROR, WARNING, INFO et DEBUG. Pour plus d’informations, voir Niveaux de journalisation
    NS_PROTOCOL et NS_PORT Facultatif Définit le protocole et le port qui doivent être utilisés par le Citrix ingress controller pour communiquer avec Citrix ADC. Par défaut, le Citrix ingress controller utilise HTTPS sur le port 443. Vous pouvez également utiliser HTTP sur le port 80.
    classes d’entrée Facultatif Si plusieurs équilibreurs de charge d’entrée sont utilisés pour équilibrer la charge de différentes ressources d’entrée. Vous pouvez utiliser cette variable d’environnement pour spécifier le Citrix ingress controller afin de configurer Citrix ADC associé à une classe d’entrée spécifique. Pour plus d’informations sur les classes Ingress, voir Prise en charge des classes Ingress
  3. Une fois que vous avez mis à jour les variables d’environnement, enregistrez le fichier YAML et déployez-le à l’aide de la commande suivante :

    kubectl create -f citrix-k8s-ingress-controller.yaml
    
  4. Vérifiez si le Citrix ingress controller est déployé correctement à l’aide de la commande suivante :

    kubectl get pods --all-namespaces
    

Cas d’utilisation : Comment fournir en toute sécurité des applications basées sur des microservices mutualisés à l’aide de partitions d’administration Citrix ADC

Vous pouvez isoler le trafic entrant entre différentes applications basées sur des microservices avec la partition d’administration Citrix ADC à l’aide du Citrix ingress controller. La partition d’administration Citrix ADC permet la mutualisation au niveau logiciel dans une seule instance Citrix ADC. Chaque partition possède son propre plan de contrôle et son propre plan réseau.

Vous pouvez déployer une instance du Citrix ingress controller dans chaque espace de noms d’un cluster.

Par exemple, imaginez que vous avez deux espaces de noms dans un cluster Kubernetes et que vous souhaitez isoler ces espaces de noms les uns des autres sous deux administrateurs différents. Vous pouvez utiliser la fonctionnalité de partition d’administration pour séparer ces deux espaces de noms. Créez l’espace de noms 1 et l’espace de noms 2 et déployez le Citrix ingress controller séparément dans ces deux espaces de noms.

Les instances du Citrix ingress controller fournissent des instructions de configuration aux partitions Citrix ADC respectives à l’aide du compte d’utilisateur système spécifié dans le manifeste YAML.

Citrix ADC gère la charge de travail du cluster Kubernetes à l'aide de partitions administrateur

Dans cet exemple, les exemples d’applications apache et livre d’or sont déployés dans deux espaces de noms différents (espace de noms 1 et espace de noms 2 respectivement) dans un cluster Kubernetes. L’équipe des applications Apache et Guestbook souhaite gérer leur charge de travail de manière indépendante et ne souhaite pas partager de ressources. La partition d’administration Citrix ADC permet d’obtenir la multilocation et dans cet exemple, deux partitions (par défaut, partition1) sont utilisées pour gérer la charge de travail des deux applications séparément.

Les conditions préalables suivantes s’appliquent :

  • Assurez-vous que vous avez configuré les partitions d’administration sur l’appliance Citrix ADC. Pour obtenir des instructions, consultez Configurer les partitions d’administration.

  • Assurez-vous de créer un compte d’utilisateur de partition spécifiquement pour le Citrix ingress controller. Le Citrix ingress controller configure Citrix ADC à l’aide de ce compte d’utilisateur de partition. Assurez-vous de ne pas associer cet utilisateur de partition à d’autres partitions de l’appliance Citrix ADC.

Exemple

L’exemple de scénario suivant montre comment déployer différentes applications dans différents espaces de noms dans un cluster Kubernetes et comment la demande peut être isolée d’ADC à l’aide de la partition d’administration.

Dans cet exemple, deux exemples d’applications sont déployés dans deux espaces de noms différents d’un cluster Kubernetes. Dans cet exemple, il est utilisé comme partition par défaut dans Citrix ADC pour l’application apache et la partition d’administration p1 pour l’application guestbook.

Créer des espaces de noms

Créez deux espaces de noms ns1 et ns2 utilisez les commandes suivantes :

    kubectl create namespace ns1
    kubectl create namespace ns2

Configurations dans l’espace de noms ns1

  1. Déployez l’application apache dans ns1.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: ns1
    
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: apache-ns1
      name: apache-ns1
      namespace: ns1
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: apache-ns1
      template:
        metadata:
          labels:
            app: apache-ns1
        spec:
          containers:
          - image: httpd
            name: httpd
    ---
    
    apiVersion: v1
    kind: Service
    metadata:
      creationTimestamp: null
      labels:
        app: apache-ns1
      name: apache-ns1
      namespace: ns1
    spec:
      ports:
      - port: 80
        protocol: TCP
        targetPort: 80
      selector:
        app: apache-ns1
    
  2. Déployez le Citrix ingress controller dans ns1.

    Vous pouvez utiliser le fichier YAML pour déployer le Citrix ingress controller ou utiliser le graphique Helm.

    Assurez-vous d’utiliser les informations d’identification de l’utilisateur qui sont liées à la partition par défaut.

    helm install cic-def-part-ns1 citrix/citrix-ingress-controller --set nsIP=<nsIP of ADC>,license.accept=yes,adcCredentialSecret=nslogin,ingressClass[0]=citrix-def-part-ns1 --namespace ns1
    
  3. Déployez la ressource Ingress.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: ingress-apache-ns1
      namespace: ns1
      annotations:
        kubernetes.io/ingress.class: "citrix-def-part-ns1"
        ingress.citrix.com/frontend-ip: "< ADC VIP IP >"
    spec:
      rules:
      - host: apache-ns1.com
        http:
          paths:
          - backend:
              service:
                name: apache-ns1
                port:
                  number: 80
            pathType: Prefix
            path: /index.html
    
  4. Le Citrix ingress controller dans ns1 configure les entités ADC dans la partition par défaut.

Configurations dans l’espace de noms ns2

  1. Déployez guestbook l’application dans ns2.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: ns2
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: redis-master
      namespace: ns2
      labels:
        app: redis
        tier: backend
        role: master
    spec:
      ports:
      - port: 6379
        targetPort: 6379
      selector:
        app: redis
        tier: backend
        role: master
    ---
    apiVersion: apps/v1 #  for k8s versions before 1.9.0 use apps/v1beta2  and before 1.8.0 use extensions/v1beta1
    kind: Deployment
    metadata:
      name: redis-master
      namespace: ns2
    spec:
      selector:
        matchLabels:
          app: redis
          role: master
          tier: backend
      replicas: 1
      template:
        metadata:
          labels:
            app: redis
            role: master
            tier: backend
        spec:
          containers:
          - name: master
            image: k8s.gcr.io/redis:e2e  # or just image: redis
            resources:
              requests:
                cpu: 100m
                memory: 100Mi
            ports:
            - containerPort: 6379
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: redis-slave
      namespace: ns2
      labels:
        app: redis
        tier: backend
        role: slave
    spec:
      ports:
      - port: 6379
      selector:
        app: redis
        tier: backend
        role: slave
    ---
    apiVersion: apps/v1 #  for k8s versions before 1.9.0 use apps/v1beta2  and before 1.8.0 use extensions/v1beta1
    kind: Deployment
    metadata:
      name: redis-slave
      namespace: ns2
    spec:
      selector:
        matchLabels:
          app: redis
          role: slave
          tier: backend
      replicas: 2
      template:
        metadata:
          labels:
            app: redis
            role: slave
            tier: backend
        spec:
          containers:
          - name: slave
            image: gcr.io/google_samples/gb-redisslave:v1
            resources:
              requests:
                cpu: 100m
                memory: 100Mi
            env:
            - name: GET_HOSTS_FROM
              value: dns
              # If your cluster config does not include a dns service, then to
              # instead access an environment variable to find the master
              # service's host, comment out the 'value: dns' line above, and
              # uncomment the line below:
              # value: env
            ports:
            - containerPort: 6379
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: frontend
      namespace: ns2
      labels:
        app: guestbook
        tier: frontend
    spec:
      # if your cluster supports it, uncomment the following to automatically create
      # an external load-balanced IP for the frontend service.
      # type: LoadBalancer
      ports:
      - port: 80
      selector:
        app: guestbook
        tier: frontend
    ---
    apiVersion: apps/v1 #  for k8s versions before 1.9.0 use apps/v1beta2  and before 1.8.0 use extensions/v1beta1
    kind: Deployment
    metadata:
      name: frontend
      namespace: ns2
    spec:
      selector:
        matchLabels:
          app: guestbook
          tier: frontend
      replicas: 3
      template:
        metadata:
          labels:
            app: guestbook
            tier: frontend
        spec:
          containers:
          - name: php-redis
            image: gcr.io/google-samples/gb-frontend:v4
            resources:
              requests:
                cpu: 100m
                memory: 100Mi
            env:
            - name: GET_HOSTS_FROM
              value: dns
              # If your cluster config does not include a dns service, then to
              # instead access environment variables to find service host
              # info, comment out the 'value: dns' line above, and uncomment the
              # line below:
              # value: env
            ports:
            - containerPort: 80
    
  2. Déployez le Citrix ingress controller dans l’espace de noms ns2.

    Assurez-vous d’utiliser les informations d’identification de l’utilisateur qui sont liées à la partition p1.

    helm install cic-adm-part-p1 citrix/citrix-ingress-controller --set nsIP=<nsIP of ADC>,nsSNIPS='[<SNIPs in partition p1>]',license.accept=yes,adcCredentialSecret=admin-part-user-p1,ingressClass[0]=citrix-adm-part-ns2 --namespace ns2
    
  3. Déployez l’entrée pour l’application guestbook.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
      kubernetes.io/ingress.class: citrix-adm-part-ns2
      ingress.citrix.com/frontend-ip: "<VIP in partition 1>"
      name: guestbook-ingress
      namespace: ns2
    spec:
      rules:
      - host: www.guestbook.com
        http:
          paths:
          - backend:
              service:
                name: frontend
                port:
                  number: 80
            path: /
            pathType: Prefix
    
  4. Le Citrix ingress controller dans ns2 configure les entités ADC dans la partition p1.

Déployer le Citrix ingress controller pour Citrix ADC avec des partitions d’administration