¡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.
Es una década que comenzó con los contenedores surgiendo como una forma novedosa de virtualizar aplicaciones pero el almacenamiento y la protección de datos eran prácticamente inexistentes. Ahora, Kubernetes ofrece una plataforma de contenedores madura para aplicaciones nativas de la nube con toda la funcionalidad necesaria para el almacenamiento de datos con estado.
Celebramos la primera década de Kubernetes con una serie de entrevistas con ingenieros que han ayudado a desarrollar Kubernetes y a 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í, Saad Ali, ingeniero de software senior de Google, que diseñó Kubernetes, habla sobre los desafíos iniciales del almacenamiento y la protección de datos, su participación en los controladores de la interfaz de almacenamiento de contenedores (CSI), la resolución del enigma del almacenamiento con estado para un entorno elástico y portátil, y cómo los operadores de Kubernetes supusieron un gran paso adelante para romper ese estancamiento.
¿Cómo era el mercado cuando se lanzó Kubernetes por primera vez?
Saad Ali: Cuando Kubernetes se lanzó por primera vez, los desarrolladores y proveedores estaban muy interesados en los contenedores, pero no tenían idea de por dónde empezar. Docker había dinamizado la industria y facilitado el desarrollo, y había mucho interés en descubrir cómo hacerlo útil para implementaciones a escala.
Muchos proveedores de almacenamiento estaban esperando al margen tratando de decidir dónde invertir. Algunos se lanzaron temprano y escribieron los complementos de volumen originales en el árbol para Kubernetes, lo cual fue un proceso desalentador que requirió verificar el código directamente en el repositorio principal de Kubernetes. Con toda la incertidumbre, la mayoría de los proveedores de almacenamiento adoptaron el enfoque de esperar y ver qué pasa. Si nunca superáramos esa vacilación, Kubernetes no sería lo que es hoy.
¿Cómo te involucraste en el almacenamiento de Kubernetes?
Ali: Me involucré con el lado del almacenamiento de Kubernetes solucionando una serie de problemas relacionados con el almacenamiento. Finalmente, se me asignó la tarea de arreglar las condiciones de carrera que habían existido desde la versión 1.0 en la pila de almacenamiento. Terminé implementando una gran remodelación de la pila del ciclo de vida del volumen en Kubernetes 1.3, incluida la extracción de la lógica de conexión/desconexión del kubelet y su traslado a un controlador central para reducir las condiciones de carrera. Eso, junto con muchas correcciones adicionales de muchos desarrolladores en múltiples versiones posteriores, ayudó a mejorar la estabilidad del subsistema de volumen general.
Me convertí en Kubernetes SIG [Special Interest Group] Codirector de almacenamiento, y una de mis principales áreas de atención en los años siguientes fue descubrir cómo hacer que el almacenamiento de Kubernetes sea más extensible. Ayudé a iniciar y desarrollar la interfaz de almacenamiento de contenedores.
¿Cuándo se dio cuenta de que Kubernetes ocupaba la posición de liderazgo en el mercado?
Ali: Para Kubernetes en general, recuerdo haber escuchado eso Pokémon Ir se estaba ejecutando sobre Kubernetes. Fue un momento increíble y me di cuenta de que Kubernetes estaba despegando.
CSI hizo que los proveedores de almacenamiento se sintieran lo suficientemente cómodos como para invertir en la creación de complementos y generó un círculo virtuoso: más proveedores desarrollaron para Kubernetes hicieron que Kubernetes fuera más útil, aumentaron la adopción de Kubernetes y llevaron a que más proveedores desarrollaran para él.
Saad Ali, Google
Para el almacenamiento de Kubernetes, cuando comenzamos a desarrollar CSI, fui a una reunión en San Francisco para hablar sobre ello y uno de los miembros de la audiencia preguntó: “¿Qué hace que este esfuerzo sea diferente de tantos esfuerzos anteriores para estandarizar el almacenamiento que la comunidad OpenStack ha intentado?”. ? ¿Qué te hace pensar que esta vez será diferente?
Eso fue un recordatorio de que el éxito no estaba garantizado, por lo que hicimos un esfuerzo activo con CSI para trabajar estrechamente con la comunidad de almacenamiento y múltiples orquestadores de contenedores, construir de manera muy metódica e iterar continuamente en CSI, y no llamarlo 1.0 hasta que tuviéramos varios controladores en funcionamiento. /integraciones.
Esto hizo que los proveedores de almacenamiento se sintieran lo suficientemente cómodos como para invertir en la creación de complementos y generó un círculo virtuoso: más proveedores desarrollando para Kubernetes hicieron que Kubernetes fuera más útil, aumentaron la adopción de Kubernetes y llevaron a que más proveedores desarrollaran para él. Fue cuando la lista de conductores de CSI superó los 100 conductores que me di cuenta de que habíamos logrado algo especial.
Cuando analizó Kubernetes, ¿cómo abordó los datos y el almacenamiento?
Ali: Más allá de la extensibilidad de la plataforma Kubernetes (con integraciones como CSI), en mi opinión, la magia del almacenamiento de Kubernetes es que desacopla el almacenamiento de bloques/archivos de la computación – “separación de preocupaciones” – y hace que las cargas de trabajo con estado sean tan elásticas como las que no tienen estado. cargas de trabajo. Cuando las cargas de trabajo con estado ya no tuvieron que anclarse al nodo en el que estaban aprovisionadas, se volvió más fácil autocurarse sin intervención humana.
Incluso Kubernetes 1.0 incluía un sistema básico de “complemento de volumen en el árbol” que permitía a Kubernetes adjuntar/formatear/montar automáticamente volúmenes de almacenamiento de archivos/bloques arbitrarios en pods y desmontarlos/separarlos a medida que los pods se movían entre los nodos. Esto fue fundamental para permitir la elasticidad de la programación para cargas de trabajo con estado. Incluso cuando algo salió mal con un nodo informático, sus datos podrían estar disponibles automáticamente en otro nodo sin intervención humana.
¿Qué problemas le surgieron primero en torno a los datos y el almacenamiento con Kubernetes?
Ali: La subpila de almacenamiento de Kubernetes es increíblemente complicada. Al principio nos ocupamos de muchas condiciones de carrera. Uno de los mayores desafíos con la pila de almacenamiento es que tiene que manejar el peor de los casos entre la recuperación automática y la posible pérdida y corrupción de datos. Ninguno de los resultados es aceptable, por lo que Kubernetes SIG Storage ha trabajado increíblemente duro para identificar y garantizar una recuperación elegante de estos casos extremos.
La magia del almacenamiento de Kubernetes es que desacopla el almacenamiento de bloques/archivos de la computación y hace que las cargas de trabajo con estado sean tan elásticas como las cargas de trabajo sin estado.
Saad Ali, Google
¿Qué tuvo que cambiar?
Ali: Originalmente, la pila de almacenamiento de Kubernetes suponía que un administrador de almacenamiento aprovisionaría previamente un grupo de volúmenes de bloques/archivos de diferentes tamaños para que los utilizaran los operadores de aplicaciones. Esto llevó a un uso ineficiente de la capacidad de almacenamiento disponible.
SIG Storage introdujo el concepto de aprovisionamiento dinámico en Kubernetes 1.6. Esto cambió las reglas del juego para la usabilidad del almacenamiento de bloques/archivos a escala y completó la automatización del ciclo de vida del volumen de almacenamiento porque aprovisionó almacenamiento bajo demanda según lo necesitaban las cargas de trabajo, eliminó la intervención humana y permitió el uso eficiente de la capacidad de almacenamiento.
¿Qué sucedió con los operadores de Kubernetes que los convirtió en un éxito para los datos y el almacenamiento?
Ali: A medida que los componentes básicos encajaron (interfaces StorageClass, PersistentVolumeClaim (PVC) y PersistentVolume (PV), CSI, aprovisionamiento dinámico), la orquestación de primitivas con estado de nivel superior se convirtió en un foco de atención.
Kubernetes ofreció StatefulSets como componente básico para cargas de trabajo con estado. Pero se hizo evidente que muchas aplicaciones complejas con estado requerían una orquestación más cuidadosa de sus datos para permitir cosas como la replicación, el escalado, etc.
Aquí es donde entraron los operadores de Kubernetes. Ofrecieron una manera fácil de extender Kubernetes para permitir operaciones con reconocimiento de aplicaciones, como fragmentación de datos para garantizar una alta disponibilidad, evitar que todas las réplicas dejen de estar disponibles a la vez, etc.
¿Cómo respaldó esto enfoques más nativos de la nube? ¿Cuáles fueron las consecuencias?
Ali: La pila de almacenamiento de Kubernetes junto con los operadores de Kubernetes permiten un uso verdaderamente elástico de los recursos informáticos disponibles. Esto, en mi opinión, es el corazón de lo que significa estar construido en la nube: tener un gran conjunto elástico de recursos informáticos que pueden ser utilizados por todas sus cargas de trabajo, bajo demanda, escalables sin intervención humana para maximizar. disponibilidad y reducir costos.
A sus 10 años, Kubernetes empieza a parecer Linux para la informática distribuida. Es una herramienta de código abierto potente y extensible que ha sido ampliamente adoptada y un componente clave para la infraestructura informática distribuida moderna.
Saad Ali, Google
Kubernetes ahora tiene 10 años. ¿Cómo lo piensas hoy?
A sus 10 años, Kubernetes empieza a parecer Linux para la informática distribuida. Es una herramienta de código abierto potente y extensible que ha sido ampliamente adoptada y un componente clave para la infraestructura informática distribuida moderna.
¿Qué problemas existen todavía en torno a Kubernetes en lo que respecta a datos y almacenamiento?
Ali: Kubernetes ha facilitado mucho el desarrollo de aplicaciones con estado portátiles y escalables que aprovechan el almacenamiento de archivos y bloques. Pero el almacenamiento sigue siendo difícil para muchos desarrolladores que no quieren preocuparse por cómo funcionan las diferentes bases de datos, las diferencias entre replicación asíncrona y síncrona, el equilibrio entre varios perfiles de redundancia de almacenamiento, etc.
Puede que no sea un problema que Kubernetes deba resolver, pero, como industria, tenemos que facilitar la creación de aplicaciones con estado para todo tipo de desarrolladores con diferentes requisitos de escala, redundancia y rendimiento, manteniendo al mismo tiempo la portabilidad independiente del proveedor.
¿Alguna otra anécdota o información para compartir?
Ali: Los proyectos de código abierto como Kubernetes son posibles gracias a muchos contribuyentes increíbles de todo el mundo. Necesitan mantenimiento y mejora continuos. Animo a cualquier persona interesada a unirse a nosotros. Si está interesado en el almacenamiento, únase a Kubernetes SIG Storage. Si está interesado en los datos, únase a la comunidad de Datos en Kubernetes. Participe y ayúdenos a impulsar la próxima generación de mejoras.
