Provisionner et utiliser des disques SSD locaux mixtes pour le stockage de blocs bruts et le stockage éphémère

Ce document explique comment provisionner et partitionner des disques SSD locaux dans Google Kubernetes Engine (GKE) pour prendre en charge les charges de travail qui nécessitent à la fois un système de fichiers de stockage éphémère standard et un stockage de blocs bruts non formaté sur le même nœud.

Utilisez cette configuration pour les applications avec état et les bases de données hautement optimisées. Ces charges de travail nécessitent souvent un accès direct au disque pour améliorer les performances, mais elles ont également besoin d'un stockage de fichiers éphémère standard pour les side-cars, les journaux ou les caches de conteneurs. En utilisant une capacité de SSD locaux mixte, vous pouvez réduire les frais de gestion du cluster et maximiser l'utilisation du matériel, car vous n'avez pas besoin de dédier des nœuds distincts ou des disques complets exclusivement à l'infrastructure de blocs bruts.

Lorsque vous créez un cluster ou un pool de nœuds avec une capacité de SSD locaux mixte, GKE partitionne chaque SSD local physiquement associé comme suit :

  • Stockage éphémère : la capacité éphémère demandée est répartie équitablement entre les disques SSD locaux et combinée pour fournir le stockage de fichiers éphémère standard du nœud. Lorsque la capacité éphémère est partitionnée sur plusieurs disques SSD locaux, le stockage est combiné dans une baie RAID-0. Vous pouvez accéder au stockage éphémère à l'aide de volumes emptyDir standards.
  • Stockage de blocs bruts : le reste de la capacité physique de chaque disque est présenté au nœud sous la forme d'appareils de stockage en mode bloc bruts distincts et non formatés.

Ce document s'adresse aux administrateurs et opérateurs de plate-forme, ainsi qu'aux ingénieurs DevOps qui souhaitent optimiser l'utilisation du matériel et les performances de stockage dans GKE pour les charges de travail spécialisées.

Remarques

En plus des limites des disques SSD locaux Compute Engine, tenez compte des points suivants spécifiques à GKE avant de configurer des modes de disques SSD locaux mixtes :

  • Compatibilité avec Autopilot : les clusters GKE Autopilot ne sont pas compatibles avec le stockage mixte de blocs bruts et de stockage éphémère. Pour savoir comment utiliser des disques SSD locaux pour le stockage éphémère standard dans Autopilot, consultez Disques SSD locaux dans les clusters Autopilot.
  • ComputeClasses personnalisées : les ComputeClasses personnalisées ne sont pas compatibles avec la configuration de disques SSD locaux mixtes.
  • Système d'exploitation : le mode SSD local mixte n'est compatible qu'avec les images de nœud Linux (Container-Optimized OS et Ubuntu). Les pools de nœuds Windows Server ne sont pas acceptés.
  • Événements de maintenance : nous vous déconseillons d'utiliser des disques SSD locaux comme stockage de blocs bruts pour les VM Z3 ou Z4D optimisées pour le stockage. Les données de ces VM risquent de ne pas survivre aux événements de maintenance. Pour en savoir plus, consultez Provisionner et utiliser le stockage de blocs bruts sauvegardé sur disque SSD local.
  • E/S partagées : étant donné que la baie RAID-0 éphémère et vos partitions de blocs bruts ciblées reposent sur les mêmes disques SSD physiques sous-jacents, les opérations intensives sur une partition logique peuvent avoir un impact sur le débit de l'autre. Pour en savoir plus sur les limites de débit maximales, consultez Performances des disques SSD locaux.
  • Tarification : lorsque vous utilisez des modes mixtes pour partitionner la capacité des disques SSD locaux, vous payez pour la capacité physique totale des disques SSD locaux sous-jacents associés au nœud, quelle que soit la capacité allouée au stockage éphémère par rapport au stockage de blocs brut. Pour en savoir plus, consultez la section Tarifs des disques SSD locaux.
  • Configuration manuelle : pour utiliser le stockage de blocs bruts sauvegardé sur disque SSD local, vous devez configurer manuellement les appareils, car GKE ne formate ni n'installe les partitions de blocs bruts. Vous devez également gérer la capacité des nœuds et les perturbations potentielles des charges de travail colocalisées. L'utilisation d'un objet PersistentVolume local permet de planifier des pods de manière intégrée. Si vos charges de travail ne nécessitent pas la persistance des données pendant le cycle de vie des pods ou si elles n'ont pas d'exigences particulières en termes de performances, utilisez plutôt la configuration de disque SSD local entièrement éphémère. La configuration entièrement éphémère convient à la plupart des cas d'utilisation.
  • Échange de mémoire de nœud : vous pouvez combiner la capacité de disques SSD locaux mixtes avec l'échange de mémoire de nœud en utilisant le profil de disque de démarrage ou le profil de disque SSD local éphémère. Le profil de SSD local dédié n'est pas compatible avec une capacité de SSD local mixte. Pour en savoir plus, consultez Échange de mémoire de nœud avec une capacité de SSD local mixte.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Pour utiliser la Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

