Kubernetes a las 10: el largo camino hacia el dominio del almacenamiento persistente

¡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.

Jan Safranek, ingeniero de software principal de Red Hat, estuvo allí durante la oleada de actividad que vio a Docker y luego a Kubernetes irrumpir en escena y las empresas y desarrolladores lucharon por cómo proporcionarle almacenamiento persistente.

Safranek estuvo allí cuando aparecieron Pets Sets y StatefulSets y ayudó a abordar este problema gestionando la implementación y escalando los módulos de contenedores. Luego, Safranek participó en el desarrollo de controladores y operadores CSI (Container Storage Interface) que proporcionaban extensiones de software para administrar aplicaciones y sus componentes.

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).

¿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 metal desnudo. Los contenedores Docker se hicieron populares muy rápidamente, pero nadie sabía cómo administrarlos porque no había herramientas disponibles. Kubernetes aportó un concepto completamente nuevo de ejecución de aplicaciones en fragmentos ligeros y aislados.

¿Cómo empezó a trabajar en la infraestructura de datos en torno a Kubernetes?

Safranek: Fue fácil para mí. Estaba trabajando en herramientas de administración de almacenamiento de Linux aquí en Red Hat y vi que se estaba estableciendo un nuevo equipo para ayudar con Kubernetes. No sabía nada al respecto, pero se veía genial, así que presenté mi solicitud allí.

Más contenido para leer:  RAKwireless acerca el núcleo 5G privado a las empresas

¿Cómo se dio cuenta de que Kubernetes ocupaba la posición de liderazgo en el mercado?

Safranek: Fue en la primera KubeCon a la que asistí en Seattle en 2016. Antes de eso, conocí a compañeros ingenieros que estaban haciendo cosas interesantes. Pero allí conocí empresas reales que ejecutaban partes importantes de su infraestructura en Kubernetes.

Cuando analizó Kubernetes, ¿cómo abordó los datos y el almacenamiento?

Safranek: Cuando me uní a Kubernetes, la gente ya se dio cuenta de que incluso cuando los contenedores eran de naturaleza efímera, tenía que haber algo persistente en el panorama general. Las API básicas [application programming interfaces] Ya estaban allí, incluso con los complementos del primer volumen, pero nadie sabía realmente cómo usarlos. Llegó PetSets y luego se cambió a StatefulSets, pero incluso con eso, aún puede ser un desafío ejecutar aplicaciones con gran cantidad de datos en Kubernetes.

¿Qué problemas le surgieron primero en torno a 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 un extremo a otro para familiarizarme con el código y el proceso general. Fue tan fácil en ese momento. Recuerdo que avanzaba tan rápido que era muy difícil mantener actualizadas mis solicitudes de extracción.

Los primeros problemas reales que necesitábamos resolver eran cómo ejecutar una aplicación con estado, que fue resuelto por PetSets/StatefulSets, y cómo consumir datos de sistemas de almacenamiento fuera de Kubernetes. Primero comenzamos con código en árbol para almacenamiento 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, rápidamente nos dimos cuenta 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 de mejora, ya que todos han sobrevivido durante años con sólo correcciones de errores menores.

Más contenido para leer:  Estudio de caso: Network Rail sobre las decisiones basadas en datos que mantienen seguros nuestros ferrocarriles

Además, a medida que más y más proveedores de almacenamiento querían integrar sus back-ends de almacenamiento con Kubernetes, aprendimos que necesitábamos una interfaz de extensión genérica para complementos de volumen. Primero, se nos ocurrió FlexVolumes, que eran muy engorrosos de usar, pero aprendimos y creamos CSI, que es la principal interfaz de almacenamiento de Kubernetes en la actualidad. Ha tenido un éxito inmenso y hay al menos 130 conductores que se han incluido voluntariamente en la lista y quién sabe cuántos más de los que no sabemos.

Y, a medida que Kubernetes fue adoptado y comenzó a ejecutar infraestructura crítica, necesitábamos asegurarnos de no romperlo. Ahora es mucho más difícil introducir una nueva función o cambiar una existente, ya que se necesitan innumerables revisiones y aprobaciones para garantizar la estabilidad de nuestras versiones.

¿Cómo se involucró con los operadores de Kubernetes?

Safranek: Red Hat fue uno de los primeros en adoptar operadores. Los inicios fueron bastante animados. Personalmente comencé con algunos malos, pero rápidamente aprendí a escribir buenos operadores. Todo viene con la práctica, como todo en el desarrollo de software. Además, hoy en día hay más documentación que nunca.

¿Qué pasó con los Operadores que los convirtió en un éxito para los datos y el almacenamiento?

Safranek: Tengo experiencias mixtas aquí. Muchos operadores no son mejores que las cartas de Helm [which describe a related set of Kubernetes resources]. Los buenos, sin embargo, ayudaron a las empresas a aliviar sus problemas con aplicaciones que necesitan datos persistentes. Todavía es difícil ejecutar correctamente una aplicación con estado, con todos los casos de esquina cubiertos.

¿Cómo respaldó esto enfoques más nativos de la nube? ¿Cuáles fueron las consecuencias?

Safranek: Como mencioné, es más fácil para los desarrolladores confiar en un operador externo para ejecutar su base de datos u otra carga de trabajo con estado mientras se concentran en juntar estas piezas en una excelente aplicación que administre su negocio.

Más contenido para leer:  Ley de facultades de investigación: el Ministerio del Interior propone repensar las salvaguardas en la recopilación masiva de datos

Kubernetes ahora tiene 10 años. ¿Cómo lo piensas hoy?

Safranek: Bueno, ha sido un viaje. Desde el principio, cuando cualquiera podía reescribir cualquier cosa en un software estable que mantuviera este mundo en funcionamiento o al menos algunas partes muy importantes del mismo, hasta que se convirtió en una aburrida pieza de infraestructura.

¿Qué problemas existen todavía en torno a Kubernetes en lo que respecta a datos y almacenamiento?

Safranek: Todos los contenedores son de naturaleza efímera y pueden tener una vida corta. Kubernetes puede intentar ejecutarlos durante mucho tiempo, pero cuando necesite eliminarlos, lo hará. Kubernetes ofrece algunas API, como PodDisruptionBudget, para mantener en funcionamiento la cantidad absolutamente necesaria de contenedores, pero todas las aplicaciones con estado deben contar con alguna 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 gente muy inteligente, he aprendido mucho y todavía estoy aprendiendo.

Nuestro objetivo fué el mismo desde 2004, unir personas y ayudarlas en sus acciones online, siempre gratis, eficiente y sobre todo fácil!

¿Donde estamos?

Mendoza, Argentina

Nuestras Redes Sociales