Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizzo di SSD locali

Questa pagina fornisce una panoramica del supporto degli SSD locali in Kubernetes e di come utilizzare gli SSD locali con Google Kubernetes Engine (GKE).

Panoramica

Le unità SSD locali offrono uno spazio di archiviazione temporaneo ad alte prestazioni per tutti i nodi del cluster. Le unità SSD locali offrono una velocità effettiva superiore e una latenza inferiore rispetto ai dischi standard. Le unità SSD locali funzionano bene nei carichi di lavoro che offrono memorizzazione ed elaborazione nella cache locale.

Puoi creare pool di nodi con SSD locali all'interno dei limiti dei tipi di macchine dei tuoi cluster e delle quote dei tuoi progetti.

I dati scritti su un'unità SSD locale sono effimeri e non persistono quando il nodo viene eliminato, riparato, sottoposto a upgrade o riscontrato un errore irreversibile.
Un'unità SSD locale è collegata a un solo nodo e i nodi stessi sono effimeri. È possibile pianificare un carico di lavoro su un nodo diverso in qualsiasi momento.

Per ulteriori informazioni sui vantaggi e sulle limitazioni delle unità SSD locali, come le prestazioni e il numero consentito di unità SSD per tipo di macchina, consulta la sezione SSD locali nella documentazione di Compute Engine.

Creazione di un cluster con SSD locali

Puoi creare un cluster o aggiornarlo per utilizzare gli SSD locali utilizzando Google Cloud Console o l'interfaccia a riga di comando di Google Cloud.

console

Puoi creare un cluster o un pool di nodi con SSD locali dal menu GKE nella console.

Per creare un cluster in cui il pool predefinito utilizza SSD locali:

Vai alla pagina Google Kubernetes Engine nella console.

Vai a Google Kubernetes Engine
Fai clic su Crea.
Configura il cluster come preferisci.
Nel riquadro di navigazione, in Pool di nodi, fai clic su default-pool.
Nel campo Numero di nodi, inserisci 2.
Nel riquadro di navigazione, in default-pool, fai clic su Nodi.
Inserisci un numero assoluto di dischi SSD locali per nodo.
Fai clic su Crea.

Per creare un pool di nodi con dischi SSD locali in un cluster esistente:

Vai alla pagina Google Kubernetes Engine nella console.

Vai a Google Kubernetes Engine
Nell'elenco dei cluster, fai clic sul nome del cluster che vuoi modificare.
Fai clic su Aggiungi pool di nodi.
Nel campo Numero di nodi, inserisci 1.
Nel riquadro di navigazione, fai clic su Nodi.
Inserisci un numero assoluto di dischi SSD locali per nodo.
Fai clic su Crea.

gcloud

Per creare un cluster o un pool di nodi con SSD locali utilizzando gcloud, specifica il flag --local-ssd count. --local-ssd-count specifica il numero di SSD locali da creare per nodo. Il numero massimo varia in base al tipo di macchina e all'area geografica. Quando vengono creati i nodi, le unità SSD locali vengono automaticamente formattate e montate sul filesystem del nodo in punti di montaggio come /mnt/disks/ssd0 per il primo disco, /mnt/disks/ssd1 per il secondo disco e così via.

Per creare un cluster in cui il pool predefinito utilizza i dischi SSD locali, esegui il comando seguente:

gcloud container clusters create CLUSTER_NAME \
  --num-nodes 2 \
  --local-ssd-count NUMBER_OF_DISKS \
  --machine-type MACHINE_TYPE

Per creare un pool di nodi con dischi SSD locali in un cluster esistente, esegui questo comando:

gcloud container node-pools create POOL_NAME \
  --cluster CLUSTER_NAME \
  --num-nodes 1 \
  --local-ssd-count NUMBER_OF_DISKS \
  --machine-type MACHINE_TYPE

Sostituisci quanto segue:

CLUSTER_NAME: il nome del cluster.
POOL_NAME: il nome del nuovo pool di nodi.
NUMBER_OF_DISKS: numero di dischi SSD locali di cui eseguire il provisioning su ogni nodo.
MACHINE_TYPE: tipo di macchina da utilizzare, poiché le SSD locali non possono essere utilizzate con il tipo e2-medium predefinito

Creazione di un pool di nodi utilizzando l'archiviazione temporanea sulle unità SSD locali

A partire dalla 1.18, un pool di nodi GKE può essere configurato per utilizzare l'SSD locale con un'interfaccia NVMe per l'archiviazione temporanea locale.

Per creare un pool di nodi utilizzando l'archiviazione temporanea sulle unità SSD locali, esegui il comando seguente:

gcloud beta 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: numero di dischi SSD locali di cui eseguire il provisioning su ogni nodo. Questi SSD vengono combinati in un unico volume logico durante la configurazione del nodo. Il numero massimo di dischi varia in base al tipo di macchina e all'area geografica. Tieni presente che alcune capacità SSD locali sono riservate per l'utilizzo in base al sistema.
MACHINE_TYPE: tipo di macchina da utilizzare, poiché le SSD locali non possono essere utilizzate con il tipo e2-medium predefinito.

I nodi nel pool di nodi vengono creati con un'etichetta cloud.google.com/gke-ephemeral-storage-local-ssd. Per verificare le etichette, esegui il comando seguente:

kubectl describe node NODE_NAME

Formattazione delle unità SSD locali per i cluster Windows Server

Quando utilizzi gli SSD locali con i cluster che eseguono i pool di nodi Windows Server, devi accedere al nodo e formattare il disco prima di utilizzarlo. Nell'esempio seguente, il disco SSD locale è formattato con il file system NTFS. Puoi anche creare directory sotto il disco. In questo esempio, le directory sono sotto il 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-ss

Utilizzo di SSD locali

La seguente sezione spiega come utilizzare gli SSD locali con GKE.

Puoi accedere agli SSD locali in uno dei seguenti modi:

Utilizza l'archiviazione temporanea come volume emptyDir (disponibile in beta nella versione 1.18 e successive di GKE), una soluzione consigliata per la maggior parte dei casi, incluse le applicazioni che richiedono spazio temporaneo temporaneo ad alte prestazioni.

Questa funzionalità configura un pool di nodi per il montaggio dello spazio di archiviazione temporaneo dei nodi su SSD locali con un'interfaccia NVMe. I pod che utilizzano emptyDir utilizzano in modo trasparente l'SSD locale, ma questo è vero per tutti i pod su tutti i nodi nel pool. Per alcuni pod non è possibile usare i volumi emptyDir locali di SSD e altri per utilizzare emptyDir convenzionali. Per i carichi di lavoro che non devono utilizzare volumi emptyDir convenzionali, pianificali su un pool di nodi diverso.
Utilizza i volumi hostpath, consigliati per:
- Carichi di lavoro che utilizzano i DaemonSet.
- Carichi di lavoro che utilizzano pool di nodi dedicati. È necessario accedere a tutte le SSD locali nello stesso percorso per tutte le istanze di un DaemonSet.
Utilizzare local PersistentVolumes, che è consigliato per:
- Carichi di lavoro che utilizzano gli oggetti StatefulSet e volumeClaimTemplate.
- Carichi di lavoro che condividono pool di nodi. Ogni SSD locale può essere prenotato tramite un oggetto PersistentVolumeClaim e percorsi host specifici non sono codificati direttamente nella specifica del pod.
- Pod che richiedono la gravità dei dati alla stessa SSD locale. Un pod è sempre pianificato sullo stesso nodo del suo PersistentVolume locale.
Nota: poiché le unità SSD locali sottostanti sono risorse temporanee, i dati che archiviano non sono durevoli. Dovresti eseguire backup frequenti su spazio di archiviazione durevole (come dischi permanenti o Cloud Storage) e repliche a livello di area geografica, per ridurre al minimo il rischio di perdita di dati durante il ciclo di vita del cluster o le operazioni del ciclo di vita delle applicazioni.

Esempio con utilizzo di spazio di archiviazione temporaneo come volume emptyDir

È possibile configurare un pool di nodi GKE in modo che utilizzi un'unità SSD locale per l'archiviazione temporanea, inclusi i volumi emptyDir.

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

Quando scegli la richiesta di risorsa di archiviazione temporanea, tieni presente la funzionalità SSD locale riservata per l'utilizzo del sistema.

apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
spec:
  containers:
    - name: CONTAINER_NAME
      image: "k8s.gcr.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: {}

Esempi di utilizzo dei volumi hostPath

I seguenti esempi mostrano come utilizzare i volumi hostPath per Windows e Linux.

Linux

Se crei un pool di nodi con tre SSD locali, il sistema operativo host monta i dischi su /mnt/disks/ssd0, /mnt/disks/ssd1 e /mnt/disks/ssd2. I container Kubernetes accedono ai dischi utilizzando il parametro hostPath definito nel file di configurazione del tuo oggetto.

Questo file di configurazione del pod di esempio fa riferimento a un'unità SSD locale: /mnt/disks/ssd0:

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "shell"
    image: "ubuntu:14.04"
    command: ["/bin/sh", "-c"]
    args: ["echo 'hello world' > /test-ssd/test.txt && sleep 1 && cat /test-ssd/test.txt"]
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    hostPath:
      path: "/mnt/disks/ssd0"
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"

