How eBPF unlocks cloud native innovation

A Barbara Liskov, la brillante ganadora del premio Turing cuya carrera inspiró tanto pensamiento moderno en torno a la computación distribuida, le gustaba mencionar el “poder de la abstracción” y su papel en “encontrar la interfaz correcta para un sistema, así como encontrar un diseño eficaz para una implementación del sistema.”

Se ha demostrado que Liskov tiene razón muchas veces, y ahora nos encontramos en una coyuntura en la que las nuevas abstracciones, y eBPF, específicamente, están impulsando la evolución del diseño de sistemas nativos en la nube de formas nuevas y poderosas. Estas nuevas abstracciones están desbloqueando la próxima ola de innovación nativa en la nube y marcarán el rumbo para la evolución de la computación nativa en la nube.

Desafíos nativos de la nube: complejidad y escala

Antes de sumergirnos en eBPF, primero examinemos qué es la nube nativa y por qué necesita evolucionar.

La nube nativa adopta un modelo de contenedor en el que un solo kernel se convierte en el denominador común para administrar muchos objetos de red. Vemos tendencias relacionadas, como que las redes se basen en espacios de nombres, donde las máquinas virtuales completas se reemplazan por contenedores o máquinas virtuales ligeras. La nube nativa cambia la escala y el alcance de unas pocas máquinas virtuales a muchos contenedores con una mayor densidad de contenedores por nodo para un uso eficiente de los recursos y una vida útil más corta de los contenedores. Estos grupos de IP dinámicos para contenedores también tienen una alta rotación de IP.

Los desafíos no terminan ahí.

Una vez que haya levantado y puesto en marcha su clúster, hay desafíos del “Día 2” como la observabilidad, la seguridad, la gestión de múltiples clústeres y de la nube, y el cumplimiento. No se cambia a un entorno nativo de la nube con solo pulsar un botón. Es un viaje progresivo.

Una vez que haya configurado un entorno nativo en la nube, enfrentará requisitos de integración con cargas de trabajo externas (por ejemplo, a través de direcciones IP más predecibles a través de abstracciones de servicios o puertas de enlace de salida, como BGP para redes de pod, CIDR, servicios y puertas de enlace). También tendrá que lidiar con la migración sucesiva hacia clústeres solo de IPv6 para una mejor flexibilidad de IAM y NAT46/64 para la interacción con cargas de trabajo heredadas y poder conectar múltiples clústeres dentro/fuera de las instalaciones de manera escalable, con reconocimiento de topología. enrutamiento y cifrado de tráfico, y mucho más.

Estos problemas solo van a crecer, y Gartner estima que para 2025 más del 95 % de las nuevas cargas de trabajo digitales se implementarán en plataformas nativas de la nube, frente al 30 % en 2021.

Limitaciones de los componentes básicos del kernel de Linux

El kernel de Linux, como siempre, es la base para resolver estos desafíos, con aplicaciones que usan sockets como fuentes y sumideros de datos y la red como bus de comunicación. Linux y Kubernetes se han unido como el “SO en la nube”.

Pero la nube nativa necesita abstracciones más nuevas que las disponibles actualmente en el kernel de Linux porque muchos de estos componentes básicos, como cgroups (CPU, manejo de memoria), espacios de nombres (net, mount, pid), SELinux, seccomp, netfiler, netlink, AppArmor, auditd, perf, fueron diseñados hace más de 10 años.

Estas herramientas no siempre interactúan entre sí y algunas son inflexibles, lo que permite solo políticas globales y no políticas por contenedor. No conocen los pods ni ninguna abstracción de servicio de nivel superior, y muchos confían en iptables para la creación de redes.

Como equipo de la plataforma, si desea proporcionar herramientas de desarrollo para un entorno nativo de la nube, aún puede quedarse atrapado en este cuadro en el que los entornos nativos de la nube no se pueden expresar de manera eficiente.

eBPF: Creación de abstracciones para el mundo nativo de la nube

eBPF es una tecnología revolucionaria que nos permite programar dinámicamente el kernel de forma segura, eficiente y escalable. Se utiliza para ampliar de manera segura y eficiente las capacidades nativas de la nube del kernel sin necesidad de cambios en el código fuente del kernel ni de cargar módulos del kernel.

eBPF:

