Google Kubernetes Engine (GKE) offre un modo semplice per eseguire automaticamente il deployment e gestire il driver Container Storage Interface (CSI) per il disco permanente di Compute Engine nei cluster. Il driver CSI per il disco permanente di Compute Engine è sempre abilitato nei cluster Autopilot e non può essere disabilitato o modificato. Nei cluster Standard, devi abilitare il driver CSI per il disco permanente di Compute Engine.
La versione del driver CSI per il disco permanente di Compute Engine è associata ai numeri di versione di GKE. La versione del driver CSI per il disco permanente di Compute Engine è in genere l'ultimo driver disponibile al momento del rilascio della versione di GKE. I driver vengono aggiornati automaticamente quando viene eseguito l'upgrade del cluster all'ultima patch di GKE.
Vantaggi
L'utilizzo del driver CSI per il disco permanente di Compute Engine offre i seguenti vantaggi:
- Consente il deployment e la gestione automatici del driver del disco permanente senza doverlo configurare manualmente.
- Puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK). Queste chiavi vengono utilizzate per criptare le chiavi di crittografia dei dati che criptano i tuoi dati. Per saperne di più sulle CMEK in GKE, consulta Utilizzo delle CMEK.
- Puoi utilizzare gli snapshot dei volumi con il driver CSI per il disco permanente di Compute Engine. Gli snapshot dei volumi ti consentono di creare una copia del volume in un momento specifico. Puoi utilizzare questa copia per riportare un volume a uno stato precedente o per eseguire il provisioning di un nuovo volume.
- Puoi utilizzare la clonazione dei volumi con il driver CSI per il disco permanente di Compute Engine nei cluster che eseguono GKE versione 1.22 e successive. La clonazione dei volumi ti consente di creare un duplicato del volume in un momento specifico, di cui è stato eseguito il provisioning con tutti i dati del volume di origine.
- Le correzioni di bug e gli aggiornamenti delle funzionalità vengono implementati indipendentemente dalle release secondarie di Kubernetes. Questa pianificazione delle release in genere comporta una cadenza di rilascio più rapida.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
installala e poi
inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima
versione eseguendo il
gcloud components updatecomando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
Abilitare il driver CSI per il disco permanente di Compute Engine
Per abilitare il driver CSI per il disco permanente di Compute Engine nei cluster Standard esistenti, utilizza il Google Cloud CLI o la Cloud de Confiance console.
Per abilitare il driver su un cluster esistente, completa i seguenti passaggi:
gcloud
gcloud container clusters update CLUSTER-NAME \
--update-addons=GcePersistentDiskCsiDriver=ENABLED
Sostituisci CLUSTER-NAME con il nome del cluster esistente.
Console
Vai alla pagina Google Kubernetes Engine nella Cloud de Confiance console.
Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.
In Funzionalità, accanto al campo Driver CSI per il disco permanente di Compute Engine, fai clic su edit Modifica driver CSI di Compute Engine.
Seleziona la casella di controllo Abilita driver CSI per il disco permanente di Compute Engine.
Fai clic su Salva modifiche.
Dopo aver abilitato il driver CSI per il disco permanente di Compute Engine, puoi utilizzarlo nei volumi Kubernetes utilizzando il nome del driver e del provisioner: pd.csi.storage.gke.io.
Disabilitare il driver CSI per il disco permanente di Compute Engine
Puoi disabilitare il driver CSI per il disco permanente di Compute Engine per i cluster Standard utilizzando Google Cloud CLI o la Cloud de Confiance console.
Se disabiliti il driver, tutti i pod che al momento utilizzano volumi permanenti di proprietà del driver non potranno essere terminati. Inoltre, i nuovi pod che tenteranno di utilizzare quei volumi permanenti non riusciranno ad avviarsi.
Per disabilitare il driver su un cluster Standard esistente, completa i seguenti passaggi:
gcloud
gcloud container clusters update CLUSTER-NAME \
--update-addons=GcePersistentDiskCsiDriver=DISABLED
Sostituisci CLUSTER-NAME con il nome del cluster esistente.
Console
Vai alla pagina Google Kubernetes Engine nella Cloud de Confiance console.
Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.
In Funzionalità, accanto al campo Driver CSI per il disco permanente di Compute Engine, fai clic su edit Modifica driver CSI di Compute Engine.
Deseleziona la casella di controllo Abilita driver CSI per il disco permanente di Compute Engine.
Fai clic su Salva modifiche.
Utilizzare il driver CSI per il disco permanente di Compute Engine per i cluster Linux
Le sezioni seguenti descrivono la procedura tipica per l'utilizzo di un volume Kubernetes supportato da un driver CSI in GKE. Queste sezioni sono specifiche per i cluster che utilizzano Linux.
Creare un oggetto StorageClass
Dopo aver abilitato il driver CSI per il disco permanente di Compute Engine, GKE installa automaticamente le seguenti StorageClasses:
standard-rwo, utilizzando il disco permanente bilanciatopremium-rwo, utilizzando il disco permanente SSD
Per i cluster Autopilot, la StorageClass predefinita è standard-rwo, che utilizza il driver CSI per il disco permanente di Compute Engine. Per i cluster Standard, la StorageClass predefinita utilizza il plug-in del volume gcePersistentDisk in-tree di Kubernetes.
Puoi trovare il nome delle StorageClass installate eseguendo il seguente comando:
kubectl get sc
Puoi anche installare un'altra StorageClass che utilizza il driver CSI per il disco permanente di Compute Engine aggiungendo pd.csi.storage.gke.io nel campo del provisioner.
Ad esempio, puoi creare una StorageClass utilizzando il seguente file, denominato pd-example-class.yaml.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: pd-example
provisioner: pd.csi.storage.gke.io
# Recommended setting. Delays the binding and provisioning of a PersistentVolume until a Pod that uses the
# PersistentVolumeClaim is created and scheduled on a node.
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
type: pd-balanced
Puoi specificare i seguenti
tipi di dischi permanenti
nel parametro type:
pd-balancedpd-ssdpd-standardpd-extreme(supportato in GKE versione 1.26 e successive)
Se utilizzi pd-standard o pd-extreme, consulta
Tipi di macchine non supportati per ulteriori limitazioni di utilizzo.
Se utilizzi l'opzione pd-extreme, devi anche aggiungere il campo provisioned-iops-on-create al manifest. Questo campo deve essere impostato sullo stesso valore delle IOPS di cui è stato eseguito il provisioning specificato
quando hai creato il disco permanente.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: pd-extreme-example
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
type: pd-extreme
provisioned-iops-on-create:'10000'
Dopo aver creato il file pd-example-class.yaml, esegui il seguente comando:
kubectl create -f pd-example-class.yaml
Creare un oggetto PersistentVolumeClaim
Puoi creare un oggetto PersistentVolumeClaim che fa riferimento alla StorageClass del driver CSI per il disco permanente di Compute Engine.
Il seguente file, denominato pvc-example.yaml, utilizza la classe di archiviazione preinstallata standard-rwo:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: podpvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: standard-rwo
resources:
requests:
storage: 6Gi
Dopo aver creato il manifest PersistentVolumeClaim, esegui il seguente comando:
kubectl create -f pvc-example.yaml
Nella StorageClass preinstallata (standard-rwo), volumeBindingMode è impostato su WaitForFirstConsumer. Quando volumeBindingMode è impostato su WaitForFirstConsumer, il PersistentVolume non viene sottoposto a provisioning finché non viene pianificato un pod che fa riferimento a PersistentVolumeClaim. Se volumeBindingMode in StorageClass è impostato su Immediate (o viene omesso), viene eseguito il provisioning di un PersistentVolume supportato da disco permanente dopo la creazione di PersistentVolumeClaim.
Creare un pod che utilizza il volume
Quando utilizzi i pod con i PersistentVolume, ti consigliamo di utilizzare un controller di workload (ad esempio un deployment o un StatefulSet). Sebbene in genere non utilizzeresti un pod autonomo, l'esempio seguente ne utilizza uno per semplicità.
L'esempio seguente utilizza il volume creato nella sezione precedente:
apiVersion: v1
kind: Pod
metadata:
name: web-server
spec:
containers:
- name: web-server
image: nginx
volumeMounts:
# The path in the container where the volume will be mounted.
- mountPath: /var/lib/www/html
# The name of the volume that is being defined in the "volumes" section.
name: mypvc
volumes:
- name: mypvc
persistentVolumeClaim:
# References the PersistentVolumeClaim created earlier.
claimName: podpvc
readOnly: false
Utilizzare il driver CSI per il disco permanente di Compute Engine per i cluster Windows
Le sezioni seguenti descrivono la procedura tipica per l'utilizzo di un volume Kubernetes supportato da un driver CSI in GKE. Queste sezioni sono specifiche per i cluster che utilizzano Windows.
Assicurati che:
- La versione del cluster sia 1.19.7-gke.2000, 1.20.2-gke.2000 o successive.
- Le versioni dei nodi siano 1.18.12-gke.1203, 1.19.6-gke.800 o successive.
Creare un oggetto StorageClass
La creazione di una StorageClass per Windows è molto simile a quella per Linux. Tieni presente che la StorageClass installata per impostazione predefinita non funzionerà per Windows perché il tipo di file system è diverso. Il driver CSI per il disco permanente di Compute Engine per Windows richiede NTFS come tipo di file system.
Ad esempio, puoi creare una StorageClass utilizzando il seguente file denominato pd-
windows-class.yaml. Assicurati di aggiungere csi.storage.k8s.io/fstype: NTFS all'elenco dei parametri:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: pd-sc-windows
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
type: pd-balanced
csi.storage.k8s.io/fstype: NTFS
Creare un oggetto PersistentVolumeClaim
Dopo aver creato una StorageClass per Windows, puoi creare un oggetto PersistentVolumeClaim che fa riferimento a questa StorageClass:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: podpvc-windows
spec:
accessModes:
- ReadWriteOnce
storageClassName: pd-sc-windows
resources:
requests:
storage: 6Gi
Creare un pod che utilizza il volume
L'esempio seguente utilizza il volume creato nell'attività precedente:
apiVersion: v1
kind: Pod
metadata:
name: web-server
spec:
# Node selector to ensure the Pod runs on a Windows node.
nodeSelector:
kubernetes.io/os: windows
containers:
- name: iis-server
# The container image to use.
image: mcr.microsoft.com/windows/servercore/iis
ports:
- containerPort: 80
volumeMounts:
# The path in the container where the volume will be mounted.
- mountPath: /var/lib/www/html
name: mypvc
volumes:
- name: mypvc
persistentVolumeClaim:
# References the PersistentVolumeClaim created earlier.
claimName: podpvc-windows
readOnly: false
Modificare dinamicamente le IOPS e il throughput di Hyperdisk utilizzando VolumeAttributeClass
Puoi utilizzare VolumeAttributesClass con il driver CSI per il disco permanente di Compute Engine per modificare dinamicamente gli attributi del disco permanente, tra cui IOPS e throughput. Assicurati che la versione del cluster GKE sia 1.34 o successive.
Questa sezione mostra come utilizzare VolumeAttributesClass per modificare dinamicamente le prestazioni del volume. Crea due risorse VolumeAttributesClass, silver e gold, per definire diversi livelli di IOPS e throughput. Poi, crea una StorageClass, un oggetto PersistentVolumeClaim che fa riferimento al livello silver e un pod per utilizzare il volume. Infine, aggiorna PersistentVolumeClaim in modo che faccia riferimento al livello gold, che esegue un aggiornamento dinamico delle impostazioni delle prestazioni del volume.
Creare un oggetto VolumeAttributesClass per definire i livelli di prestazioni
Questa sezione definisce le risorse VolumeAttributesClass con i livelli di esempio denominati silver e gold.
Salva il seguente manifest come
vac-classes.yaml:apiVersion: storage.k8s.io/v1 kind: VolumeAttributesClass metadata: name: silver driverName: pd.csi.storage.gke.io parameters: iops: "3000" throughput: "188Mi" --- apiVersion: storage.k8s.io/v1 kind: VolumeAttributesClass metadata: name: gold driverName: pd.csi.storage.gke.io parameters: iops: "6000" throughput: "345Mi"Applica il manifest:
kubectl apply -f vac-classes.yaml
Creare una StorageClass per Hyperdisk
Questa sezione definisce una risorsa StorageClass per il provisioning dei volumi Hyperdisk.
Salva il seguente manifest come
hyperdisk-sc.yaml:apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hyperdisk-example provisioner: pd.csi.storage.gke.io volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true parameters: type: hyperdisk-balancedApplica il manifest:
kubectl apply -f hyperdisk-sc.yaml
Creare una PVC con un livello di prestazioni iniziale
Questa sezione crea una PVC e utilizza il livello iniziale denominato silver.
Salva il seguente manifest come
vac-silver-pvc.yaml:apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-pv-claim spec: accessModes: - ReadWriteOnce storageClassName: hyperdisk-example volumeAttributesClassName: silver resources: requests: storage: 200GiApplica il manifest:
kubectl apply -f vac-silver-pvc.yamlPer eseguire il provisioning di un volume permanente, crea un pod che utilizza la PVC. Il
StorageClasscreato nella sezione precedente impostavolumeBindingMode: WaitForFirstConsumer, che ritarda il provisioning del volume finché un pod non utilizza la PVC. Salva il seguente manifest cometest-pod.yaml:apiVersion: v1 kind: Pod metadata: name: test-pvc-pod spec: containers: - name: nginx-container image: nginx:latest ports: - containerPort: 80 volumeMounts: - name: pvc-storage mountPath: /usr/share/nginx/html volumes: - name: pvc-storage persistentVolumeClaim: claimName: test-pv-claimApplica il manifest:
kubectl apply -f test-pod.yamlPer verificare le impostazioni delle prestazioni del disco, consulta Verificare le impostazioni delle prestazioni del disco nella Cloud de Confiance console. Le IOPS di cui è stato eseguito il provisioning devono essere
3000e il throughput di cui è stato eseguito il provisioning deve essere188, rispettivamente.
Aggiornare la PVC per utilizzare un livello di prestazioni diverso
Questa sezione aggiorna la PVC in modo che utilizzi il livello gold anziché il livello silver.
Salva il seguente manifest come
vac-gold-pvc.yaml:apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-pv-claim spec: accessModes: - ReadWriteOnce storageClassName: hyperdisk-example volumeAttributesClassName: gold resources: requests: storage: 200GiApplica il manifest:
kubectl apply -f vac-gold-pvc.yamlPer verificare che le impostazioni delle prestazioni del disco siano aggiornate, consulta Verificare le impostazioni delle prestazioni del disco nella Cloud de Confiance console. Le IOPS di cui è stato eseguito il provisioning devono essere
6000e il throughput di cui è stato eseguito il provisioning deve essere345, rispettivamente.
Verificare le impostazioni delle prestazioni del disco nella Cloud de Confiance console
Puoi verificare che le impostazioni di IOPS e throughput siano applicate al disco permanente controllando i dettagli del disco nella Cloud de Confiance console.
Recupera il nome del disco:
PV_NAME=$(kubectl get pvc test-pv-claim -o=jsonpath='{.spec.volumeName}') DISK_NAME=$(kubectl get pv $PV_NAME -o=jsonpath='{.spec.csi.volumeHandle}' | sed 's|.*/||') echo "Persistent disk name: $DISK_NAME"Nella Cloud de Confiance console, vai alla pagina Dischi.
Fai clic sul nome del disco permanente che corrisponde al nome del disco nell'output del passaggio precedente.
Nella pagina Dettagli disco, nella sezione Prestazioni, visualizza IOPS di cui è stato eseguito il provisioning e Throughput di cui è stato eseguito il provisioning.
Per ulteriori informazioni, consulta Visualizzare le impostazioni delle prestazioni di cui è stato eseguito il provisioning per Hyperdisk.
Considerazioni per la modifica dinamica
- Applicare di nuovo le configurazioni precedenti: se una PVC non può essere associata a una classe di attributi del volume a causa di un errore, ad esempio risorse non disponibili, puoi applicare di nuovo la PVC precedente in tutta sicurezza.
- Supporto delle quote: il piano di controllo di Kubernetes può applicare le quote alle PVC che fanno riferimento a una
VolumeAttributesClassspecifica utilizzandoscopeSelectorinResourceQuota.
Utilizzare il driver CSI per il disco permanente di Compute Engine con tipi di file system non predefiniti
Il tipo di file system predefinito per i dischi permanenti di Compute Engine in GKE è ext4. Puoi anche utilizzare il tipo di archiviazione xfs, a condizione che l'immagine del nodo lo supporti. Consulta Supporto dei driver di archiviazione
per un elenco dei driver supportati dall'immagine del nodo.
L'esempio seguente mostra come utilizzare xfs come tipo di file system predefinito anziché ext4 con il driver CSI per il disco permanente di Compute Engine.
Creare un oggetto StorageClass
Salva il seguente manifest come file YAML denominato
pd-xfs-class.yaml:apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: xfs-class provisioner: pd.csi.storage.gke.io parameters: # The type of Compute Engine persistent disk to provision. type: pd-balanced # Specify "xfs" as the filesystem type. csi.storage.k8s.io/fstype: xfs volumeBindingMode: WaitForFirstConsumerApplica il manifest:
kubectl apply -f pd-xfs-class.yaml
Creare un oggetto PersistentVolumeClaim
Salva il seguente manifest come
pd-xfs-pvc.yaml:apiVersion: v1 kind: PersistentVolumeClaim metadata: name: xfs-pvc spec: # References the StorageClass created earlier. storageClassName: xfs-class accessModes: - ReadWriteOnce resources: requests: # The amount of storage requested. storage: 10GiApplica il manifest:
kubectl apply -f pd-xfs-pvc.yaml
Creare un pod che utilizza il volume
Salva il seguente manifest come
pd-xfs-pod.yaml:apiVersion: v1 kind: Pod metadata: name: pd-xfs-pod spec: containers: - name: cloud-sdk image: google/cloud-sdk:slim # Keep the container running for 1 hour. args: ["sleep","3600"] volumeMounts: # The path in the container where the volume will be mounted. - mountPath: /xfs name: xfs-volume # Define the volumes available to the containers in the Pod. volumes: - name: xfs-volume persistentVolumeClaim: # References the PersistentVolumeClaim created earlier. claimName: xfs-pvcApplica il manifest:
kubectl apply -f pd-xfs-pod.yaml
Verificare che il volume sia stato montato correttamente
Apri una sessione shell nel pod:
kubectl exec -it pd-xfs-pod -- /bin/bashCerca le partizioni
xfs:df -aTh --type=xfsL'output dovrebbe essere simile al seguente:
Filesystem Type Size Used Avail Use% Mounted on /dev/sdb xfs 30G 63M 30G 1% /xfs
Visualizzare i log del driver CSI per il disco permanente di Compute Engine
Puoi utilizzare Cloud Logging per visualizzare gli eventi relativi al driver CSI per il disco permanente di Compute Engine. I log possono aiutarti a risolvere i problemi.
Per saperne di più su Cloud Logging, consulta Visualizzare i log di GKE.
Per visualizzare i log del driver CSI per il disco permanente di Compute Engine, completa i seguenti passaggi:
Vai alla pagina Cloud Logging nella Cloud de Confiance console.
Per filtrare le voci di log in modo da mostrare solo quelle relative al driver CSI in esecuzione nel tuo spazio dei nomi, esegui la seguente query di Cloud Logging:
resource.type="k8s_container" resource.labels.project_id="PROJECT_ID" resource.labels.location="LOCATION" resource.labels.cluster_name="CLUSTER_NAME" resource.labels.namespace_name="kube-system" resource.labels.container_name="gce-pd-driver"Sostituisci quanto segue:
PROJECT_ID: il nome del progetto.LOCATION: la regione o la zona di Compute Engine del cluster.CLUSTER_NAME: il nome del tuo cluster.
Problemi noti
Tipi di macchine non supportati
Se utilizzi la famiglia di macchine della serie C3, il tipo di disco permanente pd-standard non è supportato.
Se tenti di eseguire un pod su una macchina e il pod utilizza un tipo di disco permanente non supportato, vedrai un messaggio di avviso simile al seguente emesso sul pod:
AttachVolume.Attach failed for volume "pvc-d7397693-5097-4a70-9df0-b10204611053" : rpc error: code = Internal desc = unknown Attach error: failed when waiting for zonal op: operation operation-1681408439910-5f93b68c8803d-6606e4ed-b96be2e7 failed (UNSUPPORTED_OPERATION): [pd-standard] features are not compatible for creating instance.
Se il cluster ha più pool di nodi con famiglie di macchine diverse, puoi utilizzare
i taint dei nodi
e
l'affinità dei nodi
per limitare la pianificazione dei workload. Ad esempio, puoi utilizzare questo approccio per impedire l'esecuzione di un workload che utilizza pd-standard su una famiglia di macchine non supportata.
Se utilizzi il tipo di disco permanente pd-extreme, devi assicurarti che il disco sia collegato a un'istanza VM con una forma di macchina adatta. Per saperne di più, consulta Supporto delle forme di macchine.
Passaggi successivi
- Scopri come utilizzare l'espansione dei volumi.
- Scopri come utilizzare gli snapshot dei volumi.
- Scopri come utilizzare la clonazione dei volumi.
- Scopri come creare dischi permanenti regionali.
- Scopri di più sul driver su GitHub.