Lectura recomendada:
Comience con PV y PVC a partir de un ejemplo
El proyecto Kubernetes introdujo un conjunto de objetos API llamados Reclamación de volumen persistente (PVC) y Volumen persistente (PV) para administrar los volúmenes de almacenamiento.
En pocas palabras, PersistentVolume (PV) es un segmento de almacenamiento de red configurado por el administrador en el clúster, que es un volumen de datos de almacenamiento persistente; Persistent Volume Claim (PVC) describe las propiedades del almacenamiento persistente que Pod desea usar, como , Tamaño de almacenamiento de volumen, permisos de lectura y escritura, etc.
La descripción de texto anterior puede ser demasiado vaga, tomemos un ejemplo:
Definimos un PVC y declaramos los atributos de volumen requeridos:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs
spec:
accessModes:
- ReadWriteMany
storageClassName: manual
resources:
requests:
storage: 1Gi
Un PVC de 1 GiB se define en el archivo yaml, los modos de acceso indican el tipo de almacenamiento de volumen requerido, ReadWriteOnce indica que las operaciones de lectura y escritura solo se pueden realizar en un nodo. Para otros modos de acceso, consulte: https://kubernetes.io/docs / conceptos / almacenamiento / volúmenes-persistentes / # modos-de-acceso .
Luego defina un PV:
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs
spec:
storageClassName: manual
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
nfs:
server: 10.244.1.4
path: "/"
Este objeto PV definirá en detalle que el tipo de almacenamiento es NFS y el tamaño es 1 GiB.
PVC y PV son equivalentes a "interfaz" e "implementación", por lo que necesitamos unir PVC y PV antes de que se puedan usar, y al unir PVC y PV, debemos cumplir:
- Para que coincida con el campo de especificaciones de PV y PVC, como el tamaño de almacenamiento de PV, debe cumplir con los requisitos de PVC.
- Los campos storageClassName de PV y PVC deben ser los mismos para la vinculación. storageClassName representa el atributo de nombre de StorageClass.
Después de que se hace la declaración de PVC y se establece el PV, el PVC se puede utilizar:
apiVersion: v1
kind: Pod
metadata:
labels:
role: web-frontend
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
volumeMounts:
- name: nfs
mountPath: "/usr/share/nginx/html"
volumes:
- name: nfs
persistentVolumeClaim:
claimName: nfs
Solo necesita declarar el nombre del PVC en el Pod. Una vez creado el Pod, kubelet montará el PV correspondiente al PVC, que es un Volumen de tipo NFS, en el directorio del contenedor Pod.
PersistentVolumeController verificará continuamente si cada PVC actual está en el estado Bound. Si no es así, atravesará todos los PV disponibles e intentará vincularlos a este PVC "único". Entonces, si no hay un PV que pueda vincularse a PVC, el Pod iniciará un error.
En este momento, se necesita StorageClass. El proceso de vinculación de PV y PVC mencionado anteriormente se llama aprovisionamiento estático, que requiere la creación manual de PV; StorageClass también proporciona un mecanismo de aprovisionamiento dinámico que puede crear PV basado en una plantilla.
Aprovisionamiento dinámico StorageClass 的
El objeto StorageClass define las dos partes siguientes:
- Los atributos de PV. Por ejemplo, tipo de almacenamiento, tamaño de volumen, etc.
- El complemento de almacenamiento necesario para crear este tipo de fotovoltaica. Por ejemplo, Ceph y así sucesivamente.
De esta manera, k8s puede encontrar un StorageClass correspondiente de acuerdo con el PVC enviado por el usuario y luego llamar al complemento de almacenamiento declarado por StorageClass para crear el PV requerido.
Por ejemplo, declare la siguiente StorageClass:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: block-service
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd
El StorageClass llamado block-service se define aquí. El valor del campo de aprovisionamiento es: kubernetes.io/gce-pd, que es un complemento de almacenamiento integrado de k8s. El campo de tipo también se define con aprovisionador. El valor predeterminado oficial es compatible con el complemento de almacenamiento integrado de aprovisionamiento dinámico : Https://kubernetes.io/docs/concepts/storage/storage-classes/ .
Luego, puede declarar el StorageClassName como servicio de bloque en el PVC. Después de crear el objeto PVC, k8s llamará a la API del complemento de almacenamiento correspondiente para crear un objeto PV.
como sigue:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: claim1
spec:
accessModes:
- ReadWriteOnce
storageClassName: block-service
resources:
requests:
storage: 30Gi
Este mecanismo automático de creación de PV es el aprovisionamiento dinámico. Kubernetes puede encontrar una StorageClass correspondiente basada en el PVC enviado por el usuario y luego llamar al complemento de almacenamiento declarado por StorageClass para crear el PV requerido.
Cabe señalar que si StorageClassName no se declara en el PVC, el valor del storageClassName del PVC es "", lo que también significa que solo se puede vincular al PV cuyo storageClassName también es "".
Ciclo de vida de PV y PVC
La interacción entre PV y PVC sigue este ciclo de vida:
Aprovisionamiento -> Vinculación -> Uso -> Recuperación
Aprovisionamiento
k8s proporciona dos métodos de generación fotovoltaica: estática o dinámicamente
estáticamente: los PV son creados por el administrador y contienen información detallada sobre el almacenamiento real disponible para los usuarios del clúster. Existen en la API de Kubernetes y se pueden usar para consumo.
dinámicamente: cuando el PV estático creado por el administrador no coincide con el PersistentVolumeClaim del usuario, el clúster puede intentar configurar dinámicamente el volumen para el PVC. Esta configuración se basa en StorageClasses. El PVC debe solicitar StorageClasses y el administrador debe haber creado y configurado la clase para que se configure dinámicamente.
Unión
Después de que el usuario crea PersistentVolumeClaim, PersistentVolumeController verificará continuamente si cada PVC actual ya está en el estado Bound. Si no es así, atravesará todos los PV disponibles e intentará vincularlos a este PVC "único".
Utilizando
Después de que los Pods declaren y usen el PVC como volumen, el clúster encontrará el PVC. Si el PVC ya está vinculado al PV, montará el volumen en el Pod.
Recuperando
Cuando el usuario ya no usa el volumen, el PVC se puede eliminar para que los recursos se puedan reciclar. En consecuencia, después de eliminar el PVC, la estrategia de reciclaje de PV se puede retener, reciclar o eliminar. Esta estrategia se puede configurar en el campo spec.persistentVolumeReclaimPolicy.
- Retener: esta política permite la recuperación manual de recursos. Cuando se elimina el PVC, el PV todavía puede existir. El administrador puede eliminar manualmente el PV, y los recursos de almacenamiento vinculados al PV no se eliminarán. Si desea eliminar el almacenamiento correspondiente Para los datos de recursos, debe eliminar manualmente los datos correspondientes al recurso de almacenamiento.
- Eliminar: esta estrategia eliminará PV y los recursos de almacenamiento administrados por PV después de que se elimine el PVC.
- Reciclar: equivale a ejecutar el comando rm -rf / thevolume / * en el volumen para que el volumen se pueda reutilizar.
Eliminar proceso
En circunstancias normales, seguimos este proceso de eliminación:
- Elimina el Pod usando este PV;
- Quite el disco local del host (por ejemplo, desmóntelo);
- Eliminar PVC;
- Elimina el PV.
Combate real de volumen persistente local
El volumen persistente local es adecuado para aplicaciones que son similares al almacenamiento de datos distribuidos, como MongoDB y Cassandra, que necesitan almacenar datos en varios nodos diferentes y son más sensibles a la E / S. Pero en comparación con el PV normal, una vez que estos nodos están inactivos y no se pueden recuperar, es posible que se pierdan los datos del volumen persistente local.
En nuestro entorno experimental, monte varios discos RAM (discos de memoria) en el host para simular discos locales. P.ej:
Montamos varios discos en el nodo1
$ mkdir /mnt/disks
$ for vol in vol1 vol2 vol3; do
mkdir /mnt/disks/$vol
mount -t tmpfs $vol /mnt/disks/$vol
done
Luego crea el PV correspondiente:
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
spec:
capacity:
storage: 512Mi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Delete
storageClassName: local-storage
local:
path: /mnt/disks/vol1
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node1
En la definición de este PV: el campo local especifica que se trata de un volumen persistente local; y el campo de ruta especifica la ruta del disco local correspondiente a este PV, a saber: / mnt / disks / vol1. Y use nodeAffinity para especificar que este PV debe ejecutarse en node1.
Ejecute el PV anterior:
$ kubectl create -f local-pv.yaml
persistentvolume/example-pv created
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
example-pv 512Mi RWO Delete Available local-storage 16s
Luego cree una StorageClass para describir este PV:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
Esta StorageClass se denomina almacenamiento local y el aprovisionador no es aprovisionador, lo que significa que no es necesario crear PV automáticamente.
volumeBindingMode = WaitForFirstConsumer significa que debe esperar hasta que el Pod se esté ejecutando antes de permitir que el PVC y el PV se unan. Porque cuando se usa el volumen persistente local, el PV y el PVC correspondiente deben seguir al pod en el mismo nodo, de lo contrario, la programación fallará.
Luego ejecutamos StorageClass:
$ kubectl create -f local-sc.yaml
storageclass.storage.k8s.io/local-storage created
Cree otro PVC:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: example-local-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 512Mi
storageClassName: local-storage
Tenga en cuenta aquí que storageClassName debe ser la StorageClass que creamos anteriormente.
Luego crea el PVC:
$ kubectl create -f local-pvc.yaml
persistentvolumeclaim/example-local-claim created
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
example-local-claim Pending local-storage 7s
En este momento, debido a que el pod aún no se ha creado, el estado sigue siendo Pendiente.
Crea una vaina:
kind: Pod
apiVersion: v1
metadata:
name: example-pv-pod
spec:
volumes:
- name: example-pv-storage
persistentVolumeClaim:
claimName: example-local-claim
containers:
- name: example-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: example-pv-storage
Luego, veremos el estado de enlace de PVC después de crear el pod:
$ kubectl create -f local-pod.yaml
pod/example-pv-pod created
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
example-local-claim Bound example-pv 512Mi RWO local-storage 6h
Luego intentamos escribir un archivo en / usr / share / nginx / html:
$ kubectl exec -it example-pv-pod -- /bin/sh
# cd /usr/share/nginx/html
# touch test.txt
# 在node1上
$ ls /mnt/disks/vol1
test.txt