• Enlaces en cualquier parte del kernel para modificar la funcionalidad y personalizar su comportamiento sin cambiar la fuente del kernel
• Se verifica que los programas se ejecuten de manera segura para evitar el bloqueo del kernel u otras inestabilidades
• JIT compilado para una velocidad de ejecución casi nativa
• Permite agregar capacidades del sistema operativo en tiempo de ejecución sin interrumpir la carga de trabajo ni reiniciar el nodo
• Cambia el contexto del espacio del usuario en Kubernetes al kernel de Linux

Estas capacidades nos permiten abstraer de manera segura el kernel de Linux y prepararlo para el mundo nativo de la nube.

Abstracciones de eBPF para la revolución nativa de la nube

A continuación, profundicemos en 10 formas en que la abstracción eBPF está ayudando a evolucionar la pila nativa de la nube, desde acelerar la innovación hasta mejorar el rendimiento.

#1. eBPF acelera la innovación del kernel

Agregar una nueva característica o funcionalidad al kernel de Linux es un proceso largo. En el ciclo de vida típico de un parche, debe desarrollar un parche, fusionarlo aguas arriba y luego esperar hasta que se publiquen las principales distribuciones. Los usuarios suelen ceñirse a los kernels LTS (por ejemplo, Ubuntu suele tener una cadencia de dos años). Por lo tanto, la innovación con el modelo tradicional requiere módulos de kernel o la creación de sus propios kernels, dejando fuera a la mayoría de la comunidad. Y el ciclo de retroalimentación de los desarrolladores a los usuarios es mínimo o inexistente. eBPF logró romper este largo ciclo desvinculándose de las versiones del kernel. Por ejemplo, los cambios en Cilium se pueden actualizar sobre la marcha con el kernel en ejecución y funcionar en una amplia gama de versiones del kernel. Esto nos permite agregar una nueva funcionalidad nativa de la nube años antes de que fuera posible.

#2. eBPF extiende el kernel pero con un cinturón de seguridad puesto

Las nuevas características pueden aumentar la funcionalidad, pero también traer nuevos riesgos y casos extremos. El desarrollo y las pruebas cuestan mucho más para el código del núcleo que para el código eBPF para la misma funcionalidad. El verificador eBPF asegura que el código no bloquee el kernel. La portabilidad de los módulos eBPF entre las versiones del kernel se logra con CO-RE, kconfigs e información de tipo BPF. El sabor eBPF del lenguaje C también es una opción más segura para la programación del núcleo. Todo esto hace que sea más seguro agregar nuevas funciones al kernel que parchear directamente o usar un módulo del kernel.

#3. eBPF permite bucles de retroalimentación de producción cortos

Los bucles de retroalimentación tradicionales requerían parchear el kernel interno, implementar gradualmente el kernel en la flota para implementar el cambio, comenzar a experimentar, recopilar datos y llevar la retroalimentación al ciclo de desarrollo. Fue un ciclo muy largo y frágil en el que los nodos necesitaban reiniciarse y drenar su tráfico, lo que hacía imposible moverse rápidamente, especialmente en entornos dinámicos nativos de la nube. eBPF desacopla este ciclo de retroalimentación del kernel y permite actualizaciones de programas atómicos sobre la marcha, lo que acorta drásticamente este ciclo de retroalimentación.

#4. eBPF proporciona bloques de construcción en el kernel en lugar de reinventar la rueda del espacio de usuario

En lugar de requerir reescrituras de grandes partes de la pila de espacio de usuario, eBPF puede aprovechar partes del kernel y usarlas tal cual mientras hace que la integración sea mucho más fácil. eBPF agrega bloques de construcción al kernel que son demasiado complejos para otros subsistemas del kernel, especialmente para los nuevos casos de uso nativo de la nube. Con eBPF, Cilium pudo agregar fácilmente una puerta de enlace NAT 46/64 para conectar clústeres de Kubernetes solo de IPv6 a una infraestructura basada en IPv4.

#5. eBPF le permite corregir o mitigar errores del kernel sobre la marcha

Recientemente, se utilizó eBPF para corregir un error del kernel en el controlador veth (Ethernet virtual) que afectaba la selección de la cola. (Consulte la charla de la cumbre eBPF, Todas sus colas nos pertenecen). Esta solución sobre la marcha habilitada por eBPF evitó implementaciones complejas de nuevos kernels, un proceso que requiere mucho tiempo para los proveedores de la nube. Las cargas de trabajo nativas de la nube pueden traer nuevos casos extremos al kernel, pero las correcciones sobre la marcha con eBPF hacen que el procesamiento de paquetes sea más resistente y reduce la superficie de ataque de los malos actores.

