El volumen de Kubernetes ha brindado una buena abstracción para el almacenamiento de datos. Simplemente define dicho "volumen de almacenamiento", y podemos jugar libremente el tipo, la capacidad y el método de almacenamiento de este "volumen de almacenamiento". Pod no necesita preocuparse por esos detalles profesionales y complicados, siempre que se establezcan los montajes de volumen, el volumen se puede cargar en el contenedor para su uso.
Un objeto PersistentVolume, que se usa específicamente para representar un dispositivo de almacenamiento persistente, pero oculta la implementación subyacente del almacenamiento. Como una abstracción del almacenamiento, PV es en realidad algunos dispositivos de almacenamiento, sistemas de archivos, como Ceph, GlusterFS, NFS e incluso discos locales. Administrarlos está más allá del alcance de Kubernetes, por lo que generalmente lo mantiene solo el administrador del sistema, y Luego, cree el PV correspondiente en Kubernetes.
PV pertenece a los recursos del sistema del clúster y es un objeto al mismo nivel que Node. Pod no tiene derecho de administración sobre él, solo el derecho de usarlo.
PersistentVolumeClaim, conocido como PVC, es fácil de entender por el nombre y se usa para solicitar recursos de almacenamiento de Kubernetes. PVC es un objeto utilizado por Pod. Es equivalente al proxy de Pod y solicita PV del sistema en nombre de Pod. Una vez que la aplicación del recurso sea exitosa, Kubernetes asociará el PV con el PVC. Esta acción se denomina "vincular".
apiVersion: v1
kind: PersistentVolume
metadata:
name: host-10m-pv
spec:
storageClassName: host-test
accessModes:
- ReadWriteOnce
capacity:
storage: 10Mi
hostPath:
path: /tmp/host-10m-pv/"storageClassName" es la StorageClass abstracta para el tipo de almacenamiento. Este PV es administrado manualmente por nosotros, y el nombre puede ser arbitrario. Aquí escribo host-test, y también puede cambiarlo a manual, hand-work y otras palabras.
"accessModes" define el modo de acceso del dispositivo de almacenamiento. En pocas palabras, es el permiso de lectura y escritura del disco virtual, que es similar al modo de acceso a archivos de Linux. Actualmente hay tres tipos en Kubernetes:
- ReadWriteOnce: el volumen de almacenamiento se puede leer y escribir, pero los pods solo pueden montarlo en un nodo.
- ReadOnlyMany: el volumen de almacenamiento es de solo lectura, pero no de escritura, y los pods pueden montarlo varias veces en cualquier nodo.
- ReadWriteMany: el volumen de almacenamiento se puede leer y escribir, y los pods también pueden montarlo varias veces en cualquier nodo.
Debes prestar atención a que los objetos restringidos por estos tres modos de acceso sean nodos y no Pods, porque el almacenamiento es un concepto a nivel de sistema y no pertenece a los procesos en Pods.
"capacidad" indica la capacidad del dispositivo de almacenamiento, aquí lo configuré en 10 MB.
"hostPath", que especifica la ruta local al volumen de almacenamiento, que es el directorio que creamos en el nodo.
Un PVC requiere un dispositivo de almacenamiento de 5 MB y el modo de acceso es ReadWriteOnce:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: host-5m-pvc
spec:
storageClassName: host-test
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5MiEl contenido de PVC es muy similar al PV, pero no representa el almacenamiento real, sino una "aplicación" o "declaración". Los campos en las especificaciones describen el "estado deseado" de almacenamiento.
StorageClassName, accessModes y PV en PVC son los mismos, pero no habrá capacidad de campo, pero se debe usar resources.request para indicar la capacidad deseada.
De acuerdo con la descripción en el PVC, Kubernetes encontrará un PV que pueda coincidir con StorageClass y la capacidad, y luego "vinculará" el PV y el PVC para realizar la asignación de almacenamiento.
Este artículo son las notas de estudio de July Day19, el contenido proviene de Geek Time "Curso práctico introductorio de Kubernetes", se recomienda este curso.