¡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. Xing Yang, líder de tecnología de almacenamiento nativo de la nube en VMware by Broadcom, comenzó a trabajar en el 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, siguió adelante para ver cómo la plataforma de orquestación de contenedores Kubernetes alcanzaba el liderazgo del mercado y trabajaba en la interfaz de almacenamiento de contenedores (CSI) y los operadores de Kubernetes, que se basan en CRD y que aportan funcionalidad de almacenamiento y protección de datos al tiempo que conservan las características principales de Kubernetes. 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? Xing Yang: Cuando Kubernetes se lanzó por primera vez, el mercado de orquestación de contenedores todavía estaba emergiendo. Docker también acababa de presentarse y se convirtió 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 hace que Kubernetes sea una opción popular que ha evolucionado hasta convertirse en el sistema de orquestación de contenedores de facto de la actualidad. ¿Cómo se involucró 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 de VolumeSnapshot en la base de 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 ser verdaderamente modular, extensible y mantenible con un núcleo mínimo. Entonces, implementamos la función VolumeSnapshot fuera del árbol bajo Kubernetes CSI. Se convirtió en la primera función central de SIG Storage implementada como CRD. Contamos nuestra historia durante una presentación destacada en KubeCon China en 2019: CRD, ¡ya no son algo de segunda clase! Trabajamos con otros miembros de la comunidad para trasladar la función VolumeSnapshot de Alpha a Beta y, finalmente, la pusimos a disposición del público en general en la versión 1.20 de Kubernetes. Me convertí en mantenedor de Kubernetes SIG Storage. ¿Cómo se dio cuenta de que Kubernetes estaba en la posición líder en el mercado? Yang: Kubernetes fue presentado inicialmente por Google en junio de 2014 y luego donado a Linux Foundation y se convirtió en el proyecto inicial de la Cloud Native Computing Foundation (CNCF). Otros proveedores de nube pública líderes, AWS y Azure, comenzaron a ofrecer distribuciones de Kubernetes en sus nubes en 2017 y las pusieron a disposición del público en 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 la 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 de contenedores se consideraban efímeras y sin estado y, por lo tanto, no necesitaban conservar los datos. Pero eso cambió drásticamente. Las cargas de trabajo con estado comenzaron a ejecutarse en Kubernetes. Se introdujeron las reclamaciones de volumen persistente, los volúmenes persistentes y las clases de almacenamiento para aprovisionar volúmenes de datos para las aplicaciones que se ejecutaban en Kubernetes. También se introdujo la API de carga de trabajo StatefulSet para ejecutar cargas de trabajo con estado en Kubernetes. Hoy en día, cada vez se ejecutan más cargas de trabajo con estado en Kubernetes. ¿Qué problemas surgieron primero en relación con los datos y el almacenamiento con Kubernetes para usted? Yang: Cuando comencé a involucrarme con Kubernetes, CSI acababa de presentarse. Intentaba diseñar interfaces comunes para que un proveedor de almacenamiento pudiera escribir un complemento y hacer que funcionara 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 de CSI era muy básico e incluía crear, eliminar, adjuntar, separar, montar y desmontar volúmenes. Sin embargo, para admitir 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 se tomaran instantáneas de los volúmenes persistentes y se usaran 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 de 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 falla para brindar alta disponibilidad y tolerancia a fallas. La expansión de volumen de CSI es otra característica importante para las 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 de CSI que permite que el programador de Kubernetes tenga en cuenta la capacidad durante la programación. También existen lagunas en el soporte para la protección de datos en Kubernetes. Hay algunos bloques de construcción básicos, como instantáneas de volumen, que se pueden usar 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 que tenía como objetivo promover el soporte de protección de datos en Kubernetes. ¿Cómo se involucró en Kubernetes Operators? 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 de datos de Kubernetes en un informe técnico sobre la ejecución de bases de datos en Kubernetes. Como se analiza en el informe técnico, los operadores son uno de los patrones más importantes que se utilizan al ejecutar datos en Kubernetes. ¿Qué sucedió 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 bases 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 la copia de seguridad y la restauración, la migración, la actualización, etc. Facilitan la portabilidad de aplicaciones a través de nubes o la compatibilidad con nubes híbridas. Además, CNCF tiene un ecosistema rico 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 usar 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 más enfoques 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 memoria o de CPU insuficiente, o reiniciarse porque un nodo de Kubernetes deja de funcionar. El almacenamiento efímero está estrechamente vinculado al ciclo de vida de un pod, por lo que desaparece con el pod si usa almacenamiento local. Si usa almacenamiento externo, existe un problema diferente, que es la latencia agregada. Los operadores pueden ayudar a mitigar estos problemas al brindar alta disponibilidad, permitir que las aplicaciones se ejecuten de manera distribuida, automatizar la implementación, brindar monitoreo, administrar el ciclo de vida de las bases de datos y permitir que las bases de datos se ejecuten correctamente en un entorno de Kubernetes. Kubernetes ya tiene 10 años. ¿Cómo lo ve hoy? Yang: Han sucedido muchas cosas en los 10 años desde el nacimiento de Kubernetes. Se han incorporado muchas características a 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 extender los casos de uso de Kubernetes. Es la clave que permite que las bases de datos se ejecuten en Kubernetes. ¿Qué problemas aún existen en torno a Kubernetes en lo que respecta a los datos y el 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 ponerse en marcha, requiere mucho esfuerzo administrar las 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 varios clústeres sigue siendo un desafío porque Kubernetes se diseñó inicialmente para funcionar en un solo clúster. ¿Tiene 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á.