Esegui il provisioning e utilizza l'archiviazione temporanea supportata da SSD locale

Questa pagina spiega come eseguire il provisioning dello spazio di archiviazione SSD locale sui cluster Google Kubernetes Engine (GKE) e come configurare i carichi di lavoro per utilizzare i dati dallo spazio di archiviazione temporaneo basato su SSD locale collegato ai nodi del cluster.

Per scoprire di più sul supporto degli SSD locali su GKE, consulta Informazioni sullo spazio di archiviazione SSD locale.

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 update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Creare un cluster o un pool di nodi con spazio di archiviazione temporaneo basato su SSD locale

Utilizza Google Cloud CLI per creare un cluster o pool di nodi con spazio di archiviazione temporaneo basato su SSD locale.

Utilizza l'opzione --ephemeral-storage-local-ssd per collegare lo spazio di archiviazione temporaneo locale completamente gestito locale supportato dai volumi SSD locali. Questo spazio di archiviazione è legato al ciclo di vita dei pod. Quando i pod richiedono spazio di archiviazione temporaneo, GKE li pianifica per l'esecuzione sui nodi con volumi SSD locali configurati come spazio di archiviazione temporaneo. Se vuoi un controllo più specializzato o granulare sugli SSD locali, ti consigliamo di utilizzare lo spazio di archiviazione a blocchi non elaborati basato su SSD locale invece.

Se la scalabilità automatica del cluster è abilitata, GKE esegue la scalabilità automatica dei nodi quando il cluster ha bisogno di più spazio di archiviazione temporaneo. I pod possono accedere ai dati sui volumi SSD locali tramite il emptyDir volume.

Il comando gcloud CLI che esegui per creare il cluster o il pool di nodi dipende dalla generazione della serie di macchine del tipo di macchina selezionato. Ad esempio, i tipi di macchine N1 e N2 appartengono rispettivamente a una serie di macchine di prima e seconda generazione, mentre i tipi di macchine C3 appartengono a una serie di macchine di terza generazione.

Creare un cluster con SSD locale

1ª o 2ª generazione

Se utilizzi un tipo di macchina di una serie di macchine di prima o seconda generazione, crea il cluster specificando l'--ephemeral-storage-local-ssd count=NUMBER_OF_DISKS opzione. Questa opzione esegue il provisioning del numero specificato di volumi SSD locali su ogni nodo da utilizzare per lo spazio di archiviazione temporaneo di kubelet.

Queste impostazioni si applicano solo al pool di nodi predefinito. Se i pool di nodi successivi richiedono SSD locali, specificalo durante la creazione del pool di nodi.

Per creare un cluster in esecuzione su GKE versione 1.25.3-gke.1800 o successive in cui il pool predefinito utilizza i volumi SSD locali, esegui il comando seguente:

gcloud container clusters create CLUSTER_NAME \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS \
    --machine-type=MACHINE_TYPE \
    --release-channel CHANNEL_NAME

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • NUMBER_OF_DISKS: il numero di volumi SSD locali di cui eseguire il provisioning su ogni nodo. Questi volumi vengono combinati in un unico volume logico durante la configurazione del nodo. Il numero massimo di volumi varia in base al tipo di macchina e alla regione. Tieni presente che una parte della capacità degli SSD locali è riservata all'utilizzo del sistema.
  • MACHINE_TYPE: il tipo di macchina da utilizzare. Questo campo è obbligatorio, poiché gli SSD locali non possono essere utilizzati con il tipo e2-medium predefinito.
  • CHANNEL_NAME: un canale di rilascio che include versioni di GKE successive alla 1.25.3-gke.1800. Se preferisci non utilizzare un canale di rilascio, puoi anche utilizzare il flag --cluster-version anziché --release-channel, specificando una versione valida successiva alla 1.25.3-gke.1800. Per determinare le versioni valide, utilizza il comando gcloud container get-server-config.

3ª o 4ª generazione

Se utilizzi un tipo di macchina di una serie di macchine di terza o quarta generazione, non devi specificare alcuna opzione SSD locale quando crei un cluster. Il numero di dischi collegati a ogni nodo dipende dal tipo di macchina.

Per creare un cluster, esegui il comando seguente:

gcloud container clusters create CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --cluster-version CLUSTER_VERSION

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • MACHINE_TYPE: il tipo di macchina da utilizzare da una serie di macchine di terza o quarta generazione.
  • CLUSTER_VERSION: una versione del cluster GKE che supporta gli SSD locali sui tipi di macchine di una serie di macchine di terza o quarta generazione.

