Elección de un servicio de exposición de apps

Exponga de forma segura las aplicaciones al tráfico externo mediante el controlador de Red Hat OpenShift Ingress, IBM Cloud® Kubernetes Service NodePort o el equilibrador de carga de red.

Visión general de las opciones para exponer apps

Para exponer tus aplicaciones de forma segura al tráfico externo, puedes elegir entre los siguientes servicios.

Controlador de Red Hat OpenShift Ingress

Publica varias aplicaciones en un clúster configurando el enrutamiento con el controlador Ingress de Red Hat OpenShift. El controlador de Ingress utiliza el subdominio de Ingress como punto de entrada único público o privado protegido para direccionar las solicitudes entrantes. Puede utilizar un subdominio para exponer varias apps en el clúster como servicios. La solución de controlador de Ingress utiliza tres componentes.

  • El operador de Ingress que gestiona los controladores de Ingress en el clúster.
  • El controlador de Ingress es un servicio de Kubernetes basado en HAProxy que gestiona todo el tráfico de entrada para las apps en el clúster implementando reglas de direccionamiento para las apps. Este controlador está gestionado por el operador de Ingress. El controlador de Ingress escucha las solicitudes de servicio HTTP o HTTPS entrantes y, a continuación, las reenvía a los pods para esa aplicación de acuerdo con las reglas definidas en el recurso de Ingress e implementadas por el controlador de Ingress.
  • El recurso de ruta define las reglas sobre cómo direccionar y equilibrar la carga de las solicitudes entrantes para una aplicación.

Una ruta expone un servicio como nombre de host con el formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Un controlador de Ingress se despliega de forma predeterminada en el clúster, lo que permite que los clientes externos utilicen las rutas. El controlador de Ingress utiliza el selector de servicio para buscar el servicio y los puntos finales que respaldan el servicio. Puede configurar el selector de servicios para que dirija el tráfico a través de una ruta a varios servicios. También puede crear rutas seguras o no seguras utilizando el certificado TLS asignado por el controlador de Ingress para su nombre de host. Tenga en cuenta que el controlador de Ingress solo da soporte a los protocolos HTTP y HTTPS.

NodePort

Cuando expone apps con un servicio NodePort, se asigna un NodePort dentro del rango 30000 - 32767 y una dirección IP de clúster interna al servicio. Para acceder al servicio desde fuera del clúster, se usa la dirección IP pública o privada de cualquier nodo de trabajador y el NodePort en formato <IP_address>:<nodeport>. No obstante, las direcciones IP públicas y privadas del nodo trabajador no son permanentes. Cuando un nodo trabajador se elimina o se vuelve a crear, se le asigna una nueva dirección IP pública. Los NodePorts son ideales para probar el acceso público o privado o para proporcionar acceso sólo por un breve período de tiempo.

LoadBalancer

El tipo de servicio LoadBalancer se implementa de forma diferente en función del proveedor de infraestructura del clúster.

  • Clústeres clásicos: Equilibrador de cargas de red (NLB). Cada clúster estándar se suministra con cuatro direcciones IP públicas portátiles y cuatro privadas portátiles que puede utilizar para crear un equilibrador de carga de red (NLB) TCP/UDP de capa 4 para la app. Puede personalizar el NLB exponiendo cualquier puerto que necesite la app. Las direcciones IP públicas y privadas portátiles que se asignan al NLB son permanentes y no cambian cuando se vuelve a crear un nodo de trabajador en el clúster. Si crea NLB públicos, puede crear un subdominio para la app que registre las direcciones IP del NLB público con una entrada de DNS. También puede habilitar los supervisores de comprobación de estado en las IP de NLB para cada subdominio.
  • Clústeres VPC: Equilibrador de cargas para VPC. Cuando crea un servicio LoadBalancer de Kubernetes para una app en el clúster, se crea automáticamente un equilibrador de carga de VPCde capa 7 en la VPC fuera del clúster. El equilibrador de carga de VPC es multizona y direcciona las solicitudes de la app a través de los NodePorts privados que se abren automáticamente en los nodos trabajadores. De forma predeterminada, el equilibrador de carga también se crea con un nombre de host que se puede utilizar para acceder a la app, pero también puede crear un subdominio para la app que cree una entrada de DNS.
