La I/O del clúster de Kubernetes es un gran desastre, pero la ayuda está en camino

La proliferación de interfaces, API y abstracciones para la entrada y egresión de Kubernetes ha dado lugar a varios desafíos en el mundo de la orquestación de contenedores.

No hay otra manera de describir la gran proliferación de interfaces y abstracciones para controlar el tráfico de red que ingresa y egresa desde, también llamado entradas y salidas (I/O), en los clústeres de Kubernetes. Es un gran lío.

La buena noticia es que la comunidad es consciente de ello y está trabajando para mejorar las cosas.

En este blog, discutiremos la proliferación y los esfuerzos que se están realizando para simplificar el panorama.

¿Cómo llegamos aquí? Breve historia de la I/O del clúster de Kubernetes

Al principio, solo había un recurso oficial de control de entrada aguas arriba para Kubernetes conocido simplemente como “ingreso”. Era simple y tenía características mínimas que conducían a la creación e implementación de varios otros recursos del controlador de entrada con diferentes características y API para interactuar con ellos.

El recurso de entrada original de Kubernetes se encuentra actualmente en proceso de quedar obsoleto en favor de un recurso de gateway y API más nuevos que se han desarrollado en el grupo de trabajo Kubernetes SIG Network específicamente para abordar la proliferación de implementaciones similares, pero diferentes, de características de ingreso.

Los gateways API y las mallas de servicio comparten la funcionalidad de entrada

A medida que las soluciones de administración de API migraban a la nube y las soluciones de Kubernetes en forma de gateways API, se agregó otro control que funcionalmente es un controlador de entrada. Además de la docena de controladores de entrada Kubernetes, hay una docena de gateways API de Kubernetes que agregan otra dimensión de complejidad y confusión a los usuarios de Kubernetes.

Y luego están las diferentes implementaciones de malla de servicios y API que son efectivamente otra interfaz de entrada (en la red mesh implementada por los proxies distribuidos). Se requieren todas las mismas necesidades funcionales que comprenden controladores de entrada y gateways API para controlar el tráfico dentro y fuera de los gateways de malla de servicio donde se produce I/O de cluster en muchas redes de producción.

En resumen, el estado actual de la proliferación de interfaces y API en torno a la IO del cluster es la suma de todas estas diferentes implementaciones en todas las diferentes categorías de soluciones.

Las desventajas de la proliferación

Hay dos desventajas principales de esta proliferación:

• El rápido crecimiento de las interfaces y las API ha dado como resultado una mayor área de superficie de ataque, con vulnerabilidades de API cada vez más frecuente.
• La gran cantidad de soluciones disponibles para controladores de entrada, gateways API y funcionalidad de malla de servicio crea confusión y complicaciones para los usuarios finales. Esto ha llevado a un entorno en el que los proveedores y usuarios deben hablar varios “idiomas” para proporcionar soporte integral de Kubernetes para la política de seguridad.

A medida que surgen más soluciones en el ecosistema de Kubernetes, la funcionalidad de las diversas categorías de entrada y egreso se superpone cada vez más. Esta superposición crea confusión para las personas que eligen herramientas y agrega complejidad a un panorama ya desafiante.

Por qué el complejo ecosistema de Kubernetes necesita estandarización de políticas

La Container Network Interface (CNI) define la API para enviar tráfico de red dentro del clúster entre pods, y hay una serie de implementaciones interoperables populares, incluyendo OVN, Calico, Cilium, etc. Aunque existen algunas extensiones únicas en los diferentes productos, comparten un núcleo común de capacidades de políticas de red que permiten a los operadores de plataforma especificar qué entidades habilitadas para la red pueden comunicarse y cómo.

Las políticas de red están optimizadas para proporcionar un entorno de denegación predeterminado donde las reglas de permitir son excepciones a ese comportamiento basado en la identificación del tráfico basado en etiquetas, espacios de nombres, implementaciones y otros atributos de metadatos nativos de la nube. Éstas son exactamente el tipo de funciones primitivas que serían una buena base para el filtrado del tráfico que entra y sale de los clústeres de Kubernetes. Sin embargo, el CNI no tiene un alcance extra cluster y, por lo tanto, no se ha compartido este enfoque estandarizado en el mundo de los controladores de entrada y los gateways API.

Las mallas de servicio tienden a tener herramientas de política de filtrado de tráfico similares que no tienen un enfoque estandarizado en comparación con la política de red definida para las CNI. Service mesh también introduce filtros de capa 7 y listas de permitidos que no se consideraron dentro del alcance de las API de CNI y que aún no han visto avances en la adopción en el grupo de trabajo del CNI.

