Operador de Ingress

El operador de entrada de Red Hat OpenShift implementa reglas de enrutamiento que se aplican a todo el tráfico entrante para las aplicaciones de su clúster.

Los controladores de Ingress los gestionan el operador de Ingress. Durante la creación del clúster, el controlador de Ingress predeterminado se registra con el subdominio de Ingress predeterminado para el clúster con el formato <cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. Cuando registra su aplicación con este subdominio creando un recurso de ruta, el controlador de Ingress garantiza que las solicitudes a su aplicación a través de este subdominio se envíen por proxy correctamente a los pods de aplicación. Para ver el controlador de Ingress predeterminado en el clúster, ejecute oc describe ingresscontroller/default -n openshift-ingress-operator.

Si desea registrar la app con un dominio distinto, puede crear un controlador de Ingress personalizado que en su lugar implemente reglas de direccionamiento para un dominio personalizado.

Controlador de Ingress

Se crea un controlador de Ingress de Red Hat OpenShift basado en HAProxy para cada IngressController, y se crea un servicio de controlador de Ingress en cada zona donde tiene nodos de trabajador.

El operador de Ingress configura el controlador de Ingress con el mismo dominio que se ha especificado en el IngressController. El controlador de Ingress escucha las solicitudes de servicio HTTP, HTTPS o TCP de entrada a través de ese dominio. A continuación, el componente de servicio del equilibrador de carga del controlador de Ingress reenvía las solicitudes a los pods para esa aplicación, solo de acuerdo con las reglas definidas en el recurso de ruta e implementadas por el controlador de Ingress.

Si tiene un clúster multizona, se despliega un controlador de Ingress de alta disponibilidad en el clúster y se configura con un equilibrador de carga de VPC multizona. Se necesitan dos nodos de trabajador por zona para que las dos réplicas del controlador de Ingress se puedan desplegar y actualizar correctamente.

Si crea manualmente un controlador de Ingress, el controlador de Ingress no se registra automáticamente con el subdominio de Ingress o con una aplicación en el clúster.

Recurso de ruta

Para exponer una aplicación utilizando la ruta, debe crear un servicio de Kubernetes para la aplicación y registrarlo con el controlador de Ingress definiendo un recurso de ruta. El recurso de Ingress es un recurso de Red Hat OpenShift que define las reglas para direccionar las solicitudes entrantes para las aplicaciones.

El recurso de ruta también especifica la vía de acceso a los servicios de aplicaciones. Las vías de acceso a los servicios de app se añaden al subdominio de Ingress del clúster para formar un URL de app exclusivo, como por ejemplo mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1.

Es necesario un recurso de ruta para cada proyecto donde tenga aplicaciones que desee exponer.

• Si las aplicaciones del clúster están todas en el mismo proyecto, debe crear un recurso de ruta para definir las reglas de direccionamiento de las aplicaciones que desea exponer. Tenga en cuenta que si desea utilizar distintos dominios para las apps dentro del mismo proyecto, puede crear un recurso por dominio.
• Si las aplicaciones del clúster están en proyectos diferentes, debe crear un recurso de ruta para cada proyecto, para definir las reglas de direccionamiento de la aplicación.

Para obtener más información, consulte Planificación de redes para uno o varios proyectos.

Si desea personalizar las reglas de direccionamiento para la app, puede utilizar las anotaciones HAProxy específicas de la ruta que gestiona el tráfico para la app. Estas anotaciones soportadas tienen el formato haproxy.router.openshift.io/<annotation> o router.openshift.io/<annotation>. Tenga en cuenta que las anotaciones de IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) y las anotaciones de NGINX (nginx.ingress.kubernetes.io/<annotation>) no están soportadas para el controlador de Ingress o el recurso de ruta en Red Hat OpenShift versión 4.

Clúster de una sola zona

En el siguiente diagrama se muestra cómo Ingress dirige la comunicación procedente de internet a una app en un clúster clásico de una sola zona.

