Questa pagina mostra come utilizzare l'hardware di archiviazione esterno, ad esempio i dischi permanenti di Compute Engine, come volumi temporanei nei workload Google Kubernetes Engine (GKE). Dovresti già avere familiarità con i volumi e le StorageClasses di Kubernetes.
Quando utilizzare l'archiviazione temporanea in Kubernetes
L'archiviazione temporanea è utile in qualsiasi situazione in cui i workload hanno bisogno dei dati solo durante il ciclo di vita dell'applicazione, ad esempio per pipeline di elaborazione dei dati, job di machine learning, elaborazione batch, caching locale o analisi. Per impostazione predefinita, una parte del disco di avvio del nodo GKE è disponibile per l'utilizzo come archiviazione temporanea nei pod. Questo approccio spesso richiede un'attenta pianificazione dello spazio.
I volumi temporanei generici di Kubernetes consentono di richiedere esplicitamente l'archiviazione temporanea per i pod utilizzando PersistentVolumeClaim. GKE esegue il provisioning dinamico dei dischi permanenti di Compute Engine Persistent Disks e li collega ai nodi. Questo tipo di archiviazione temporanea è utile in situazioni come le seguenti:
- I workload hanno requisiti di prestazioni elevate, quindi devi controllare l'hardware di archiviazione.
- Hai bisogno di spazio di archiviazione temporanea a breve termine e specifico per i container.
- Vuoi evitare di utilizzare
emptyDirper il provisioning dell'archiviazione temporanea. I volumiemptyDirsono ancora utili nelle situazioni in cui vuoi che più container condividano i dati nell'archiviazione temporanea. - Vuoi una capacità di archiviazione temporanea maggiore rispetto ai valori predefiniti integrati di GKE.
- Vuoi evitare di dover pianificare in anticipo le dimensioni e il tipo del disco di avvio del nodo per i cluster GKE in modalità Standard.
Tipi di archiviazione temporanea in GKE
In generale, puoi utilizzare la capacità di archiviazione del disco di avvio o i dischi permanenti dedicati come archiviazione temporanea nei pod e nei container. La tabella seguente descrive le differenze:
| Tipo di archiviazione | Come utilizzarlo | Descrizione |
|---|---|---|
| Disco di avvio - Dischi permanenti | Monta un volume utilizzando Per le istruzioni, consulta la guida alla creazione di volumi . |
Lo spazio di archiviazione temporanea richiesto viene prelevato da una parte riservata del disco di avvio del nodo. Questo è il valore predefinito sia nei cluster Autopilot che in quelli Standard. Utilizza questa opzione quando i pod hanno piccole richieste di archiviazione temporanea o quando vuoi condividere i dati temporanei tra più container nel pod. Autopilot
Standard Nessun limite di dimensioni, ma richiede un'attenta pianificazione delle dimensioni del disco di avvio del nodo e tipo di hardware di archiviazione. Per informazioni dettagliate su come GKE calcola la prenotazione dello spazio di archiviazione temporanea nel disco di avvio del nodo, consulta la sezione Prenotazione dello spazio di archiviazione temporanea locale. |
| Dischi SSD locali |
|
I dischi SSD locali utilizzano incrementi fissi di 375 GB supportati
nei cluster GKE in modalità Standard e nei nodi Autopilot
che eseguono GPU A100 (80 GB).
Utilizza questa opzione quando hai bisogno di uno spazio di archiviazione temporanea con un throughput elevato. Per maggiori dettagli, consulta la sezione Informazioni sugli SSD locali per GKE. |
| Dischi permanenti dedicati |
Questo documento fornisce istruzioni per richiedere questo tipo di archiviazione temporanea. |
Google Cloud esegue il provisioning dinamico dell'hardware esterno richiesto lo collega ai nodi e monta il volume richiesto nel pod. Utilizza questa opzione quando i pod hanno richieste di archiviazione temporanea di grandi dimensioni o quando vuoi controllare il tipo di Persistent Disk sottostante. Questi volumi hanno le seguenti proprietà:
Per informazioni dettagliate su questo tipo di volume temporaneo, consulta la sezione Volumi temporanei generici. |
Prezzi
Lo spazio di archiviazione di cui esegui il provisioning tramite volumi temporanei generici, come descritto in questa guida, viene fatturato in base ai prezzi dei dischi di Compute Engine.
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.
- Assicurati di avere un cluster GKE Autopilot o Standard che esegue la versione 1.23 o successive.
- Assicurati di avere una quota sufficiente nel tuo Google Cloud progetto per l' hardware di archiviazione. Per gestire la quota, consulta la guida Visualizza e gestisci le quote.
Crea una StorageClass
La creazione di una StorageClass Kubernetes personalizzata ti consente di specificare il tipo di spazio di archiviazione di cui eseguire il provisioning in base ai requisiti di prezzo e prestazioni. Questo passaggio è facoltativo, ma consigliato. Se vuoi utilizzare la StorageClass predefinita di GKE, che ha il tipo di Persistent Disk pd-balanced, salta questo passaggio.
Salva il seguente manifest come
ephemeral-pd-class.yaml:apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ephemeral-ssd provisioner: pd.csi.storage.gke.io volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true parameters: type: STORAGE_TYPESostituisci
STORAGE_TYPEcon il nome del tipo di Persistent Disk che vuoi utilizzare, ad esempiopd-ssd. Per un elenco dei tipi supportati, consulta la sezione Tipi di dischi permanenti nella documentazione di Compute Engine.Crea la StorageClass:
kubectl create -f ephemeral-pd-class.yaml
Richiedi la capacità di archiviazione temporanea in un pod
Per eseguire il provisioning, collegare e utilizzare l'hardware esterno come spazio di archiviazione temporanea, aggiungi il volume corrispondente al manifest del pod e aggiungi un montaggio del volume alla specifica del container.
Salva il seguente manifest come
ephemeral-ssd-deployment.yaml:apiVersion: apps/v1 kind: Deployment metadata: name: ephemeral-deployment spec: replicas: 1 selector: matchLabels: storage: ephemeral template: metadata: labels: storage: ephemeral spec: containers: - name: ephemeral-container image: nginx resources: requests: cpu: 500m memory: 2Gi ephemeral-storage: 2Gi volumeMounts: - mountPath: "/short-term" name: ephemeral-volume volumes: - name: ephemeral-volume ephemeral: volumeClaimTemplate: metadata: labels: type: ephemeral spec: accessModes: ["ReadWriteOnce"] storageClassName: "ephemeral-ssd" resources: requests: storage: 1TiQuesto manifest crea un nuovo PersistentVolumeClaim Kubernetes che richiede un nuovo PersistentVolume denominato
ephemeral-volumecon le seguenti proprietà:spec.volumes.ephemeral: il tipo di volumeephemeral..spec.accessModes: la modalità di accesso al volume, che determina l'accesso in lettura/scrittura da parte dei pod e la condivisione del volume tra i nodi. Questo esempio utilizzaReadWriteOnce, che monta il PersistentVolume su un singolo nodo per l'accesso da parte di uno o più pod sul nodo. Per maggiori dettagli, consulta la sezione Modalità di accesso..spec.storageClassName: facoltativamente, il nome della StorageClass che hai creato. Se ometti questo campo, GKE utilizza la StorageClass predefinita ed esegue il provisioning di un Persistent Diskpd-balanced..spec.resources.requests.storage: la capacità di archiviazione che vuoi utilizzare.
Crea il deployment:
kubectl create -f ephemeral-ssd-deployment.yaml
GKE esegue il provisioning di un disco Compute Engine che soddisfa i requisiti di PersistentVolumeClaim e lo collega al nodo. GKE monta il volume nel pod e fornisce la capacità richiesta al container.
Verifica che GKE abbia montato un volume temporaneo
Crea una sessione shell nel pod:
kubectl exec -it deploy/ephemeral-deployment -- bashControlla i volumi montati:
df -hL'output è simile al seguente:
Filesystem Size Used Available Use% Mounted on ... /dev/sdb 1006.9G 28.0K 1006.8G 0% /short-term /dev/sda1 94.3G 3.6G 90.6G 4% /etc/hosts /dev/sda1 94.3G 3.6G 90.6G 4% /dev/termination-log /dev/sda1 94.3G 3.6G 90.6G 4% /etc/hostname /dev/sda1 94.3G 3.6G 90.6G 4% /etc/resolv.conf ...Esci dalla sessione shell:
exit