Provisionner et utiliser le stockage de blocs bruts sauvegardé sur disque SSD local

Standard

Cette page explique comment provisionner le stockage SSD local sur les clusters Google Kubernetes Engine (GKE) et comment configurer les charges de travail pour qu'elles utilisent les données du stockage de blocs bruts sauvegardé sur disque SSD local dans votre cluster.

L'utilisation de cette option des disques SSD locaux vous permet de mieux contrôler l'espace de stockage sous-jacent et de créer votre propre cache au niveau du nœud pour les pods afin d'améliorer les performances de vos applications. Vous pouvez également personnaliser cette option en installant un système de fichiers sur les disques SSD locaux. Pour ce faire, exécutez un DaemonSet pour configurer RAID et formater les disques selon les besoins.

Pour en savoir plus sur la compatibilité des disques SSD locaux avec l'accès aux blocs bruts sur GKE, consultez la page À propos des disques SSD locaux.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Créer un cluster ou un pool de nœuds doté d'un stockage de blocs bruts sauvegardé sur disque SSD local

Utilisez gcloud CLI avec l'option --local-nvme-ssd-block pour créer un cluster avec un stockage de blocs bruts sauvegardé sur disque SSD local.

La commande de gcloud CLI que vous exécutez pour créer le cluster ou le pool de nœuds dépend de la génération de séries de machines à laquelle appartient le type de machine que vous utilisez. Par exemple, les types de machines N1 et N2 appartiennent respectivement à une série de machines de première et deuxième génération, tandis que les types de machines C3 appartiennent à une série de machines de troisième génération.

Créer un cluster avec un disque SSD local

1re ou 2e génération

Si vous utilisez un type de machine d'une série de machines de première ou deuxième génération, vous créez votre cluster en spécifiant l'option --local-nvme-ssd-block count=NUMBER_OF_DISKS. L'option spécifie le nombre de disques SSD locaux à associer à chaque nœud. Le nombre maximal varie selon le type de machine et la région.

Pour créer un cluster, procédez comme suit :

gcloud container clusters create CLUSTER_NAME \
    --local-nvme-ssd-block count=NUMBER_OF_DISKS \
    --machine-type=MACHINE_TYPE \
    --release-channel CHANNEL_NAME

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster.
NUMBER_OF_DISKS : nombre de disques SSD locaux à provisionner sur chaque nœud. Le nombre maximal de disques varie selon le type de machine et la région.
MACHINE_TYPE : type de machine de première ou de deuxième génération à utiliser. Ce champ est obligatoire, car vous ne pouvez pas utiliser de disques SSD locaux avec le type e2-medium par défaut.
CHANNEL_NAME : canal de publication incluant les versions de GKE ultérieures à la version 1.25.3-gke.1800.

3e génération

Si vous utilisez un type de machine d'une série de machines de troisième génération, utilisez l'option --local-nvme-ssd-block, sans champ de décompte, pour créer un cluster. GKE provisionne automatiquement la capacité des disques SSD locaux pour votre cluster en fonction de la forme de la VM. Le nombre maximal varie selon le type de machine et la région.

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

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster.
MACHINE_TYPE : type de machine à utiliser depuis une série de machines de troisième génération.
CLUSTER_VERSION : version de cluster GKE compatible avec les disques SSD locaux sur les types de machines de troisième génération.

Créer un pool de nœuds avec un disque SSD local

1re ou 2e génération

Pour créer un pool de nœuds utilisant des disques SSD locaux pour l'accès aux blocs bruts, exécutez la commande suivante :

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

Remplacez les éléments suivants :

POOL_NAME : nom de votre nouveau pool de nœuds.
CLUSTER_NAME : nom du cluster.
MACHINE_TYPE : type de machine de première ou de deuxième génération à utiliser. Ce champ est obligatoire, car le disque SSD local ne peut pas être utilisé avec le type e2-medium par défaut.
NUMBER_OF_DISKS : nombre de disques SSD locaux à provisionner sur chaque nœud. Le nombre maximal de disques varie selon le type de machine et la région.

3e génération

Si vous utilisez un type de machine d'une série de machines de troisième génération, utilisez l'option --local-nvme-ssd-block, sans champ de décompte, pour créer un cluster :

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

Remplacez les éléments suivants :

POOL_NAME : nom du nouveau pool de nœuds.
CLUSTER_NAME : nom du cluster.
MACHINE_TYPE : type de machine à utiliser depuis un type de machine de troisième génération.
NODE_VERSION : version de pool de nœuds GKE compatible avec les disques SSD locaux sur les types de machines de troisième génération.

Les nœuds du pool de nœuds sont créés avec le libellé cloud.google.com/gke-local-nvme-ssd=true. Vous pouvez vérifier les libellés en exécutant la commande suivante :

kubectl describe node NODE_NAME

Pour chaque disque SSD local que vous associez au pool de nœuds, le système d'exploitation hôte crée un lien symbolique pour accéder au disque dans un dossier ordinal et un lien symbolique avec un identifiant unique universel (UUID). Par exemple, si vous créez un pool de nœuds avec trois disques SSD locaux à l'aide de l'option --local-nvme-ssd-block, le système d'exploitation hôte crée les liens symboliques suivants pour les disques :

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

De même, le système d'exploitation hôte crée également les liens symboliques suivants avec des UUID pour les disques :

/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

Ainsi, les disques sont accessibles à l'aide d'un identifiant unique.

Accéder aux volumes SSD locaux

L'exemple suivant montre comment accéder à l'espace de stockage de blocs bruts basé sur un disque SSD local.

Objets PersistentVolume locaux

