Contrôleur d'entrée Citrix ADC

Routage de contenu avancé pour Kubernetes avec Citrix ADC

Kubernetes native Ingress propose un routage de base basé sur l’hôte et le chemin d’accès. Toutefois, d’autres techniques de routage avancées telles que le routage basé sur des valeurs d’en-tête ou des chaînes de requête ne sont pas prises en charge dans la structure Ingress. Vous pouvez exposer ces fonctionnalités sur Kubernetes Ingress via les annotations Ingress, mais les annotations sont complexes à gérer et à valider.

Vous pouvez exposer les fonctionnalités avancées de routage de contenu fournies par Citrix ADC en tant qu’API de définition de ressource personnalisée (CRD) pour Kubernetes.

À l’aide de CRD de routage de contenu, vous pouvez router le trafic en fonction des paramètres suivants :

  • Nom d’hôte
  • Chemin d’accès URL
  • en-têtes HTTP
  • Cookie
  • Paramètres de requête
  • Méthode HTTP
  • Expression de stratégie Citrix ADC

Remarque :

Une ressource d’entrée et des CRD de routage de contenu ne peuvent pas coexister pour le même point de terminaison (adresse IP et port). L’utilisation de CRD de routage de contenu avec entrée n’est pas prise en charge.

La fonctionnalité avancée de routage de contenu est exposée dans Kubernetes avec les CRD suivants :

  • Listener
  • HTTPRoute

CRD de routage de contenu

CRD Listener

Un objet CRD Listener représente les informations de point de terminaison telles que l’adresse IP virtuelle, le port, les certificats et d’autres configurations frontales. Il définit également les actions par défaut telles que l’envoi du trafic par défaut vers un back-end ou la redirection du trafic. Un objet CRD Listener peut faire référence à des objets CRD HTTPRoute qui représentent la logique de routage HTTP pour la demande HTTP entrante.

Pour obtenir la définition complète du CRD, reportez-vous au CRD Listener. Pour obtenir des informations complètes sur tous les attributs du CRD Listener, reportez-vous à la documentation du CRD Listener.

Le CRD Listener prend en charge les profils HTTP, SSL et TCP. À l’aide de ces profils, vous pouvez personnaliser le comportement du protocole par défaut. Le CRD Listener prend également en charge le profil analytique qui permet à Citrix ADC d’exporter le type de transactions ou de données vers différents points de terminaison. Pour plus d’informations sur la prise en charge des profils pour Listener CRD, reportez-vous à la section Prise en charge des profils pour le CRD Listener.

Déployer le CRD Listener

  1. Téléchargez le CRD Listener.

  2. Déployez le CRD Listener avec la commande suivante.

    Kubectl create -f  Listener.yaml
    

    Exemple :

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

Comment écrire des objets CRD Listener

Après avoir déployé le CRD fourni par Citrix dans le cluster Kubernetes, vous pouvez définir la configuration du module d’écoute dans un fichier YAML. Dans le fichier YAML, utilisez Listener dans le champ type et dans la section de spécification, ajoutez les attributs CRD Listener en fonction de vos besoins pour la configuration du module d’écoute. Après avoir déployé le fichier YAML, le Citrix ingress controller applique la configuration du module d’écoute sur le périphérique Citrix ADC d’entrée.

Voici un exemple de définition d’objet CRD Listener nommé 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-->

Dans cet exemple, un écouteur expose un point de terminaison HTTPS. Dans la section des certificats, les certificats SSL pour le point de terminaison sont configurés à l’aide de secrets Kubernetes nommés my-secret et other-secret d’un certificat préconfiguré ADC par défaut avec certkey nommé second-secret. L’action par défaut pour l’écouteur est configurée en tant que service Kubernetes. Les itinéraires sont attachés à l’écouteur à l’aide de sélecteurs d’étiquettes et de références d’itinéraires individuelles à l’aide du nom et de l’espace de noms.

Après avoir défini l’objet CRD Listener dans le fichier YAML, déployez le fichier YAML à l’aide de la commande suivante. Dans cet exemple, Listener-crd.yaml correspond à la définition YAML.

Kubectl create -f  Listener-crd.yaml

CRD de route HTTP

