.png)
La E/S 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 salida de Kubernetes llevó a varios desafíos en el mundo de la orquestación de contenedores.
No hay otra forma de describir la gran proliferación de interfaces y abstracciones para controlar el tráfico de red que entra y sale, también llamado entradas y salidas (E/S), en los clústeres de Kubernetes. Es un gran desastre.
La buena noticia es que la comunidad es consciente de esto 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 paisaje.
¿Cómo llegamos aquí? Una breve historia de la E/S del clúster de Kubernetes
Al principio, solo había un recurso oficial de control de entrada ascendente para Kubernetes conocido simplemente como "ingress". Era simple y tenía características mínimas que condujeron a la creación e implementación de varios otros recursos de 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 desuso en favor de un recurso de puerta de enlace y una API más nuevos que se desarrollaron en el grupo de trabajo de Kubernetes SIG Network específicamente para abordar la proliferación de implementaciones similares, pero diferentes, de características de entrada.
Las puertas de enlace de API y las mallas de servicio comparten la funcionalidad de entrada
A medida que las soluciones de administración de API migraron a la nube y las soluciones de Kubernetes en forma de puertas de enlace de API, se agregó otro control que es funcionalmente un controlador de entrada. Además de la docena de controladores de entrada de Kubernetes, hay una docena de puertas de enlace de 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 de malla implementada por los proxies distribuidos). Se requieren las mismas necesidades funcionales que comprenden los controladores de entrada y las puertas de enlace de API para controlar el tráfico dentro y fuera de las puertas de enlace de malla de servicio donde se produce la E/S del clúster en muchas redes de producción.
En resumen, el estado actual de la proliferación de interfaces y API en torno a la E/S de clúster es la suma de todas estas implementaciones diferentes en todas las diferentes categorías de soluciones.
Las desventajas de la proliferación
Hay dos desventajas principales en esta proliferación:
- El rápido crecimiento de las interfaces y las API dio lugar a un aumento de la superficie expuesta a los ataques, con vulnerabilidades de API cada vez más frecuentes.
- La gran cantidad de soluciones disponibles para controladores de entrada, puertas de enlace API y funcionalidad de malla de servicios crea confusión y complicaciones para los usuarios finales. Esto llevó a un entorno en el que los proveedores y los 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 salida 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 interfaz de red de contenedores (CNI) define la API para enviar tráfico de red dentro del clúster entre pods, y hay un serial de implementaciones interoperables populares, incluidas OVN, Calico, Cilium, etc. Aunque hay algunas extensiones únicas en los diferentes productos, comparten un núcleo común de capacidades de política de red que permiten a los operadores de plataformas especificar qué entidades habilitadas para la red pueden comunicar y cómo.
Las directivas de red están optimizadas para proporcionar un entorno de denegación predeterminada en el que las reglas de licencia son excepciones a ese comportamiento en función de la identificación del tráfico en función de etiquetas, espacios de nombres, implementaciones y otros atributos de metadatos nativos de la nube. Este es exactamente el tipo de funciones primitivas que serían una buena base para el filtrado del tráfico entrante y saliente de los clústeres de Kubernetes. Sin embargo, el CNI no tiene un alcance adicional al clúster y, por lo tanto, no se compartió este enfoque estandarizado en el mundo de los controladores de entrada y las puertas de enlace de API.
Las mallas de servicio tienden a tener herramientas de directiva de filtrado de tráfico similares que no tienen un enfoque estandarizado en comparación con la directiva de red definida para CNI. La malla de servicios también presenta el filtrado de capa 7 y las listas de permitidos que no se consideraron dentro del alcance de las API de CNI y aún no vieron avances en la adopción en el grupo de trabajo de CNI.
Esfuerzos de estandarización por parte de la comunidad de Kubernetes
Para abordar estos problemas, los grupos están tomando varias iniciativas para estandarizar las interfaces y API de entrada y salida. Estos incluyen varios esfuerzos importantes bajo el liderazgo del Grupo de Interés Especial (SIG) de la Red de Kubernetes, incluido el Grupo de Trabajo de Políticas de Red, el Grupo de Trabajo de Gateway y la Iniciativa GAMMA.
Grupo de trabajo de puerta de enlace
El grupo de trabajo de puerta de enlace es responsable de desarrollar una API unificada para gestionar el tráfico de entrada y salida en clústeres de Kubernetes. El proyecto principal del grupo es la API de Kubernetes Gateway , que está diseñada para proporcionar una API más flexible y expresiva para configurar el tráfico de entrada y salida 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 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 componentes de red de Kubernetes.
Kubernetes Gateway API 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 gestionar el tráfico de red en entornos de Kubernetes.
Para obtener más información sobre las mejoras clave del grupo, acceda a estos recursos:
Iniciativa GAMMA
La iniciativa GAMMA (API de puerta de enlace, malla 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 empleadas 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 directivas de red se centra en definir e implementar directivas de red para Kubernetes a fin de mejorar la seguridad y el aislamiento entre pods, servicios y otras entidades de red en un clúster de Kubernetes. Actualmente admite un amplio conjunto de herramientas para especificar el tráfico de red. Está ampliamente implementado por CNI populares y, por lo tanto, no es una herramienta que se aplique al tráfico de entrada/salida del clúster.
El grupo está trabajando actualmente en varios proyectos:
- Directiva de red administrativa: proporciona a los administradores de clústeres más control sobre las directivas 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 forma coherente en todos los espacios de nombres.
- Directiva de red V2: soluciona las limitaciones en la implementación actual de directivas de red mediante la introducción de nuevas características y la ampliación de la API existente, como la compatibilidad con el filtrado de tráfico de salida, las capacidades mejoradas de coincidencia de directivas y la aplicación mejorada de directivas para mejorar la seguridad.
- NetworkPolicy++: Introducción de funcionalidades avanzadas de directiva de red mediante la ampliación de la API de directiva de red existente. Esto proporciona un control más granular sobre la gestió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 comunitaria está reemplazando a las organizaciones de estándares
Anteriormente en este blog, hay referencias a los esfuerzos para estandarizar las abstracciones y las API, pero eso no es necesariamente un respaldo 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 la "estandarización" de facto debido a la implementación generalizada de la comunidad es la medida más importante del éxito.
La introducción de la API de Kubernetes Gateway y la obsolescencia del recurso de entrada es un ejemplo de una comunidad dedicada a mejorar su plataforma de infraestructura que se une para realizar cambios generalizados sin obtener ningún beneficio competitivo de esa inversión.
En el momento de la publicación de este blog, había 19 proyectos de malla de servicios y controladores de entrada de código abierto en varias etapas de desarrollo de su implementación de API de puerta de enlace para reemplazar su implementación anterior a medida. La mayoría de estos se encuentran actualmente en versión beta y varios están disponibles para el público en general (GA).
La implementación rápida y compartida es la nueva forma de estandarizar las interfaces de software a la velocidad del desarrollo comunitario. El trabajo que se realiza en el SIG de la red no es un trabajo académico; la comunidad mostró su voluntad de contribuir y posteriormente adoptar las interfaces y API comunes definidas en los grupos de trabajo. Cualquiera puede participar y contribuir como quiera.
¿Todavía hay margen de mejora?
El trabajo actualmente en curso dentro del SIG de red limpiará gran parte del desorden de proliferación que existe actualmente en relación con la E/S del clúster. Sin embargo, hay otras dimensiones de confusión y complejidad que no fueron objeto de alineación por parte de la comunidad.
El trabajo de la Iniciativa GAMMA para compartir características de entrada y API con el trabajo del grupo de trabajo de API de puerta de enlace contribuye en gran medida a reconocer que los requisitos funcionales de la malla de servicios pueden ser muy similares a los de un CNI, donde la entrada tradicional ocurre para mallas que no son de servicio.
A pesar de este trabajo, sigue habiendo una superposición funcional entre CNI y la malla de servicio 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 servicios filtró exclusivamente un subconjunto de ese tráfico mirando solo los elementos del protocolo de capa 7.
El grupo de trabajo de políticas de red está evolucionando y estandarizando la API que adoptarán todos los 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 hay un grupo equivalente que intente estandarizar las API para el filtrado de capa 7 que se implementan de manera diferente por diferentes mallas de servicio (aunque su uso compartido del proxy Envoy de código abierto para filtrar la aplicación da como resultado mucha uniformidad). Desde el punto de vista organizacional, podría ser difícil unificar las abstracciones entre los diferentes artefactos de software (CNI frente a mallas de servicio) porque no hay ningún proyecto que esté autorizado para preocupar por esto e implementarlo. Desde una perspectiva arquitectónica, esto tiene sentido, pero la unificación podría tomar una perspectiva de liderazgo de CNCF en lugar de una perspectiva centrada en el proyecto.
¿Dónde terminará todo esto?
Aceptar que la superposición funcional continua entre los CNI y las mallas de servicio es inevitable significa que el objetivo del SIG de red debe 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 CNI, una malla de servicio o alguna otra forma de ofrecer 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 servicios y dictan una separación lógica de características y estándares. Pero desde una perspectiva de UX, existe el riesgo de ser sordo y exponer a los usuarios del sistema a una interfaz ascendente centrada en el desarrollador del sistema que expone las "perillas nerd".
Si es natural que los usuarios piensen en un proveedor de CNI y 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 directiva de red tiene un amplio conjunto de primitivas de filtrado para seleccionar tráfico y realizar acciones condicionales. Podría ampliar y mejorar para manejar todas las reglas de coincidencia/acción abstractas y compatibles con Kubernetes para redes dentro del clúster, entre clústeres y fuera del clúster.
Háganos saber lo que piensa sobre el valor de las abstracciones comunes en todos los casos de uso de procesamiento de tráfico. Si le interesa este tema, esté atento a este trabajo que avanza rápidamente y afectará a muchos usuarios de Kubernetes.
Obtenga más información sobre Illumio poner en contacto con nosotros hoy.
.webp)
