Ingress Controller de Citrix ADC

Soporte de clases de entrada

¿Qué es la clase Ingress?

En un clúster de Kubernetes, puede haber varios controladores de entrada y debes tener una forma de asociar un recurso de entrada concreto con un controlador de entrada.

Puede especificar el controlador de entrada que debe gestionar el recurso de entrada mediante la anotación kubernetes.io/ingress.class en la definición del recurso de entrada.

Citrix Ingress Controller y clases Ingress

El Citrix Ingress Controller admite la aceptación de varios recursos de entrada, que tienen anotaciones kuberneters.io/ingress.class. Cada recurso de entrada solo se puede asociar a una ingress.class. Sin embargo, es posible que el Ingress Controller necesite gestionar varios recursos de entrada de diferentes clases.

Puede asociar el Ingress Controller con varias clases de entrada mediante el argumento --ingress-classes de la sección spec del archivo YAML.

Si no ingress-classes se especifica para el Ingress Controller, acepta todos los recursos de entrada, independientemente de la presencia de la anotación kubernetes.io/ingress.class en el objeto de entrada.

Si ingress-classes se especifica, el Ingress Controller solo acepta los recursos de entrada que coinciden con la anotación kubernetes.io/ingress.class. En tal caso, el controlador de Ingress no procesa un recurso de Ingress sin la anotación ingress.class.

Nota: Los nombres de clase de entrada no distinguen entre mayúsculas y minúsculas.

Configuraciones YAML de ejemplo con clases Ingress

A continuación se presenta el fragmento de un archivo YAML de ejemplo para asociar ingress-classes al Ingress Controller. Esta configuración funciona en ambos casos en los que Ingress Controller se ejecuta como un pod independiente o se ejecuta como un sidecar con Citrix ADC CPX. En el fragmento YAML dado, las siguientes clases de entrada están asociadas con el Ingress Controller.

  • my-custom-class

  • Citrix

spec:
    serviceAccountName: cic-k8s-role
    containers:
    - name: cic-k8s-ingress-controller
      image:"quay.io/citrix/citrix-k8s-ingress-controller:latest"
      # specify the ingress classes names to be supportedbyIngress Controller in args section.
      # First line should be --ingress-classes, andeverysubsequent line should be
      # the name of allowed ingress class. In the givenexampletwo classes named
      # "citrix" and "my-custom-class" are accepted. Thiswill be case-insensitive.
      args:
        - --ingress-classes
          Citrix
          my-custom-class
<!--NeedCopy-->

A continuación se presenta el fragmento de un archivo YAML de entrada en el que se representa la asociación de clase Ingress. En el ejemplo dado, un recurso Ingress denominado web-ingress se asocia a la clase de entrada my-custom-class. Si el Citrix Ingress Controller está configurado para aceptar my-custom-class, procesa este recurso Ingress.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: my-custom-class
  name: web-ingress
<!--NeedCopy-->

Compatibilidad con Ingress V1 e IngressClass

Con la versión 1.19 de Kubernetes, el recurso Ingress está disponible de forma general. Como parte de este cambio, IngressClass se agrega un nuevo recurso llamado as a la API de ingreso. Con este recurso, puede asociar controladores de Ingress específicos a Ingress. Para obtener más información sobre el recurso IngressClass, consulta la documentación de Kubernetes.

A continuación se muestra un recurso IngressClass de ejemplo.


apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: citrix
spec:
  controller: citrix.com/ingress-controller

<!--NeedCopy-->

Un IngressClassrecurso debe hacer referencia a la clase de entrada asociada con el controlador que debe implementar las reglas de entrada, como se muestra a continuación:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
spec:
  ingressClassName: citrix
  rules:
  - host: abc.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80
<!--NeedCopy-->

El Citrix Ingress Controller usa las siguientes reglas para coincidir con los Ingresos.

  • Si el Citrix Ingress Controller se inicia sin especificar el argumento --ingress-classes:

    • Si la versión de Kubernetes es inferior a 1.19 (se admite el recurso IngressClass V1)

      • Coincide con cualquier objeto de entrada
    • Si la versión de Kubernetes es mayor o igual a 1.19 (se admite el recurso IngressClass V1)

      • Coincide con cualquier objeto de entrada en el que el campo spec.ingressClassName no esté establecido.

      • Coincide con cualquier entrada si el campo spec.ingressClassName del objeto Ingress está establecido y existe un recurso v1.IngressClass con el mismo nombre y el campo spec.controller del recurso es citrix.com/ingress-controller.

  • Si el Citrix Ingress Controller se inicia con una o más clases de entrada establecidas mediante el argumento --ingress-classes.

    • Si la versión de Kubernetes es inferior a 1.19 (se admite el recurso IngressClass V1)

      • Hace coincidir cualquier entrada con la anotación de la clase de entrada que kubernetes.io/ingress.class coincide con la de las clases de entrada configuradas.
    • Si la versión de Kubernetes es mayor o igual a 1.19 (se admite el recurso IngressClass V1).

      • Coincide con cualquier entrada en la que la anotación de clase de entrada kubernetes.io/ingress.class coincida con las clases de entrada configuradas. Esta anotación está obsoleta, pero tiene mayor precedencia sobre el campo spec.IngressClassName para admitir la compatibilidad con versiones anteriores.

      • Coincide con cualquier objeto de entrada, si existe un recurso v1.IngressClass con los siguientes atributos:

        • El nombre del recurso coincide con el valor del argumento --ingress-classes.

        • El campo spec.controller del recurso se establece como citrix.com/ingress-controller.

        • El nombre del recurso coincide con el campo spec.ingressClassName del objeto Ingress.

      • Coincide con cualquier objeto de entrada en el que el campo spec.ingressClassName no esté establecido y si existe un recurso v1.IngressClass con los siguientes atributos:

        • El nombre de los recursos coincide con el valor del argumento --ingress-classes.

        • El campo spec.controller del recurso se establece como citrix.com/ingress-controller.

        • El recurso se configura como la clase predeterminada mediante la anotación ingressclass.kubernetes.io/is-default-class. Para obtener más información, consulta la documentación de Kubernetes.

