Les disques durs SSD locaux sont des disques SSD de taille fixe qui peuvent être installés sur une seule VM Compute Engine. Vous pouvez utiliser des disques SSD locaux sur GKE pour obtenir un stockage hautement performant et non persistant (éphémère) qui est associé à chaque nœud de votre cluster. Les disques SSD locaux assurent également un débit plus élevé et une latence plus faible que les disques standards.
À partir de la version 1.25.3-gke.1800, vous pouvez configurer un pool de nœuds GKE pour qu'il utilise un disque SSD local avec une interface NVMe pour le stockage éphémère local ou le stockage de blocs bruts.
Si vous utilisez GKE avec des clusters standards, vous pouvez associer des volumes SSD locaux aux nœuds lorsque vous créez des pools de nœuds. Cela améliore les performances du stockage éphémère pour vos charges de travail qui utilisent des volumes emptyDir ou des volumes PersistentVolumes locaux. Vous pouvez créer des pools de nœuds dotés de disques SSD locaux dans les limites inhérentes au type de machine de votre cluster et selon les quotas de votre projet.
Un disque SSD local est associé à un seul nœud, et les nœuds eux-mêmes sont éphémères. Une charge de travail peut être programmée sur un nœud différent à tout moment.
Lorsque vous configurez des SSD locaux, GKE installe automatiquement les répertoires suivants sur le volume SSD local pour améliorer les performances : /var/lib/kubelet, /var/log/pods et /var/lib/containerd. Cela permet d'accéder plus rapidement aux données kubelet critiques, aux journaux de pod et aux fichiers d'exécution des conteneurs.
Pour plus d'informations sur les avantages et les limites des disques SSD locaux, comme les performances et le nombre autorisé de disques SSD par type de machine, consultez la section Disques SSD locaux dans la documentation Compute Engine.
Pourquoi choisir des disques SSD locaux pour GKE ?
Le disque SSD local est un bon choix si vos charges de travail présentent l'une des exigences suivantes :
- Vous souhaitez exécuter des applications qui téléchargent et traitent des données, telles que l'IA ou le machine learning, l'analyse, le traitement par lot, la mise en cache locale et les bases de données en mémoire.
- Vos applications ont des besoins de stockage spécialisés et vous souhaitez disposer d'un accès aux blocs bruts pour un stockage éphémère hautes performances.
- Vous souhaitez exécuter des applications de données spécialisées et exploiter des volumes SSD locaux comme un cache au niveau du nœud pour vos pods. Vous pouvez utiliser cette approche pour améliorer les performances des applications de base de données en mémoire telles que Aerospike ou Redis.
Stockage éphémère
Nous vous recommandons d'utiliser l'option --ephemeral-storage-local-ssd pour provisionner un SSD local pour le stockage éphémère des nœuds (c'est l'option par défaut si vous utilisez une série de machines de troisième génération).
Cette approche place les volumes emptyDir, les couches accessibles en écriture du conteneur et les images qui constituent ensemble le stockage éphémère de votre nœud sur un SSD local. Les avantages incluent une bande passante d'E/S améliorée par rapport au disque persistant par défaut et des temps de démarrage des pods améliorés.
L'utilisation de disques SSD locaux pour le stockage éphémère des nœuds signifie que les volumes SSD locaux ne sont pas disponibles pour d'autres utilisations. Ne modifiez pas directement les appareils SSD locaux tels que /dev/nvme* à l'aide d'un Daemonset, d'un chemin d'accès ou d'un autre mécanisme privilégié, car le nœud pourrait échouer.
Si vous avez besoin d'un contrôle précis des volumes SSD locaux, utilisez plutôt l'approche par bloc brut.
Stockage d'appareil de stockage en mode bloc
Le stockage d'appareil de stockage en mode blocs permet un accès aléatoire aux données dans des blocs de taille fixe. Certaines applications spécialisées nécessitent un accès direct au stockage d'appareil de stockage en mode bloc, car, par exemple, la couche du système de fichiers introduit une surcharge inutile.
Voici quelques scénarios courants d'utilisation du stockage d'appareil de stockage en mode bloc :
- Bases de données où les données sont organisées directement sur le stockage sous-jacent.
- Logiciels qui mettent en œuvre un type de service de stockage (systèmes de stockage définis par logiciel).
Dans GKE version v1.25.3-gke.1800 et ultérieure, vous pouvez créer des clusters et des pools de nœuds avec des disques SSD locaux NVMe de blocs bruts associés à l'aide de l'option --local-nvme-ssd-block. Vous pouvez ensuite personnaliser le stockage de blocs en formatant un système de fichiers de votre choix (tel que ZFS ou HDFS) et en configurant la fonction RAID. Cette option est adaptée si vous avez besoin de contrôle supplémentaire pour exécuter des charges de travail qui nécessitent spécifiquement l'accès à un stockage en mode bloc basé sur un SSD local.
Vous pouvez également utiliser l'approche d'accès aux blocs avec des disques SSD locaux si vous souhaitez qu'un cache de données unifié partage les données entre les pods, et que ces données sont liées au cycle de vie d'un nœud. Pour ce faire, installez un DaemonSet avec une configuration RAID, formatez un système de fichiers et utilisez un volume PersistentVolume local pour partager les données entre les pods.
Configuration requise pour la machine
La manière dont vous provisionnez le SSD local pour vos clusters et pools de nœuds GKE dépend du type de machine sous-jacent. GKE est compatible avec les volumes SSD locaux sur les séries de machines de première, deuxième et troisième génération Compute Engine. Les volumes SSD locaux requièrent le type de machine n1-standard-1 ou supérieur.
Le type de machine par défaut, e2-medium, n'est pas accepté.
Pour identifier votre série de machines, utilisez le numéro figurant dans le nom du type de machine. Par exemple, les machines N1 sont de première génération et les machines N2 de deuxième génération.
Pour obtenir la liste des séries et types de machines disponibles, consultez le Guide des ressources de familles de machines et guide comparatif dans la documentation Compute Engine.
Exigences concernant les séries de machines de première et de deuxième génération
Pour utiliser une série de machines de première ou deuxième génération avec un SSD local, votre cluster ou votre pool de nœuds doit exécuter GKE version 1.25.3-gke.1800 ou ultérieure.
Pour provisionner un SSD local sur une série de machines de première ou deuxième génération, spécifiez le nombre de volumes SSD locaux à utiliser avec votre VM. Pour obtenir la liste des séries de machines et le nombre autorisé de SSD locaux correspondant, consultez la section Choisir un nombre valide de disques SSD locaux dans la documentation Compute Engine.
Exigences concernant les séries de machines de troisième et quatrième génération
Si vous souhaitez utiliser une série de machines de troisième génération avec un disque SSD local, votre cluster ou votre pool de nœuds doit exécuter l'une des versions suivantes de GKE :
- 1.25.13-gke.200 à 1.26
- 1.26.8-gke.200 à 1.27
- 1.27.5-gke.200 à 1.28
- 1.28.1-gke.200 à 1.29
Si vous souhaitez utiliser une série de machines de quatrième génération avec un SSD local, votre cluster ou votre pool de nœuds doit exécuter l'une des versions suivantes de GKE:
- 1.32.1-gke.1357000
Pour les séries de machines de troisième et quatrième génération, chaque type de machine est préconfiguré avec aucun SSD local ou un nombre fixe de volumes SSD locaux. Vous ne spécifiez pas le nombre de volumes SSD locaux à inclure. Au lieu de cela, la capacité SSD locale disponible pour vos clusters est implicitement définie dans le format de la VM.
Pour obtenir la liste des séries de machines et le nombre autorisé de SSD locaux correspondant, consultez la section Choisir un nombre valide de disques SSD locaux dans la documentation Compute Engine.
Modèle d'utilisation des volumes SSD locaux
Pour utiliser des volumes SSD locaux dans vos clusters, procédez comme suit :
- Provisionner un pool de nœuds avec des disques SSD locaux associés : pour créer un pool de nœuds GKE avec des disques SSD locaux associés, transmettez le paramètre de stockage éphémère ou de stockage de blocs brut lorsque vous appelez la commande
create cluster. Définir les paramètres de SSD local crée un pool de nœuds GKE avec un SSD local associé et configuré en tant que stockage éphémère local ou stockage de blocs bruts, en fonction des paramètres que vous choisissez. Pour en savoir plus sur les options de provisionnement des disques SSD locaux, consultez la section Paramètres des disques SSD locaux. - Accéder aux données depuis des volumes SSD locaux : pour utiliser les données de volumes SSD locaux, vous pouvez utiliser une construction Kubernetes telle que emptyDir ou un volume persistant local. Pour en savoir plus sur ces options, consultez la section Accès aux disques SSD locaux.
Paramètres SSD locaux sur GKE
Le tableau suivant récapitule les paramètres recommandés fournis par GKE pour le provisionnement de stockage SSD local sur des clusters. Vous pouvez utiliser la CLI gcloud pour transmettre ces paramètres.
| Type de SSD local | Commande gcloud CLI | Disponibilité GKE | Profil des disques SSD locaux |
|---|---|---|---|
| Stockage éphémère sur SSD local | gcloud container clusters create |
v1.25.3-gke.1800 ou ultérieure |
Technologie de stockage : NVMe Données partagées entre les pods : non Cycle de vie des données : pod Taille et besoins de la configuration RAID : jusqu'à 9 Tio. GKE configure automatiquement RAID en arrière-plan. Format : système de fichiers (Kubernetes emptyDir) Intégration du programmeur Kubernetes : entièrement intégré par défaut. Le programmeur Kubernetes assurera l'espace sur le nœud avant l'emplacement et fera évoluer les nœuds si nécessaire. Pour savoir comment utiliser ce paramètre d'API, consultez la section Provisionner et utiliser un stockage éphémère basé sur disque SSD local. |
| Bloc SSD NVMe local | gcloud container clusters create |
v1.25.3-gke.1800 ou ultérieure |
Technologie de stockage : NVMe Données partagées entre les pods : oui, via les PV locaux. Cycle de vie des données : nœud Taille et besoins de la configuration RAID : jusqu'à 9 Tio. Vous devez configurer manuellement le mode RAID pour les tailles plus importantes. Format : bloc brut Intégration du programmeur Kubernetes : non, par défaut. Vous devez garantir la capacité sur les nœuds et gérer les voisins bruyants. Si vous activez les PV locaux, la planification est intégrée. Pour savoir comment utiliser ce paramètre d'API, consultez la section Provisionner et utiliser un stockage de blocs bruts sauvegardé sur disque SSD local. |
Compatibilité avec les paramètres SSD locaux existants
Le tableau suivant récapitule ces paramètres SSD locaux existants et leurs remplaçants recommandés :
| Paramètres SSD locaux existants | Commande gcloud CLI | Profil des disques SSD locaux | Version DG recommandée des paramètres SSD locaux |
|---|---|---|---|
| Paramètre "Local SSD Count" (Nombre de SSD locaux) | gcloud container clusters create |
Technologie de stockage : SCSI Données partagées entre les pods : oui, via les PV locaux Cycle de vie des données : nœud Taille et besoin de la configuration RAID : 375 Gio. Vous devez configurer manuellement le mode RAID pour les tailles plus importantes. Format : système de fichiers (ext-4) Intégration du programmeur Kubernetes : non, par défaut. Vous devez garantir la capacité sur les nœuds et gérer les voisins bruyants. Si vous activez les PV locaux, la planification est intégrée. |
gcloud container clusters create |
| Paramètre Ephemeral Storage (bêta) | gcloud beta container clusters create |
Technologie de stockage : NVMe Données partagées entre les pods : non Cycle de vie des données : pod Taille et besoins de la configuration RAID : jusqu'à 9 Tio. GKE configure automatiquement RAID en arrière-plan. Format : système de fichiers (Kubernetes emptyDir) Intégration du programmeur Kubernetes : entièrement intégré par défaut. Le programmeur Kubernetes assurera l'espace sur les nœuds avant l'emplacement et fera évoluer les nœuds si nécessaire. |
gcloud container clusters create |
| Paramètre Local SSD Volumes (alpha) | gcloud alpha container clusters create |
Technologie de stockage : NVMe ou SCSI Données partagées entre les pods : non Cycle de vie des données : nœud Taille et besoin de la configuration RAID : 375 Gio. Vous devez configurer manuellement le mode RAID pour les tailles plus importantes. Format : système de fichiers (ext-4) ou bloc brut Intégration du programmeur Kubernetes : non par défaut, vous devez garantir la capacité sur les nœuds et gérer les voisins bruyants. |
gcloud container clusters create |
Accès aux disques SSD locaux
Vous pouvez accéder aux volumes SSD locaux selon l'une des méthodes suivantes :
Volume emptyDir
Dans GKE version v1.25.3-gke.1800 et ultérieure, vous pouvez utiliser le stockage éphémère en tant que volume emptyDir sauvegardé par des disques SSD locaux, via l'option --ephemeral-storage-local-ssd. Nous recommandons cette approche dans la plupart des cas, y compris les applications qui nécessitent un espace de travail éphémère hautes performances.
GKE vous permet de configurer un pool de nœuds pour installer le stockage éphémère des nœuds sur le disque SSD local avec une interface NVMe.
Pour en savoir plus, consultez cet exemple.
Volume persistant local
Un volume persistant local représente un disque local qui est associé à un seul nœud. Les volumes persistants locaux vous permettent de partager des ressources SSD locales entre des pods. Le disque local étant un disque SSD local, les données restent éphémères.
Nous recommandons cette approche si l'un des éléments suivants est exécuté sur votre cluster :
- Des charges de travail qui utilisent des StatefulSets et des volumeClaimTemplates.
- les charges de travail qui partagent des pools de nœuds. Chaque volume SSD local peut être réservé via un objet PersistentVolumeClaim, et les chemins d'accès à l'hôte spécifiques ne sont pas directement codés dans la spécification du pod.
- Des pods présentant une exigence de gravité des données sur le même disque SSD local. Un pod est toujours programmé sur le même nœud que son volume persistant local.
Pour en savoir plus, consultez cet exemple et la documentation Open Source Volumes de Kubernetes.
Restrictions
Votre application doit gérer correctement la perte d'accès aux données sur les volumes SSD locaux. Les données écrites sur un disque SSD local ne persistent pas lorsque le pod ou le nœud est supprimé, réparé, mis à niveau ou présente une erreur non récupérable.
Le paramètre SSD local de stockage éphémère configure les volumes SSD locaux pour qu'ils aient un cycle de vie de données basé sur un pod, et le paramètre de bloc SSD local NVMe configure les volumes SSD locaux de sorte qu'ils aient un cycle de vie de données basé sur un nœud.
Si vous avez besoin d'un stockage persistant, nous vous recommandons d'utiliser une option de stockage durable (par exemple, des disques persistants, Filestore ou Cloud Storage). Vous pouvez également utiliser des instances répliquées régionales pour minimiser le risque de perte de données pendant le cycle de vie du cluster ou les opérations du cycle de vie de l'application.
Les paramètres de configuration SSD locaux ne peuvent pas être modifiés une fois le pool de nœuds créé. Vous ne pouvez pas activer, désactiver ni mettre à jour la configuration SSD locale pour un pool de nœuds existant. Vous devez supprimer le pool de nœuds et en créer un autre pour apporter des modifications.
Les pods exploitant emptyDir utilisent de manière transparente des disques SSD locaux. Toutefois, cela s'applique à tous les pods de tous les nœuds de ce pool. GKE n'accepte pas que, dans le même pool de nœuds, certains pods utilisant des volumes emptyDir de disques SSD locaux sauvegardés par des disques SSD locaux et d'autres pods utilisant des volumes emptyDir sauvegardés par un disque de démarrage des nœuds. Si vous avez des charges de travail qui utilisent des volumes emptyDir sauvegardés par un disque de démarrage des nœuds, planifiez les charges de travail sur un autre pool de nœuds.
Les clusters Autopilot et le provisionnement automatique des nœuds ne sont pas compatibles avec les disques SSD locaux.
Nous vous recommandons d'utiliser le disque SSD local en tant que stockage éphémère pour les charges de travail exécutées sur des VM optimisées pour le stockage (Z3). Les nœuds Z3 sont arrêtés lors des événements de maintenance. De ce fait, les données stockées sur le disque SSD local pour ces nœuds peuvent ne pas être disponibles lors d'événements de maintenance et la récupération des données n'est pas garantie après la maintenance.
Étapes suivantes
- Provisionner et utiliser un stockage éphémère sauvegardé sur disque SSD local.
- Provisionner et utiliser le stockage de blocs bruts sauvegardé sur disque SSD local.