Ingress

Puede utilizar Ingress para exponer la app al tráfico externo a través del controlador de Ingress de Red Hat OpenShift. Red Hat OpenShift Controller Manager convierte los recursos de Ingress en recursos de ruta y el controlador de Red Hat OpenShift Ingress procesa esas rutas.

Elección entre soluciones de equilibrio de carga

Ahora que conoce las opciones que tiene para exponer apps en su clúster de Red Hat OpenShift, elija la mejor solución para su carga de trabajo.

En la tabla siguiente se comparan las características de cada método de exposición de apps.

Comparación de redes externas para aplicaciones en Red Hat OpenShift clústeres.
Características NodePort LoadBalancer (Clásico - NLB) LoadBalancer (equilibrador de carga de VPC) Controlador de Ingress
IP externa estable Sí Sí
Nombre de host externo Sí Sí Sí
Terminación SSL Sí Sí Sí
Equilibrio de carga HTTP(S) Sí
Reglas de direccionamiento personalizadas Sí
Varias apps por ruta o servicio Sí
Despliegue híbrido multinube coherente Sí

* Los mandatos ibmcloud oc nlb-dns proporcionan terminación SSL. En clústeres clásicos, estos mandatos solo reciben soporte para NLB públicos.

Planificación del equilibrio de carga externo público

Exponer públicamente una app del clúster en internet.

En los clústeres clásicos, los nodos de trabajo están conectados a una VLAN pública. La VLAN pública determina la dirección IP pública que se asigna a cada nodo trabajador, lo que proporciona a cada nodo trabajador una interfaz de red pública. Los servicios de red públicos se conectan a esta interfaz de red pública proporcionando a su app una dirección IP pública y, opcionalmente, un URL público.

En clústeres de VPC, los nodos trabajadores solo se conectan a subredes de VPC privadas. Sin embargo, cuando se crean servicios de red públicos, se crea automáticamente un equilibrador de carga de VPC. El equilibrador de carga de VPC puede direccionar solicitudes públicas a la app especificando la app en un URL público. Cuando se expone públicamente una app, cualquiera que tenga el URL público puede enviar una solicitud a la app.

Cuando se expone públicamente una app, cualquiera que tenga la dirección IP pública del servicio o el URL que haya establecido para la app puede enviar una solicitud a la app. Por este motivo, exponga las menos apps posibles. Exponga una app al público solo cuando la app esté preparada para aceptar tráfico procedente de clientes o usuarios web externos.

La interfaz de red pública de los nodos trabajadores está protegida por valores predefinidos de política de red de Calico que se configuran en cada nodo trabajador durante la creación del clúster. De forma predeterminada, todo el tráfico de red de salida está permitido para todos los nodos trabajadores. El tráfico de red de entrada está bloqueado, excepto en algunos puertos. Estos puertos están abiertos para que IBM pueda supervisar el tráfico de red e instalar automáticamente actualizaciones de seguridad para el maestro de Kubernetes, de modo que se puedan establecer conexiones con los servicios de redes públicas. Para obtener más información sobre estas políticas, incluido cómo modificarlas, consulte Políticas de red.

Red de app pública para clústeres clásicos

Para que una aplicación esté disponible de forma pública en Internet en un clúster clásico, elija un método de exposición de aplicaciones que utilice rutas, NodePorts, NLB o configure Ingress. En la tabla siguiente se describe cada método posible, por qué se puede utilizar y cómo configurarlo. Para obtener información básica acerca de los servicios de red que se muestran en la lista, consulte Tipos de servicio de Kubernetes.

No puede utilizar varios métodos de exposición de aplicaciones para una aplicación.

Características de los métodos de exposición de aplicaciones públicas
Nombre Método de equilibrio de carga Caso de uso Implementación
Ruta Equilibrio de carga HTTP(S) que expone la app con un subdominio y utiliza reglas de direccionamiento personalizadas

