Questa pagina spiega come eseguire il provisioning dell'archiviazione SSD locale sui cluster Google Kubernetes Engine (GKE) e come configurare i carichi di lavoro in modo da utilizzare i dati dall'archiviazione a blocchi non elaborata supportata da SSD locali e collegata ai nodi nel 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 al fine di offrire prestazioni migliori per le tue applicazioni. Puoi personalizzare questa opzione anche installando un file system su dischi SSD locali eseguendo un DaemonSet per configurare il 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à, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo
gcloud components update
.
Crea un cluster o un pool di nodi con archiviazione a blocchi non elaborata supportata da SSD locali
Usa gcloud CLI con l'opzione --local-nvme-ssd-block
per creare un cluster con archiviazione a blocchi non elaborata supportata da SSD locali.
Il comando gcloud CLI che esegui per creare il cluster o il pool di nodi dipende dalla generazione di 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.
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, crei 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 di cui eseguire il provisioning su ciascun 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 SSD locali con il tipo predefinitoe2-medium
.CHANNEL_NAME
: un canale di rilascio che include versioni di GKE successive alla 1.25.3-gke.1800.
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.
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 di una serie di macchine di terza generazione.CLUSTER_VERSION
: una versione del cluster GKE che supporta SSD locali su tipi di macchine di una serie di macchine di terza generazione.
Crea un pool di nodi con SSD locale
1a o 2a generazione
Per creare un pool di nodi che utilizzi dischi SSD locali per l'accesso ai blocchi non elaborati, esegui questo 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é non è possibile utilizzare SSD locale con il tipo predefinitoe2-medium
.NUMBER_OF_DISKS
: il numero di dischi SSD locali di cui eseguire il provisioning 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 un tipo di macchina di terza generazione.NODE_VERSION
: una versione del pool di nodi GKE che supporta gli SSD locali su tipi di macchine di una serie di macchine di terza 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 questo comando:
kubectl describe node NODE_NAME
Per ogni SSD locale collegato al pool di nodi, il sistema operativo host crea un collegamento simbolico (link simbolico) per accedere al disco in una cartella ordinale e un collegamento simbolico 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 gli 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 ti assicuri che i dischi siano accessibili tramite un identificatore univoco.
Accesso ai volumi SSD locali
L'esempio seguente mostra come accedere all'archiviazione a blocchi non elaborata supportata da SSD locali.
PersistentVolume locali
I volumi SSD locali possono essere montati come pod utilizzando PersistentVolumes.
Puoi creare oggetti PersistentVolume da SSD locale creando manualmente un PersistentVolume o eseguendo il provisioner statico del volume locale.
Limitazioni degli oggetti PersistentVolume locali
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 dei nodi elimina le istanze di Compute Engine, il che comporta anche l'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 utilizzando SSD locale per i dati permanenti. Devi prima eseguire il backup dei dati dell'applicazione e poi ripristinarli in un nuovo cluster o pool di nodi.
- Gli oggetti PersistentVolume locali non vengono ripuliti automaticamente quando un nodo viene eliminato, eseguito l'upgrade, riparato o fatto lo scale down. Ti consigliamo di scansionare ed eliminare periodicamente gli oggetti PersistentVolume locali inattivi associati ai nodi eliminati.
Creare manualmente il 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. L'esempio seguente mostra la specifica del 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 il RAID e formattati, quindi montati in /mnt/disks/ssd0
nel 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 il RAID. Se nel cluster è presente un solo nodo o se hai configurato il 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 PersistentVolume, devi cancellare manualmente i dati dal disco.
Esegui il provisioner statico del volume locale
Puoi creare automaticamente oggetti PersistentVolume per SSD locale 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 per loro e ripulisce i dati sui dischi SSD locali quando il PersistentVolume viene rilasciato.
Per eseguire il provisioner statico del volume locale:
Utilizza un DaemonSet per configurare il RAID e formattare i dischi:
- Scaricare la specifica di
gke-daemonset-raid-disks.yaml
. Esegui il deployment dei dischi RAID del DaemonSet. 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
- Scaricare la specifica di
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:
- ServiceAccount per il provisioner
- ClusterRole e ClusterRoleBinding per le autorizzazioni:
- Creazione ed eliminazione di oggetti PersistentVolume
- Recupero oggetti nodo
- ConfigMap con impostazioni del provisioner per GKE
- DaemonSet per l'esecuzione del provisioner
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.
Salva il seguente manifest di 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.Crea l'oggetto PersistentVolumeClaim:
kubectl create -f provisioner-pvc-example.yaml
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.Crea il pod:
kubectl create -f provisioner-pod-example.yaml
Abilita l'associazione di volumi ritardati
Per una pianificazione migliore, ti consigliamo di creare anche un oggetto StorageClass con volumeBindingMode: WaitForFirstConsumer
. Questo ritarda l'associazione di PersistentVolumeClaim 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 migliorato prende in considerazione le richieste di CPU e memoria dei pod, l'affinità dei nodi, l'affinità dei pod e l'anti-affinità, nonché le richieste multiple di PersistentVolumeClaim, insieme alle richieste di PersistentVolumeClaim e i nodi che hanno SSD locali disponibili, quando seleziona un nodo per un pod eseguibile.
Questo esempio utilizza la modalità di associazione di volumi 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 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 Risoluzione dei problemi di archiviazione in GKE.