1. Un usuario envía una solicitud a la app accediendo al URL de la app. Este URL es el subdominio de Ingress del clúster, junto con la vía de acceso del recurso de Ingress de la aplicación expuesta, como por ejemplo mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Un servicio de sistema DNS resuelve el subdominio en el URL a la dirección IP pública portátil del equilibrador de carga que expone el controlador de Ingress en el clúster.

3. Basándose en la dirección IP resuelta, el cliente envía la solicitud al servicio de controlador de Ingress.

4. El controlador de Ingress comprueba las reglas de direccionamiento que implementa el controlador de Ingress para una regla de direccionamiento para la vía de acceso de myapp. Si se encuentra una regla coincidente, la solicitud se envía por proxy de acuerdo con las reglas que ha definido en el controlador de Ingress y el recurso de ruta al pod donde se despliega la aplicación. La dirección IP de origen del paquete se cambia por la dirección IP del nodo de trabajador donde se ejecuta el pod del controlador de Ingress. Si se despliegan varias instancias de aplicación en el clúster, la carga del controlador de Ingress equilibra las solicitudes entre los pods de aplicación.

5. Cuando la aplicación devuelve un paquete de respuesta, utiliza la dirección IP del nodo de trabajador donde existe el controlador de Ingress que reenvió la solicitud. A continuación, el controlador de Ingress envía el paquete de respuesta al cliente.

Clúster multizona

En el siguiente diagrama se muestra cómo Ingress dirige la comunicación procedente de internet a una app en un clúster clásico multizona.

1. Un usuario envía una solicitud a la app accediendo al URL de la app. Este URL es el subdominio de Ingress del clúster, junto con la vía de acceso del recurso de Ingress de la aplicación expuesta, como por ejemplo mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Un servicio de sistema DNS resuelve el subdominio de ruta en la dirección IP pública flotante de un servicio de controlador de Ingress cuyo estado el MZLB ha notificado como correcto. El MZLB comprueba continuamente las direcciones IP públicas portátiles de los servicios que exponen el controlador de Ingress en cada zona del clúster. Los servicios de controlador de Ingress manejan las solicitudes en varias zonas en un ciclo de iteración.

3. El cliente envía la solicitud a la dirección IP del servicio que expone el controlador de Ingress.

4. El controlador de Ingress comprueba las reglas de direccionamiento que implementa el controlador de Ingress para la vía de acceso de myapp. Si se encuentra una regla coincidente, la solicitud se envía por proxy de acuerdo con las reglas que ha definido en el controlador de Ingress y el recurso de ruta al pod donde se despliega la aplicación. La dirección IP de origen del paquete se cambia por la dirección IP del nodo de trabajador donde se ejecuta el pod del controlador de Ingress. Si se despliegan varias instancias de aplicación en el clúster, el servicio de controlador de Ingress envía las solicitudes entre los pods de aplicación en todas las zonas.

5. Cuando la aplicación devuelve un paquete de respuesta, utiliza la dirección IP del nodo de trabajador donde existe el servicio de controlador de Ingress que reenvió la solicitud. A continuación, el controlador de Ingress envía el paquete de respuesta al cliente.

Clúster de VPC con un punto final de servicio en la nube público

Cuando se crea un clúster de VPC multizona con el punto final de servicio de nube pública habilitado, se crea un controlador de Ingress público de forma predeterminada. En el siguiente diagrama se muestra cómo Ingress dirige la comunicación procedente de Internet a una app en un clúster multizona de VPC.

1. Un usuario envía una solicitud a la app accediendo al URL de la app. Este URL es el subdominio de Ingress del clúster para la aplicación expuesta, junto con la vía de acceso del recurso de Ingress, como por ejemplo mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Un servicio DNS resuelve el subdominio de ruta en el nombre de host del equilibrador de carga de VPC que se asigna al controlador de Ingress. En los clústeres de VPC, las direcciones IP externas son flotantes y se mantienen detrás de un nombre de host asignado por VPC.

3. El equilibrador de carga de VPC resuelve el nombre de host de VPC en una dirección IP disponible en una zona del controlador de Ingress cuyo estado se ha notificado como correcto. El equilibrador de carga de VPC comprueba continuamente las direcciones IP externas del controlador de Ingress en cada zona del clúster.

