¡Kubernetes cumple 10 años! A mediados de 2024 se cumplirá el décimo aniversario de la plataforma de orquestación de contenedores líder en el mercado. Sin embargo, según Patrick McFadin, responsable de relaciones con los 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 K8s, superó sus primeros desafíos y cree que todavía está 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. Marcamos la primera década de Kubernetes con una serie de entrevistas con ingenieros que ayudaron a desarrollar Kubernetes y abordar los desafíos en el almacenamiento y la 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 en el especialista en bases de datos NoSQL DataStax, habla sobre cómo Kubernetes fue uno entre muchos orquestadores de contenedores, el momento en que se dio cuenta de que «Kubernetes simplemente ganó», los obstáculos para el almacenamiento eficiente y el papel de StatefulSet y los operadores que brindan automatización programable para el almacenamiento y otros servicios. ¿Cómo era el mercado cuando se lanzó Kubernetes por primera vez? Cuando Kubernetes llegó por primera vez, había múltiples actores en torno a la orquestación de contenedores. Tenías 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. El problema de la gestión de grandes infraestructuras era un problema claro que la gente estaba tratando de resolver, por lo que el mercado estaba listo para una buena solución. ¿Cómo te involucraste en el trabajo sobre la infraestructura de datos en torno a Kubernetes? Trabajar en una gran base de datos distribuida me puso justo en medio del trabajo con los desafíos operativos para los usuarios. Puedes gestionar un puñado de servidores sin muchas herramientas, pero eso se pierde cuando te encuentras escalando más allá de 10, 100 o 1000 nodos. Mesos era una buena opción para Apache Cassandra y fue la razón por la que comencé a trabajar en ese proyecto. También estaba trabajando en Apache Spark, que encajaba bien con Mesos. En ese momento, Kubernetes se estaba volviendo conocido como un 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 te diste cuenta de que Kubernetes estaba en la posición líder en el mercado? Durante una conferencia celebrada en 2017 por Mesosphere, una empresa que proporcionaba 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». Tardó un tiempo en concretarse, pero este fue uno de los puntos de inflexión que vi. Cuando analizaste Kubernetes, ¿cómo abordaste los datos y el almacenamiento? Ese fue el problema principal entre Mesos y Kubernetes. Mesos era mucho mejor en la gestión de los recursos de almacenamiento. Kubernetes trató el almacenamiento como una ocurrencia de último momento al principio, y cuando tu base de datos depende de un almacenamiento de alta calidad, fue una combinación horrible. Evitar Kubernetes para las cargas de trabajo de datos fue el mejor enfoque durante mucho tiempo. ¿Qué problemas surgieron primero en relación con los datos y el almacenamiento con Kubernetes para ti? Aprovisionamiento y calidad. Kubernetes inicialmente trató el almacenamiento como efímero, lo que significa que tan pronto como se eliminaba el contenedor, todo tu almacenamiento desaparecía. No es bueno para las bases de datos. Había algunos trucos para mantener los datos de un reinicio a otro, pero ninguno estaba integrado en Kubernetes. Luego, al ser volúmenes de contenedores, el rendimiento dejaba mucho que desear. En general, hubo muchos problemas que impidieron que los usuarios serios se lanzaran. ¿Qué tenía que cambiar? Cambiar la forma en que se abordaba el almacenamiento fue 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 forma de traducir comandos como «iniciar» y «detener». Los operadores crearon la capa de traducción entre Kubernetes y los servicios establecidos que se estaban incorporando. ¿Cómo se involucró con los operadores de Kubernetes? La comunidad de datos sobre Kubernetes trabajó mucho para que este concepto fuera algo que la gente estuviera dispuesta a aceptar. Cuando comenzamos, recibimos comentarios que decían: «¿Poner mis datos en Kubernetes? ¿Estás loco?». Pero también vimos a muchos desarrolladores decir: «Quiero todo en un solo lugar, así que haz que funcione». Con el tiempo, ese esfuerzo de la comunidad 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 las que no. Eso se basó en los esfuerzos por crear operadores de calidad. ¿Qué sucedió con los operadores que los convirtió en un éxito para los datos y el almacenamiento? Los operadores resolvieron un gran problema y fueron fáciles de armar. Muchas personas armaron sus propios operadores, era como si saliera otro operador para los proyectos cada dos fines de semana. Eso fue genial, pero significó que había mucha fragmentación con proyectos abandonados que hacían lo básico, pero no había colaboración. Todos querían ser los que armaran el operador, así que terminaste con muchos que hacían lo mismo de maneras muy 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. La comunidad tardó un poco en unirse y acordar lo que queríamos, en lo que queríamos trabajar y cómo hacerlo juntos. Pero cuando eso comenzó, creo que marcó una gran diferencia. ¿Cómo respaldó esto más enfoques nativos de la nube? ¿Cuáles fueron las consecuencias? Creo que ayudó al enfoque general de las aplicaciones nativas de la nube porque podías ejecutar tus aplicaciones y tu 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 pudiste hacer eso también para tu base de datos, las cosas se simplificaron. Y cuando pudiste comenzar con las pruebas, fue más fácil demostrar que esto funcionaba y pudiste pasar a la producción. Es todo el argumento en torno a la gravedad de los datos. Vimos que los datos se movían al almacenamiento en torno a la virtualización, y vimos que más datos se movían a la nube junto con las aplicaciones, por lo que es natural que vieras que eso también sucediera 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 ves hoy? Creo que muchas personas piensan que Kubernetes está terminado y que las cosas seguirán creciendo. Yo no lo veo así. Creo que estamos en la fase de adolescentes malhumorados y todavía hay muchas cosas que resolver, pero es un sistema estable en el que se puede confiar. DataStax ha creado su Cassandra como servicio, Astra DB, en Kubernetes. Creo que es la recomendación más firme que puedo darle. ¿Qué problemas aún existen en torno a Kubernetes en lo que respecta a los datos y el almacenamiento? La madurez del proyecto estará en la eficiencia. Todavía se necesita mucho esfuerzo manual para ejecutar una implementación de Kubernetes sin problemas. Escalar hacia arriba 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] Ganando terreno. Explicar lo que se quiere desde el punto de vista de la aplicación y ver cómo surge la infraestructura parecerá magia, pero en realidad eso es solo un progreso.