Cilium Service Mesh: El futuro de la infraestructura nativa en la nube está en eBPF

Con el auge de los contenedores y el formato Docker en los últimos 10 años, los desarrolladores han tenido un gran éxito. Sin embargo, los equipos de ingeniería de plataforma encargados de construir y operar la infraestructura de Kubernetes han tenido que enfrentarse a múltiples retos y ha sido un proceso de prueba y error.

En los primeros días de los contenedores, hubo una competencia entre Docker Swarm, CoreOS y Apache Mesos (famoso por eliminar la "ballena fallida" en Twitter) para determinar quién se llevaría el trono en la orquestación de cargas de trabajo contenerizadas en clústeres en la nube y en las instalaciones. Más tarde, se revelaron los secretos del sistema Borg desarrollado por Google y apareció Kubernetes (¡el Borg para el resto de nosotros!), que rápidamente atrajo el interés de la comunidad y el apoyo de la industria, convirtiéndose en la tecnología de orquestación de contenedores por defecto.

Tanto es así que he argumentado que Kubernetes es como un "sistema operativo nativo de la nube", el nuevo "Linux empresarial", por así decirlo.

Espacios de nombres, sidecars y service mesh

A medida que los equipos de plataforma evolucionan su infraestructura de aplicaciones nativas de la nube, constantemente agregan nuevas métricas, crean trazas, añaden comprobaciones de seguridad y más. Los espacios de nombres de Kubernetes aíslan a los equipos de desarrollo de aplicaciones para que no interfieran entre sí, lo cual es increíblemente útil. Sin embargo, con el tiempo, los equipos de plataforma descubrieron que estaban escribiendo el mismo código para cada aplicación, por lo que decidieron colocar ese código en una biblioteca.

En ese momento surgió un nuevo modelo llamado sidecars. Con los sidecars, en lugar de tener que construir físicamente estas bibliotecas en las aplicaciones, los equipos de plataforma podían hacer que coexistieran junto a las aplicaciones. Implementaciones de service mesh como Istio y Linkerd utilizan el modelo sidecar para acceder al espacio de nombres de red de cada instancia de un contenedor de aplicación en un pod de Kubernetes. Esto permite al service mesh modificar el tráfico de red en nombre de la aplicación, por ejemplo, añadir mTLS a una conexión o dirigir paquetes a instancias específicas de un servicio.

Sin embargo, desplegar sidecars en cada pod utiliza recursos adicionales y los operadores de plataforma se quejan de la complejidad operativa. Además, alarga significativamente el recorrido de cada paquete de red, lo que añade una latencia significativa y ralentiza la capacidad de respuesta de la aplicación, llevando a Kelsey Hightower de Google a lamentar nuestro "desorden de servicios".

Diferencias entre pruebas de carga y pruebas de estrés: todo lo que necesitas saber

Casi 10 años en este viaje de contenedores y Kubernetes "nativos de la nube", nos encontramos en una encrucijada en cuanto a dónde deben residir las abstracciones y cuál es la arquitectura adecuada para las características compartidas de la plataforma en los requisitos comunes de las aplicaciones nativas de la nube a través de la red. Los propios contenedores surgieron de cgroups y los espacios de nombres en el kernel de Linux, y el modelo de sidecar permite que las herramientas de redes, seguridad y observabilidad compartan los mismos cgroups y espacios de nombres que los contenedores de aplicación en un pod de Kubernetes.

Una evolución de vuelta al kernel

Pero, ¿y si el propio kernel pudiera ejecutar el service mesh de forma nativa, al igual que ya ejecuta la pila TCP/IP? ¿Y si se pudiera liberar al camino de datos de la latencia del sidecar en casos donde la latencia realmente importa, como en los servicios financieros y las plataformas de negociación que manejan millones de transacciones concurrentes, y en otros casos de uso empresarial comunes? ¿Y si los ingenieros de plataformas de Kubernetes pudieran obtener los beneficios de las características del service mesh sin tener que aprender nuevas abstracciones?

Estas fueron las inspiraciones que llevaron a Thomas Graf, CTO y co-fundador de Isovalent, a crear Cilium Service Mesh, una importante nueva incorporación de código abierto en la categoría de service mesh. Isovalent anunció hoy la disponibilidad general de Cilium Service Mesh. Mientras que gigantes de la web como Google y Lyft son los impulsores detrás del sidecar service mesh Istio y el proxy de facto Envoy, respectivamente, Cilium Service Mesh proviene de los mantenedores del kernel de Linux y los contribuyentes en el mundo de la red empresarial. Esto resulta ser muy relevante.

