Provisioning e utilizzo dell'archiviazione a blocchi non elaborati supportata da SSD locali

Standard

---

Questa pagina spiega come eseguire il provisioning di spazio di archiviazione SSD locale su Google Kubernetes Engine (GKE) e come configurare carichi di lavoro per consumare dati da SSD locali supportati. archiviazione a blocchi non elaborata collegata ai nodi nel tuo 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 offrire prestazioni migliori alle tue applicazioni. Puoi anche personalizzare questa opzione l'installazione di un file system su dischi SSD locali eseguendo un DaemonSet per configurare RAID formattare i dischi in base alle esigenze.

Nota: i volumi SSD locali richiedono un tipo di macchina n1-standard-1 o superiore; il valore predefinito tipo di macchina 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'SSD locale nei 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 archiviazione temporanea per i carichi di lavoro in esecuzione sulle VM Z3.

Per saperne di più sul supporto degli SSD locali per l'accesso a blocchi non elaborati su GKE, consulta l'articolo Informazioni sulle unità SSD locali.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Attiva l'API Google Kubernetes Engine.
Abilita 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, scarica la versione più recente eseguendo gcloud components update.
  Nota: per gcloud CLI esistente di installazione, assicurati di impostare compute/region e compute/zone proprietà. Se imposti località predefinite, puoi evitare errori in gcloud CLI come i seguenti: 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 con archiviazione a blocchi non elaborati supportati da SSD locali.

Nota: per utilizzare l'archiviazione a blocchi non elaborati supportata da SSD locali, è necessario configurare manualmente dai dispositivi. I dischi SSD locali non sono formattati per RAID. Inoltre, sei responsabile per garantire la capacità sui nodi e gestire potenziali interruzioni dei carichi di lavoro in co-location. Se utilizzi PersistentVolume locale, la pianificazione è integrata. Se non è necessario che i dati rimangano memorizzati nel pod o se non hai prestazioni speciali utilizza l'opzione --ephemeral-storage-local-ssd che dovrebbe adattarsi 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, tipi di macchina N1 e N2 appartengono rispettivamente a una serie di macchine di prima e seconda generazione, mentre C3 che appartengono a serie di macchine di terza generazione.

Crea un cluster con SSD locale

1a o 2a 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 sul provisioning su ogni nodo. Il numero massimo di dischi varia in base al tipo di macchina e alla regione.
• MACHINE_TYPE: prima o seconda generazione e il tipo di macchina da utilizzare. Questo campo è obbligatorio perché non puoi usano gli SSD locali con il tipo predefinito e2-medium.
• 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 terza generazione, utilizza l'opzione --local-nvme-ssd-block, senza un campo di conteggio, per creare un cluster. GKE esegue automaticamente il provisioning della capacità SSD locale 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 di terze parti.
• CLUSTER_VERSION: una versione del cluster GKE che supporta SSD locale su tipi di macchine da un di terze parti.

Crea un pool di nodi con SSD locale

1a o 2a 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. È obbligatorio specificare questo campo perché l'SSD locale non può da utilizzare con il tipo predefinito e2-medium.
• NUMBER_OF_DISKS: il numero di dischi SSD locali da su ciascun nodo. Il numero massimo di dischi varia in base al tipo di macchina e alla regione.

3a 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 una di terze parti.
• 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'istruzione cloud.google.com/gke-local-nvme-ssd=true dell'etichetta. 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 collegamenti 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 collegamenti simbolici con UUID 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.

Accedi a 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 oggetti PersistentVolume.

Puoi creare oggetti PersistentVolume da un SSD locale creando manualmente un PersistentVolume o eseguendo il provisioner statico per il volume locale.

Limitazioni degli oggetti PersistentVolume locali

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

• Scalabilità automatica dei cluster e il provisioning dinamico e non sono supportati dai 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 attivare gli upgrade automatici dei nodi o la riparazione automatica dei nodi per di cluster o pool di nodi utilizzando SSD locale per i dati permanenti. Devi eseguire il backup prima i dati dell'applicazione e poi ripristinali in un nuovo cluster o nodo piscina.

Attenzione :i cluster e i pool di nodi creati con la console Google Cloud includono upgrade automatico abilitato per impostazione predefinita. Per disattivarla, consulta upgrade automatici dei nodi.

• Gli oggetti PersistentVolume locali non vengono ripuliti automaticamente quando viene eliminati, sottoposti a upgrade, riparati o sottoposti a scale down. Ti consigliamo di eseguire periodicamente la scansione ed eliminare gli oggetti Local PersistentVolume obsoleti associati ai nodi eliminati.

crea manualmente l'oggetto PersistentVolume

Puoi creare manualmente un PersistentVolume per ogni SSD locale nodo nel tuo 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 assegnare 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 ha il seguente aspetto:

  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 provisioner statico per il volume locale è un progetto della community e non gestiti o supportati da Google. Inoltre, non può essere utilizzato con Windows.

Puoi creare automaticamente oggetti PersistentVolume per SSD locale utilizzando provisioner statico per volume. 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 viene rilasciato il PersistentVolume.

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 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 tue esigenze.

   La specifica include le seguenti risorse:

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

3. Esegui il deployment del provisioner:

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

   Dopo aver eseguito correttamente l'esecuzione, il provisioner crea un PersistentVolume per il dispositivo SSD locale RAID 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 dell'oggetto PersistentVolumeClaim.

5. Crea l'oggetto 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 migliore, ti consigliamo di creare anche un oggetto StorageClass 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 un oggetto StorageClass con associazione ritardata, salva il manifest YAML in un e applicarlo al cluster utilizzando il comando seguente:

kubectl apply -f filename

Risoluzione dei problemi

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

Passaggi successivi

• Scopri di più sui pool di nodi.