Implementar reglas de direccionamiento personalizadas y terminación de SSL para varias apps. Elija este método para continuar siendo nativo de Red Hat OpenShift; por ejemplo, puede utilizar la consola web de Red Hat OpenShift para crear y gestionar rutas.

  1. Crea un servicio de « ClusterIP » para asignar una dirección IP interna a tu aplicación.
  2. Establezca una ruta Red Hat OpenShift.
  3. Personalice las reglas de direccionamiento con configuraciones opcionales.
NodePort Puerto en un nodo trabajador que expone la app en la dirección IP pública del trabajador Probar el acceso público a una app o proporcionar acceso solo durante un breve período de tiempo. Cree un servicio NodePort público.
NLB v1.0 (+ subdominio) Equilibrado de cargas básico que expone la aplicación con una dirección IP o un subdominio. Exponer rápidamente una app al público con una dirección IP o un subdominio que admita terminación SSL. Cree un equilibrador de cargas de red público (NLB) 1.0 en un clúster único o multizona. Opcionalmente, registrar un subdominio y comprobaciones de estado.
NLB v2.0 (+ subdominio) Equilibrado de cargas DSR que expone la aplicación con una dirección IP o un subdominio.

Exponga una aplicación que puede recibir altos niveles de tráfico al público con una dirección IP o un subdominio que admita la terminación SSL.

  1. Complete los requisitos previos.
  2. Cree un NLB 2.0 público en un clúster de una zona o multizona.
  3. Opcionalmente, registrar un subdominio y comprobaciones de estado.
Controlador de Ingress Equilibrio de carga HTTP(S) que expone la app con un subdominio y utiliza reglas de direccionamiento personalizadas Implementar reglas de direccionamiento personalizadas y terminación de SSL para varias apps. Cree un Recurso de Ingress para el controlador de Ingress público predeterminado.

Red de app pública para clústeres de VPC

Para que una aplicación esté disponible de manera pública en Internet en un clúster de VPC, elija un método de exposición de aplicaciones que utilice rutas, equilibradores de carga de VPC o configure Ingress. En la tabla siguiente se describe cada método posible, por qué se puede utilizar y cómo configurarlo. Para obtener información básica acerca de los servicios de red que se muestran en la lista, consulte Tipos de servicio de Kubernetes.

No puede utilizar varios métodos de exposición de aplicaciones para una aplicación.

Características de los métodos de exposición de aplicaciones públicas
Nombre Método de equilibrio de carga Caso de uso Implementación
Ruta Equilibrio de carga HTTP(S) que expone la app con un subdominio y utiliza reglas de direccionamiento personalizadas Implementar reglas de direccionamiento personalizadas y terminación de SSL para varias apps. Elija este método para que sigan siendo nativas de Red Hat OpenShift; por ejemplo, puede utilizar la consola web de Red Hat OpenShift para crear y gestionar rutas. Cree una ruta utilizando el controlador de Ingress público predeterminado en los clústeres con un punto final de servicio de nube pública, o cree una ruta utilizando un controlador de Ingress público personalizado en clústeres con solo un punto final de servicio de nube privada.
Equilibrador de carga de VPC Equilibrado de cargas básico que expone la aplicación con un nombre de host. Exposición rápida de una app al público con un nombre de host asignado por el equilibrador de carga de VPC. Cree un servicio LoadBalancer público en el clúster. Se crea automáticamente un equilibrador de carga de VPC multizona en la VPC que asigna un nombre de host al servicio LoadBalancer para la app.
Ingress Equilibrado de cargas HTTP(S) que expone la aplicación con un subdominio que usa reglas de direccionamiento personalizadas. Implementar reglas de direccionamiento personalizadas y terminación de SSL para varias apps. Cree un recurso Ingress para el controlador Ingress público predeterminado en clústeres con un punto final público de servicio de nube, o cree un recurso Ingress para un controlador Ingress público personalizado en clústeres con solo un punto final privado de servicio de nube.

