Cilium Service Mesh: un nuevo puente de regreso al núcleo de la infraestructura nativa de la nube

Si bien los desarrolladores han prosperado claramente con los contenedores y el formato Docker durante los últimos 10 años, ha sido una década de bricolaje y prueba y error para los equipos de ingeniería de plataformas encargados de construir y operar la infraestructura de Kubernetes.

En los primeros días de los contenedores, había una carrera de jaulas de tres vías entre Docker Swarm, CoreOS y Apache Mesos (conocido por matar a las «ballenas fallidas» en Twitter) para ver quién tomaría la nube cruzada y orquestaría las cargas de trabajo en contenedores en el nube Trono – grupo de lugar.Luego, se revelaron los secretos del sistema Borg nativo de Google, seguido de Liberar Kubernetes (¡Para el resto de nosotros, Borg!), Inmediatamente hizo crecer todos los intereses de la comunidad y el apoyo de la industria en la tecnología de orquestación de contenedores de facto.

Tanto, de hecho, que tengo debate Kubernetes es como un «sistema operativo nativo de la nube», el nuevo «Linux empresarial», por así decirlo.

Pero, ¿es realmente así? A pesar de todo el poder que proporciona Kubernetes en términos de administración de recursos de clúster, los equipos de ingeniería de plataformas siguen sumidos en los desafíos más difíciles de cómo las aplicaciones nativas de la nube se comunican entre sí y comparten funciones comunes de red, seguridad y resistencia. En resumen, Kubernetes de nivel empresarial es más que una orquestación de contenedores.

Espacios de nombres, sidecars y mallas de servicio

A medida que los equipos de la plataforma evolucionan su infraestructura de aplicaciones nativas de la nube, constantemente superponen cosas como publicar nuevas métricas, crear registros, agregar controles de seguridad y más. Los espacios de nombres de Kubernetes son muy útiles para aislar a los equipos de desarrollo de aplicaciones para que no se pisen entre sí. Pero con el tiempo, el equipo de la plataforma descubrió que estaban escribiendo el mismo código para cada aplicación, lo que provocó que colocaran ese código en una biblioteca.

VER: Kit de herramientas de contratación: Desarrollador backend (Tecnopedia Premium)

Luego vino un nuevo modelo llamado sidecar. Con Sidecar, en lugar de construir físicamente estas bibliotecas en la aplicación, el equipo de la plataforma ahora puede permitir que coexista con la aplicación. Las implementaciones de Service Mesh como Istio y Linkerd usan un modelo sidecar para que puedan acceder al espacio de nombres de red de cada instancia de un contenedor de aplicaciones en un pod. Esto permite que la malla de servicios modifique el tráfico de red en nombre de la aplicación, por ejemplo, agregando mTLS a la conexión, o dirija paquetes a instancias específicas del servicio.

Pero la implementación de sidecars en cada módulo consume recursos adicionales y los operadores de la plataforma se quejan de la complejidad operativa. También alargó significativamente la ruta de cada paquete de red, agregando una latencia significativa y ralentizando la capacidad de respuesta de las aplicaciones, lo que llevó a Kelsey Hightower de Google lamento Nuestro «caos de servicio».

Casi 10 años después de este viaje nativo en la nube, contenedor más Kubernetes, nos encontramos en una encrucijada donde debe residir la abstracción y cuál es la arquitectura adecuada para compartir las capacidades de la plataforma en las necesidades comunes de las aplicaciones nativas de la nube. Los propios contenedores nacen de cgroups y espacios de nombres en el kernel de Linux, y el modelo sidecar permite que las herramientas de redes, seguridad y observabilidad compartan los mismos cgroups y espacios de nombres que los contenedores de aplicaciones en los pods de Kubernetes.

Hasta ahora, ha sido un enfoque normativo. Los equipos de la plataforma tuvieron que adoptar un modelo sidecar porque no había otras buenas herramientas entre las que elegir para acceder o modificar el comportamiento de las cargas de trabajo de las aplicaciones.

Volver a la evolución del núcleo

Pero, ¿y si el propio núcleo pudiera ejecutar la red de servicio localmente como si ya ejecutara la pila TCP/IP? ¿Qué pasaría si las rutas de datos pudieran deshacerse de la latencia del sidecar en situaciones en las que la baja latencia es realmente importante (como servicios financieros y plataformas comerciales que llevan millones de transacciones simultáneas y otros casos de uso empresarial comunes)? ¿Qué pasaría si los ingenieros de la plataforma Kubernetes pudieran obtener los beneficios de las características de Service Mesh sin aprender nuevas abstracciones?