Creare un pool di nodi con SSD locale

1ª o 2ª generazione

Per creare un pool di nodi in esecuzione su GKE versione 1.25.3-gke.1800 o successive che utilizza i volumi SSD locali, esegui il comando seguente:

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS \
    --machine-type=MACHINE_TYPE

Sostituisci quanto segue:

  • POOL_NAME: il nome del nuovo pool di nodi.
  • CLUSTER_NAME: il nome del cluster.
  • NUMBER_OF_DISKS: il numero di volumi SSD locali di cui eseguire il provisioning su ogni nodo. Questi volumi vengono combinati in un unico volume logico durante la configurazione del nodo. Il numero massimo di volumi varia in base al tipo di macchina e alla regione. Tieni presente che una parte della capacità degli SSD locali è riservata all'utilizzo del sistema.
  • MACHINE_TYPE: il tipo di macchina da utilizzare. Questo campo è obbligatorio, poiché gli SSD locali non possono essere utilizzati con il tipo e2-medium predefinito.

3ª o 4ª generazione

Se utilizzi un tipo di macchina di una serie di macchine di terza o quarta generazione, non devi specificare alcuna opzione SSD locale quando crei un pool di nodi. Il numero di volumi collegati a ogni nodo dipende dal tipo di macchina.

Per creare un pool di nodi, esegui il comando seguente:

gcloud container node-pools create POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --node-version NODE_VERSION

Sostituisci quanto segue:

  • POOL_NAME: il nome del nuovo pool di nodi.
  • CLUSTER_NAME: il nome del cluster.
  • MACHINE_TYPE: il tipo di macchina da utilizzare da una serie di macchine di terza o quarta generazione.
  • NODE_VERSION: una versione del pool di nodi GKE che supporta gli SSD locali sui tipi di macchine di una serie di macchine di terza o quarta generazione.

I nodi del pool di nodi vengono creati con l'etichetta cloud.google.com/gke-ephemeral-storage-local-ssd=true. Puoi verificare le etichette eseguendo il comando seguente:

kubectl describe node NODE_NAME

Utilizzare lo spazio di archiviazione temporaneo basato su SSD locale con i cluster Autopilot

Puoi utilizzare gli SSD locali per lo spazio di archiviazione temporaneo quando configuri i pod in uno dei seguenti modi:

  • Seleziona esplicitamente una serie di macchine per eseguire i pod e specifica il cloud.google.com/gke-ephemeral-storage-local-ssd: "true" selettore di nodi o una prenotazione di capacità con SSD locali. Per scoprire di più sulla selezione delle serie di macchine su Autopilot, consulta Ottimizzare le prestazioni dei pod Autopilot scegliendo una serie di macchine.
  • Richiedi un tipo di GPU che supporta gli SSD locali e specifica il cloud.google.com/gke-ephemeral-storage-local-ssd: "true" selettore di nodi o una prenotazione di capacità con SSD locali. Le GPU NVIDIA H100 (80 GB) e le GPU NVIDIA A100 (80 GB) utilizzano sempre gli SSD locali per lo spazio di archiviazione temporaneo e non puoi specificare il selettore di nodi per queste GPU. Per scoprire di più sulla richiesta di GPU su Autopilot, consulta Richiedere GPU nei container.

Per un elenco delle serie di macchine compatibili con gli SSD locali, consulta Serie di macchine che supportano gli SSD locali in Autopilot.

Richiedere gli SSD locali direttamente nei manifest dei carichi di lavoro

Per utilizzare gli SSD locali per lo spazio di archiviazione temporaneo, aggiungi il cloud.google.com/gke-ephemeral-storage-local-ssd: "true" selettore di nodi al tuo manifest del carico di lavoro. Ad esempio, il seguente manifest del pod seleziona gli SSD locali come spazio di archiviazione temporaneo per i pod GPU:

apiVersion: v1
kind: Pod
metadata:
  name: l4-localssd-pod
spec:
  containers:
  - name: my-gpu-container
    image: nvidia/cuda:11.0.3-runtime-ubuntu20.04
    command: ["/bin/bash", "-c", "--"]
    args: ["while true; do sleep 600; done;"]
    resources:
      requests:
        cpu: 16
        memory: 64Gi
        ephemeral-storage: 800Gi
      limits:
       cpu: 16
       memory: 64Gi
       ephemeral-storage: 800Gi
       nvidia.com/gpu: 8
  nodeSelector:
    cloud.google.com/gke-accelerator: nvidia-l4
    cloud.google.com/gke-ephemeral-storage-local-ssd: "true"

