Esegui il provisioning e utilizza SSD locali miste per l'archiviazione a blocchi non elaborati e temporanea

Standard

Questo documento mostra come eseguire il provisioning e il partizionamento delle unità SSD locali in Google Kubernetes Engine (GKE) per supportare i workload che richiedono sia un file system di archiviazione temporanea standard sia un'archiviazione a blocchi non formattata sullo stesso nodo.

Utilizza questa configurazione per applicazioni stateful e database altamente ottimizzati. Questi workload spesso richiedono l'accesso diretto al disco per migliorare le prestazioni, ma hanno anche bisogno di uno spazio di archiviazione dei file temporaneo standard per sidecar, log o cache dei container. Utilizzando la capacità degli SSD locali misti, puoi ridurre l'overhead di gestione dei cluster e massimizzare l'utilizzo dell'hardware, perché non devi dedicare nodi separati o dischi interi esclusivamente all'infrastruttura di blocchi non elaborati.

Quando crei un cluster o pool di nodi con capacità SSD locale mista, GKE partiziona ogni SSD locale collegato fisicamente come segue:

• Archiviazione temporanea: la capacità temporanea richiesta viene divisa equamente tra le unità SSD locali e combinata per fornire l'archiviazione di file temporanei standard del nodo. Quando la capacità temporanea è partizionata su più unità SSD locali, lo spazio di archiviazione viene combinato in un array RAID-0. Puoi accedere allo spazio di archiviazione temporaneo utilizzando i volumi emptyDir standard.
• Archiviazione a blocchi non elaborati: la capacità fisica rimanente su ogni disco viene presentata al nodo come dispositivi a blocchi non elaborati distinti e non formattati.

Questo documento è rivolto ad amministratori e operatori della piattaforma e a DevOps che vogliono ottimizzare l'utilizzo dell'hardware e le prestazioni dello spazio di archiviazione in GKE per workload specializzati.

Considerazioni

Oltre alle limitazioni delle unità SSD locali di Compute Engine, esamina le seguenti considerazioni specifiche di GKE prima di configurare le modalità SSD locali miste:

• Compatibilità con Autopilot: i cluster GKE Autopilot non supportano l'archiviazione a blocchi non elaborati e l'archiviazione temporanea miste. Per scoprire come utilizzare gli SSD locali per l'archiviazione temporanea standard in Autopilot, consulta SSD locali nei cluster Autopilot.
• ComputeClass personalizzate: le ComputeClass personalizzate non supportano la configurazione SSD locale mista.
• Sistema operativo: la modalità SSD locale mista è supportata solo sulle immagini dei nodi Linux (Container-Optimized OS e Ubuntu). I node pool Windows Server non sono supportati.
• Eventi di manutenzione: sconsigliamo di utilizzare l'SSD locale come archiviazione a blocchi non elaborati per le VM Z3 o Z4D ottimizzate per l'archiviazione. I dati su queste VM potrebbero non sopravvivere agli eventi di manutenzione. Per saperne di più, consulta Esegui il provisioning e utilizza l'archiviazione a blocchi non elaborati supportata da SSD locali.
• I/O condiviso: poiché sia l'array RAID-0 temporaneo sia le partizioni di blocchi non elaborati target si basano sulle stesse unità SSD fisiche sottostanti, le operazioni intensive su una partizione logica potrebbero influire sul throughput dell'altra. Per informazioni sui limiti di throughput massimo, consulta Prestazioni degli SSD locali.
• Prezzi: quando utilizzi modalità miste per partizionare la capacità dell'SSD locale, paghi per la capacità fisica totale dell'SSD locale sottostante collegata al nodo, indipendentemente dalla capacità allocata per l'archiviazione temporanea rispetto all'archiviazione a blocchi non elaborata. Per saperne di più, consulta Prezzi degli SSD locali.
• Configurazione manuale: per utilizzare l'archiviazione a blocchi non elaborati supportata da SSD locali, devi configurare manualmente i dispositivi, perché GKE non formatta o monta le partizioni dei blocchi non elaborati. Sei anche responsabile della gestione della capacità dei nodi e della gestione di potenziali interruzioni dei workload in colocation. L'utilizzo di un oggetto PersistentVolume locale fornisce la pianificazione dei pod integrata. Se i tuoi workload non richiedono la persistenza dei dati durante il ciclo di vita del pod o se non hanno esigenze di prestazioni specializzate, utilizza invece la configurazione dell'SSD locale completamente temporanea. La configurazione completamente temporanea è adatta alla maggior parte dei casi d'uso.
• Scambio di memoria dei nodi: puoi combinare la capacità delle unità SSD locali miste con lo scambio di memoria dei nodi utilizzando il profilo del disco di avvio o il profilo delle unità SSD locali temporanee. Il profilo SSD locale dedicato non è supportato con una capacità SSD locale mista. Per saperne di più, consulta Scambio di memoria dei nodi con capacità SSD locale mista.

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
• Per 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 comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Per utilizzare questa funzionalità, i nodi GKE devono eseguire la versione 1.37.0-gke.3570000 o successiva.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per creare cluster e node pool con capacità SSD locale mista, chiedi all'amministratore di concederti il ruolo IAM Kubernetes Engine Admin (roles/container.admin) nel progetto. Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Crea un cluster o pool di nodi con spazio di archiviazione SSD locale misto