Pour utiliser cette fonctionnalité, les nœuds GKE doivent exécuter la version 1.37.0-gke.3570000 ou une version ultérieure.

Rôles requis

Pour obtenir les autorisations nécessaires pour créer des clusters et des pools de nœuds avec une capacité de SSD locaux mixte, demandez à votre administrateur de vous accorder le rôle IAM Administrateur Kubernetes Engine (roles/container.admin) sur votre projet. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Créer un cluster ou un pool de nœuds avec un stockage SSD local mixte

Vous pouvez allouer une capacité éphémère et réserver des partitions de blocs bruts à l'aide de la propriété capacity de l'option --ephemeral-storage-local-ssd.

Créez votre cluster ou votre pool de nœuds en spécifiant le sous-champ capacity avec l'option --ephemeral-storage-local-ssd.

Si votre type de machine autorise un nombre configurable de disques SSD locaux, vous devez également spécifier le sous-champ count. Si votre type de machine comporte un nombre fixe de disques SSD locaux, par exemple les types -lssd, vous pouvez omettre le sous-champ count, car GKE calcule automatiquement le nombre de disques en fonction de la forme de la VM.

Créer un cluster avec un stockage SSD local mixte

Pour créer un cluster, utilisez la commande gcloud container clusters create. Ces paramètres ne s'appliquent qu'au pool de nœuds par défaut. Si les pools de nœuds suivants nécessitent un stockage SSD local mixte, spécifiez l'option --ephemeral-storage-local-ssd lorsque vous créez le pool de nœuds. Le nombre maximal de disques que vous pouvez associer varie selon le type de machine et la région.

Si la version de votre cluster est antérieure à 1.37.0-gke.3570000, ajoutez l'un des flags suivants aux commandes de création de cluster suivantes :

  • L'option --cluster-version=<var>VERSION</var> avec <var>VERSION</var> défini sur 1.37.0-gke.3570000 ou une version ultérieure, ou
  • L'option --release-channel=rapid

Pour les types de machines avec un nombre de disques SSD locaux configurable, exécutez la commande suivante :

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS,capacity=CAPACITY

Pour les types de machines avec un nombre fixe de disques SSD locaux, exécutez la commande suivante :

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd capacity=CAPACITY

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster que vous souhaitez créer.
  • MACHINE_TYPE : type de machine à utiliser. Pour obtenir la liste des types de machines compatibles, consultez Compatibilité avec les séries de machines. Vous ne pouvez pas utiliser de SSD locaux avec le type de machine e2-medium par défaut, car les types de machines à cœur partagé ne les acceptent pas.
  • NUMBER_OF_DISKS : pour les types de machines avec un nombre de SSD locaux configurable, nombre de disques SSD locaux à provisionner sur chaque nœud.

  • CAPACITY : capacité totale de SSD locaux à formater pour le stockage éphémère. Cette valeur doit être supérieure à 0 et strictement inférieure à la capacité physique totale du SSD local (nombre de disques × taille par disque), par exemple 200GB. Veuillez noter les points suivants :

    • La valeur ne peut pas être modifiée une fois le cluster créé.
    • GKE réserve une partie de cette capacité à l'usage du système. Le stockage éphémère pouvant être alloué est donc inférieur à CAPACITY. Pour en savoir plus, consultez Réservation de stockage éphémère local.

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

Pour ajouter un pool de nœuds à un cluster existant, utilisez la commande gcloud container node-pools create.

Si la version de votre pool de nœuds est antérieure à 1.37.0-gke.3570000, vous devez procéder comme suit :

  • Ajoutez l'option --node-version=<var>VERSION</var> aux commandes de création de pools de nœuds suivantes, avec <var>VERSION</var> défini sur 1.37.0-gke.3570000 ou une version ultérieure.
  • Assurez-vous que le plan de contrôle du cluster est en version 1.37.0-gke.3570000 ou ultérieure.