Nota:

  • Si se definen tanto la anotación como spec.ingressClassName, la anotación coincide antes que spec.ingressClassName. Si la anotación no coincide, no se lleva a cabo la operación de coincidencia para el campo spec.ingressClassName.

  • Cuando utiliza gráficos Helm para instalar el Citrix Ingress Controller, si el recurso IngressClass es compatible y el Citrix Ingress Controller se implementa con el argumento --ingress-classes, el recurso v1.IngressClass se crea de forma predeterminada.

Actualización del estado de Ingress para los recursos de Ingress con la dirección IP especificada

Para actualizar el campo Status.LoadBalancer.Ingress de los recursos de entrada administrados por el Citrix Ingress Controller con las direcciones IP asignadas, especifique el argumento de línea de comandos --update-ingress-status yes cuando inicie el Citrix Ingress Controller. Esta función solo se admite para el Citrix Ingress Controller implementado como un pod independiente para administrar Citrix ADC VPX o MPX. Para Citrix ADC CPX implementados como sidecars, esta función no es compatible.

A continuación se muestra un ejemplo de YAML con el argumento de línea de --update-ingress-status yes comandos habilitado.

args:
    - --feature-node-watch false
    - --ipam citrix-ipam-controller
    - --update-ingress-status yes
    imagePullPolicy: Always
<!--NeedCopy-->

Actualización del estado de entrada para implementaciones de sidecar

En Kubernetes, Ingress se puede usar como un único punto de entrada para exponer varias aplicaciones al mundo exterior. El Ingress tendría un campo Address (Status.LoadBalancer.IP) que se actualiza después de la creación correcta del Ingress. Este campo se actualiza con una dirección IP pública o un nombre de host a través del cual se puede acceder a la aplicación de Kubernetes. En implementaciones en la nube, este campo también puede ser la dirección IP o el nombre de host de un equilibrador de carga en la nube.

En las implementaciones en la nube, Citrix ADC CPX junto con el controlador de entrada se exponen mediante un servicio type LoadBalancer que, a su vez, crea un equilibrador de carga en la nube. A continuación, el equilibrador de carga en la nube expone Citrix ADC CPX junto con el controlador de entrada. Por lo tanto, los recursos de Ingress expuestos con Citrix ADC CPX deben actualizarse con la dirección IP pública o el nombre de host del equilibrador de carga en la nube.

Esto se aplica incluso en implementaciones locales. En implementaciones de entrada de doble nivel, en las que Citrix ADC CPX se expone como tipo de servicio LoadBalancer a la entrada de Citrix ADC VPX de nivel 1, los recursos de entrada operados por Citrix ADC CPX se actualizan con la dirección VIP.

En este tema se proporciona información sobre cómo habilitar la actualización del estado de entrada para Citrix ADC CPX con el Citrix Ingress Controller como implementaciones de sidecar.

Nota: La actualización del estado de entrada para la función sidecar solo se admite en los servicios de tipo LoadBalancer.

Salida de entrada de muestra después de una actualización del estado de entrada

A continuación, se muestra un ejemplo de salida de entrada después de la actualización del estado de entrada:

    $ kubectl get ingress

    NAME             HOSTS              ADDRESS                           PORTS    AGE                                       
    sample-ingress   sample.citrix.com   sample.abc.somexampledomain.com   80      1d

Habilitar la actualización del estado de entrada para las implementaciones de sidecar

Puede habilitar la función de actualización del estado de entrada para implementaciones de automóviles laterales especificando el siguiente argumento en el archivo YAML de Citrix ADC CPX. Debe agregar el argumento a la sección args de Citrix ADC CPX en el archivo YAML de implementación para Citrix ADC CPX con el Citrix Ingress Controller.

    args:
    - --cpx-service <namespace>/<name-of-the-type-load-balancer-service-exposing-cpx>

En la siguiente tabla se describe el argumento de la actualización de entrada en detalle.

Palabra clave/variable Descripción
--cpx-service Especifica el argumento para habilitar esta función.
<namespace>/<name-of-the-type-load-balancer-service-exposing-cpx> Especifica el formato en el que se proporcionará el valor del argumento.
<namespace> Especifica el espacio de nombres en el que se crea el servicio.
<name-of-the-type-load-balancer-service-exposing-cpx> Especifica el nombre del servicio que expone Citrix ADC CPX.

Nota:

La actualización del estado de entrada para la función sidecar solo se admite en los servicios de tipo LoadBalancer. El servicio definido en el argumento --cpx-service default/some-cpx-service debe ser un servicio de Kubernetes de type LoadBalancer.