‫Hasta ahora con Kubernetes, no hemos discutido realmente el almacenamiento
‫o los volúmenes.
‫Has lidiado con eso con Docker, y luego
‫con Compose y Swarm y, hasta cierto punto, es lo
‫mismo en Kubernetes.
‫Tiene contenedores, y suponemos que los contenedores no
‫tienen estado, lo que significa que cuando
‫tira el contenedor, todo desaparece.
‫Cuando reemplaza un contenedor con una actualización, o cambia
‫algo y lo aplica con una aplicación kubectl, pierde el contenedor, pierde todo
‫lo que contiene.
‫Obviamente, Kubernetes, al igual que los otros orquestadores,
‫tiene que tener una forma de mantener
‫los datos persistentes. Es incluso más que los volúmenes en sí.
‫Incluso los contenedores y las implementaciones pueden ser diferentes en
‫Kubernetes con algo llamado StatefulSets.
‫Estos son recursos que son diferentes
‫a las implementaciones.
‫Básicamente están diseñados en torno a bases de datos y cosas que requieren mucha
‫más persistencia, incluido el mismo nombre, las mismas
‫IPs y cosas por el estilo.
‫No conseguimos eso fuera de la puerta con Swarm
‫o con Docker necesariamente.
‫Realmente no tenía una manera de mantener esos
‫atributos diferentes entre los contenedores.
‫StatefulSets es una nueva característica en Kubernetes que
‫solo ha estado fuera un poco de tiempo aquí.
‫Es lo que vería si considerara
‫las bases de datos o algo muy sensible a
‫cambios como nombres, direcciones IP, volúmenes y datos
‫persistentes. Una palabra de precaución aquí.
‫La razón por la que no vamos
‫a analizar muchos de los detalles es porque no recomiendo
‫que su primer despliegue de Kubernetes
‫implique muchos StatefulSets. De hecho, idealmente, su primer
‫despliegue de un orquestador, de cualquier orquestador, ya sea
‫Swarm o Kubernetes, solo está relacionado con apátridas y, ya
‫sabes, que sea simple. Tal vez solo haga sus interfaces web
‫o algunas API, o algunas características de los trabajadores, o algo que
‫no involucre bases de datos. De hecho, si puede usar bases de
‫datos en la nube, hágalo.
‫Siempre recomiendo externalizar sus bases de datos a
‫menos que tenga requisitos específicos que simplemente no
‫puede evitar para ejecutarse. La orquestación, inicialmente, se
‫diseñó realmente para que los contenedores fueran inmutables,
‫distribuidos y reemplazables.
‫Esta idea de la firmeza para la capacidad de estado va
‫a agregar más trabajo y complejidad, y
‫muchas más pruebas para usted. Idealmente, fuera de la puerta, no
‫tiene que preocuparse por esto.
‫Más tarde, una vez que esté mucho más cómodo con todas las demás
‫cosas de Kubernetes, puede volver y decir, ahora
‫quiero considerar mis bases de datos.
‫No es que no deba ejecutar bases de datos en clústeres.
‫Es solo más trabajo. Es mas dificil.
‫Las bases de datos y el almacenamiento persistente siempre son más difíciles y
‫con más detalles para trabajar. Ahí está mi consejo profesional.
‫Con cualquier contenedor, puede agregar un volumen muy
‫similar a como lo hizo en Swarm y
‫en Docker and Docker Compose. Simplemente puede agregar una declaración de volumen en
‫la plantilla dentro de la especificación. Si piensa en el archivo
‫YAML, podemos poner un volumen allí como se esperaría,
‫y el formato exacto y los detalles
‫están en los recursos. A diferencia de Docker
‫y Swarm, donde el volumen es con un contenedor,
‫en este caso, técnicamente es con la cápsula. Se conecta a cada contenedor, o solo a un contenedor,
‫en la cápsula si se lo indica.
‫Entonces, lo estás controlando a nivel de contenedor, pero su persistencia está en el
‫nivel de pod. Hay una característica
‫más nueva que son los volúmenes persistentes.
‫Eso funciona con algo más llamado reclamo.
‫La idea interesante con esto es que lo
‫está usando, o lo define, fuera de
‫los pods. Básicamente, estás creando ese recurso
‫por sí mismo, y luego estás haciendo un reclamo contra
‫ese recurso dentro de la especificación de tu pod.
‫La razón por la que esto es más interesante es que cuando
‫Kubernetes se hace cargo de la empresa, a menudo hay
‫personas que se encargan del almacenamiento, a menudo de terceros, que no es el mismo
‫equipo que ejecuta Kubernetes.
‫Ellos serán los involucrados en la administración y creación
‫de estos volúmenes persistentes.
‫Entonces son los implementadores de aplicaciones los que van a
‫decir, oye, necesito
‫un volumen de este tipo. Por lo tanto, voy a hacer un reclamo
‫de SSD o tal vez necesitemos almacenamiento de RAM, o tal vez necesite NFS, o
‫lo que sea. Ese almacenamiento
‫se proporcionará automáticamente porque el equipo de almacenamiento
‫ya lo configuró en Kubernetes.
‫Esa es la idea de los volúmenes persistentes.
‫Si solo necesita un almacenamiento simple en un
‫solo servidor temporalmente para el pod, simplemente use el atributo de
‫volúmenes estándar.
‫Una última cosa aquí es
‫sobre la creación de complementos CSI. En la historia
‫de Kubernetes, cualquier cosa que fuera almacenamiento de terceros,
‫ya sea almacenamiento en la nube o almacenamiento de un proveedor
‫externo, o algo personalizado, cualquiera de esas cosas
‫se agregó en el árbol.
‫Eso significa que se agregó a los binarios de
‫Kubernetes y se envió con Kubernetes.
‫Eso significa que Kubernetes vino con el almacenamiento de Amazon
‫y Azure construido de inmediato.
‫Eso fue bastante conveniente, pero agregó
‫muchos desafíos.
‫La mayoría de ellos estaban relacionados con el hecho de
‫que los proveedores de almacenamiento ahora estaban contribuyendo con código al núcleo de su
‫sistema que probablemente ni siquiera necesitaba porque solo puede usar un proveedor de almacenamiento, entonces,
‫¿por qué tenerlos todos?
‫Además, los proveedores de almacenamiento tuvieron que controlar sus ciclos de lanzamiento alrededor
‫del ciclo de lanzamiento de Kubernetes, y no era
‫un modelo muy flexible.
‫Entonces, la industria se unió, y al igual
‫que lo hizo con las redes y con Dockerfiles e
‫imágenes, creó un estándar. Ese estándar es el CSI.
‫Eso significa Interfaz de almacenamiento de contenedores.
‫Eso proporcionará complementos ahora para que cualquier proveedor de almacenamiento
‫pueda crear un complemento que instalaría en todos
‫los nodos, y que sería diferente según el
‫complemento y sus instrucciones.
‫Luego, operarán en una API estándar que proporciona el CSI para
‫que cualquiera de sus contenedores
‫pueda usar ese complemento para llegar a su almacenamiento.
‫Es un modelo mucho mejor y más flexible.
‫Ese es el futuro de Kubernetes, pero
‫aún es bastante nuevo. Muy a menudo en los
‫ejemplos, e incluso sus proveedores de almacenamiento pueden recomendar, dependiendo
‫de su madurez de CSI, que use su complemento tradicional, que está
‫integrado en Kubernetes y viene listo para usar.