Ingress Controller de Citrix ADC

Redirección de contenido avanzado para Kubernetes con Citrix ADC

Ingress nativo de Kubernetes ofrece una redirección básica basada en host y rutas. Sin embargo, otras técnicas de redirección avanzadas, como la redirección basada en valores de encabezado o cadenas de consulta, no se admiten en la estructura Ingress. Puede exponer estas funciones en Kubernetes Ingress a través de anotaciones de Ingress, pero las anotaciones son complejas de administrar y validar.

Puede exponer las capacidades avanzadas de redirección de contenido proporcionadas por Citrix ADC como una API de definición de recursos personalizada (CRD) para Kubernetes.

Con los CRD de redirección de contenido, puede redirigir el tráfico en función de los siguientes parámetros:

  • Nombre de host
  • Ruta de URL
  • Encabezados HTTP
  • Cookie
  • Parámetros de consulta
  • Método HTTP
  • Expresión de directiva de Citrix ADC

Nota:

Un recurso de entrada y un CRD de redirección de contenido no pueden coexistir para el mismo punto final (dirección IP y puerto). No se admite el uso de CRD de redirección de contenido con Ingress.

La función de redirección de contenido avanzado se expone en Kubernetes con los siguientes CRD:

  • Oyente
  • Ruta HTTP

CRD de redirección de contenido

CRD oyente

Un objeto Listener CRD representa la información de punto final, como la dirección IP virtual, el puerto, los certificados y otras configuraciones de front-end. También define las acciones predeterminadas, como enviar el tráfico predeterminado a un back-end o redirigir el tráfico. Un objeto CRD Listener puede hacer referencia a objetos CRD HTTPRoute que representan la lógica de redirección HTTP para la solicitud HTTP entrante.

Para obtener la definición completa de CRD, consulte la CRD de oyente. Para obtener información completa sobre todos los atributos de la CRD de Listener, consulte la documentación de Listener CRD.

Listener CRD admite perfiles HTTP, SSL y TCP. Con estos perfiles, puede personalizar el comportamiento del protocolo predeterminado. Listener CRD también admite el perfil de análisis que permite a Citrix ADC exportar el tipo de transacciones o datos a diferentes puntos finales. Para obtener más información sobre la compatibilidad de perfiles para la CRD de oyente, consulte la compatibilidad de perfiles para la CRD de escucha.

Implementar el CRD de escucha

  1. Descargue el CRD de Listener.

  2. Implemente el CRD de escucha con el siguiente comando.

    Kubectl create -f  Listener.yaml
    

    Ejemplo:

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

Cómo escribir objetos Listener CRD

Después de implementar la CRD proporcionada por Citrix en el clúster de Kubernetes, puede definir la configuración del agente de escucha en un archivo YAML. En el archivo YAML, use Listener en el campo kind y en la sección de especificaciones agregue los atributos CRD del listener según sus requisitos para la configuración de la escucha. Después de implementar el archivo YAML, el Citrix Ingress Controller aplica la configuración del agente de escucha en el dispositivo Citrix ADC de entrada.

A continuación se presenta una definición de objeto CRD de escucha de ejemplo denominada 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-->

En este ejemplo, un agente de escucha expone un extremo HTTPS. En la sección de certificados, los certificados SSL para el dispositivo de punto final se configuran con secretos de Kubernetes denominados my-secret y other-secret, y un certificado ADC preconfigurado predeterminado con certkey llamado second-secret. La acción predeterminada del agente de escucha se configura como un servicio de Kubernetes. Las rutas se adjuntan con el oyente mediante selectores de etiquetas y referencias de rutas individuales mediante el nombre y el espacio de nombres.

Después de definir el objeto Listener CRD en el archivo YAML, implemente el archivo YAML con el siguiente comando. En este ejemplo, Listener-crd.yaml es la definición de YAML.

Kubectl create -f  Listener-crd.yaml

CRD de ruta HTTP

Un objeto CRD HTTPRoute representa la lógica de redirección HTTP para las solicitudes HTTP entrantes. Puede usar una combinación de varios parámetros HTTP, como el nombre de host, la ruta, los encabezados, los parámetros de consulta y las cookies, para redirigir el tráfico entrante a un servicio de back-end. Un objeto HTTPRoute se puede enlazar a uno o más objetos Listener que representan la información del punto final. Puede tener una o más reglas en un objeto HTTPRoute, y cada regla especifica una acción asociada a él. El orden de evaluación de las reglas dentro de un objeto HTTPRoute es el mismo que el orden mencionado en el objeto. Por ejemplo, si hay dos reglas con el orden rule1 y rule2, con rule1 se escribe antes que rule2, rule1 se evalúa primero antes que rule2.