4. Basándose en la dirección IP resuelta, el equilibrador de carga de VPC envía la solicitud a un controlador de Ingress.

5. El controlador de Ingress comprueba las reglas de direccionamiento que implementa el controlador de Ingress para la vía de acceso de myapp. Si se encuentra una regla coincidente, la solicitud se envía por proxy de acuerdo con las reglas que ha definido en el controlador de Ingress y el recurso de ruta al pod donde se despliega la aplicación. La dirección IP de origen del paquete se cambia por la dirección IP del nodo de trabajador donde se ejecuta el pod del controlador de Ingress. Si se despliegan varias instancias de aplicación en el clúster, la carga del controlador de Ingress equilibra las solicitudes entre los pods de aplicación en todas las zonas.

6. Cuando la aplicación devuelve un paquete de respuesta, utiliza la dirección IP del nodo de trabajador donde existe el servicio de controlador de Ingress que reenvió la solicitud. Luego el equilibrador de carga de VPC envía el paquete de respuesta al cliente.

Clúster de VPC con solo un punto final de servicio de nube privado

Cuando se crea un clúster de VPC multizona con solo el punto final de servicio de nube privada, se crea un controlador de Ingress privado de forma predeterminada. Solo los clientes que están conectados a su red de VPC privada pueden acceder a apps que están expuestas por un controlador de Ingress privado. En el siguiente diagrama se muestra cómo Ingress dirige la comunicación procedente de redes privadas a una app en un clúster multizona de VPC.

1. Un cliente que está conectado a su red privada de VPC envía una solicitud a su app utilizando el URL de la app. Este URL es el subdominio de Ingress del clúster para la aplicación expuesta, junto con la vía de acceso del recurso de Ingress, como por ejemplo mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp. Por ejemplo, puede utilizar la VPN de Virtual Private Cloud, IBM Cloud Transit Gateway o IBM Cloud Direct Link para permitir solicitudes desde una red en local, desde otra VPC o desde la infraestructura clásica de IBM Cloud hacia apps que se ejecuten en su clúster.

2. Un servicio DNS resuelve el subdominio de ruta en el nombre de host del equilibrador de carga de VPC que se asigna a los servicios para el controlador de Ingress. En los clústeres de VPC, las direcciones IP privadas de los servicios del controlador Ingress son flotantes y se mantienen detrás de un nombre de host asignado por VPC. Recuerde que aunque el registro de DNS del subdominio de la ruta está registrado en el sistema DNS público, se puede acceder a los servidores de resolución de DNS desde la VPC.

3. El equilibrador de carga de VPC privado resuelve el nombre de host de VPC en una dirección IP privada disponible de un servicio de controlador de Ingress que se ha notificado como un estado correcto. El equilibrador de carga de VPC comprueba continuamente las direcciones IP de los servicios que exponen el controlador de Ingress en cada zona del clúster.

4. Basándose en la dirección IP resuelta, el equilibrador de carga de VPC envía la solicitud a un servicio de controlador de Ingress.

5. El controlador de Ingress comprueba las reglas de direccionamiento que implementa el controlador de Ingress para la vía de acceso de myapp. Si se encuentra una regla coincidente, la solicitud se envía por proxy de acuerdo con las reglas que ha definido en el controlador de Ingress y el recurso de ruta al pod donde se despliega la aplicación. La dirección IP de origen del paquete se cambia por la dirección IP del nodo de trabajador donde se ejecuta el pod del controlador de Ingress. Si se despliegan varias instancias de aplicación en el clúster, la carga del controlador de Ingress equilibra las solicitudes entre los pods de aplicación en todas las zonas.

6. Cuando la aplicación devuelve un paquete de respuesta, utiliza la dirección IP del nodo de trabajador donde existe el controlador de Ingress que reenvió la solicitud de cliente. A continuación, el controlador de Ingress envía al cliente el paquete de respuesta a través del equilibrador de carga de VPC.