Soporte de clase Ingress

Last published : Oct 02, 2026
Related information
Configurar

¿Qué es una clase Ingress?

En un clúster de Kubernetes, puede haber varios controladores de Ingress y es necesario tener una forma de asociar un recurso de Ingress particular con un controlador de Ingress.
Puede especificar el controlador de Ingress que debe manejar el recurso de Ingress utilizando ingressClassName en la definición de su recurso de Ingress.

NetScaler Ingress Controller y clases Ingress

El NetScaler Ingress Controller admite la aceptación de múltiples recursos de Ingress, que tienen spec.ingressClassName. Cada recurso de Ingress se puede asociar con una única ingress.class. Sin embargo, el Ingress Controller podría necesitar manejar varios recursos de Ingress de diferentes clases.
Puede asociar el Ingress Controller con varias clases de Ingress utilizando el argumento --ingress-classes en la sección spec del archivo YAML.
Si no se especifica ingress-classes para el Ingress Controller, entonces acepta todos los recursos de Ingress independientemente de la presencia de ingressClassName en el objeto Ingress.
Si se especifica ingress-classes, el Ingress Controller solo acepta aquellos recursos de Ingress que coincidan con ingressClassName. En tal caso, el Ingress Controller no procesa un recurso de Ingress sin ingress.class.
Nota: Los nombres de las clases Ingress no distinguen entre mayúsculas y minúsculas.

Ejemplos de configuraciones YAML con clases Ingress

A continuación se muestra el fragmento de un archivo YAML de ejemplo para asociar ingress-classes con el Ingress Controller. Esta configuración funciona en ambos casos: cuando el Ingress Controller se ejecuta como un pod independiente o como un sidecar con NetScaler CPX. En el fragmento YAML proporcionado, las siguientes clases de Ingress 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
A continuación se muestra el fragmento de un archivo YAML de Ingress donde se representa la asociación de clases de Ingress. En el ejemplo dado, un recurso de Ingress llamado web-ingress está asociado con la clase de Ingress my-custom-class. Si el NetScaler Ingress Controller está configurado para aceptar my-custom-class, procesa este recurso de Ingress.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
  name: web-ingress
spec:
  ingressClassName: my-custom-class

Soporte para 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, se añade un nuevo recurso llamado IngressClass a la API de Ingress. Mediante este recurso, puede asociar controladores Ingress específicos a Ingresses. Para obtener más información sobre el recurso IngressClass, consulte 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
Un recurso IngressClass debe hacer referencia a la clase de Ingress asociada con el controlador que debe implementar las reglas de Ingress, 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
El NetScaler Ingress Controller utiliza las siguientes reglas para hacer coincidir los Ingresses.
  • Si el NetScaler 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 Ingress
    • Si la versión de Kubernetes es superior o igual a 1.19 (se admite el recurso IngressClass V1)
      • Coincide con cualquier objeto Ingress en el que el campo spec.ingressClassName no esté establecido.
      • Coincide con cualquier Ingress 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 NetScaler Ingress Controller se inicia con una o más clases de Ingress establecidas mediante el argumento --ingress-classes.
    • Si la versión de Kubernetes es inferior a 1.19 (se admite el recurso IngressClass V1)
      • Coincide con cualquier Ingress con la anotación de clase de Ingress kubernetes.io/ingress.class que coincida con la de las clases de Ingress configuradas.
    • Si la versión de Kubernetes es superior 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á en desuso, 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 donde 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 utilizando la anotación ingressclass.kubernetes.io/is-default-class. Para obtener más información, consulte la documentación de Kubernetes.
Nota:
  • Si se definen tanto la anotación como spec.ingressClassName, la anotación se compara antes que spec.ingressClassName. Si la anotación no coincide, no se realiza la operación de coincidencia para el campo spec.ingressClassName.
  • Cuando se utilizan gráficos de Helm para instalar NetScaler Ingress Controller, si el recurso IngressClass es compatible y NetScaler 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 Ingress gestionados por NetScaler Ingress Controller con las direcciones IP asignadas, especifique el argumento de línea de comandos --update-ingress-status yes al iniciar NetScaler Ingress Controller.
Nota:
Para implementaciones de Helm, el parámetro equivalente del gráfico de Helm para update-ingress-status es updateIngressStatus, que debe establecerse en true.
Esta característica es compatible tanto con implementaciones de NSIC independientes como con sidecar. Para un NSIC implementado como sidecar, esta característica es compatible a partir de la versión 2.2.10 de NSIC.

Actualización del estado de Ingress para implementaciones sidecar

En Kubernetes, Ingress se puede utilizar como un único punto de entrada para exponer múltiples aplicaciones al mundo exterior. El Ingress tendría un campo Address (Status.LoadBalancer.IP) que se actualiza después de la creación exitosa 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 balanceador de carga en la nube.
En implementaciones en la nube, NetScaler CPX junto con el controlador de Ingress se expone utilizando un servicio de type LoadBalancer que, a su vez, crea un balanceador de carga en la nube. El balanceador de carga en la nube expone entonces el NetScaler CPX junto con el controlador de Ingress. Por lo tanto, los recursos de Ingress expuestos con NetScaler CPX deben actualizarse utilizando la dirección IP pública o el nombre de host del balanceador de carga en la nube.
Esta actualización también es aplicable a implementaciones locales.
  • En implementaciones de Ingress de dos niveles, en las que NetScaler CPX se expone utilizando un servicio de tipo LoadBalancer al Ingress NetScaler VPX de nivel 1, el campo Address (Status.LoadBalancer.IP) de los recursos de Ingress operados por NetScaler CPX se actualiza con la dirección VIP.
  • En implementaciones de Ingress de dos niveles, en las que NetScaler CPX se expone utilizando un servicio de tipo ClusterIP o NodePort, el campo Address (Status.LoadBalancer.IP) de los recursos de Ingress operados por NetScaler CPX se actualiza con la dirección IP del clúster del servicio CPX.

Salida de Ingress de ejemplo después de una actualización de estado de Ingress

A continuación se muestra una salida de Ingress de ejemplo después de la actualización del estado de Ingress:
    $ kubectl get ingress

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