Planificación del equilibrio de carga externo privado

Exponer de forma privada una app del clúster solo en la red privada.

Al desplegar una app en un clúster de Kubernetes en IBM Cloud Kubernetes Service, puede que desee que la app sea accesible sólo para usuarios y servicios que se encuentren en la misma red privada que el clúster. El equilibrio de carga privado es ideal para hacer que la app esté disponible para las solicitudes desde fuera del clúster sin exponer la app al público en general. También puede utilizar el equilibrio de carga privado para probar el acceso, el direccionamiento de solicitudes y otras configuraciones para la app antes de exponer su app al público con los servicios de red públicos.

Como ejemplo, supongamos que ha creado un equilibrador de carga privado para la app. Puede acceder a este equilibrador de carga privado:

  • Cualquier pod en ese mismo clúster.
  • Cualquier pod en cualquier clúster de la misma cuenta de IBM Cloud.
  • Si no está en la cuenta de IBM Cloud sino todavía detrás del cortafuegos de la empresa, cualquier sistema a través de una conexión VPN a la subred donde se encuentra la IP del equilibrador de carga.
  • Si está en una cuenta de IBM Cloud distinta, cualquier sistema a través de una conexión VPN a la subred donde se encuentra la IP del equilibrador de carga.
  • En clústeres clásicos, si tiene habilitado VRF o la distribución de VLAN, cualquier sistema que esté conectado a cualquiera de las VLAN privadas de la misma cuenta de IBM Cloud.
  • En clústeres de VPC:
    • Si se permite el tráfico entre subredes de VPC, cualquier sistema en la misma VPC.
    • Si se permite el tráfico entre las VPC, cualquier sistema que tenga acceso a la VPC en la que se encuentra el clúster.

Red de app privada para clústeres clásicos

Cuando los nodos de trabajador están conectados a una VLAN pública y privada, puede permitir que la aplicación sea accesible desde una red privada solo mediante la creación de rutas privadas, NodePorts y NLB, o la configuración de Ingress. A continuación, puede crear políticas de Calico para bloquear el tráfico público a los servicios.

La interfaz de red pública de los nodos trabajadores está protegida por valores predefinidos de política de red de Calico que se configuran en cada nodo trabajador durante la creación del clúster. De forma predeterminada, todo el tráfico de red de salida está permitido para todos los nodos trabajadores. El tráfico de red de entrada está bloqueado, excepto en algunos puertos. Estos puertos están abiertos para que IBM pueda supervisar el tráfico de red e instalar automáticamente actualizaciones de seguridad para el maestro de Kubernetes, de modo que se puedan establecer conexiones con los servicios NodePort, LoadBalancer e Ingress.

Puesto que las políticas predeterminadas de red de Calico permiten el tráfico público de entrada a estos servicios, puede crear políticas de Calico para bloquear todo el tráfico público a los servicios. Por ejemplo, un servicio NodePort abre un puerto en un nodo trabajador sobre la dirección IP privada y pública del nodo trabajador. Un servicio de NLB con una dirección IP privada portátil abre un NodePort público en cada nodo trabajador. Debe crear una política de red preDNAT de Calico para bloquear los NodePorts públicos.

Consulte los siguientes métodos para redes de apps privadas:

Características de los patrones de despliegue de red para una configuración de VLAN pública y privada
Nombre Método de equilibrio de carga Caso de uso Implementación
Ruta Equilibrio de carga HTTP(S) que expone la app con un subdominio y utiliza reglas de direccionamiento personalizadas Implementar reglas de direccionamiento personalizadas y terminación de SSL para varias apps. Elija este método para que sigan siendo nativas de Red Hat OpenShift; por ejemplo, puede utilizar la consola web de Red Hat OpenShift para crear y gestionar rutas.
  1. Crea un servicio ClusterIP para asignar una dirección IP interna a tu aplicación.
  2. Cree un controlador Ingress que esté expuesto por un equilibrador de carga privado.
  3. Establece una ruta Red Hat OpenShift.
  4. Personalice las reglas de enrutamiento con configuraciones opcionales.
