¡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. Pero, según Patrick McFadin, encargado de relaciones con desarrolladores de DataStax, la plataforma de orquestación de contenedores se encuentra en una fase de “adolescente hosco”, con algunos desafíos en la eficiencia de la gestión aún por resolver.
También recuerda cómo Kubernetes, también conocido como K8, superó sus primeros desafíos y cree que todavía estará aquí por algún tiempo.
Los primeros años de Kubernetes comenzaron cuando los contenedores surgieron como una nueva forma de virtualizar aplicaciones, pero con una funcionalidad de almacenamiento y protección de datos que 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í, Patrick McFadin, vicepresidente de relaciones con desarrolladores de DataStax, especialista en bases de datos NoSQL, habla sobre cómo Kubernetes fue uno entre muchos orquestadores de contenedores, el momento en que se dio cuenta de que “Kubernetes acaba de ganar”, los obstáculos para el almacenamiento eficiente y el papel de StatefulSet y operadores que proporcionan automatización programable para almacenamiento y otros servicios.
¿Cómo era el mercado cuando se lanzó Kubernetes por primera vez?
Cuando Kubernetes llegó por primera vez, había varios actores en torno a la orquestación de contenedores. Tenía Docker Swarm y Apache Mesos, que fue diseñado para ejecutar grandes cargas de trabajo analíticas. Kubernetes llegó con un reclamo a la fama: vino de Google. La cuestión de la gestión de grandes infraestructuras era un problema claro que la gente intentaba resolver, por lo que el mercado estaba preparado para una buena solución.
¿Cómo empezó a trabajar en la infraestructura de datos en torno a Kubernetes?
Trabajar en una gran base de datos distribuida me puso en medio de los desafíos operativos para los usuarios. Puede administrar un puñado de servidores sin muchas herramientas, pero eso desaparece cuando se encuentra ampliando más de 10, 100 o 1000 nodos. Mesos encajaba bien con Apache Cassandra y fue la razón por la que comencé a trabajar con ese proyecto. También estaba trabajando en Apache Spark, que encajaba bien con Mesos. En ese momento, Kubernetes se estaba volviendo muy conocido como administrador de contenedores para front-end, por lo que en la comunidad de infraestructura de back-end no estaba teniendo un impacto tan grande.
¿Cómo se dio cuenta de que Kubernetes ocupaba la posición de liderazgo en el mercado?
Durante una conferencia celebrada en 2017 por Mesosphere, una empresa que proporcionó una versión empresarial de Mesos, el director ejecutivo y cofundador Ben Hindman anunció el soporte de Mesos para Kubernetes. Fue un momento de iluminación. Me volví hacia la persona que estaba a mi lado y le dije: “Kubernetes acaba de ganar”. Me tomó un tiempo lograrlo, pero este fue uno de los puntos de inflexión que vi.
Cuando analizó Kubernetes, ¿cómo abordó los datos y el almacenamiento?
Ese fue el principal problema entre Mesos y Kubernetes. Mesos fue mucho mejor en la gestión de recursos de almacenamiento. Inicialmente, Kubernetes trató el almacenamiento como una idea de último momento, y cuando su base de datos depende de un almacenamiento de alta calidad, fue una opción horrible. Evitar Kubernetes para cargas de trabajo de datos fue el mejor enfoque durante mucho tiempo.
¿Qué problemas le surgieron primero en torno a los datos y el almacenamiento con Kubernetes?
Aprovisionamiento y calidad. Inicialmente, Kubernetes trataba el almacenamiento como efímero, lo que significa que tan pronto como se eliminaba el contenedor, todo el almacenamiento desaparecía. No es bueno para bases de datos. Había algunos trucos para mantener los datos de un reinicio a otro, pero ninguno estaba integrado en Kubernetes. Dado el volumen de los contenedores, el rendimiento dejaba mucho que desear. En general, hubo muchos problemas que impidieron que los usuarios serios participaran.
¿Qué tuvo que cambiar?
Cambiar la forma en que se abordaba el almacenamiento era la primera orden del día. Kubernetes introdujo StatefulSet, que cambió por completo la forma en que se aprovisionaba el almacenamiento. Modeló lo que se necesitaba para un servidor con estado como una base de datos. El siguiente gran cambio fue la incorporación de operadores. Debido a que se estaban agregando servidores a un sistema que controlaba el aprovisionamiento, era necesario que hubiera una manera de traducir comandos como “iniciar” y “detener”. Los operadores crearon la capa de traducción entre Kubernetes y los servicios establecidos que se incorporan.
¿Cómo se involucró con los operadores de Kubernetes?
La comunidad de Datos sobre Kubernetes trabajó mucho para que este concepto fuera uno que la gente estuviera dispuesta a aceptar. Cuando empezamos, recibimos comentarios que decían: “¿Poner mis datos en Kubernetes? ¿Estás loco?” Pero también vimos a muchos desarrolladores decir: “Quiero que todo esté en un solo lugar, así que haz que funcione”. Con el tiempo, ese esfuerzo comunitario tuvo éxito. Creo que 2022 fue el punto de inflexión en el que vimos más personas dispuestas a ejecutar sus datos en Kubernetes que no. Esto se basó en los esfuerzos por crear operadores de calidad.
¿Qué pasó con los Operadores que los convirtió en un éxito para los datos y el almacenamiento?
Los operadores resolvieron un problema enorme y fueron fáciles de montar. Mucha gente reunió sus propios operadores; era como si apareciera otro operador para proyectos cada dos fines de semana. Eso fue genial, pero significó que había muchas fracturas con proyectos abandonados que hacían lo básico, pero no colaboraban. Todos querían ser quienes crearan el operador, así que terminaste con muchos que hacían lo mismo de maneras ligeramente diferentes.
Vimos esto en la comunidad Apache Cassandra. Creo que había alrededor de 12 operadores diferentes al mismo tiempo en un momento dado y todos eran buenos en cosas específicas. Pero no nos beneficiamos de colaborar entre nosotros y mejorar las cosas. A la comunidad le tomó un poco de tiempo reunirse y acordar lo que queríamos, en qué queríamos trabajar y cómo hacerlo juntos. Pero cuando eso empezó, creo que marcó una gran diferencia.
¿Cómo respaldó esto enfoques más nativos de la nube? ¿Cuáles fueron las consecuencias?
Creo que ayudó al enfoque general de las aplicaciones nativas de la nube porque podía ejecutar sus aplicaciones y su infraestructura en el mismo lugar y administrar todo de manera consistente. Cuando tienes microservicios y contenedores, quieres poder escalar y mover cosas cuando lo necesites en lugar de estar atado a lo que tienes. Cuando también podía hacer eso para su base de datos, simplemente simplificaba las cosas. Y cuando se pudo comenzar con las pruebas, fue más fácil demostrar que esto funcionaba y se podía pasar a producción. Es todo el argumento en torno a la gravedad de los datos. Vimos que los datos se trasladaban al almacenamiento en torno a la virtualización y vimos que más datos se trasladaban a la nube junto con las aplicaciones, por lo que es natural que veamos que eso también ocurre con los contenedores y los nativos de la nube.
DataStax ha construido su Cassandra como servicio, Astra DB, en Kubernetes. Creo que ese es el respaldo más fuerte que puedo darle.
Patrick McFadin, DataStax
Kubernetes ahora tiene 10 años. ¿Cómo lo piensas hoy?
Creo que mucha gente piensa que Kubernetes está terminado y que las cosas seguirán creciendo. No veo eso. Creo que estamos en la fase de adolescente hosco y todavía quedan muchas cosas por resolver. Pero es un sistema estable en el que puede confiar. DataStax ha construido su Cassandra como servicio, Astra DB, en Kubernetes. Creo que ese es el respaldo más fuerte que puedo darle.
¿Qué problemas existen todavía en torno a Kubernetes en lo que respecta a datos y almacenamiento?
La madurez del proyecto va a estar en la eficiencia. Todavía se necesita mucho esfuerzo manual para ejecutar una implementación de Kubernetes sin problemas. Ampliar es fácil, pero reducirlo es difícil, hasta el punto de que rara vez se hace. GenAI [generative artificial intelligence] Sin duda aparecerá aquí como la idea de AIOps. [artificial intelligence for IT operations] gana terreno. Explicar lo que se quiere desde el punto de vista de la aplicación y ver cómo emerge la infraestructura parecerá mágico, pero en realidad eso es solo un progreso.
