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 esperada en la versión 1.31 de esta semana, pero también sobre lo que él ve como algunas de las brechas en términos de almacenamiento para bases de datos y, en 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 serán de interés para las personas que se ocupan del almacenamiento de datos?
Serguéi Pronin: No creo que haya muchas mejoras relacionadas con el almacenamiento porque la versión 1.31 se centró en gran medida en una eliminación importante del 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 nube, y luego se trasladaron a la estructura de complementos. Ese fue el enfoque principal de este lanzamiento.
Hay algunas mejoras de almacenamiento. Creo que el más importante y el 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 quisieran cambiar la cantidad de IOPS del volumen; usted sabe que en Amazon tiene volúmenes de EBS y ellos tienen IOPS. Anteriormente, para hacerlo en Kubernetes, debía crear una nueva clase de almacenamiento y luego migrar su aplicación a este nuevo volumen de almacenamiento.
Fue todo un proceso. Por ahora, a través de Kubernetes, puedes simplemente cambiar el 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.
Ésa es una característica importante del almacenamiento que está cambiando. ¿Hay otros 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” a los volúmenes persistentes.
Esto le permite medir el tiempo entre varios estados del volumen persistente. Puede estar en estado pendiente, puede estar entrante, puede tener un error, etc. Y ahora, a medida que se agrega el estado del tiempo de transición de la última fase, varios administradores de clúster pueden aprovecharlo para medir varios objetivos de nivel de servicio, etc., de manera mucho más sencilla.
Nuevamente, no es una gran mejora, pero definitivamente es algo que la comunidad estaba esperando desde hace bastante tiempo. Especialmente los administradores de clústeres, porque los volúmenes persistentes están madurando en el entorno de Kubernetes y algo que se esperaría desde el día cero no está ahí. Y ahora se agregó, así que es algo bueno.
¿Hay otras adiciones que agruparías con estas?
Tengo algunos, pero no son realmente importantes y no están en GA, así que no creo que valga la pena mencionarlos.
¿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 se diseñó como una herramienta para aliviar el trabajo de los administradores y, para diversos recursos informáticos, como CPU o RAM, es bastante fácil implementar un escalado automatizado para ellos.
Si ve que alcanza un cierto umbral, puede agregar más nodos a la imagen o puede realizar un escalado vertical agregando más recursos de CPU o RAM al contenedor.
Pero en el caso del almacenamiento, este no es realmente el caso. Mientras que, si nos fijamos en la mayoría de los proveedores de nube, me refiero a proveedores de nube pública como Amazon RDS o Aurora. [databases]por ejemplo: tienen escalado de almacenamiento automatizado desde el día cero, y es muy sorprendente para mí que no haya nada parecido en Kubernetes a partir de ahora.
Hay algunas soluciones ad hoc desarrolladas por empresas, pero son muy limitadas o ya no se mantienen. Es más como: “Oye, creé un POC. ¡Ahora, comunidad, descúbrelo!”
Y para mí como desarrollador de varios [Kubernetes] Operadores de 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 agradable Aurora de Amazon a Operadores, ¿cuáles son las compensaciones que tendré?”. vas a hacer? Este es uno de esos.
¿Hay algún desarrollo en Kubernetes que apunte hacia esto, o simplemente no hay nada?
Siempre hay algunas actividades en varios campos en Kubernetes, pero desafortunadamente, por ahora solo hay discusiones. No he visto ninguna 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 del ecosistema CNCF, como el proyecto Keda, por ejemplo.
Keda es el escalado automático basado en eventos de Kubernetes. La CNCF lo incubó desde una incubadora nativa de la nube y calculan el escalado con bastante éxito. Entonces yo pensaría, ¿por qué no agregar almacenamiento? Lo discutimos con ellos hace algún tiempo, pero aún no avanzamos.
¿Hay otras áreas importantes que cree que aún deben resolverse en Kubernetes con respecto al almacenamiento?
Creo que la estandarización general sobre 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 nuevamente, si observo cómo varios operadores de Kubernetes o cómo varios proyectos de Kubernetes interactúan con el almacenamiento, algunos de ellos usan conjuntos con estado, la mayoría de ellos, algunos crean implementaciones y montan. PVC.
Entonces, desde un punto de vista técnico, es muy diferente, y la razón de esto 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 quieran jugar con el almacenamiento de manera un poco diferente. .
Pero el resultado final que debería obtener es simplemente estabilidad. Su almacenamiento debe estar disponible todo el tiempo, 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 se trata de 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 sólidas son las soluciones y cuáles son las compensaciones que se harían?
¿Se sigue considerando 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 K8 [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 resulta en el hecho de que una vez que las empresas comienzan a buscar datos en Kubernetes, quieren aplicar el proceso de pensamiento existente. [about] cómo deberían verse las bases de datos. Entonces, hoy ejecutan algo en máquinas virtuales y tienen integración LDAP, varios niveles de cifrado, estándares, etc., y están tratando de proyectarlos en bases de datos en Kubernetes, que aún no existen.
Todavía faltan algunas funciones que las empresas creerían: “Oh, eso debería estar ahí el día cero. ¿Por qué no está ahí? Pero poco a poco estamos llegando allí. Nos estamos poniendo al día lentamente y creo que cubrimos los aspectos de estabilidad y rendimiento, por lo que en este momento no veo ningún problema para nadie con SLA o con el tiempo de actividad si ejecutan sus bases de datos en K8.
Pero en materia de seguridad y cumplimiento, definitivamente existen algunas lagunas, o tal vez incluso algunas características complicadas. Describí esta cosa de escala exterior. [It’s] todavía no hay [and] alguien esperaría que estuviera allí de inmediato. Entonces, 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ás que está disponible. Para algunos, como PostgreSQL, es más bien 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, y así sucesivamente.
Lo mismo ocurre con las copias de seguridad: cómo abordar la continuidad del negocio en general. ¿Cifras tus copias de seguridad, cómo se almacenan, etc.?
La mayoría de los operadores ya resolvieron eso, pero, por ejemplo, cosas como la recuperación ante desastres, donde desea ejecutar su base de datos en diferentes centros de datos y tener una conmutación por error automatizada dentro de sus SLA, bueno, todavía no está ahí.