NodePort Puerto en un nodo trabajador que expone la app en la dirección IP privada del trabajador Probar el acceso privado a una app o proporcionar acceso solo durante un breve período de tiempo.
  1. Cree un servicio NodePort.
  2. Un servicio NodePort abre un puerto en un nodo trabajador sobre la dirección IP privada y pública del nodo trabajador. Debe utilizar una política de red preDNAT de Calico para bloquear el tráfico a los NodePorts públicos.
NLB 1.0 Equilibrio de carga básico que expone la app con una dirección IP privada Exponer rápidamente una app a una red privada con una dirección IP privada.
  1. Crear un servicio NLB privado. Un NLB con una dirección IP privada portátil sigue teniendo un puerto de nodo público abierto en cada nodo de trabajo.
  2. Crear una política de red preDNAT de Calico para bloquear el tráfico a los NodePorts públicos.
NLB v2.0 Equilibrio de carga de DSR que expone la app con una dirección IP privada Exponer una app que pueda recibir altos niveles de tráfico a una red privada con una dirección IP.
  1. Cumplir los requisitos previos.
  2. Crear un NLB privado 2.0 en un clúster de una o varias zonas. Un NLB con una dirección IP privada portátil sigue teniendo un puerto de nodo público abierto en cada nodo de trabajo.
  3. Crear una política de red preDNAT de Calico para bloquear el tráfico a los NodePorts públicos.
Ingress Equilibrio de carga HTTP(S) que expone la app con un subdominio y utiliza reglas de direccionamiento personalizadas Implementar reglas de direccionamiento personalizadas y terminación de SSL para varias apps. Consulte Exposición pública de apps con Ingress

Red de app privada para clústeres de VPC

Para que una aplicación esté disponible a través de una red privada solo en un clúster de VPC, elija un patrón de despliegue de equilibrio de carga basado en la configuración de punto final de servicio del clúster: punto final de servicio de nube pública y privada, o solo punto final de servicio de nube privada. Para cada configuración de punto final de servicio, en la tabla siguiente se describe cada método posible de exposición de apps, por qué se puede utilizar y cómo configurarlo.

Patrones de despliegue de red privada para un clúster de VPC
Nombre Método de equilibrio de carga Caso de uso Implementación
Ruta Equilibrio de carga HTTP(S) que expone la app con un subdominio y utiliza reglas de direccionamiento personalizadas Implementar reglas de direccionamiento personalizadas y terminación de SSL para varias apps. Elija este método para que sigan siendo nativas de Red Hat OpenShift; por ejemplo, puede utilizar la consola web de Red Hat OpenShift para crear y gestionar rutas. Cree un controlador de Ingress utilizando el controlador de Ingress privado predeterminado en clústeres con solo un punto final de servicio de nube privada, o cree una ruta utilizando un controlador de Ingress privado personalizado en clústeres con un punto final de servicio de nube pública.
NodePort Puerto en un nodo trabajador que expone la app en la dirección IP privada del trabajador Probar el acceso privado a una app o proporcionar acceso solo durante un breve período de tiempo. Cree un servicio NodePort privado.
Equilibrador de carga de VPC Equilibrio de carga básico que expone la app con un nombre de host privado Exposición rápida de una app a una red pública mediante un nombre de host privado asignado por el equilibrador de carga de VPC. Cree un servicio LoadBalancer privado en el clúster. Se crea automáticamente un equilibrador de carga de VPC multizona en la VPC que asigna un nombre de host al servicio LoadBalancer para la app.
Ingress Equilibrio de carga HTTP(S) que expone la app con un subdominio y utiliza reglas de direccionamiento personalizadas Implementar reglas de direccionamiento personalizadas y terminación de SSL para varias apps. Cree un recurso de Ingress para el controlador de Ingress privado predeterminado en clústeres con solo un punto final de servicio en la nube privado o cree un recurso de Ingress para un controlador de Ingress privado personalizado en clústeres con un punto final de servicio en la nube público.