Puoi allocare capacità temporanea e prenotare partizioni di blocchi non elaborati utilizzando la proprietà capacity del flag --ephemeral-storage-local-ssd.

Crea il cluster o il pool di nodi specificando il sottocampo capacity con il flag --ephemeral-storage-local-ssd.

Se il tipo di macchina consente un numero configurabile di SSD locali, devi specificare anche il campo secondario count. Se il tipo di macchina ha un numero fisso di SSD locali, ad esempio i tipi -lssd, puoi omettere il campo secondario count perché GKE calcola automaticamente il numero di dischi in base alla forma della VM.

Crea un cluster con spazio di archiviazione SSD locale misto

Per creare un nuovo cluster, utilizza il comando gcloud container clusters create. Queste impostazioni si applicano solo al pool di nodi predefinito. Se i pool di nodi successivi richiedono uno spazio di archiviazione SSD locale misto, specifica il flag --ephemeral-storage-local-ssd quando crei il pool di nodi. Il numero massimo di dischi che puoi collegare varia in base al tipo di macchina e alla regione.

Se la versione del tuo cluster è precedente alla 1.37.0-gke.3570000, aggiungi uno dei seguenti flag ai seguenti comandi di creazione del cluster:

• Il flag --cluster-version=<var>VERSION</var> con <var>VERSION</var> impostato su 1.37.0-gke.3570000 o versioni successive, oppure
• Il flag --release-channel=rapid.

Per i tipi di macchine con un numero di SSD locali configurabile, esegui questo comando:

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS,capacity=CAPACITY

Per i tipi di macchine con un numero fisso di SSD locali, esegui questo comando:

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd capacity=CAPACITY

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster che vuoi creare.
• MACHINE_TYPE: il tipo di macchina da utilizzare. Per un elenco dei tipi di macchine supportati, consulta Supporto delle serie di macchine. Non puoi utilizzare gli SSD locali con il tipo di macchina e2-medium predefinito, perché i tipi di macchine con core condivisi non li supportano.
• NUMBER_OF_DISKS: per i tipi di macchine con un numero di SSD locali configurabile, il numero di dischi SSD locali di cui eseguire il provisioning su ogni nodo.

• CAPACITY: la capacità totale dell'SSD locale da formattare per l'archiviazione temporanea. Questo valore deve essere maggiore di 0 e rigorosamente inferiore alla capacità fisica totale dell'SSD locale (numero di dischi × dimensione per disco), ad esempio 200GB. Tieni presente quanto segue:

  • Il valore non può essere modificato dopo la creazione del cluster.
  • GKE riserva parte di questa capacità per l'utilizzo del sistema, quindi l'archiviazione temporanea allocabile è inferiore a CAPACITY. Per saperne di più, consulta Prenotazione di archiviazione temporanea locale.

Cresa un pool di nodi con spazio di archiviazione SSD locale misto

Per aggiungere un pool di nodi a un cluster esistente, utilizza il comando gcloud container node-pools create.

Se la versione del pool di nodi è precedente alla 1.37.0-gke.3570000, devi:

• Aggiungi il flag --node-version=<var>VERSION</var> ai seguenti comandi di creazione dei pool di nodi, con <var>VERSION</var> impostato su 1.37.0-gke.3570000 o versioni successive.
• Assicurati che il control plane del cluster sia nella versione 1.37.0-gke.3570000 o successiva.

Per i tipi di macchine con un numero di SSD locali configurabile, esegui questo comando:

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

Per i tipi di macchine con un numero fisso di SSD locali, esegui questo comando:

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

Sostituisci quanto segue:

• POOL_NAME: il nome del nuovo pool di nodi che vuoi creare.
• CLUSTER_NAME: il nome del cluster.
• MACHINE_TYPE: il tipo di macchina da utilizzare. Per un elenco dei tipi di macchine supportati, consulta Supporto delle serie di macchine. Non puoi utilizzare gli SSD locali con il tipo di macchina e2-medium predefinito, perché i tipi di macchine con core condivisi non li supportano.
• NUMBER_OF_DISKS: per i tipi di macchine con un numero di SSD locali configurabile, il numero di dischi SSD locali di cui eseguire il provisioning su ogni nodo.