#6. eBPF acerca el procesamiento de datos a la fuente, lo que reduce el consumo de recursos

Las funciones de red virtualizadas tradicionales, como los equilibradores de carga y los cortafuegos, se resuelven a nivel de paquete. Cada paquete debe ser inspeccionado, modificado o descartado, lo cual es computacionalmente costoso para el núcleo. eBPF reformuló el problema original acercándose lo más posible al origen del evento, hacia enlaces por socket, enlaces por grupo y XDP (ruta de datos eXpress), por ejemplo. Esto resultó en un importante ahorro de costos de recursos y permitió la migración de cajas dedicadas a nodos de trabajo genéricos. Seznam.cz pudo reducir el consumo de CPU de su balanceador de carga en 72 veces usando eBPF.

#7. eBPF permite una menor latencia de tráfico

Mediante el uso de eBPF para el reenvío, permitimos que muchas partes de la pila de red se pasen por alto, lo que mejora en gran medida la eficiencia y el rendimiento de la red. Por ejemplo, con eBPF, Cilium pudo implementar un administrador de ancho de banda que redujo la latencia p99 en 4,2 veces. También ayudó a habilitar BIG TCP y un nuevo reemplazo de controlador veth que permite que los contenedores alcancen velocidades de red de host.

#8. eBPF ofrece un procesamiento de datos eficiente

eBPF reduce el avance lento de funciones del kernel que ralentiza el procesamiento de datos al mantener la ruta rápida al mínimo. No es necesario que los casos de uso nativos de la nube complejos y personalizados formen parte del kernel. Simplemente se convierten en más bloques de construcción en eBPF que se pueden aprovechar en diferentes casos extremos. Por ejemplo, al desacoplar ayudantes y mapas de los puntos de entrada en eBPF, Cilium pudo crear un reemplazo de kube-proxy más rápido y personalizable en eBPF que puede continuar escalando cuando iptables se queda corto.

#9. eBPF facilita una visibilidad profunda del sistema a baja altura

Dada la rotación de las cargas de trabajo nativas de la nube, puede ser difícil encontrar y depurar problemas. Los colectores eBPF hacen posible construir plataformas de seguimiento y observabilidad de baja sobrecarga y para toda la flota. En lugar de tener que modificar el código de la aplicación o agregar sidecars, eBPF permite una observabilidad de instrumentación cero. La resolución de problemas de producción sobre la marcha también se puede realizar de forma segura a través de bpftrace, al tiempo que permite una visibilidad, programabilidad y facilidad de uso significativamente más ricas que las de perf de estilo antiguo.

#10. eBPF crea abstracciones de identidad seguras para la aplicación de políticas

En entornos nativos de la nube, eBPF le permite abstraerse de la alta rotación de IP de pod hacia identidades más duraderas. Las direcciones IP no tienen sentido dado que todo se centra en las etiquetas de los pods y que la vida útil del pod es generalmente muy corta con cargas de trabajo efímeras. Al comprender el contexto del proceso en el núcleo, eBPF ayuda a abstraerse de la IP para proporcionar abstracciones de identidad más concretas. Con una abstracción de identidad segura para las cargas de trabajo, Cilium pudo crear funciones como puertas de enlace de salida para pods de corta duración y mTLS.

eBPF para innovación, abstracción y rendimiento

La nube nativa está cambiando los requisitos de las plataformas que necesitan admitir niveles más altos de rendimiento y escalabilidad junto con cambios constantes. Muchos de los componentes básicos del kernel de Linux que admiten estas cargas de trabajo exigentes tienen décadas de antigüedad. Afortunadamente, eBPF nos permite cambiar dinámicamente el núcleo para crear abstracciones que estén listas para el mundo nativo de la nube. eBPF está desbloqueando la innovación nativa de la nube, creando nuevos bloques de construcción del kernel y mejorando drásticamente el rendimiento de las plataformas de aplicaciones.

Bill Mulligan es un mantenedor de Cilium y está muy involucrado en el ecosistema eBPF. Trabaja en Isovalent.

—

New Tech Forum ofrece un lugar para explorar y discutir la tecnología empresarial emergente en una profundidad y amplitud sin precedentes. La selección es subjetiva, basada en nuestra elección de las tecnologías que creemos que son importantes y de mayor interés para los lectores de InfoWorld. InfoWorld no acepta garantías de marketing para la publicación y se reserva el derecho de editar todo el contenido aportado. Envíe todas las consultas a newtechforum@infoworld.com.