Les volumes SSD locaux peuvent être installés en tant que pods à l'aide de volumes persistants.

Vous pouvez créer des volumes persistants à partir de disques SSD locaux en créant manuellement un volume persistant ou en exécutant l'approvisionneur statique de volumes locaux.

Limites des volumes persistants locaux

L'autoscaling des clusters et le provisionnement dynamique ne sont pas compatibles avec les volumes persistants locaux.
La mise à niveau d'un cluster GKE ou la réparation de nœuds supprime les instances Compute Engine, et donc toutes les données stockées sur les disques SSD locaux.
N'activez pas les mises à niveau automatiques de nœuds ni la réparation automatique de nœuds pour des clusters ou des pools de nœuds utilisant des disques SSD locaux pour les données persistantes. Vous devez d'abord sauvegarder vos données d'application, puis restaurer les données sur un nouveau cluster ou un nouveau pool de nœuds.

Les objets PersistentVolume locaux ne sont pas nettoyés automatiquement lorsqu'un nœud est supprimé, mis à niveau, réparé ou réduit. Nous vous recommandons d'analyser et de supprimer régulièrement les objets PersistentVolume locaux obsolètes associés à des nœuds supprimés.

Créer manuellement un PersistentVolume

Vous pouvez créer manuellement un volume persistant pour chaque disque SSD local sur chaque nœud de votre cluster.

Utilisez le champ nodeAffinity dans un objet PersistentVolume pour référencer un disque SSD local sur un nœud spécifique. L'exemple suivant montre la spécification PersistentVolume pour les disques SSD locaux sur les nœuds exécutant 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"

Dans cet exemple, les disques SSD locaux sont configurés manuellement pour RAID et formatés, puis installés à l'emplacement /mnt/disks/ssd0 sur le nœud gke-test-cluster-default-pool-926ddf80-f166. Le champ nodeAffinity permet d'attribuer des charges de travail aux nœuds dotés de disques SSD locaux configurés manuellement pour la configuration RAID. Si vous ne disposez que d'un seul nœud dans votre cluster ou si vous avez configuré RAID pour tous les nœuds, le champ nodeAffinity n'est pas nécessaire.

La spécification PersistenVolumeClaim correspondante se présente comme suit :

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

Si vous supprimez le volume persistant, vous devez effacer manuellement les données du disque.

Exécuter l'approvisionneur statique de volumes locaux

Vous pouvez créer automatiquement des volumes persistants pour les disques SSD locaux à l'aide de l'approvisionneur statique de volumes locaux. L'approvisionneur est un DaemonSet qui gère les disques SSD locaux sur chaque nœud, crée et supprime les PersistentVolumes pour eux et nettoie les données sur le disque SSD local lors de la publication du PersistentVolume.

Pour exécuter l'approvisionneur statique de volumes locaux :

Utilisez DaemonSet pour configurer RAID et formater les disques :
1. Téléchargez la spécification gke-daemonset-raid-disks.yaml.
2. Déployez le DaemonSet des disques RAID. Le DaemonSet définit une baie de disques RAID 0 sur tous les disques SSD locaux et formate l'appareil sur un système de fichiers ext4.
```
kubectl create -f gke-daemonset-raid-disks.yaml
```
Téléchargez la spécification gke-nvme-ssd-block-raid.yaml, puis modifiez les champs d'espace de noms de la spécification selon vos besoins.

La spécification inclut les ressources suivantes :
- ServiceAccount pour l'approvisionneur
- ClusterRole et ClusterRoleBindings pour les autorisations permettant :
  - de créer et supprimer des objets PersistentVolume ;
  - d'obtenir des objets Node.
- ConfigMap avec les paramètres d'approvisionneur pour GKE
- DaemonSet pour l'exécution de l'approvisionneur
Déployez l'approvisionneur :
```
kubectl create -f gke-nvme-ssd-block-raid.yaml
```
Une fois exécuté, il crée un objet PersistentVolume pour le disque SSD local RAID dans le cluster.

Enregistrez le fichier manifeste de PersistentVolumeClaim suivant sous le nom provisioner-pvc-example.yaml :

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

Remplacez PVC_NAME par le nom de votre PersistentVolumeClaim.

Créez la PersistentVolumeClaim :

kubectl create -f provisioner-pvc-example.yaml

Enregistrez le fichier manifeste de pod suivant sous le nom 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

Remplacez POD_NAME par le nom de votre pod.

Créez le pod :

kubectl create -f provisioner-pod-example.yaml

Activer la liaison de volume retardé

Pour améliorer la programmation, nous vous recommandons également de créer également une classe StorageClass avec volumeBindingMode: WaitForFirstConsumer. Cela retarde la liaison de la PersistentVolumeClaim jusqu'à la programmation du pod, de sorte qu'un disque SSD local soit choisi à partir d'un nœud approprié pouvant exécuter le pod. Lorsque vous sélectionnez un nœud pour un pod exécutable, ce comportement de programmation amélioré prend en compte les demandes de processeurs et de mémoire du pod, d'affinité des nœuds, d'affinité et d'anti-affinité du pod, de PersistentVolumeClaim multiples ainsi que les nœuds pour lesquels des disques SSD locaux sont disponibles.

Cet exemple utilise le mode de liaison de volume retardé :

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

Pour créer une StorageClass avec liaison différée, enregistrez le fichier manifeste YAML en tant que fichier local et appliquez-le au cluster à l'aide de la commande suivante :

kubectl apply -f filename

Dépannage

Pour obtenir des instructions de dépannage, consultez la page Résoudre les problèmes de stockage dans GKE.

Étapes suivantes

En savoir plus sur les pools de nœuds.