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.
Dans les versions 1.25.3-gke.1800 et ultérieures, vous pouvez configurer un pool de nœuds GKE pour utiliser le 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 lors de la création de 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.
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 un disque SSD local 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 le disque SSD local pour le stockage éphémère des nœuds (valeur 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 en conteneur et les images qui constituent votre espace de stockage éphémère des nœuds sur le disque SSD local. Cela présente plusieurs avantages en améliorant la bande passante d'E/S par rapport au disque persistant par défaut, ainsi que 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 le disque de démarrage à l'aide d'un Daemonset, d'un chemin d'accès ou autre mécanisme privilégié car alors 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 nécessitant spécifiquement un accès au stockage de blocs sauvegardé par un disque 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
La façon dont vous provisionnez des disques SSD locaux 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 dans le nom du type de machine. Par exemple, les machines N1 sont des machines de première génération et les machines N2 de deuxième génération.
Pour obtenir la liste des types et séries de machines disponibles, consultez le Guide de ressources et de comparaison des familles de machines dans la documentation de Compute Engine.
Exigences relatives aux séries de machines de première et deuxième génération
Pour utiliser une série de machines de première ou de deuxième génération avec un disque 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 disque SSD local sur une série de machines de première ou deuxième génération, vous devez spécifier le nombre de volumes SSD locaux à utiliser avec votre VM. Pour obtenir une liste des séries de machines et du nombre autorisé de disques SSD locaux, consultez la page Choisir un nombre valide de disques SSD locaux dans la documentation Compute Engine.
Configuration requise pour la série de machines de troisiè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
Pour les séries de machines de troisième génération, chaque type de machine est préconfiguré avec ou sans disque SSD local. 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 une liste des séries de machines et du nombre autorisé de disques SSD locaux, consultez la page Choisir un nombre valide de disques SSD locaux dans la documentation Compute Engine.
Modèle d'utilisation pour les 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. La définition des paramètres SSD locaux crée un pool de nœuds GKE avec un disque SSD local associé et configuré en tant que stockage éphémère local ou stockage de blocs brut en fonction des paramètres que vous choisissez. Pour en savoir plus sur les options de provisionnement d'un disque SSD local, consultez la page 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 des disques SSD locaux sur GKE
Le tableau suivant récapitule les paramètres fournis par GKE pour le provisionnement du stockage SSD local sur les clusters. Vous pouvez utiliser gcloud CLI pour transmettre ces paramètres.
| Type des disques SSD locaux | Commande gcloud CLI | Disponibilité GKE | Profil des disques SSD locaux |
|---|---|---|---|
| SSD local de stockage éphémère | 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 API, consultez la page Provisionner et utiliser un stockage éphémère basé sur 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 apprendre à utiliser ce paramètre API, consultez la page Provisionner et utiliser un stockage de blocs brut basé sur 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 du nombre de disques 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 de volumes SSD locaux (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 StatefulSet 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 recréer un 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.