En este podcast, analizamos las características de almacenamiento que se esperan en Kubernetes 1.31 con Sergey Pronin, gerente de productos del grupo en Percona, que desarrolla productos de código abierto para bases de datos SQL y NoSQL. Pronin habla sobre la funcionalidad de almacenamiento que se espera en la versión 1.31 de esta semana, pero también sobre lo que ve como algunas de las brechas en términos de almacenamiento para bases de datos y, de manera más general, para el almacenamiento en Kubernetes. También analiza las brechas de cumplimiento y seguridad que cree que aún deben abordarse en Kubernetes. ¿Cómo resumiría las próximas incorporaciones a Kubernetes que son de interés para las personas que trabajan con almacenamiento de datos? Sergey Pronin: No creo que haya muchas mejoras relacionadas con el almacenamiento porque la versión 1.31 se centró principalmente en una importante eliminación de código heredado. Son como 1,5 millones de líneas de código eliminadas de la base de código central, pero esta base de código se creó principalmente para interfaces de almacenamiento de contenedores (CSI) heredadas creadas por varios proveedores de la nube, y luego se trasladaron a la estructura de complementos. Ese fue el enfoque principal de esta versión. Hay algunas mejoras de almacenamiento. Creo que la más grande y la más interesante para mí es la clase de atributos de volumen. Permite a los usuarios modificar volúmenes existentes sobre la marcha, como si desea cambiar la cantidad de IOPS del volumen; ya sabe que en Amazon tiene volúmenes EBS y tienen IOPS. Anteriormente, para hacerlo en Kubernetes, crearía una nueva clase de almacenamiento y luego migraría su aplicación a este nuevo volumen de almacenamiento. Era todo un proceso. Por ahora, a través de Kubernetes, puede simplemente cambiar las IOPS para este volumen específico y eso es todo, pero esta característica estaba en alfa, y ahora en 1.31 pasa a beta, por lo que se está acercando a la versión GA o estable. Esa es una característica de almacenamiento importante que está cambiando. ¿Hay otras en 1.31? Hay algunas adiciones al estado del volumen persistente. En 1.31, se agregó un nuevo estado de «tiempo de transición de la última fase del estado» a los volúmenes persistentes. Esto le permite medir el tiempo entre varios estados del volumen persistente. Puede estar en estado pendiente, puede estar en estado entrante, puede estar en estado de error, etc. Y ahora, como se agrega este último estado de tiempo de transición de fase, varios administradores de clústeres pueden aprovecharlo para medir varios objetivos de nivel de servicio, etc., de manera mucho más fácil. Nuevamente, no es una gran mejora, pero definitivamente es algo que la comunidad estuvo esperando durante bastante tiempo. Especialmente los administradores de clústeres, porque los volúmenes persistentes están madurando en el entorno de Kubernetes y algo que esperaría desde el día cero no está allí. Y ahora se agregó, por lo que es algo bueno. ¿Hay otras adiciones que agruparía con estas? Tengo algunas, pero no son realmente importantes y no están en GA, por lo que no creo que valga la pena mencionarlas. ¿Cuáles cree que son los desafíos restantes en Kubernetes para las personas que desean administrar el almacenamiento? Creo que uno de los problemas que veo radica en el ámbito del escalado y el almacenamiento automatizados. Históricamente, Kubernetes fue diseñado como una herramienta para quitarle trabajo a los administradores, y para varios recursos computacionales como CPU o RAM, es bastante fácil implementar un escalado automático para ellos. Si ves que alcanzas un cierto umbral, puedes agregar más nodos a la imagen o puedes realizar un escalado vertical agregando más recursos de CPU o RAM al contenedor. Pero, para el almacenamiento, realmente no es el caso. Mientras que, si observas a la mayoría de los proveedores de la nube, me refiero a los proveedores de nube pública como Amazon RDS o Aurora [databases]Por ejemplo, han automatizado el escalado del almacenamiento desde el día cero, y me sorprende muchísimo que no haya nada parecido en Kubernetes hasta ahora. Hay algunas soluciones ad hoc desarrolladas por empresas, pero son muy limitadas o ya no se mantienen. Es más bien algo como: «Oye, creé una prueba de concepto. ¡Ahora, comunidad, averígüenlo!». Y para mí, como desarrollador de varias [Kubernetes] Operadores para bases de datos, definitivamente quiero brindar el mismo nivel de experiencia de usuario a mis usuarios en Kubernetes, porque a veces piensan, «Está bien, si paso de esta linda Aurora de Amazon a Operators, ¿cuáles son las compensaciones que voy a hacer?» Este es uno de ellos. ¿Hay algún desarrollo en Kubernetes que se dirija hacia esto, o simplemente no hay nada? Siempre hay algunas actividades en varios campos en Kubernetes, pero lamentablemente, solo hay discusiones por ahora. No he visto ni una sola línea de código creada para eso. Además, no estoy 100% seguro de que deba ser impulsado por la comunidad de Kubernetes, o puede ser algo en el ecosistema CNCF, como el proyecto Keda, por ejemplo. Keda es el escalado automático impulsado por eventos de Kubernetes. CNCF lo incubó a partir de una incubadora nativa de la nube, y hacen un escalado computacional con bastante éxito. Entonces, pensaría, ¿por qué no agregar almacenamiento? Lo discutimos con ellos hace algún tiempo, pero aún no se ha avanzado. ¿Crees que hay otras áreas importantes que aún no se han resuelto en Kubernetes con respecto al almacenamiento? Creo que la estandarización general de cómo interactúan los distintos operadores con el almacenamiento definitivamente ayudaría. Pero, de nuevo, no creo que sea algo que la comunidad de Kubernetes deba resolver. Debería ser una comunidad más amplia, que involucre a varios SIG, porque, de nuevo, si miro cómo interactúan los distintos operadores de Kubernetes o cómo interactúan los distintos proyectos de Kubernetes con el almacenamiento, algunos de ellos usan conjuntos con estado, la mayoría de ellos, algunos de ellos crean implementaciones y montan PVC. Entonces, desde un punto de vista técnico, es muy diferente, y la razón de eso es una tecnología subyacente que potencia esta aplicación, como puede ser alguna base de datos MySQL o alguna base de datos MongoDB, y para aquellos que quizás quieran jugar con el almacenamiento de una manera un poco diferente. Pero el resultado final que debería obtener es solo estabilidad. Su almacenamiento debe estar disponible en todo momento, sus datos deben ser consistentes y debe poder inspirar confianza a los usuarios de que si ejecuta algo relacionado con el almacenamiento en Kubernetes, simplemente funcionará. No es una magia vudú. Habiendo estado en este campo durante bastante tiempo, todavía siento que no hemos llegado a este punto en el que las empresas se sientan seguras y digan: «Oh, sí, ejecutar bases de datos en Kubernetes es para nosotros. Creemos que es el camino a seguir». Todavía hay muchas preguntas [like] ¿Qué tan estable es, qué tan robustas son las soluciones y cuáles son las compensaciones que tendrían que hacer? ¿Todavía se considera que el almacenamiento en Kubernetes es bastante complejo? ¿Es eso lo que estás diciendo? Sí, bueno, yo diría que hace unos tres o cuatro años, ejecutar bases de datos en Kubernetes era algo totalmente nuevo. Mientras que alguna gran empresa sería lo suficientemente valiente como para ejecutar bases de datos en K8s [Kubernetes]Ahora vemos que el almacenamiento general en Kubernetes, los operadores y otras herramientas en este ecosistema CNCF están madurando para admitir el almacenamiento en Kubernetes. Pero eso da como resultado el hecho de que una vez que las empresas comienzan a analizar los datos en Kubernetes, quieren aplicar el proceso de pensamiento existente. [about] Así que, hoy en día, ejecutan algo en máquinas virtuales y tienen integración LDAP, varios niveles de cifrado, estándares, etc., y están tratando de proyectarlos a bases de datos en Kubernetes, que aún no están ahí. Todavía faltan algunas funciones que las empresas pensarían: «Oh, eso debería estar ahí desde el día cero. ¿Por qué no está ahí?». Pero poco a poco lo estamos logrando. Nos estamos poniendo al día y creo que cubrimos los aspectos de estabilidad y rendimiento, así que, en este momento, no vería ningún problema para nadie con los SLA o con el tiempo de actividad si ejecutan sus bases de datos en K8. Pero en cuanto a seguridad y cumplimiento, definitivamente hay algunas brechas, o tal vez incluso algunas características complicadas. Describí esta cuestión del escalado externo. [It’s] Todavía no está ahí [and] Alguien esperaría que estuviera disponible de inmediato. Así que, sí, creo que estamos mejorando año tras año, pero todavía queda mucho trabajo por hacer. ¿Cuáles considera que son las brechas en términos de cumplimiento y seguridad? Cifrado de datos en reposo para bases de datos. Para algunos, vería que está disponible. Para otros, como PostgreSQL, todavía es más como un deseo. No está disponible en la versión comunitaria de PostgreSQL. [It’s] Solo en algunas versiones empresariales como EnterpriseDB, por ejemplo. Lo tienen. Lo bifurcaron, etc. Es similar con las copias de seguridad: cómo se aborda la continuidad empresarial en general. ¿Se cifran las copias de seguridad, cómo se almacenan, etc.? La mayoría de los operadores ya han resuelto eso, pero, por ejemplo, cosas como la recuperación ante desastres, donde se desea ejecutar la base de datos en diferentes centros de datos y tener una conmutación por error automatizada dentro de los acuerdos de nivel de servicio, bueno, todavía no está ahí.