A medida que los mundos de DevOps y NetOps convergen y los entornos de contenedores incorporan definiciones utilizadas tradicionalmente en el ámbito de las redes, parece conveniente analizar el uso del término «ingress», a menudo confuso, en el contexto de la ruta de datos y los entornos de contenedores.
Los términos «ingress» y «egress» se han utilizado tradicionalmente para describir la dirección del tráfico en la red desde la perspectiva del centro de datos. «Ingress» se refiere al tráfico entrante y «egress», al saliente.
A medida que los entornos de contenedores han ido madurando, el término «ingress» ha adquirido una definición muy específica y centrada en las aplicaciones.
Ingress. Objeto de API que gestiona el acceso externo a los servicios de un clúster, normalmente mediante HTTP. Ingress puede proporcionar balanceo de carga, terminación SSL y alojamiento virtual basado en nombres.
Es importante detenerse un momento y señalar que un recurso Ingress, tal como se define en un entorno de Kubernetes, describe funcionalidades que se presupone que se ejecutan dentro del propio perímetro del contenedor.
Cada ingress es un proxy inverso que acepta solicitudes externas y, basándose en las reglas especificadas por el recurso ingress de Kubernetes, dirige dichas solicitudes al servicio de Kubernetes correspondiente. A su vez, el servicio distribuye la carga de las solicitudes entre un conjunto de contenedores asociados, normalmente mediante algoritmos nativos de balanceo de carga de capa 4 (TCP). Esta es una de las formas de presentar una API unificada al exterior. El ingress analiza las llamadas a la API (la ruta URI) y las distribuye entre los microservicios correspondientes alojados en contenedores dentro del clúster de contenedores.
F5 ofrece las mismas capacidades que un ingress clásico de Kubernetes, pero añade otras adicionales, como el enrutamiento SNI y el balanceo de carga de capa 4 (TCP). La posibilidad de realizar enrutamiento SNI (indicación del nombre del servidor) resulta útil para quienes desean cifrar de extremo a extremo mediante TLS los intercambios de mensajes, ya que permite a F5 enrutar correctamente las solicitudes basándose en la información de las cabeceras sin descifrar la carga útil o el mensaje. Aunque esto limita las funciones que pueden aplicarse a la solicitud —por ejemplo, no se puede analizar en busca de contenido malicioso—, proporciona la compatibilidad necesaria para arquitecturas en las que el contenido debe permanecer cifrado por motivos normativos u operativos. El balanceo de carga de capa 4 (TCP) suele utilizarse fuera de los entornos de contenedores para escalar servicios de ingress de Kubernetes.
F5 suele implementarse fuera del entorno de contenedores. A menudo se utiliza como solución de equilibrio de carga para exponer los clústeres al exterior, es decir, para proporcionar acceso público a servicios compuestos por un clúster de contenedores. Una encuesta de la CNCF reveló que el 67 % de los encuestados elige una opción de equilibrador de carga para exponer los servicios del clúster al exterior, mientras que otro 33 % aprovecha las capacidades de entrada (L7).
Para poder ofrecer las mismas funcionalidades que un ingress de Kubernetes, se utiliza un «conector» nativo para contenedores que facilita la actualización de las políticas que definen el tráfico. Este conector se aloja en el orquestador de contenedores y se integra con él (normalmente Kubernetes, aunque Red Hat OpenShift también es popular). La comunicación con el ingress de F5 se realiza mediante una API. Las actualizaciones incluyen cambios en las definiciones de los recursos de ingress (políticas de enrutamiento HTTP), así como cambios de configuración, como el inicio o la eliminación de una instancia de contenedor que afecte a la definición de un servicio existente.
La ventaja de utilizar F5 en lugar de servicios de entrada sencillos es la posibilidad de aplicar funcionalidades avanzadas al tráfico entrante y saliente. Al utilizar F5, se pueden aplicar medidas de seguridad, enriquecimiento de cabeceras y optimizaciones de rendimiento específicas para cada cliente sin modificar el entorno ni la arquitectura de contenedores, ni la propia aplicación.
Recursos adicionales:
- Consulta la documentación: F5 Container Ingress Services
- Descargar desde Docker Store: F5 Container Ingress Services
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.