Kubernetes tiene 10 años. A mediados de 2024 se cumple el décimo aniversario de la plataforma de orquestación de contenedores líder en el mercado.
Esa década comenzó cuando los contenedores surgieron como una nueva forma de virtualizar aplicaciones, pero la funcionalidad de almacenamiento y protección de datos era prácticamente inexistente. Ahora, Kubernetes ofrece una plataforma de contenedores madura para aplicaciones nativas de la nube, con todo lo necesario para el almacenamiento de datos con estado.
Celebramos la primera década de Kubernetes con una serie de entrevistas con ingenieros que ayudaron a desarrollar Kubernetes y abordar los desafíos en almacenamiento y protección de datos (incluido el uso de operadores de Kubernetes) mientras miramos hacia un futuro caracterizado por cargas de trabajo de inteligencia artificial (IA).
Aquí, Michelle Au, ingeniera de software de Google que se centra en el desarrollo del almacenamiento de Kubernetes, habla sobre cómo involucrarse en trabajos como agregar soporte para instantáneas y operadores, que agregan funcionalidad y complejidad más allá del núcleo de Kubernetes para servicios avanzados como el almacenamiento y la protección de datos. .
¿Cómo era el mercado cuando se lanzó Kubernetes por primera vez?
Kubernetes fue uno de los primeros en ocupar este espacio. Los contenedores se estaban volviendo populares y las empresas comenzaban a explorar la zona. Hubo muchos proyectos alternativos de orquestación de cargas de trabajo como Mesosphere, Docker Swarm, Cloud Foundry y Nomad.
¿Cómo te involucraste en el almacenamiento de Kubernetes?
En 2017 me uní al equipo de Kubernetes en Google y comencé a trabajar en proyectos como parte del SIG. [special interest group] comunidad de almacenamiento. Antes de eso, solo había oído hablar de Kubernetes a través de rumores, pero nunca lo usé. Pero pensé que sería una gran oportunidad poder participar en un proyecto de código abierto que estaba remodelando la industria.
¿Cuándo se dio cuenta de que Kubernetes ocupaba la posición de liderazgo en el mercado?
Al principio ese no era el caso. Pero ver el crecimiento exponencial de las cargas de trabajo año tras año y escuchar todas las historias de éxito, especialmente con cargas de trabajo con estado, es algo que me enorgullece mucho de lo que hemos construido.
Cuando analizó Kubernetes, ¿cómo abordó los datos y el almacenamiento?
Cuando comencé a aprender sobre Kubernetes, las mayores fortalezas que inmediatamente me surgieron fueron la API declarativa. [application programming interface] y paradigma de diseño de reconciliación, portabilidad de cargas de trabajo entre entornos y estandarización de las mejores prácticas de implementación de cargas de trabajo. Todas estas fortalezas de Kubernetes también fueron objetivos que me guiaron al diseñar las funciones de almacenamiento de Kubernetes.
¿Qué problemas le surgieron primero en torno a los datos y el almacenamiento con Kubernetes?
Cuando me uní al equipo, la ejecución de cargas de trabajo con estado se limitaba principalmente a implementaciones a pequeña escala en la nube. Todavía había muchos puntos de fricción en términos de soporte del ecosistema de almacenamiento, así como de programación, mantenimiento y gestión de interrupciones. Ejecutar estas cargas de trabajo con éxito requirió muchos procesos personalizados, especialmente en torno a los desafíos del segundo día.
Uno de mis primeros proyectos fue agregar soporte para almacenamiento local. Mientras trabajaba en eso, me di cuenta de que había un problema más amplio relacionado con la localización de los datos y decidí abordar el problema de manera más amplia introduciendo la noción de topología de almacenamiento en el programador de Kubernetes. Esto simplificó el proceso de aprovisionamiento de cargas de trabajo con estado para que sean tolerantes a fallas en todos los dominios de fallas, ya sea que se ejecuten en la nube o en las instalaciones.
Más allá de eso, comenzamos a pasar de los problemas del día uno a los problemas del día dos. La compatibilidad con instantáneas era una brecha importante en Kubernetes, pero es fundamental para cualquier estrategia de recuperación ante desastres.
¿Qué tuvo que cambiar?
La implementación de instantáneas fue sorprendentemente nada trivial. Mapear una operación imperativa a una API declarativa requirió múltiples rondas de lluvia de ideas, los proveedores de almacenamiento tenían una semántica ligeramente diferente y también estaba la cuestión de cómo manejar la coherencia de la aplicación. Pero al final pudimos llegar a un consenso y ofrecer esta capacidad crítica que fortaleció aún más la preparación de la carga de trabajo con estado de Kubernetes.
¿Cómo se involucró con los operadores de Kubernetes?
Como parte del equipo de Google Kubernetes Engine (GKE), he trabajado estrechamente con clientes y socios que buscan ejecutar operadores en nuestra plataforma. También me uní a la comunidad de Datos sobre Kubernetes como representante del proyecto Kubernetes y GKE para comprender mejor los puntos débiles que enfrentan los usuarios hoy en día y ayudar a transmitir esos problemas al proyecto Kubernetes.
¿Qué pasó con los operadores que los convirtió en un éxito para los datos y el almacenamiento?
La llegada de los recursos personalizados realmente cambió las reglas del juego para los operadores. Hizo posible desarrollar una API declarativa estilo Kubernetes para su caso de uso específico. Muchas cargas de trabajo con estado tienen una serie de procesos operativos complejos y complicados que no se pueden abstraer fácilmente en el núcleo de Kubernetes, como la configuración de HA. [high availability] y replicación, y gestionar procesos de interrupción y actualización. Los operadores ahora pueden orquestar esta complejidad para los usuarios finales.
¿Cómo respaldó esto enfoques más nativos de la nube? ¿Cuáles fueron las consecuencias?
Las API declarativas pueden habilitar fácilmente GitOps o paradigmas de configuración como código. Los operadores para cargas de trabajo con estado facilitan la automatización del aprovisionamiento, las actualizaciones y otras operaciones de mantenimiento, con el beneficio adicional de ser compatibles con la forma en que las organizaciones administran todas sus otras cargas de trabajo de Kubernetes.
Kubernetes ahora tiene 10 años. ¿Cómo lo piensas hoy?
Kubernetes ha recorrido un largo camino desde “de ninguna manera ejecutaría una base de datos en Kubernetes” hasta “estoy ejecutando bases de datos a escala de petabytes con actualizaciones automáticas y continuas”. Kubernetes se ha convertido en una plataforma estable para ejecutar algunas de las cargas de trabajo más exigentes, y eso se ha demostrado a medida que el proyecto ha cambiado el enfoque de las características que permiten grandes cargas de trabajo a esfuerzos que mejoran la confiabilidad y la estabilidad en los últimos años.
¿Qué problemas existen todavía en torno a Kubernetes en lo que respecta a datos y almacenamiento?
El descubrimiento de ecosistemas es un desafío. Hay muchos proveedores en el sector y, como usuario final, evaluar todas las opciones lleva mucho tiempo y es difícil. Creo que aquí es donde la comunidad de Datos sobre Kubernetes puede ayudar. Han organizado charlas y blogs sobre una amplia variedad de cargas de trabajo con estado que van desde temas introductorios hasta avanzados.
El crecimiento de la IA/ML también ha introducido nuevos desafíos. Las cargas de trabajo de IA/ML tienen patrones de datos y requisitos muy diferentes a los de las bases de datos tradicionales y, por lo general, utilizan almacenamiento de objetos y archivos en lugar de almacenamiento en bloques.
Además, los entornos híbridos o multinube son una realidad, lo que añade requisitos adicionales para la portabilidad entre entornos. He visto que nuestras abstracciones de almacenamiento de Kubernetes continúan resistiendo estos nuevos casos de uso, aunque creo que todavía hay margen para mejoras, especialmente en lo que respecta al ciclo de vida y la administración de los datos.
¿Alguna otra anécdota o información para compartir?
Siempre estamos buscando más contribuyentes y participantes en el almacenamiento SIG de Kubernetes, así como en los datos en Kubernetes. Únase a estas comunidades si está interesado en compartir sus historias o contribuir al proyecto.