• CAPACITY: la capacità totale dell'SSD locale da formattare per l'archiviazione temporanea. Questo valore deve essere maggiore di 0 e rigorosamente inferiore alla capacità fisica totale dell'SSD locale (numero di dischi × dimensione per disco), ad esempio 200GB. Tieni presente quanto segue:

  • Il valore non può essere modificato dopo la creazione del pool di nodi.
  • GKE riserva parte di questa capacità per l'utilizzo del sistema, quindi l'archiviazione temporanea allocabile è inferiore a CAPACITY. Per saperne di più, consulta Prenotazione di archiviazione temporanea locale.

Verifica le etichette dei nodi

Dopo il provisioning, per verificare che i nodi abbiano le etichette corrette sia per l'archiviazione a blocchi non elaborati sia per l'archiviazione temporanea, esegui questo comando:

kubectl describe node NODE_NAME

L'output dovrebbe contenere entrambe le seguenti etichette dei nodi:

• cloud.google.com/gke-ephemeral-storage-local-ssd: "true"
• cloud.google.com/gke-local-nvme-ssd-partition: "true"

Nota: l'etichetta cloud.google.com/gke-local-nvme-ssd-partition: "true" è diversa dall'etichetta cloud.google.com/gke-local-nvme-ssd=true utilizzata per la configurazione dei blocchi completamente non elaborati. Per ulteriori informazioni sull'utilizzo della configurazione a blocchi completamente non elaborati, consulta Archiviazione a blocchi non elaborati supportata da SSD locale.

Accedi alla capacità temporanea

Accedi allo spazio di archiviazione temporaneo prenotato tramite volumi emptyDir esattamente come faresti per qualsiasi altro volume temporaneo GKE.

Accedi alla capacità dei blocchi non elaborati

Per accedere alla capacità dei blocchi non elaborati, devi creare un oggetto StorageClass, eseguire il provisioning di un oggetto PersistentVolume locale e richiederlo utilizzando un oggetto PersistentVolumeClaim.

Avviso: il flusso di lavoro standard dei blocchi non elaborati utilizza un DaemonSet RAID della community (gke-daemonset-raid-disks.yaml) insieme al provisioner statico del volume locale. Se adatti il RAID DaemonSet per i nodi di configurazione mista (ad esempio modificando il relativo nodeSelector), non devi eseguire questa configurazione RAID. GKE gestisce già la parte temporanea di ogni disco e l'esecuzione del DaemonSet RAID interrompe la capacità temporanea del nodo.

Crea un oggetto StorageClass

Poiché esegui il provisioning degli oggetti PersistentVolume senza il provisioner statico della community, ti consigliamo di creare un oggetto StorageClass con il campo volumeBindingMode: WaitForFirstConsumer. In questo modo, l'associazione viene ritardata fino alla pianificazione dei pod, garantendo che Kubernetes scelga un'unità SSD locale da un nodo appropriato in grado di eseguire il pod.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "local-storage"
provisioner: "kubernetes.io/no-provisioner"
volumeBindingMode: "WaitForFirstConsumer"

Crea il PersistentVolume

Gli oggetti PersistentVolume locali presentano limitazioni importanti per quanto riguarda gli upgrade dei nodi, la scalabilità e la scalabilità automatica dei cluster. Prima di creare i volumi, consulta le limitazioni dei PersistentVolume locali per capire in che modo gli eventi del ciclo di vita influiscono sui tuoi dati.

Per creare l'oggetto PersistentVolume, completa i seguenti passaggi per trovare il percorso del link simbolico alla partizione dell'SSD locale, determinare la capacità rimanente esatta e configurare il manifest.

Trova la capacità della partizione

Esegui questo comando sul nodo di destinazione per trovare la capacità esatta del blocco non elaborato rimanente per la partizione.

kubectl debug node/NODE_NAME -it --image=ubuntu -- \
    sh -c 'ls -l /host/dev/disk/by-id/ | grep partition; lsblk -o NAME,SIZE,TYPE'

Sostituisci NODE_NAME con il nome del nodo a cui è collegata l'unità SSD locale.

L'output mostra la mappatura tra i nomi dei dispositivi e i collegamenti simbolici delle partizioni, in modo da poter verificare quale partizione corrisponde a quale dispositivo. Inoltre, elenca i dispositivi a blocchi collegati al nodo e le relative dimensioni.

Ad esempio, se colleghi due SSD locali al nodo e allochi 200 GB allo spazio di archiviazione temporaneo (capacity=200GB), l'output è simile al seguente:

google-local-ssd-partition0 -> /dev/nvme0n1p2
google-local-ssd-partition1 -> /dev/nvme0n2p2
NAME          SIZE TYPE
...
nvme0n1       375G disk
|-nvme0n1p1   100G part
| `-md0     199.9G raid0
`-nvme0n1p2   275G part
nvme0n2       375G disk
|-nvme0n2p1   100G part
| `-md0     199.9G raid0
`-nvme0n2p2   275G part

Prendi nota della mappatura tra il collegamento simbolico google-local-ssd-partition e il nome del dispositivo sottostante, nonché delle dimensioni della partizione. Utilizza la dimensione come PARTITION_SIZE e il percorso del collegamento simbolico come LOCAL_SSD_SYMLINK_PATH nel manifest PersistentVolume.

Ad esempio, nell'output precedente, il collegamento simbolico /dev/disk/by-id/google-local-ssd-partition0 punta alla partizione nvme0n1p2, che ha una dimensione di 275G.

Il comando kubectl debug lascia un pod temporaneo in esecuzione nello spazio dei nomi predefinito. Per evitare che consumi risorse, elimina questo pod eseguendo il seguente comando:

kubectl delete pod DEBUG_POD_NAME

Sostituisci DEBUG_POD_NAME con il nome del pod creato dal comando kubectl debug, che viene stampato quando esegui il comando.

Configura il manifest del PersistentVolume

Configura il manifest del volume con le dimensioni della partizione che hai trovato. Il campo nodeAffinity è obbligatorio per i volumi locali. In questo modo, Kubernetes pianifica i pod che richiedono questo volume sul nodo specifico a cui è collegata fisicamente l'unità SSD locale. L'esempio seguente mostra un manifest per una partizione di un'unità SSD locale a blocchi non formattati:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: PARTITION_SIZE
  accessModes:
  - "ReadWriteOnce"
  volumeMode: "Block"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "LOCAL_SSD_SYMLINK_PATH"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - "NODE_NAME"

Sostituisci quanto segue:

• PARTITION_SIZE: la capacità effettiva del blocco non elaborato rimanente che hai trovato nel primo passaggio. Utilizza il suffisso Gi (ad esempio, 275Gi) in modo che il valore corrisponda esattamente alla capacità della partizione.
• NODE_NAME: il nome del nodo a cui è collegata l'unità SSD locale.
• LOCAL_SSD_SYMLINK_PATH: il percorso del link simbolico alla partizione dell'SSD locale non formattata che hai trovato nel primo passaggio. Per ogni SSD locale collegata al pool di nodi, il sistema operativo host crea un link simbolico per accedere alla capacità rimanente dei blocchi non elaborati. I percorsi seguono un pattern indicizzato su base zero. Ad esempio, se colleghi tre SSD locali, i percorsi dei blocchi non elaborati per le partizioni sono i seguenti:
  • /dev/disk/by-id/google-local-ssd-partition0
  • /dev/disk/by-id/google-local-ssd-partition1
  • /dev/disk/by-id/google-local-ssd-partition2

Crea il PersistentVolumeClaim

Crea un oggetto PersistentVolumeClaim per richiedere il volume. La specifica corrispondente è simile alla seguente:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: "example-local-pvc"
spec:
  accessModes:
  - "ReadWriteOnce"
  volumeMode: "Block"
  storageClassName: "local-storage"
  resources:
    requests:
      storage: PARTITION_SIZE

Utilizza il volume in un pod

Puoi utilizzare l'oggetto PersistentVolume in un pod facendo riferimento all'oggetto PersistentVolumeClaim in una specifica volumeDevices. Di seguito è riportato un manifest del pod di esempio che utilizza la richiesta example-local-pvc:

apiVersion: v1
kind: Pod
metadata:
  name: "example-pod"
spec:
  containers:
  - name: "app"
    image: "ubuntu:22.04"
    command: ["/bin/sh", "-c"]
    args: ["tail -f /dev/null"]
    volumeDevices:
    - name: "raw"
      devicePath: "/dev/xvda"
  volumes:
  - name: "raw"
    persistentVolumeClaim:
      claimName: "example-local-pvc"

Poiché utilizzi il provisioner kubernetes.io/no-provisioner, GKE non esegue automaticamente la pulizia dei volumi locali. Se elimini l'oggetto PersistentVolume, devi cancellare manualmente i dati dal disco sottostante prima che possa essere riutilizzato in sicurezza.

Risoluzione dei problemi

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

Passaggi successivi

• Scopri come utilizzare lo spazio di archiviazione degli SSD locali completamente temporaneo per la memorizzazione nella cache dei workload.
• Scopri come eseguire il provisioning di volumi SSD locali di blocchi completamente non formattati per l'archiviazione di database dedicati ad alte prestazioni.
• Scopri come eseguire il deployment di un'applicazione stateful.