¡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.
Xing Yang, líder de tecnología de almacenamiento nativo de la nube en VMware by Broadcom, comenzó a trabajar en almacenamiento en Kubernetes en 2017 en proyectos basados en definiciones de recursos personalizados (CRD), que permiten que la plataforma de orquestación funcione en torno a un núcleo extensible.
Más tarde, vio cómo la plataforma de orquestación de contenedores Kubernetes alcanzó el liderazgo del mercado y trabajó en la interfaz de almacenamiento de contenedores (CSI) y los operadores de Kubernetes, que se basan en CRD y que brindan funcionalidad de almacenamiento y protección de datos al tiempo que conservan las características principales de Kubernetes.
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?
Xing Yang: Cuando Kubernetes se lanzó por primera vez, el mercado de orquestación de contenedores aún estaba emergente. Docker también acababa de presentarse y se había convertido en una herramienta popular para crear imágenes. Kubernetes es un sistema de orquestación de contenedores que facilita la implementación de imágenes de Docker en sistemas distribuidos. Esto convierte a Kubernetes en una opción popular que ha evolucionado hasta convertirse en el sistema de orquestación de contenedores de facto de la actualidad.
¿Cómo te involucraste en esta área?
yang: Comencé contribuyendo al proyecto VolumeSnapshot en Kubernetes SIG Storage en 2017, trabajando en estrecha colaboración con Jing Xu de Google. Inicialmente intentamos introducir la API y el controlador VolumeSnapshot en la base del código central de Kubernetes, pero SIG Architecture lo rechazó.
Nos pidieron que usáramos CRD en su lugar. La razón es que Kubernetes debería hacerse verdaderamente modular, extensible y mantenible con un núcleo mínimo. Entonces, implementamos la función VolumeSnapshot fuera del árbol en Kubernetes CSI. Se convirtió en la primera característica principal de SIG Storage implementada como CRD. Contamos nuestra historia durante una presentación principal en KubeCon China en 2019: ¡Los CRD ya no son algo de segunda clase!
Trabajamos con otros miembros de la comunidad para mover la función VolumeSnapshot de Alpha a Beta y finalmente la hicimos disponible de forma general en la versión Kubernetes 1.20. Me convertí en mantenedor de Kubernetes SIG Storage.
¿Cómo se dio cuenta de que Kubernetes ocupaba la posición de liderazgo en el mercado?
yang: Kubernetes fue presentado inicialmente por Google en junio de 2014 y luego donado a la Fundación Linux y se convirtió en el proyecto inicial de la Cloud Native Computing Foundation (CNCF).
Otros proveedores líderes de nube pública, AWS y Azure, comenzaron a ofrecer distribuciones de Kubernetes en sus nubes en 2017 y las hicieron disponibles de forma general en 2018. Cuando los principales proveedores de nube tenían distribuciones de Kubernetes en su nube, me di cuenta de que Kubernetes estaba ganando impulso en la nube y había logrado adopción empresarial.
Cuando analizó Kubernetes, ¿cómo abordó los datos y el almacenamiento?
yang: Cuando Kubernetes se introdujo por primera vez, estaba destinado únicamente a cargas de trabajo sin estado. En ese momento, las aplicaciones contenedoras se consideraban efímeras y sin estado y, por lo tanto, no necesitaban conservar datos.
Pero eso cambió drásticamente. Las cargas de trabajo con estado comenzaron a ejecutarse en Kubernetes. Se introdujeron reclamaciones de volúmenes persistentes, volúmenes persistentes y clases de almacenamiento para aprovisionar volúmenes de datos para aplicaciones que se ejecutan en Kubernetes. La API de carga de trabajo StatefulSet también se introdujo para ejecutar cargas de trabajo con estado en Kubernetes. En la actualidad, en Kubernetes se ejecutan cada vez más cargas de trabajo con estado.
¿Qué problemas le surgieron primero en torno a los datos y el almacenamiento con Kubernetes?
yang: Cuando comencé a involucrarme en Kubernetes, acababan de presentar CSI. Intentó diseñar interfaces comunes para que un proveedor de almacenamiento pudiera escribir un complemento y hacerlo funcionar en una variedad de sistemas de orquestación, que incluían Docker, Mesos, Kubernetes y Cloud Foundry en ese momento.
El conjunto inicial de interfaces CSI era muy básico e incluía crear, eliminar, adjuntar, desconectar, montar y desmontar volúmenes. Sin embargo, para soportar cargas de trabajo con estado se necesitaban funcionalidades más avanzadas. Por ejemplo, la instantánea de volumen, la clonación, la expansión de volumen y la topología no eran compatibles con CSI al principio.
¿Qué tuvo que cambiar?
yang: Se necesitaban funcionalidades más avanzadas para que CSI admitiera cargas de trabajo con estado que se ejecutan en Kubernetes de manera más efectiva.
La instantánea de volumen se introdujo en CSI para permitir que los volúmenes persistentes se tomen instantáneas y se utilicen como una forma de restaurar datos si se produce una pérdida o corrupción de datos. También se agregó la clonación de volumen a CSI que se puede usar para copiar los datos almacenados en un volumen persistente para crear un nuevo volumen a partir de él.
La topología CSI también es una característica muy importante para las cargas de trabajo de bases de datos distribuidas. Permite a Kubernetes realizar una programación inteligente para que el volumen se aprovisione dinámicamente en el mejor lugar para ejecutar el pod. Por lo tanto, puede implementar y escalar las cargas de trabajo en dominios de fallas para proporcionar alta disponibilidad y tolerancia a fallas.
La expansión del volumen CSI es otra característica importante para cargas de trabajo con estado. Le permite expandir el volumen a un tamaño mayor si su aplicación necesita más espacio para escribir datos.
También existe la función de seguimiento de capacidad CSI que permite al programador de Kubernetes tener en cuenta la capacidad durante la programación.
También existen lagunas en el soporte de la protección de datos en Kubernetes. Existen algunos componentes básicos, como instantáneas de volumen, que se pueden utilizar para realizar copias de seguridad y restaurar, pero se necesita más para proteger las cargas de trabajo con estado en caso de un desastre. Formamos un Grupo de Trabajo de Protección de Datos a principios de 2020 cuyo objetivo era promover el soporte de protección de datos en Kubernetes.
¿Cómo se involucró con los operadores de Kubernetes?
yang: A medida que se han puesto a disposición funciones de almacenamiento más avanzadas, Kubernetes se ha convertido en una plataforma más madura para proporcionar almacenamiento para cargas de trabajo con estado, siendo las bases de datos uno de los tipos de cargas de trabajo más importantes.
Como copresidente de CNCF TAG Storage, tuve la oportunidad de colaborar con la comunidad Data on Kubernetes en un documento técnico sobre la ejecución de bases de datos en Kubernetes. Como se analiza en el documento técnico, los operadores son uno de los patrones más importantes que se utilizan al ejecutar datos en Kubernetes.
¿Qué pasó con los operadores que los convirtió en un éxito para los datos y el almacenamiento?
yang: Los operadores aprovechan los CRD que son flexibles y extensibles. Muchas bases de datos tradicionales no se diseñaron originalmente para Kubernetes, pero con los operadores se puede encapsular una lógica empresarial compleja debajo de estos CRD. Para los usuarios, es fácil solicitar un clúster de base de datos definiendo un recurso personalizado (CR). La lógica de control del operador se basa en la naturaleza declarativa de Kubernetes y concilia el estado real de la base de datos con el estado deseado definido en el CR, e intenta continuamente cerrar la brecha y mantener la base de datos en funcionamiento.
Los operadores ayudan a automatizar las operaciones del segundo día, como copia de seguridad y restauración, migración, actualización, etc. Facilitan la transferencia de aplicaciones a través de nubes o admiten nubes híbridas. Además, CNCF tiene un rico ecosistema con muchas herramientas disponibles. Por ejemplo, Prometheus para monitoreo, Cert Manager para autenticación, Fluentd para procesamiento de registros, Argo CD para entrega continua declarativa y muchos más. Los operadores pueden utilizar estas herramientas de terceros para mejorar las capacidades de los clústeres de bases de datos que se ejecutan en Kubernetes.
¿Cómo respaldó esto enfoques más nativos de la nube? ¿Cuáles fueron las consecuencias?
yang: En un entorno nativo de la nube, un pod de Kubernetes que se ejecuta como parte de una aplicación de base de datos puede cerrarse debido a un error de falta de CPU o de memoria o reiniciarse porque un nodo de Kubernetes deja de funcionar. El almacenamiento efímero está estrechamente relacionado con el ciclo de vida de un pod, por lo que desaparece con el pod si usa almacenamiento local. Si utiliza almacenamiento externo, existe un problema diferente: la latencia adicional.
Los operadores pueden ayudar a mitigar estos problemas proporcionando alta disponibilidad, permitiendo que las aplicaciones se ejecuten de forma distribuida, automatizando la implementación, proporcionando monitoreo, administrando el ciclo de vida de las bases de datos y permitiendo que las bases de datos se ejecuten correctamente en un entorno de Kubernetes.
Kubernetes ahora tiene 10 años. ¿Cómo lo piensas hoy?
yang: Han pasado muchas cosas en los 10 años transcurridos desde el nacimiento de Kubernetes. Se han integrado muchas funciones en Kubernetes para admitir cargas de trabajo de datos y Kubernetes está madurando. Kubernetes tiene API declarativas. Es flexible y extensible. Proporciona una forma de abstraer la infraestructura subyacente. Los operadores han sido una carta mágica para ampliar los casos de uso de Kubernetes. Es la clave que permite que las bases de datos se ejecuten en Kubernetes.
¿Qué problemas existen todavía en torno a Kubernetes en lo que respecta a datos y almacenamiento?
yang: Las operaciones del segundo día siguen siendo un desafío cuando se ejecutan datos en Kubernetes, pero esto se puede mitigar mediante el uso de operadores. Kubernetes es demasiado complejo, lleva mucho tiempo implementarlo, requiere mucho esfuerzo administrar cargas de trabajo de datos en Kubernetes y es complicado integrarlo con el entorno existente.
Y para los operadores, la falta de estandarización sigue siendo un problema. Además, ejecutar cargas de trabajo con estado en un entorno de múltiples clústeres sigue siendo un desafío porque Kubernetes se diseñó inicialmente para funcionar en un solo clúster.
¿Alguna otra anécdota o información para compartir?
yang: Kubernetes ha recorrido un largo camino desde su nacimiento hace 10 años. El futuro es brillante para Kubernetes en la próxima década y más allá.