Pour les types de machines avec un nombre de disques SSD locaux configurable, exécutez la commande suivante :

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS,capacity=CAPACITY

Pour les types de machines avec un nombre fixe de disques SSD locaux, exécutez la commande suivante :

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd capacity=CAPACITY

Remplacez les éléments suivants :

  • POOL_NAME : nom du nouveau pool de nœuds que vous souhaitez créer.
  • CLUSTER_NAME : nom du cluster.
  • MACHINE_TYPE : type de machine à utiliser. Pour obtenir la liste des types de machines compatibles, consultez Compatibilité avec les séries de machines. Vous ne pouvez pas utiliser de SSD locaux avec le type de machine e2-medium par défaut, car les types de machines à cœur partagé ne les acceptent pas.
  • NUMBER_OF_DISKS : pour les types de machines avec un nombre de SSD locaux configurable, nombre de disques SSD locaux à provisionner sur chaque nœud.

  • CAPACITY : capacité totale de SSD locaux à formater pour le stockage éphémère. Cette valeur doit être supérieure à 0 et strictement inférieure à la capacité physique totale du SSD local (nombre de disques × taille par disque), par exemple 200GB. Veuillez noter les points suivants :

    • La valeur ne peut pas être modifiée une fois le pool de nœuds créé.
    • GKE réserve une partie de cette capacité à l'usage du système. Le stockage éphémère pouvant être alloué est donc inférieur à CAPACITY. Pour en savoir plus, consultez Réservation de stockage éphémère local.

Vérifier les étiquettes de nœud

Après le provisionnement, pour vérifier que les nœuds disposent des étiquettes appropriées pour le stockage de blocs éphémère et brut, exécutez la commande suivante :

kubectl describe node NODE_NAME

Le résultat doit contenir les deux étiquettes de nœud suivantes :

  • cloud.google.com/gke-ephemeral-storage-local-ssd: "true"
  • cloud.google.com/gke-local-nvme-ssd-partition: "true"

Accéder à la capacité éphémère

Accédez à votre stockage éphémère réservé via des volumes emptyDir, exactement comme vous le feriez pour n'importe quel autre volume éphémère GKE.

Accéder à la capacité de bloc brute

Pour accéder à votre capacité de stockage de blocs bruts, vous devez créer un objet StorageClass, provisionner un objet PersistentVolume local et le revendiquer à l'aide d'un objet PersistentVolumeClaim.

Créer un objet StorageClass

Étant donné que vous provisionnez vos objets PersistentVolume sans l'approvisionneur statique de la communauté, nous vous recommandons de créer un objet StorageClass avec le champ volumeBindingMode: WaitForFirstConsumer. Cela retarde la liaison jusqu'à la programmation du pod, ce qui garantit que Kubernetes choisit un disque SSD local à partir d'un nœud approprié pouvant exécuter le pod.

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

Créer le PersistentVolume

Les objets PersistentVolume locaux présentent des limites importantes concernant les mises à niveau des nœuds, le scaling et l'autoscaling des clusters. Avant de créer vos volumes, consultez les limites des volumes persistants locaux pour comprendre l'impact des événements de cycle de vie sur vos données.

Pour créer l'objet PersistentVolume, procédez comme suit pour trouver le chemin d'accès du lien symbolique vers la partition du disque SSD local, déterminer sa capacité restante exacte et configurer le fichier manifeste.

Trouver la capacité de la partition

Exécutez la commande suivante sur le nœud cible pour trouver la capacité de bloc brut exacte restante pour la partition.

kubectl debug node/NODE_NAME -it --image=ubuntu -- \
    sh -c 'ls -l /host/dev/disk/by-id/ | grep partition; lsblk -o NAME,SIZE,TYPE'

Remplacez NODE_NAME par le nom du nœud auquel le disque SSD local est associé.

Le résultat affiche le mappage entre les noms d'appareils et les liens symboliques de partition afin que vous puissiez vérifier quelle partition correspond à quel appareil. Elle liste également les appareils de stockage en mode bloc associés au nœud et leur taille.

Par exemple, si vous associez deux disques SSD locaux au nœud et allouez 200 Go à l'espace de stockage éphémère (capacity=200GB), le résultat ressemble à ceci :