Esfuerzos de estandarización por parte de la comunidad de Kubernetes

Para abordar estos problemas, los grupos están tomando diversas iniciativas para estandarizar las interfaces de entrada y salida y las API. Estos incluyen varios esfuerzos importantes bajo la dirección del Grupo de Interés Especial de la Red Kubernetes (SIG), incluido el Grupo de Trabajo sobre Políticas de Red, el Grupo de Trabajo Gateway y la Iniciativa GAMMA.

Grupo de Trabajo de Gateway

El Grupo de Trabajo de Gateway es responsable de desarrollar una API unificada para administrar el tráfico de entrada y salida en clústeres de Kubernetes. El principal proyecto del grupo es el API de puerta de enlace de Kubernetes que está diseñado para proporcionar una API más flexible y expresiva para configurar el tráfico de entrada y egresión de Kubernetes6]]. Al ofrecer una API estandarizada, el Grupo de Trabajo de Gateway tiene como objetivo simplificar el proceso de implementación y administración de los componentes de red de Kubernetes.

Al ofrecer una API estandarizada, el Grupo de Trabajo de Gateway tiene como objetivo simplificar el proceso de implementación y administración de los componentes de red de Kubernetes.

API de Kubernetes Gateway V1.0

La API de Kubernetes Gateway está diseñada para abordar algunas de las limitaciones y problemas asociados con el recurso de entrada original. Estas mejoras abordan las limitaciones del recurso de entrada original y proporcionan un enfoque más eficiente y fácil de usar para administrar el tráfico de red en entornos Kubernetes.

Para obtener más información sobre las mejoras clave del grupo, acceda a estos recursos:

• Descripción general de la API de Kubernetes Gateway
• Guía rápida de la nueva puerta de enlace de API de Kubernetes

Iniciativa GAMMA

El Iniciativa GAMMA (API Gateway, Mesh y Middleware) es un esfuerzo de colaboración entre varios SIG de Kubernetes y las partes interesadas de la industria. Su objetivo es consolidar y estandarizar las API e interfaces utilizadas para el tráfico de entrada y salida de Kubernetes. Esta iniciativa tiene como objetivo reducir la confusión y la complejidad para los usuarios finales, facilitando la implementación y administración de los componentes de red de Kubernetes.

Grupo de trabajo sobre políticas de red

El Grupo de Trabajo de Políticas de Red se centra en definir e implementar políticas de red para Kubernetes para mejorar la seguridad y el aislamiento entre pods, servicios y otras entidades de red en un clúster de Kubernetes. Actualmente soporta un rico conjunto de herramientas para especificar el tráfico de red.Es ampliamente implementado por los CNIs populares, y por lo tanto no es una herramienta que se aplica al tráfico de entrada/egreso de cluster.

Actualmente el grupo está trabajando en varios proyectos:

• Política de red administrativa: proporciona a los administradores de cluster más control sobre las políticas de red mediante la introducción de un mayor nivel de abstracción. Esto permite a los administradores definir políticas globales para todo el clúster que se pueden aplicar de manera consistente en todos los espacios de nombres.
• Política de red V2: Aborda las limitaciones en la implementación actual de políticas de red mediante la introducción de nuevas características y la ampliación de la API existente, como el soporte para el filtrado de tráfico de egresión, capacidades mejoradas de coincidencia de políticas y una mejor aplicación de políticas para una mejor seguridad.

• NetworkPolicy++: Introducción de capacidades avanzadas de políticas de red mediante la ampliación de la API de política de red existente. Esto proporciona un control más granular sobre la administración del tráfico, la seguridad y el aislamiento, lo que permite a los usuarios crear políticas sofisticadas adaptadas a sus necesidades específicas.

La adopción de la comunidad está reemplazando a las organizaciones de estándares

Anteriormente en este blog, hay referencias a los esfuerzos para estandarizar abstracciones y API, pero eso no es necesariamente un aval para hacerlo a través de organizaciones de estándares tradicionales como IETF, ITU, IEEE, etc. Las comunidades de código abierto votan con el tiempo de su desarrollador y su base de código, por lo que lograr una “estandarización” de facto debido al despliegue generalizado de la comunidad es la medida más importante de éxito.

La introducción de la API de Kubernetes Gateway, y la descalificación del recurso de ingreso, es un ejemplo de una comunidad dedicada a mejorar su plataforma de infraestructura que se une para realizar cambios generalizados sin obtener ninguna ventaja competitiva de esa inversión.