Estas inspiraciones llevaron al CTO y cofundador de Isovalent, Thomas Graf, a crear Cilium Service Mesh, un importante nuevo participante de código abierto en la categoría de malla de servicios.equivalente Anunciar Cilium Service Mesh se lanza oficialmente hoy. Los extensores de red como Google y Lyft son la fuerza impulsora detrás de Istio, la malla de servicio sidecar, y Envoy, el servicio de proxy de facto, respectivamente, mientras que Cilium Service Mesh proviene de los mantenedores del kernel de Linux y contribuyentes del mundo de las redes empresariales. Resulta que esto puede ser importante.

El lanzamiento de Cilium Service Mesh se originó a partir de eBPF, un marco Tomando el mundo del kernel de Linux por asalto Al permitir que los usuarios carguen y ejecuten programas personalizados en el kernel del sistema operativo. Después de ser creado por los mantenedores del kernel que reconocieron el potencial de eBPF en las redes nativas de la nube, Cilium (un proyecto CNCF) es ahora el plano de datos predeterminado para Google Kubernetes Engine, Amazon EKS Anywhere y Alibaba Cloud.

Cilium usa eBPF para ampliar las capacidades de red del kernel para que sean nativas de la nube, con reconocimiento de identidad de Kubernetes y rutas de datos más eficientes. Durante años, Cilium, actuando como la interfaz de red de Kubernetes, ha tenido muchos componentes de una red de servicios, como equilibrio de carga, observabilidad y cifrado. Si Kubernetes es un sistema operativo distribuido, entonces Cilium es la capa de red distribuida de ese sistema operativo. Ampliar las capacidades de Cilium para admitir una gama completa de capacidades de red de servicios no es un gran salto.

Thomas Graf, fundador de Cilium, CTO y cofundador de Isovalent entrada en el blog:

Con la primera versión estable de Cilium Service Mesh, los usuarios ahora pueden elegir ejecutar Service Mesh con o sin sidecars. Cuándo y qué modelo es mejor usar depende de una variedad de factores, incluidos los gastos generales, la administración de recursos, los dominios de fallas y las consideraciones de seguridad. De hecho, las ventajas y desventajas son muy similares a las máquinas virtuales y los contenedores. Las máquinas virtuales proporcionan un aislamiento más estricto. Los contenedores son más ligeros, capaces de compartir recursos y proporcionar una distribución justa de los recursos disponibles. Debido a esto, los contenedores a menudo aumentan la densidad de implementación al tiempo que sopesan los desafíos adicionales de seguridad y administración de recursos. Con una malla de servicios de Cilium, puede usar ambas opciones en su plataforma o incluso mezclarlas.

El futuro de la infraestructura nativa de la nube es eBPF

Como uno de los mantenedores del proyecto Cilium, cuyos colaboradores incluyen Datadog, F5, Form3, Google, Isovalent, Microsoft, Seznam.cz y The New York Times, Liz Rice, directora de código abierto de Isovalent, ve un cambio en la nube. Computación Instrumentación directamente en el núcleo como un cambio de juego para los ingenieros de plataforma.

«Cuando usamos eBPF para instrumentar en el kernel, 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 la aplicación o en cómo están configuradas», dijo Rice. «Desde una perspectiva nativa de la nube, esto hace que las cosas sean más fáciles de proteger y administrar, y más eficientes en el uso de los recursos. En el viejo mundo, tendrías que instrumentar cada aplicación individualmente usando una biblioteca común o un contenedor sidecar».

La ola de innovación en virtualización que redefinió el centro de datos en la década de 2000 estuvo liderada en gran medida por una plataforma de un solo proveedor dentro de VMware.

La infraestructura nativa de la nube es un panorama de proveedores más fragmentado. Pero el realismo de Isovalent en eBPF hace que sea una empresa muy interesante para observar cómo las abstracciones clave de redes y seguridad regresan al kernel. Como creador original de Cilium, el equipo de Isovalent también incluye mantenedores del kernel de Linux y un importante inversor en Martin Casado de Andreessen Horowitz, mejor conocido como el creador de Nicira, la plataforma de red que define la virtualización.

Después de una década de virtualización que gobierna la infraestructura empresarial, y luego una década de contenedores y Kubernetes, parece que estamos en la cúspide de otra gran ola de innovación. Curiosamente, la próxima ola de innovación puede llevarnos de vuelta al poder del kernel de Linux.

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

Obtenga la certificación con Docker y realice el examen de certificación CKA de Kubernetes este curso De la Academia Tecnopedia.