Provisioning e utilizzo di archiviazione a blocchi non elaborati basata su SSD locale

Standard

---

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 in modo che consumino i dati dallo spazio di archiviazione a blocchi non elaborati basato su SSD locale collegato ai nodi del cluster.

L'utilizzo di questa opzione SSD locale ti offre un maggiore controllo sullo spazio di archiviazione sottostante e ti consente di creare la tua cache a livello di nodo per i pod per migliorare le prestazioni delle tue applicazioni. Puoi anche personalizzare questa opzione installando un file system sui dischi SSD locali eseguendo un DaemonSet per configurare RAID e formattare i dischi, se necessario.

Nota: i volumi SSD locali richiedono il tipo di macchina n1-standard-1 o superiore; il tipo di macchina predefinito e2-medium non è supportato. Per scoprire di più, consulta i tipi di macchine nella documentazione di Compute Engine.

Avviso: sconsigliamo di utilizzare l'SSD locale come archiviazione a blocchi non elaborata per le VM ottimizzate per lo spazio di archiviazione (Z3). I dati nell'unità SSD locale dei nodi Z3 potrebbero non essere disponibili durante gli eventi di manutenzione e il recupero dei dati non è garantito dopo la manutenzione. Pertanto, ti consigliamo di utilizzare l'unità SSD locale come spazio di archiviazione temporaneo per i carichi di lavoro in esecuzione sulle VM Z3.

Per scoprire di più sul supporto delle SSD locali per l'accesso a blocchi non elaborati su GKE, consulta Informazioni sulle SSD locali.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Crea un cluster o un pool di nodi con archiviazione a blocchi non elaborati basata su SSD locali

Utilizza gcloud CLI con l'opzione --local-nvme-ssd-block per creare un cluster con archiviazione a blocchi non elaborati basata su SSD locale.

Nota: per utilizzare l'archiviazione a blocchi non elaborati basata su SSD locali, devi configurare manualmente i dispositivi. I dischi SSD locali non sono formattati per RAID. Inoltre, è tua responsabilità garantire la capacità sui nodi e gestire potenziali interruzioni dovute ai carichi di lavoro in co-locazione. Se utilizzi PersistentVolume locale, la pianificazione è integrata. Se non hai bisogno che i dati persistano durante il ciclo di vita del pod o se non hai requisiti di prestazioni speciali, utilizza l'opzione --ephemeral-storage-local-ssd, che dovrebbe essere adatta alla maggior parte dei casi d'uso.

Il comando gcloud CLI che esegui per creare il cluster o il pool di nodi dipende dalla generazione della serie di macchine a cui appartiene il tipo di macchina che utilizzi. 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'opzione --local-nvme-ssd-block count=NUMBER_OF_DISKS. L'opzione specifica il numero di dischi SSD locali da collegare a ciascun nodo. Il numero massimo varia in base al tipo di macchina e alla regione.

Per creare un cluster:

gcloud container clusters create CLUSTER_NAME \
    --local-nvme-ssd-block 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 dischi SSD locali da eseguire il provisioning su ogni nodo. Il numero massimo di dischi varia in base al tipo di macchina e alla regione.
• MACHINE_TYPE: il tipo di macchina di prima o seconda generazione da utilizzare. La specifica di questo campo è obbligatoria, perché non puoi utilizzare le unità SSD locali con il tipo e2-medium predefinito.
• CHANNEL_NAME: un canale di rilascio che include le versioni di GKE successive alla 1.25.3-gke.1800.

Terza generazione

Se utilizzi un tipo di macchina di una serie di macchine di 3ª generazione, utilizza l'opzione --local-nvme-ssd-block, senza un campo di conteggio, per creare un cluster. GKE esegue automaticamente il provisioning della capacità dell'unità SSD locale per il tuo cluster in base alla forma della VM. Il numero massimo varia in base al tipo di macchina e alla regione.

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --cluster-version CLUSTER_VERSION \
    --local-nvme-ssd-block

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster.
• MACHINE_TYPE: il tipo di macchina da utilizzare da una serie di macchine di terza generazione.
• CLUSTER_VERSION: una versione del cluster GKE che supporta l'SSD locale sui tipi di macchine di una serie di macchine di 3ª generazione.

Crea un pool di nodi con SSD locale

1ª o 2ª generazione

Per creare un pool di nodi che utilizza i dischi SSD locali per l'accesso a blocchi non elaborati, esegui il seguente comando:

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

Sostituisci quanto segue:

• POOL_NAME: il nome del nuovo pool di nodi.
• CLUSTER_NAME: il nome del cluster.
• MACHINE_TYPE: il tipo di macchina di prima o seconda generazione da utilizzare. La specifica di questo campo è obbligatoria, poiché l'SSD locale non può essere utilizzato con il tipo e2-medium predefinito.
• NUMBER_OF_DISKS: il numero di dischi SSD locali da eseguire il provisioning su ogni nodo. Il numero massimo di dischi varia in base al tipo di macchina e alla regione.

Terza generazione

Se utilizzi un tipo di macchina di una serie di macchine di terza generazione, utilizza l'opzione --local-nvme-ssd-block, senza un campo di conteggio, per creare un cluster:

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

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 un tipo di macchina di terza generazione.
• NODE_VERSION: una versione del pool di nodi GKE che supporta l'SSD locale sui tipi di macchine di una serie di macchine di 3ª generazione.

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

kubectl describe node NODE_NAME

Per ogni SSD locale collegata al pool di nodi, il sistema operativo host crea un link simbolico (symlink) per accedere al disco in una cartella ordinale e un symlink con un identificatore univoco universale (UUID). Ad esempio, se crei un pool di nodi con tre SSD locali utilizzando l'opzione --local-nvme-ssd-block, il sistema operativo host crea i seguenti link simbolici per i dischi:

• /dev/disk/by-id/google-local-ssd-block0
• /dev/disk/by-id/google-local-ssd-block1
• /dev/disk/by-id/google-local-ssd-block2

Di conseguenza, il sistema operativo host crea anche i seguenti link simbolici con UUID per i dischi:

• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID1
• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID2
• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID3

In questo modo, è possibile accedere ai dischi utilizzando un identificatore univoco.

Accedere ai volumi SSD locali

L'esempio seguente mostra come accedere allo spazio di archiviazione a blocchi non elaborato basato su SSD locale.

PersistentVolume locali

I volumi SSD locali possono essere montati come pod utilizzando gli PersistentVolumes.

Puoi creare PersistentVolume da SSD locale creando manualmente un PersistentVolume o eseguendo il provisioning statico del volume locale.

Limitazioni dei PersistentVolume locali

Nota: quando utilizzi i canali di rilascio, l'upgrade automatico e la riparazione automatica non possono essere disattivati. Non è consigliabile utilizzare PersistentVolume locali con cluster in un canale di rilascio.

• La scalabilità automatica del cluster e il provisioning dinamico non sono supportati con i PersistentVolume locali.

• L'upgrade di un cluster GKE o la riparazione dei nodi elimina le istanze Compute Engine, con conseguente eliminazione di tutti i dati sui dischi SSD locali.

• Non abilitare gli upgrade automatici dei nodi o la riparazione automatica dei nodi per i cluster o i pool di nodi che utilizzano l'SSD locale per i dati permanenti. Devi prima eseguire il backup degli dati dell'applicazione, quindi ripristinarli in un nuovo cluster o in un nuovo pool di nodi.

Attenzione: per i cluster e i pool di nodi creati con la console Google Cloud, l'upgrade automatico dei nodi è abilitato per impostazione predefinita. Per disattivare questa opzione, consulta gli upgrade automatici dei nodi.

• Gli oggetti PersistentVolume locali non vengono ripuliti automaticamente quando un nodo viene eliminato, sottoposto ad upgrade, riparato o ridotto di dimensioni. Ti consigliamo di eseguire periodicamente la scansione ed eliminare gli oggetti Local PersistentVolume obsoleti associati ai nodi eliminati.

Crea manualmente il PersistentVolume

Puoi creare manualmente un PersistentVolume per ogni SSD locale su ogni nodo del cluster.

Utilizza il campo nodeAffinity in un oggetto PersistentVolume per fare riferimento a un SSD locale su un nodo specifico. L'esempio seguente mostra la specifica del volume permanente per l'unità SSD locale sui nodi che eseguono Linux:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - "ReadWriteOnce"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "/mnt/disks/ssd0"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - "gke-test-cluster-default-pool-926ddf80-f166"

In questo esempio, i dischi SSD locali sono configurati manualmente per RAID e formattati, quindi montati su /mnt/disks/ssd0 sul nodo gke-test-cluster-default-pool-926ddf80-f166. Il campo nodeAffinity viene utilizzato per contribuire ad assegnare i carichi di lavoro ai nodi con SSD locali configurati manualmente per RAID. Se il cluster ha un solo nodo o se hai configurato RAID per tutti i nodi, il campo nodeAffinity non è necessario.

