Closed dmlls closed 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 de glusterfs
.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:
La forma en la que se va a trabajar va a ser la siguiente:
PersistentVolume
(PV) que incluirá los detalles de conexión con el Google Compute Engine (GCE) persistent disk (PD). El GCE PersistentDisk habrá sido proveído previamente con el modelo de Hugging Face que será utilizado para generar los resúmenes(p. ej. t5-large
).PersistentVolumeClaim
(PVC), el cual se asociará (bound) con el PersistentVolume
. Se trata de una abstracción que permite que el PersistentVolumeClaim
esté completamente desacoplado del sistema de almacenamiento subyacente (en nuestro caso GCE PersistentDisk).PesistentVolumeClaim
para poder acceder a los modelos almacenados en GCE PersistentDisk).Como podemos ver, en el caso de que se cambiara de storage provider, solo habría que modificar el componente PersistentVolume
para que se refiriera a la nueva localización del volumen (el cual podría ser AWS EBS, Azure Disk, CSI, o nuestro propio servidor con Glusterfs instalado, por ejemplo).
De esta forma, logramos separar la computación del almacenamiento.
La siguiente imagen ilustra los puntos indicados anteriormente (fuente):
Adicionalmente, este vídeo proporciona una visión general pero instructiva de las diferentes estrategias de almacenamiento en Kubernetes.
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).