En el momento de la publicación de este blog, había 19 proyectos de controlador de entrada de código abierto y malla de servicio en varias etapas del desarrollo de su implementación de API de gateway para reemplazar su implementación previa a medida. La mayoría de estos se encuentran actualmente en versión beta y varios están en disponibilidad general (GA).

La implementación rápida y compartida es la nueva manera de estandarizar las interfaces de software a la velocidad del desarrollo de la comunidad. El trabajo que se realiza en la Red SIG no es un trabajo académico; la comunidad ha mostrado voluntad de contribuir y posteriormente adoptar las interfaces comunes y APIs definidas en los grupos de trabajo. Cualquiera puede participar y contribuir a su elección.

¿Todavía hay margen de mejora?

El trabajo actualmente en curso dentro de la Red SIG limpiará gran parte del desorden de proliferación que existe actualmente en relación con las E/S de clústeres. Sin embargo, existen otras dimensiones de confusión y complejidad que no han sido objeto de alineación por parte de la comunidad.

El trabajo de la Iniciativa GAMMA para compartir características de ingreso y APIs con el trabajo del grupo de trabajo de API de gateway, va muy lejos para reconocer que los requerimientos funcionales de la malla de servicio pueden ser muy similares a los de un CNI, donde la entrada tradicional ocurre para no-service-mesh.

A pesar de este trabajo, sigue existiendo solapamiento funcional entre CNI y service-mesh que no se está alineando. En los primeros días, el CNI implementó políticas de red de capa para filtrar el tráfico en las Capas 3 y 4 y la malla de servicio filtraba exclusivamente un subconjunto de ese tráfico al observar solo los elementos de protocolo de Capa 7.

El grupo de trabajo de políticas de red está evolucionando y estandarizando la API que será adoptada por todos los diversos proveedores de CNI, pero la mayoría de las soluciones de malla de servicios populares también tienen alguna forma no estandarizada de API de políticas de filtrado de capas 3 y 4. Ninguno planea alinear eso con el trabajo del Grupo de Trabajo de Políticas de Red.

Al mismo tiempo, no existe un grupo equivalente que intente estandarizar las API para el filtrado de Capa 7 que se implementan de manera diferente mediante diferentes mallas de servicio (aunque su uso compartido del Envoy Proxy de código abierto para la aplicación de filtros da como resultado mucha uniformidad). Organizacionalmente, podría ser difícil unificar abstracciones entre los diferentes artefactos de software (CNIs vs. mallas de servicio) porque no hay ningún proyecto que esté fletado para preocuparse por esto e implementarlo. Desde una perspectiva arquitectónica, esto tiene sentido, pero la unificación podría tomar una perspectiva de liderazgo CNCF-en lugar de una perspectiva centrada en el proyecto.

¿Dónde acabará todo esto?

Aceptar que la superposición funcional continua entre las CNI y las mallas de servicio es inevitable significa que el objetivo del SIG de red debería ser, en última instancia, definir una API común para las características relevantes de seguridad, administración de tráfico y enrutamiento, independientemente de si se implementan en algo empaquetado como un CNI, una malla de servicio o alguna otra forma de entregar una abstracción de red virtual.

Los expertos en infraestructura de Kubernetes plantearán algunas buenas objeciones basadas en los principios arquitectónicos que diferencian un CNI de una malla de servicio y dictan una separación lógica de características y estándares. Pero desde una perspectiva de UX, existe el riesgo de ser sordos y exponer a los usuarios del sistema a una interfaz de abajo hacia arriba centrada en el desarrollador del sistema que expone las “perillas nerd”.

Si es natural que los usuarios piensen tanto en un proveedor de CNI como en una malla de servicios como implementando su pila de red y características, podría mejorar el atractivo de la plataforma para compartir abstracciones y API más comunes. La política de red tiene un amplio conjunto de primitivas de filtrado para seleccionar el tráfico y realizar acciones condicionales. Podría ampliarse y mejorarse para manejar todas las reglas abstraídas de coincidencia/acción conscientes de Kubernetes para redes dentro del clúster, entre clústeres y fuera del cluster.

Háganos saber lo que piensa del valor de las abstracciones comunes en todos los casos de uso de procesamiento de tráfico. Si te importa este tema, vigila este trabajo que está progresando rápidamente y afectará a muchos usuarios de Kubernetes.

Más información sobre Illumio por contactando con nosotros hoy.