La specifica PersistenVolumeClaim corrispondente è la seguente:

  kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: ssd-local-claim
  spec:
    accessModes:
    - ReadWriteOnce
    storageClassName: local-storage
    resources:
      requests:
        storage: 37Gi

Se elimini il volume persistente, devi cancellare manualmente i dati dal disco.

Esegui il provisioner statico del volume locale

Nota: il provisioning statico dei volumi locali è un progetto della community e non è gestito o supportato da Google. Inoltre, non può essere utilizzato con Windows.

Puoi creare automaticamente PersistentVolume per l'SSD locale utilizzando il provisioning statico del volume locale. Il provisioning è un DaemonSet che gestisce i dischi SSD locali su ogni nodo, crea ed elimina i relativi PersistentVolume e ripulisce i dati sui dischi SSD locali quando il PersistentVolume viene rilasciato.

Per eseguire il provisioner statico del volume locale:

1. Utilizza un DaemonSet per configurare RAID e formattare i dischi:

   1. Scarica la specifica gke-daemonset-raid-disks.yaml.

   2. Esegui il deployment del DaemonSet dei dischi RAID. Il DaemonSet imposta un array RAID 0 su tutti i dischi SSD locali e formatta il dispositivo in un file system ext4.

      kubectl create -f gke-daemonset-raid-disks.yaml
      

2. Scarica la specifica gke-nvme-ssd-block-raid.yaml e modifica i campi dello spazio dei nomi della specifica in base alle esigenze.

   La specifica include le seguenti risorse:

   • AccountServiceAccount per il provisioning
   • ClusterRole e ClusterRoleBindings per le autorizzazioni per:
     • Creare ed eliminare oggetti PersistentVolume
     • Recupera gli oggetti Node
   • ConfigMap con le impostazioni del provisioning per GKE
   • DaemonSet per l'esecuzione del provisioning

3. Esegui il deployment del provisioning:

   kubectl create -f gke-nvme-ssd-block-raid.yaml
   

   Una volta eseguito correttamente, il provisioning crea un oggetto PersistentVolume per il dispositivo RAID SSD locale nel cluster.

4. Salva il seguente manifest PersistentVolumeClaim come provisioner-pvc-example.yaml:

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: PVC_NAME
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: 50Gi
     storageClassName: nvme-ssd-block
   

   Sostituisci PVC_NAME con il nome del tuo PersistentVolumeClaim.

5. Crea il PersistentVolumeClaim:

   kubectl create -f provisioner-pvc-example.yaml
   

6. Salva il seguente manifest del pod come provisioner-pod-example.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
   spec:
     containers:
     - name: "shell"
       image: "ubuntu:14.04"
       command: ["/bin/sh", "-c"]
       args: ["echo 'hello world' > /cache/test.txt && sleep 1 && cat /cache/test.txt && sleep 3600"]
       volumeMounts:
       - mountPath: /cache
         name: local-ssd-storage
     volumes:
     - name: local-ssd-storage
       persistentVolumeClaim:
         claimName: PVC_NAME
   

   Sostituisci POD_NAME con il nome del pod.

7. Crea il pod:

   kubectl create -f provisioner-pod-example.yaml
   

Attivare l'associazione del volume ritardata

Nota: se hai seguito le istruzioni per eseguire il provisioner statico del volume locale, il relativo manifest fornisce una definizione StorageClass appropriata. Se utilizzi il provisioning statico dei volumi locali, non devi eseguire i passaggi descritti in questa sezione.

Per una pianificazione migliorata, ti consigliamo di creare anche un StorageClass con volumeBindingMode: WaitForFirstConsumer. Ciò ritarda l'associazione di PersistentVolumeClaim fino alla pianificazione del pod, in modo che venga scelta un'unità SSD locale da un nodo appropriato che può eseguire il pod. Questo comportamento di pianificazione migliorato prende in considerazione le richieste di CPU e memoria dei pod, l'affinità dei nodi, l'affinità e l'anti-affinità dei pod e più richieste di claim volume permanente, oltre a indicare quali nodi dispongono di unità SSD locali disponibili, quando si seleziona un nodo per un pod eseguibile.

Questo esempio utilizza la modalità di associazione del volume ritardata:

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

Per creare una classe di archiviazione con il vincolo ritardato, salva il manifest YAML in un file locale e applicalo al cluster utilizzando il seguente comando:

kubectl apply -f filename

Risoluzione dei problemi

Per le istruzioni per la risoluzione dei problemi, consulta Risolvere i problemi di archiviazione in GKE.

Passaggi successivi

• Scopri di più sui pool di nodi.