Richiedere gli SSD locali con le prenotazioni di capacità

Se utilizzi una prenotazione di capacità di Compute Engine per prenotare macchine con SSD locali, Autopilot collega gli SSD locali disponibili dalla prenotazione ai nodi e non devi selezionare esplicitamente gli SSD locali nel manifest del carico di lavoro. Per scoprire di più sull'utilizzo delle prenotazioni con Autopilot, consulta Utilizzare le prenotazioni di capacità nei cluster Autopilot.

Ad esempio, il seguente manifest del pod seleziona una prenotazione specifica con SSD locali:

apiVersion: v1
kind: Pod
metadata:
  name: local-ssd-pod
spec:
  nodeSelector:
    cloud.google.com/machine-family: MACHINE_SERIES
    cloud.google.com/reservation-name: localssd-count-reservation
    cloud.google.com/reservation-affinity: "specific"
  containers:
  - name: my-container
    image: "k8s.gcr.io/pause"
    resources:
      requests:
        cpu: 6
        memory: "25Gi"
        ephemeral-storage: "100Gi"
      limits:
        cpu: 12
        memory: "50Gi"
        ephemeral-storage: "200Gi"

Sostituisci MACHINE_SERIES con una serie di macchine supportata che supporta anche gli SSD locali. Se la serie di macchine specificata non supporta gli SSD locali, il deployment non riesce e viene visualizzato un errore.

Serie di macchine che supportano gli SSD locali in Autopilot

I cluster Autopilot supportano l'utilizzo degli SSD locali per lo spazio di archiviazione temporaneo con le seguenti serie di macchine:

(solo con prenotazione di capacità)
(solo con prenotazione di capacità)
(solo con prenotazione di capacità)
(solo con prenotazione di capacità)
(solo con prenotazione di capacità)
(sempre in bundle)
(solo con prenotazione di capacità)
(sempre in bundle)
(sempre in bundle)
(sempre in bundle)
(sempre in bundle)
(ad eccezione dei tipi di macchine G4 con meno di una GPU (anteprima), che non supportano Autopilot)

Utilizzare il parametro API legacy

L'opzione --local-ssd-count è un parametro API legacy che supporta gli SSD locali SCSI. La serie di macchine di terza generazione di Compute Engine non supporta SCSI e supporta solo NVMe. Utilizza questa opzione solo con i cluster Windows Server. Se al momento utilizzi il parametro API legacy sui cluster Linux, ti consigliamo di utilizzare invece l'opzione --ephemeral-storage-local-ssd.

SSD locale sui cluster Windows Server

Quando utilizzi gli SSD locali con i tuoi cluster che eseguono i pool di nodi Windows Server, devi accedere al nodo e formattare il volume prima di utilizzarlo. Nell'esempio seguente, il volume SSD locale viene formattato con il file system NTFS. Puoi anche creare directory nel volume. In questo esempio, le directory si trovano nel disco D.

PS C:\> Get-Disk | Where partitionstyle -eq 'raw' | Initialize-Disk -PartitionStyle MBR -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem ntfs -Confirm:$false
PS C:\> mkdir D:\test-ssd

Accedere ai volumi SSD locali

Il seguente esempio mostra come puoi accedere allo spazio di archiviazione temporaneo basato su SSD locale.

Spazio di archiviazione temporaneo come volume emptyDir

Un pool di nodi GKE può essere configurato per utilizzare gli SSD locali per lo spazio di archiviazione temporaneo, inclusi i volumi emptyDir.

Il seguente manifest del pod utilizza un emptyDir e un selettore di nodi cloud.google.com/gke-ephemeral-storage-local-ssd. Puoi applicare una tecnica simile per i manifest di deployment o i manifest di StatefulSet.

Quando scegli la richiesta di risorse di spazio di archiviazione temporaneo, tieni conto della capacità degli SSD locali riservata all'utilizzo del sistema.

apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
spec:
  containers:
    - name: CONTAINER_NAME
      image: "registry.k8s.io/pause"
      resources:
        requests:
          ephemeral-storage: "200Gi"
      volumeMounts:
        - mountPath: /cache
          name: scratch-volume
  nodeSelector:
    cloud.google.com/gke-ephemeral-storage-local-ssd: "true"
  volumes:
    - name: scratch-volume
      emptyDir: {}

Risoluzione dei problemi

Per istruzioni sulla risoluzione dei problemi, consulta Risolvere i problemi di archiviazione in GKE.

Passaggi successivi