Un objet CRD HTTPRoute représente la logique de routage HTTP pour les demandes HTTP entrantes. Vous pouvez utiliser une combinaison de différents paramètres HTTP tels que le nom d’hôte, le chemin, les en-têtes, les paramètres de requête et les cookies pour acheminer le trafic entrant vers un service principal. Un objet HTTPRoute peut être attaché à un ou plusieurs objets Listener qui représentent les informations de point final. Vous pouvez avoir une ou plusieurs règles dans un objet HTTPRoute, chaque règle spécifiant une action qui lui est associée. L’ordre d’évaluation des règles au sein d’un objet HTTPRoute est le même que l’ordre mentionné dans l’objet. Par exemple, s’il existe deux règles avec la règle d’ordre1 et la règle2, si la règle1 est écrite avant la règle2, la règle1 est évaluée en premier avant la règle2.

La définition CRD HTTPRoute est disponible sur HTTPRoute.yaml. Pour obtenir des informations complètes sur les attributs de CRD de route HTTP, consultez la documentation HTTPRoute CRD.

Citrix prend désormais en charge la configuration de la ressource CRD de route HTTP en tant que moteur de ressource dans la version Ingress with Kubernetes Ingress. networking.k8s.io/v1Grâce à cette fonctionnalité, vous pouvez étendre les fonctionnalités avancées de routage de contenu à Ingress. Pour plus d’informations, consultez la section Routage de contenu avancé pour Kubernetes Ingress à l’aide de HTTPRoute CRD.

Déployer le CRD HTTPRoute

Effectuez les opérations suivantes pour déployer le CRD HTTPRoute :

  1. Téléchargez le fichier HTTPRoute.yaml.

  2. Appliquez le CRD HTTPRoute dans votre cluster à l’aide de la commande suivante.

    Kubectl appliquer -f http : //route.yaml

    Exemple :

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

Comment écrire des objets CRD HTTPRoute

Une fois que vous avez déployé le CRD HTTPRoute, vous pouvez définir la configuration de l’itinéraire HTTP dans un fichier YAML. Dans le fichier YAML, utilisez HTTPRoute dans le champ type et dans la section de spécification, ajoutez les attributs CRD HTTPRoute en fonction de vos besoins pour la configuration de l’itinéraire HTTP.

Voici un exemple de définition d’objet CRD HTTPRoute nommé comme 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-->

Dans cet exemple, toute demande dont le nom d’en-tête correspond my-header est acheminée vers le service d’application mobile et tout le reste du trafic est acheminé vers le service d’application par défaut. Pour des explications détaillées et les spécifications de l’API de HTTPRoute, voir CRD HTTPRoute.

Après avoir défini les routes HTTP dans le fichier YAML, déployez le fichier YAML pour l’objet CRD HTTPRoute à l’aide de la commande suivante. Dans cet exemple, Route-crd.yaml correspond à la définition YAML.

Kubectl create -f  Route-crd.yaml

Une fois que vous avez déployé le fichier YAML, le Citrix ingress controller applique la configuration d’itinéraire HTTP sur le périphérique Citrix ADC d’entrée.

Attachement d’objets CRD HTTPRoute à un objet CRD Listener

Vous pouvez attacher des objets CRD HTTPRoute à un objet CRD Listener de deux manières :

  • Utiliser le nom et l’espace de noms
  • Utilisation des étiquettes et du sélecteur

Attachement d’objets CRD HTTPRoute en utilisant un nom et un espace de

Dans cette approche, un objet CRD Listener fait explicitement référence à un ou plusieurs objets HTTPRoute en spécifiant le nom et l’espace de noms dans la section routes. L’ordre d’évaluation des objets HTTPRoute est le même que l’ordre spécifié dans l’objet CRD Listener, le premier objet HTTPRoute étant évalué en premier et ainsi de suite.

Par exemple, un extrait de l’objet CRD Listener s’affiche comme suit.

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

Dans cet exemple, l’objet CRD HTTPRoute nommé route1 est évalué avant l’objet HTTPRoute nommé route2.

Attachement d’un objet CRD HTTPRoute à l’aide d’étiquettes et

Vous pouvez également attacher des objets HTTPRoute à un objet Listener à l’aide d’étiquettes et d’un sélecteur. Vous pouvez spécifier un ou plusieurs libellés dans l’objet CRD Listener. Tous les objets HTTPRoute qui correspondent aux étiquettes sont automatiquement liés à l’objet Listener et les règles sont créées dans Citrix ADC. Lorsque vous utilisez cette approche, il n’existe aucun ordre d’évaluation particulier entre plusieurs objets HTTPRoute. La seule exception est un objet HTTPRoute avec un itinéraire par défaut (un itinéraire avec juste un nom d’hôte ou un chemin «/») qui est évalué comme le dernier objet.

Par exemple, l’extrait d’une ressource d’écoute est le suivant :

routes:
- labelSelector:
    team: team1
Routage de contenu avancé pour Kubernetes avec Citrix ADC