Acerca de Ingress
Ingress es un servicio que equilibra cargas de trabajo de tráfico de red en el clúster reenviando solicitudes públicas o privadas a sus apps. Puede utilizar Ingress para exponer varios servicios de app a la red privada o pública mediante un único dominio privado o público.
En el clúster, el controlador de Ingress de Red Hat OpenShift es un equilibrador de carga de capa 7 que implementa un controlador de Ingress de HAProxy. Un servicio de LoadBalancer
de capa 4 expone el controlador de Ingress, para
que el controlador de Ingress pueda recibir las solicitudes externas que entran en el clúster. A continuación, el controlador de Ingress reenvía las solicitudes a los pods de aplicación en el clúster basándose en las distintas características
de protocolo de la capa 7 como, por ejemplo, las cabeceras.
¿Cuáles son los componentes de Ingress?
En los clústeres que ejecutan Red Hat OpenShift versión 4, Ingress consta de tres componentes: un operador de Ingress, un controlador de Ingress y recursos de ruta.
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.
Clusters clásicos: Direcciones IP del controlador de entrada
Para buscar las direcciones IP de los servicios de controlador de Ingress predeterminados, ejecute oc get svc -n openshift-ingress
y busque el campo IP EXTERNA. Si tiene un clúster multizona, tenga en cuenta
que el servicio de controlador de Ingress en la primera zona donde tiene nodos de trabajador siempre se denomina router-default
, y los servicios de controlador de Ingress en las zonas que se añaden posteriormente al clúster
tienen nombres como, por ejemplo, router-dal12
.
Clústeres VPC: nombres de host del controlador de entrada
Cuando se crea un clúster de VPC, se crea automáticamente un equilibrador de carga de VPC multizona público y uno privado fuera del clúster en la VPC. El equilibrador de carga de VPC público crea un nombre de host para registrar el controlador de Ingress público, y el equilibrador de carga de VPC privado crea un nombre de host para registrar el controlador de Ingress privado. En los clústeres de VPC, se asigna un nombre de host a los controladores de Ingress porque las direcciones IP externas no son estáticas y pueden cambiar con el tiempo. Tenga en cuenta que este nombre de host del controlador de Ingress es distinto del subdominio de Ingress predeterminado del clúster.
El subdominio de Ingress para el clúster se enlaza automáticamente con el nombre de host del equilibrador de carga de VPC del controlador de Ingress público. Tenga en cuenta que el subdominio de Ingress para el clúster, que es similar a
<cluster_name>.<hash>-0000.<region>.containers.appdomain.cloud
, es distinto del nombre de host asignado por el equilibrador de carga de VPC para el controlador de Ingress público, que es similar a 01ab23cd-<region>.lb.appdomain.cloud
.
El subdominio Ingress es la ruta pública a través de la cual los usuarios acceden a la app desde Internet, y se puede configurar de modo que utilice la terminación de TLS. El equilibrador de carga de VPC utiliza el nombre de host asignado
para el controlador de Ingress público para reenviar el tráfico al servicio de controlador de Ingress.
Para encontrar el nombre de host que se asigna a su controlador de Ingress público y el nombre de host que se asigna a su controlador de Ingress privado, ejecute oc get svc -n openshift-ingress
y busque el campo IP EXTERNA.
En el panel de control de la infraestructura de VPC, el equilibrador de carga de VPC solo notifica como correctos los dos nodos de trabajador que ejecutan los pods de réplica del controlador de Ingress, porque estos nodos de trabajador se configuran como escuchas para el equilibrador de carga de VPC. Aunque sólo los nodos trabajadores de escucha se notifican como en buen estado, Red Hat OpenShift on IBM Cloud mantiene actualizada la agrupación de fondo de nodos trabajadores de los escuchas, de forma que todos los nodos trabajadores del clúster pueden seguir recibiendo solicitudes del equilibrador de carga de VPC.
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.
¿Cómo llega a mi app una solicitud con Ingress en un clúster clásico?
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.
-
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
. -
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.
-
Basándose en la dirección IP resuelta, el cliente envía la solicitud al servicio de controlador de Ingress.
-
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. -
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.
-
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
. -
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.
-
El cliente envía la solicitud a la dirección IP del servicio que expone el controlador de Ingress.
-
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. -
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.
¿Cómo llega a mi app una solicitud en un clúster de VPC?
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.
-
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
. -
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.
-
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.
-
Basándose en la dirección IP resuelta, el equilibrador de carga de VPC envía la solicitud a un controlador de Ingress.
-
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. -
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.
-
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. -
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.
-
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.
-
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.
-
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. -
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.
¿Cómo puedo personalizar el direccionamiento?
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>
.
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.
Para empezar, consulte Personalización de Ingress.
¿Cómo puedo habilitar certificados TLS?
Para equilibrar la carga de las conexiones HTTPS entrantes con el subdominio, puede configurar el controlador de Ingress para descifrar el tráfico de red y reenviar la solicitud descifrada a las aplicaciones que están expuestas en el clúster.
Cuando configura el controlador de Ingress público, elige el dominio por el que se puede acceder a las aplicaciones. Si utiliza el dominio proporcionado por IBM, como por ejemplo mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp
,
puede utilizar el certificado TLS predeterminado que se crea para el subdominio de Ingress. Si configura un registro CNAME para correlacionar un dominio personalizado con el dominio proporcionado por IBM, puede proporcionar su propio certificado
TLS para su dominio personalizado.
Para obtener más información sobre los certificados TLS, consulte Gestión de certificados y secretos TLS.