Windows

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "test"
    image: "mcr.microsoft.com/windows/servercore/iis"
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    hostPath:
      path: "d:\\test-ssd"
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"
    kubernetes.io/os: windows

Esempi di utilizzo degli oggetti PersistentVolume locali

Le unità SSD locali possono essere specificate come PersistentVolume.

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

Limitazioni

Attualmente la scalabilità automatica dei cluster e il provisioning dinamico non sono supportati con gli oggetti PersistentVolume locali.
L'upgrade di un cluster GKE o la riparazione di nodi elimina le istanze di Compute Engine, eliminando anche tutti i dati sulle 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 SSD locali per i dati permanenti. Devi prima eseguire il backup dei dati dell'applicazione, quindi ripristinare i dati in un nuovo cluster o pool di nodi. Tieni presente che quando utilizzi canali di rilascio, l'upgrade e la riparazione automatica non possono essere disattivati. Non è consigliabile utilizzare volumi permanenti locali con cluster in un canale di rilascio.

Gli oggetti PersistentVolume locali non vengono ripuliti automaticamente quando un nodo viene eliminato, aggiornato, riparato o ridotto. Ti consigliamo di eseguire periodicamente la scansione e l'eliminazione di oggetti PersistentVolume locali inattivi associati ai nodi eliminati.

Creazione manuale dell'oggetto PersistentVolume

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

Utilizza il campo nodeAffinity in un oggetto PersistentVolume per fare riferimento a un SSD locale su un nodo specifico. Ad esempio, il seguente esempio di Linux è una specifica PersistentVolume per un'unità SSD locale montata in /mnt/disks/ssd0 sul nodo gke-test-cluster-default-pool-926ddf80-f166:

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"

Windows

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ssd-local-pv
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: "d:\\test-ssd"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - gke-gke-cluster-windows-dds-2263bc7c-wq6m

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

Ora puoi creare un pod per accedere al disco. Per assicurarti che i tuoi pod siano pianificati correttamente sui nodi Windows Server, devi aggiungere un selettore nodo alla specifica dei pod:

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "test"
    image: "mcr.microsoft.com/windows/servercore/iis"
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    persistentVolumeClaim:
      claimName: ssd-local-claim
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"
  tolerations:
  - key: "node.kubernetes.io/os"
    value: "windows"
    operator: "Equal"
    effect: "NoSchedule"

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

Esecuzione del provisioner statico del volume locale

Puoi creare volumi permanenti per SSD locali utilizzando automaticamente il provisioner statico del volume locale. Il provisioner è un DaemonSet che gestisce gli SSD locali su ogni nodo, li crea ed elimina i PersistentVolume e pulisce i dati sull'SSD locale al momento del rilascio del PersistentVolume.

Per eseguire il provisioner statico del volume locale:

Scarica la specifica gke.yaml dal repository sig-storage-local-static-provisioner e modifica i campi namespace della specifica in base alle tue esigenze.

La specifica include:
- ServiceAccount per il provisioner
- ClusterRole e ClusterRoleBinding per le autorizzazioni relative a:
  - Crea ed elimina oggetti PersistentVolume
  - Recupera oggetti nodo
- ConfigMap con impostazioni provisioner per GKE
- DaemonSet per l'esecuzione del provisioner
Esegui il deployment del provisioner:
```
kubectl apply -f gke.yaml
```

Una volta eseguito correttamente il provisioner, viene creato un oggetto PersistentVolume per ogni SSD locale nel cluster.

Attivazione dell'associazione di volumi ritardati

Per una pianificazione migliore, ti consigliamo di creare anche un oggetto StorageClass con volumeBindingMode: WaitForFirstConsumer. Questo ritarda l'associazione PersistentVolumeClaim fino alla pianificazione del pod, in modo che un'unità SSD locale venga scelta da un nodo appropriato che può eseguire il pod. Quando si seleziona un nodo per un pod eseguibile, questo comportamento di pianificazione avanzato considera richieste CPU e memoria dei pod, affinità nodo, affinità pod e anti-affinità e più richieste PersistentVolumeClaim, nonché quali nodi hanno SSD locali disponibili.

In questo esempio viene utilizzata la modalità di associazione del volume ritardato:

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

Quando utilizzi cluster con pool di nodi Windows Server, devi creare un oggetto StorageClass, perché StorageClass predefinita utilizza ext4 come tipo di file system, che funziona solo per i container Linux.

Il seguente file YAML utilizza un disco permanente di Compute Engine con NTFS come tipo di archiviazione file. Puoi utilizzare questo oggetto StorageClass quando lavori con i cluster Windows.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storageclass-name
parameters:
  type: pd-standard
  fstype: NTFS
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

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

kubectl apply -f filename

Passaggi successivi

Scopri di più sui pool di nodi.