La definición de CRD de HTTPRoute está disponible en http://route.yaml. Para obtener información completa sobre los atributos de la CRD de ruta HTTP, consulte la documentación de CRD de HTTPRoute.

Ahora, Citrix admite la configuración del recurso CRD de ruta HTTP como backend de recursos en la versión Ingress with Kubernetes Ingress. networking.k8s.io/v1Con esta función, puede ampliar las capacidades avanzadas de redirección de contenido a Ingress. Para obtener más información, consulte Redirección de contenido avanzado para Kubernetes Ingress mediante la CRD de HTTPRoute.

Implementar la CRD de HTTPRoute

Realice lo siguiente para implementar la CRD de HTTPRoute:

  1. Descarga el archivo Httproute.yaml.

  2. Aplique la CRD de HTTPRoute en su clúster mediante el siguiente comando.

    Kubectl aplica -f - http://route.yaml

    Ejemplo:

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

Cómo escribir objetos CRD HTTPRoute

Una vez que haya implementado la CRD de HTTPRoute, puede definir la configuración de la ruta HTTP en un archivo YAML. En el archivo YAML, use HTTPRoute en el campo kind y en la sección de especificaciones agregue los atributos CRD HTTPRoute según sus requisitos para la configuración de ruta HTTP.

A continuación se presenta un ejemplo de definición de objeto CRD de HTTPRoute denominada 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-->

En este ejemplo, cualquier solicitud con un nombre de encabezado que coincida con my-header se redirige al servicio de aplicación móvil y el resto del tráfico se redirige al servicio de aplicación predeterminado. Para obtener explicaciones detalladas y especificaciones de API de HTTPRoute, consulte HTTPRoute CRD.

Después de haber definido las rutas HTTP en el archivo YAML, implemente el archivo YAML para el objeto CRD HTTPRoute mediante el siguiente comando. En este ejemplo, Route-crd.yaml es la definición de YAML.

Kubectl create -f  Route-crd.yaml

Una vez que implementa el archivo YAML, el Citrix Ingress Controller aplica la configuración de ruta HTTP en el dispositivo Citrix ADC de entrada.

Adjuntar objetos CRD HTTPRoute a un objeto CRD Listener

Puede adjuntar objetos CRD HTTPRoute a un objeto CRD Listener de dos maneras:

  • Usar nombre y espacio de nombres
  • Uso de etiquetas y selector

Adjuntar objetos CRD HTTPRoute mediante el nombre y el espacio de nombres

En este enfoque, un objeto CRD Listener hace referencia explícitamente a uno o más objetos HTTPRoute especificando el nombre y el espacio de nombres en la sección routes. El orden de evaluación de los objetos HTTPRoute es el mismo que el orden especificado en el objeto CRD Listener con el primer objeto HTTPRoute que se evalúa primero y así sucesivamente.

Por ejemplo, se muestra un fragmento del objeto CRD Listener de la siguiente manera.

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

En este ejemplo, el objeto CRD HTTPRoute denominado route1 se evalúa antes que el objeto HTTPRoute denominado route2.

Adjuntar un objeto CRD HTTPRoute mediante etiquetas y selector

También puede adjuntar objetos HTTPRoute a un objeto Listener mediante etiquetas y selectores. Puede especificar una o más etiquetas en el objeto CRD Listener. Todos los objetos HTTPRoute que coincidan con las etiquetas se vinculan automáticamente al objeto Listener y las reglas se crean en Citrix ADC. Cuando se utiliza este enfoque, no hay un orden de evaluación particular entre varios objetos HTTPRoute. La única excepción es un objeto HTTPRoute con una ruta predeterminada (una ruta con solo un nombre de host o una ruta ‘/’) que se evalúa como el último objeto.

Por ejemplo, el fragmento de un recurso de escucha es el siguiente:

routes:
- labelSelector:
    team: team1
Redirección de contenido avanzado para Kubernetes con Citrix ADC