El lanzamiento de Cilium Service Mesh tiene sus orígenes en eBPF, un marco que ha creado una revolución en el mundo del kernel de Linux al permitir a los usuarios cargar y ejecutar programas personalizados dentro del kernel del sistema operativo. Después de su creación por mantenedores del kernel que reconocieron el potencial de eBPF en la red nativa de la nube, Cilium, un proyecto de la CNCF, se ha convertido en la plataforma de datos por defecto de Google Kubernetes Engine, Amazon EKS Anywhere y Alibaba Cloud.

Cilium utiliza eBPF para ampliar las capacidades de red del kernel y hacerlas nativas de la nube, con conocimiento de las identidades de Kubernetes y una ruta de datos mucho más eficiente. Durante años, Cilium ha actuado como una interfaz de red de Kubernetes y ha tenido muchos de los componentes de un service mesh, como el equilibrio de carga, la observabilidad y el cifrado. Si Kubernetes es el sistema operativo distribuido, Cilium es la capa de red distribuida de ese sistema operativo. No es un gran salto extender las capacidades de Cilium para admitir una amplia gama de características de service mesh.

El creador de Cilium y CTO y co-fundador de Isovalent, Thomas Graf, dijo lo siguiente en una publicación de blog:

Cómo seleccionar software de manera eficiente: consejos y técnicas

Con esta primera versión estable de Cilium Service Mesh, los usuarios ahora tienen la opción de ejecutar un service mesh con o sin sidecars. Cuándo utilizar mejor cada modelo depende de varios factores, incluyendo la sobrecarga, la gestión de recursos, dominio de fallos y consideraciones de seguridad. De hecho, los compromisos son bastante similares a las máquinas virtuales y los contenedores. Las VM proporcionan un aislamiento más estricto. Los contenedores son más ligeros, pueden compartir recursos y ofrecen una distribución equitativa de los recursos disponibles. Por esta razón, los contenedores suelen aumentar la densidad de implementación, con el compromiso de desafíos adicionales de seguridad y gestión de recursos. Con Cilium Service Mesh, tienes ambas opciones disponibles en tu plataforma e incluso puedes ejecutar una combinación de ambas.

El futuro de la infraestructura nativa de la nube es eBPF

Como uno de los mantenedores del proyecto Cilium (los contribuyentes incluyen a Datadog, F5, Form3, Google, Isovalent, Microsoft, Seznam.cz y The New York Times), Liz Rice, COO de Isovalent, ve este cambio de colocar la instrumentación en la nube directamente en el kernel como algo revolucionario para los ingenieros de plataforma.

"Cuando colocamos la instrumentación dentro del kernel utilizando eBPF, podemos ver y controlar todo lo que sucede en esa máquina virtual, por lo que no tenemos que hacer ningún cambio en las cargas de trabajo de las aplicaciones ni en su configuración", dijo Rice. "Desde una perspectiva nativa de la nube, esto hace que sea mucho más fácil asegurar y gestionar, y mucho más eficiente en términos de recursos. En el mundo antiguo, tendríamos que instrumentar cada aplicación por separado, ya sea con bibliotecas comunes o con contenedores sidecar".

La ola de innovación en virtualización que redefinió el centro de datos en los años 2000 estuvo en gran parte guiada por una única plataforma de proveedor, VMware.

La infraestructura nativa de la nube es un panorama de proveedores mucho más fragmentado. Pero los antecedentes de Isovalent en eBPF hacen que sea una empresa muy interesante de seguir en cómo las preocupaciones clave de abstracción de networking y seguridad están volviendo al kernel. Como creadores originales de Cilium, el equipo de Isovalent también incluye mantenedores del kernel de Linux y un inversor principal en Martin Casado de Andreessen Horowitz, que es conocido por ser el creador de Nicira, la plataforma de red definitoria para la virtualización.

Después de una década en la que la virtualización dominó la infraestructura empresarial, seguida de una década de contenedores y Kubernetes, parece que estamos en el umbral de otra gran ola de innovación. Curiosamente, la próxima ola de innovación podría llevarnos directamente al poder del núcleo del sistema operativo Linux.

Las mejores alternativas gratuitas y de pago a PhpStorm para desarrolladores de PHP

Divulgación: Trabajo para MongoDB, pero las opiniones expresadas aquí son mías.

Obtenga la certificación de Docker y estudie para el examen de certificación CKA de Kubernetes con este curso de Newsmatic Academy.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Desarrollo, allí encontraras muchos artículos similares a Cilium Service Mesh: El futuro de la infraestructura nativa en la nube está en eBPF , tenemos lo ultimo en tecnología 2023.