dmlls
commented
3 years ago Tras un análisis detenido de la documentación de Kubernetes correspondiente a los volúmenes, las opciones que mejor se ajustan a nuestro caso parecen ser:
gcePersistentDisk: este tipo de volumen monta un Google Compute Engine (GCE) persistent disk (PD) en los pods especificados. Este volumen se ajusta a nuestras necesidades, dado que alojaremos nuestra arquitectura en Google Cloud, y esta clase de volumen está pensada para permitir accesos concurrentes de solo lectura. No obstante, presenta la desventaja de que "casa" nuestra arquitectura con este cloud provider (algo que queremos evitar a toda costa a fin de facilitar posibles futuras migraciones a otros cloud providers).glusterfs: monta un volumen Glusterfs (sistema de ficheros en red open-source). Presenta la ventaja de disminuir el acople con un cloud provider específico, pero la desventaja de tener que gestionar la instalación y configuración deglusterfs.local: monta un volumen en un dispositivo de almacenamiento local, como un disco, partición o directorio. De nuevo, es independiente del cloud provider, pero existe el incoveniente de estar asociado a un nodo específico. Si ese nodo dejara de funcionar correctamente, los pods no podrían acceder a este volumen, comprometiendo a toda la infraestructura.persistentVolumeClaim: monta un volumen persistente sin necesidad de conocer los detalles de un cloud environment específico. El ciclo de vida de los volúmenes persistentes va más allá del ciclo de vida de los pods, el cual es efímero. Por tanto, independientemente de la creación o destrucción de pods, el volumen va a persistir, lo cual se ajusta perfectamente a lo que necesitamos. Estos volúmenes persistentes pueden ir montados, a su vez, sobre una implementación específica de un cloud provider, por ejemplo, GCE PersistentDisk (ver primer punto).
Tras considerar las ventajas e inconvenientes de cada una de estas opciones, se ha decidido que la opción más adecuada es almacenar los modelos a través de un persistentVolumeClaim por los siguientes dos motivos principales:
- Abstrae los detalles específicos del cloud environment, proporcionando una solución desacoplada del mismo.
- Puede proveerse de manera estática, de forma que carguemos nuestros modelos una sola vez, y a partir de entonces puedan ser utilizados por los diferentes pods.
Los modelos de codificación y resumen de texto pueden llegar a tener un gran tamaño (del orden de GBs). Dado que los diferentes pods correspondientes a un modelo, p. ej.
T5-large, van a utilizar todos ese mismo modelo, parece contraproducente que cada pod tenga su propia copia del mismo.Una posible opción a explorar son los volúmenes de Kubernetes, que permiten establecer un espacio de memoria externo a los contenedores (p. ej., en el propio disco del servidor) al que pueden acceder de forma compartida (requiere una correcta configuración).