¡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. Jan Safranek, ingeniero de software principal de Red Hat, estuvo presente durante la oleada de actividad que vio a Docker y luego a Kubernetes irrumpir en escena y las empresas y los desarrolladores lidiar con cómo proporcionarle almacenamiento persistente. Safranek estuvo presente cuando aparecieron Pets Sets y StatefulSets y ayudó a abordar este problema mediante la gestión de la implementación y el escalado de pods de contenedores. Luego, Safranek participó en el desarrollo de controladores y operadores de CSI (interfaz de almacenamiento de contenedores) que proporcionaban extensiones de software para administrar aplicaciones y sus componentes. 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 materia de 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). ¿Cómo era el mercado cuando se lanzó Kubernetes por primera vez? Jan Safranek: El mundo estaba dominado por máquinas virtuales pesadas o de hardware. Los contenedores Docker se hicieron populares muy rápidamente, pero nadie sabía cómo gestionarlos porque no había herramientas disponibles. Kubernetes trajo consigo un concepto completamente nuevo de ejecución de aplicaciones en fragmentos ligeros y aislados. ¿Cómo se involucró en el trabajo sobre la infraestructura de datos en torno a Kubernetes? Safranek: Para mí fue fácil. Estaba trabajando en herramientas de gestión de almacenamiento de Linux aquí en Red Hat y vi que se estaba formando un nuevo equipo para ayudar con Kubernetes. No sabía nada al respecto, pero parecía interesante, así que me presenté. ¿Cómo se dio cuenta de que Kubernetes estaba en la posición líder del mercado? Safranek: Fue en la primera KubeCon a la que asistí en Seattle en 2016. Antes de eso, conocí a otros ingenieros que estaban haciendo cosas interesantes. Pero allí conocí empresas reales que ejecutaban partes importantes de su infraestructura en Kubernetes. Cuando se interesó en Kubernetes, ¿cómo abordó los datos y el almacenamiento? Safranek: Cuando me uní a Kubernetes, la gente ya se había dado cuenta de que, aunque los contenedores fueran efímeros por naturaleza, tenía que haber algo persistente en el panorama general. Las API básicas [application programming interfaces] Ya existían, incluso con los primeros complementos de volumen, pero nadie sabía realmente cómo usarlos. Llegaron los PetSets y luego cambiaron a StatefulSets, pero incluso con eso puede seguir siendo un desafío ejecutar aplicaciones pesadas basadas en datos en Kubernetes. ¿Qué problemas surgieron primero para usted en relación con los datos y el almacenamiento con Kubernetes? Safranek: Empecé a investigar lo que ya existía en Kubernetes y cómo usarlo. Agregué algunos ejemplos y pruebas de extremo a extremo para familiarizarme con el código y el proceso general. Era muy fácil en ese momento. Recuerdo que avanzaba tan rápido que era muy difícil mantener mis solicitudes de extracción actualizadas. Los primeros problemas reales que necesitábamos resolver eran cómo ejecutar una aplicación con estado, que se resolvió con PetSets/StatefulSets, y cómo consumir datos de sistemas de almacenamiento fuera de Kubernetes. Primero comenzamos con código en árbol para almacenamiento basado en la nube y algunos complementos genéricos para almacenamiento tradicional como NFS e iSCSI. ¿Qué tuvo que cambiar? Safranek: Con una mayor adopción, nos dimos cuenta rápidamente de que necesitábamos un código más sólido. Nuestros controladores iniciales eran muy frágiles, por lo que tuvimos que reescribir todo para proporcionar un comportamiento estable y consistente. Sin embargo, todavía hay margen para mejoras, ya que todos ellos han sobrevivido durante años con solo correcciones de errores menores. Además, a medida que más y más proveedores de almacenamiento querían integrar sus back-ends de almacenamiento con Kubernetes, nos dimos cuenta de que necesitábamos una interfaz de extensión genérica para los complementos de volumen. Primero, se nos ocurrió FlexVolumes, que eran muy engorrosos de usar, pero aprendimos y creamos CSI, que es la interfaz de almacenamiento principal de Kubernetes en la actualidad. Se ha vuelto inmensamente exitoso, y hay al menos 130 controladores que se han incluido voluntariamente y quién sabe cuántos más que no conocemos. Y, a medida que Kubernetes se adoptó y comenzó a ejecutar infraestructura crítica, necesitábamos asegurarnos de no romperlo. Ahora es mucho más difícil introducir una nueva característica o cambiar una existente, ya que se necesitan innumerables revisiones y aprobaciones para garantizar la estabilidad de nuestras versiones. ¿Cómo se involucró en el mundo de los operadores de Kubernetes? Safranek: Red Hat fue uno de los primeros en adoptar los operadores. Los comienzos fueron bastante animados. Personalmente, comencé con algunos malos, pero rápidamente aprendí a escribir buenos operadores. Todo se logra con la práctica, como con cualquier cosa en el desarrollo de software. Además, hoy en día hay más documentación que nunca. ¿Qué sucedió con los operadores que los convirtió en un éxito para los datos y el almacenamiento? Safranek: Tengo una experiencia mixta aquí. Muchos operadores no son mejores que los gráficos de Helm. [which describe a related set of Kubernetes resources]. Sin embargo, los buenos ayudaron a las empresas a aliviar sus problemas con las aplicaciones que necesitan datos persistentes. Todavía es difícil ejecutar una aplicación con estado correctamente, con todos los casos extremos cubiertos. ¿Cómo respaldó esto más enfoques nativos de la nube? ¿Cuáles fueron las consecuencias? Safranek: Como mencioné, es más fácil para los devops confiar en un operador externo para ejecutar su base de datos u otra carga de trabajo con estado mientras se concentran en unir estas piezas en una gran aplicación que ejecute su negocio. Kubernetes ahora tiene 10 años. ¿Cómo lo ve hoy? Safranek: Bueno, ha sido un viaje. Desde los comienzos, cuando cualquiera podía reescribir cualquier cosa en un software estable como una roca que mantiene este mundo en funcionamiento o al menos algunas partes muy importantes de él, hasta que se convirtió en una pieza aburrida de infraestructura. ¿Qué problemas aún existen en torno a Kubernetes en lo que respecta a los datos y el almacenamiento? Safranek: Todos los contenedores son efímeros por naturaleza y podrían tener una vida útil corta. Kubernetes puede intentar ejecutarlos durante mucho tiempo, pero cuando necesite eliminarlos, lo hará. Kubernetes ofrece algunas API, como PodDisruptionBudget, para mantener la cantidad absolutamente necesaria de contenedores en funcionamiento, pero todas las aplicaciones con estado deben contar con algún tipo de interrupción. Este es un concepto nuevo y todavía es difícil manejarlo correctamente. ¿Alguna otra anécdota o información para compartir? Safranek: Lo mejor de trabajar en Kubernetes es que he conocido a gente muy inteligente, he aprendido mucho y todavía sigo aprendiendo.