Esegui il provisioning e utilizza l'archiviazione a blocchi non elaborati 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 a blocchi non elaborati supportato da SSD locali 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, in modo da offrire prestazioni migliori per le 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 in base alle esigenze.

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

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 a blocchi non elaborati supportato da SSD locali

Utilizza gcloud CLI con l'opzione --local-nvme-ssd-block per creare un cluster con spazio di archiviazione a blocchi non elaborati supportato da SSD locali.

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 stai utilizzando. 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 locali

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 ogni 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 di cui 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 gli SSD locali con il tipo e2-medium predefinito.
  • CHANNEL_NAME: un canale di rilascio che include versioni di GKE successive alla 1.25.3-gke.1800.

3ª o 4ª generazione

Se utilizzi un tipo di macchina di una serie di macchine di terza o quarta 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 per il 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 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 locali

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, perché gli SSD locali non possono essere utilizzati con il tipo e2-medium predefinito.
  • NUMBER_OF_DISKS: il numero di dischi SSD locali di cui eseguire il provisioning su ogni nodo. Il numero massimo di dischi varia in base al tipo di macchina e alla regione.

3ª o 4ª generazione

Se utilizzi un tipo di macchina di una serie di macchine di terza o quarta 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:

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 collegato al pool di nodi, il sistema operativo host crea un collegamento 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 symlink 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, i dischi possono essere accessibili utilizzando un identificatore univoco.

Accedere ai volumi SSD locali

L'esempio seguente mostra come accedere allo spazio di archiviazione a blocchi non elaborati supportato da SSD locali.

PersistentVolume locali

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

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

Limitazioni dei PersistentVolume locali

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

Creare manualmente 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 PersistentVolume per gli SSD locali 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 vengono configurati manualmente per RAID e formattati, quindi montati in /mnt/disks/ssd0 sul nodo gke-test-cluster-default-pool-926ddf80-f166. Il campo nodeAffinity viene utilizzato per assegnare i carichi di lavoro ai nodi con SSD locali configurati manualmente per RAID. Se hai un solo nodo nel cluster o se hai configurato RAID per tutti i nodi, il campo nodeAffinity non è necessario.

La specifica PersistentVolumeClaim corrispondente è simile alla seguente:

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

Se elimini PersistentVolume, devi cancellare manualmente i dati dal disco.

Eseguire il provisioner statico del volume locale

Puoi creare automaticamente PersistentVolume per gli SSD locali utilizzando il provisioner statico del volume locale. Il provisioner è un DaemonSet che gestisce i dischi SSD locali su ogni nodo, crea ed elimina i PersistentVolume e pulisce 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 gke-daemonset-raid-disks.yaml specifica.

    2. Esegui il deployment di DaemonSet dei dischi RAID. 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 queste risorse:

    • ServiceAccount per il provisioner
    • ClusterRole e ClusterRoleBinding per le autorizzazioni a:
      • Creare ed eliminare oggetti PersistentVolume
      • Recuperare oggetti Node
    • ConfigMap con le impostazioni del provisioner per GKE
    • DaemonSet per l'esecuzione del provisioner

  3. Esegui il deployment del provisioner:

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

    Una volta eseguito correttamente il provisioner, crea un oggetto 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 di PersistentVolumeClaim.

  5. Crea 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

Abilitare l'associazione ritardata dei volumi

Per una pianificazione migliore, ti consigliamo di creare anche una StorageClass con volumeBindingMode: WaitForFirstConsumer. In questo modo, l'associazione PersistentVolumeClaim viene ritardata fino alla pianificazione del pod, in modo che venga scelto un SSD locale da un nodo appropriato in grado di eseguire il pod. Questo comportamento di pianificazione avanzato considera le richieste di CPU e memoria del pod, l'affinità nodo, l'affinità e l'anti-affinità del pod e più richieste PersistentVolumeClaim, nonché i nodi con SSD locali disponibili, quando seleziona un nodo per un pod eseguibile.

Questo esempio utilizza la modalità di associazione ritardata dei volumi:

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

Per creare una StorageClass con associazione ritardata, salva il manifest YAML in un file locale e applicalo al cluster utilizzando il seguente comando:

kubectl apply -f filename

Risoluzione dei problemi

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

Passaggi successivi