google-local-ssd-partition0 -> /dev/nvme0n1p2
google-local-ssd-partition1 -> /dev/nvme0n2p2
NAME          SIZE TYPE
...
nvme0n1       375G disk
|-nvme0n1p1   100G part
| `-md0     199.9G raid0
`-nvme0n1p2   275G part
nvme0n2       375G disk
|-nvme0n2p1   100G part
| `-md0     199.9G raid0
`-nvme0n2p2   275G part

Notez le mappage entre le lien symbolique google-local-ssd-partition et le nom de l'appareil sous-jacent, ainsi que la taille de cette partition. Vous utilisez la taille comme PARTITION_SIZE et le chemin d'accès du lien symbolique comme LOCAL_SSD_SYMLINK_PATH dans le fichier manifeste PersistentVolume.

Par exemple, dans le résultat précédent, le lien symbolique /dev/disk/by-id/google-local-ssd-partition0 pointe vers la partition nvme0n1p2, dont la taille est de 275G.

La commande kubectl debug laisse un pod temporaire s'exécuter dans l'espace de noms par défaut. Pour éviter qu'il ne consomme des ressources, supprimez ce pod en exécutant la commande suivante :

kubectl delete pod DEBUG_POD_NAME

Remplacez DEBUG_POD_NAME par le nom du pod créé par la commande kubectl debug, qui s'affiche lorsque vous exécutez la commande.

Configurer le fichier manifeste PersistentVolume

Configurez le fichier manifeste du volume avec la taille de partition que vous avez trouvée. Le champ nodeAffinity est obligatoire pour les volumes locaux. Cela permet de s'assurer que Kubernetes planifie les pods revendiquant ce volume sur le nœud spécifique auquel le disque SSD local est physiquement associé. L'exemple suivant illustre un fichier manifeste pour une partition de disque SSD local de bloc brut :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: PARTITION_SIZE
  accessModes:
  - "ReadWriteOnce"
  volumeMode: "Block"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "LOCAL_SSD_SYMLINK_PATH"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - "NODE_NAME"

Remplacez les éléments suivants :

  • PARTITION_SIZE : capacité brute réelle restante que vous avez trouvée à la première étape. Utilisez le suffixe Gi (par exemple, 275Gi) pour que la valeur corresponde exactement à la capacité de la partition.
  • NODE_NAME : nom du nœud auquel le disque SSD local est associé.
  • LOCAL_SSD_SYMLINK_PATH : chemin d'accès du lien symbolique vers la partition SSD locale non formatée que vous avez trouvée à la première étape. Pour chaque disque SSD local associé au pool de nœuds, l'OS hôte crée un lien symbolique pour accéder à la capacité de bloc brut restante. Les chemins suivent un modèle d'indexation commençant par zéro. Par exemple, si vous associez trois disques SSD locaux, les chemins d'accès aux blocs bruts pour les partitions sont les suivants :
    • /dev/disk/by-id/google-local-ssd-partition0
    • /dev/disk/by-id/google-local-ssd-partition1
    • /dev/disk/by-id/google-local-ssd-partition2

Créer la PersistentVolumeClaim

Créez un objet PersistentVolumeClaim pour revendiquer le volume. La spécification correspondante se présente comme suit :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: "example-local-pvc"
spec:
  accessModes:
  - "ReadWriteOnce"
  volumeMode: "Block"
  storageClassName: "local-storage"
  resources:
    requests:
      storage: PARTITION_SIZE

Utiliser le volume dans un pod

Vous pouvez utiliser l'objet PersistentVolume dans un pod en référençant l'objet PersistentVolumeClaim dans une spécification volumeDevices. Voici un exemple de fichier manifeste de pod qui utilise la revendication example-local-pvc :

apiVersion: v1
kind: Pod
metadata:
  name: "example-pod"
spec:
  containers:
  - name: "app"
    image: "ubuntu:22.04"
    command: ["/bin/sh", "-c"]
    args: ["tail -f /dev/null"]
    volumeDevices:
    - name: "raw"
      devicePath: "/dev/xvda"
  volumes:
  - name: "raw"
    persistentVolumeClaim:
      claimName: "example-local-pvc"

Comme vous utilisez l'approvisionneur kubernetes.io/no-provisioner, GKE ne nettoie pas automatiquement les volumes locaux. Si vous supprimez l'objet PersistentVolume, vous devez effacer manuellement les données du disque sous-jacent avant de pouvoir le réutiliser en toute sécurité.

Dépannage

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

Étapes suivantes