Présentation du stockage pour les clusters GKE


Ce document décrit les options d'espace de stockage compatibles avec GKE et aborde certains points clés à prendre en compte pour sélectionner la meilleure option en fonction des besoins de votre entreprise.

GKE est compatible avec les types d'espace de stockage et les intégrations suivants :

Stockage de blocs (Persistent Disk)

Les volumes Persistent Disk sont des périphériques de stockage réseau durables gérés par Compute Engine auxquels vos clusters GKE peuvent accéder, au même titre que des disques physiques sur un ordinateur ou un serveur. Lorsque vos clusters nécessitent davantage d'espace de stockage, vous pouvez associer des volumes Persistent Disk à vos nœuds ou redimensionner vos volumes Persistent Disk existants. Vous pouvez laisser GKE provisionner les PersistentVolumes de manière dynamique par Persistent Disk ou provisionner les disques manuellement.

Cette option d'espace de stockage est compatible avec les clusters GKE Autopilot et Standard.

Par défaut, les volumes Persistent Disk sont des ressources zonales (conservées dans une seule zone d'une région). Vous pouvez créer des volumes Persistent Disk régionaux (conservés sur deux zones de la même région). Vous pouvez également associer un volume Persistent Disk en lecture seule à plusieurs nœuds simultanément. Cette fonctionnalité est compatible avec les volumes Persistent Disk zonaux et régionaux.

L'espace de stockage Persistent Disk sur GKE est persistant, ce qui signifie que les données stockées sur vos disques sont conservées même si le pod qui l'utilise est arrêté.

Pourquoi utiliser l'espace de stockage Persistent Disk

Utilisez l'espace de stockage Persistent Disk si vos clusters nécessitent un accès à un stockage de blocs durable et à hautes performances. Un volume Persistent Disk est généralement associé à un seul pod. Cette option d'espace de stockage est compatible avec le mode d'accès ReadWriteOnce. GKE permet de configurer des volumes Persistent Disk avec une plage d'options de latence et de performances, parmi lesquelles :

  • Balanced Persistent Disk : adapté aux applications d'entreprise standards. Cette option offre un bon équilibre entre performances et coûts. Reposent sur des disques durs SSD. Il s'agit de l'option par défaut pour le provisionnement dynamique de volumes sur les clusters et les nœuds exécutant GKE version 1.24 ou ultérieure.
  • Performance Persistent Disk : adapté à l'analyse horizontale, aux bases de données et à la mise en cache persistante. Cette option est idéale pour les charges de travail sensibles aux performances. Reposent sur des disques durs SSD.
  • Standard Persistent Disk : adapté au big data et aux charges de travail de calcul importantes. Cette option est le type de disque le plus rentable. Elle repose sur des disques durs standards (HDD).
  • Persistent Disk Extrême : adapté aux applications d'entreprise telles que SAP HANA et Oracle. Cette option offre les meilleures performances pour répondre aux besoins des bases de données en mémoire les plus volumineuses. Elle repose sur des disques durs SSD. Pour les applications critiques, où Persistent Disk ne fournit pas suffisamment de performances, utilisez des disques Hyperdisk Extrême.

Pour commencer à utiliser cette option d'espace de stockage, consultez les ressources suivantes :

Stockage de blocs (Google Cloud Hyperdisk)

Les volumes Hyperdisk utilisent la nouvelle génération de stockage de blocs Google Cloud. Les volumes Hyperdisk vous permettent d'ajuster de manière dynamique les performances de votre stockage de blocs en fonction de votre charge de travail. Vous pouvez configurer des opérations d'entrée/sortie par seconde (IOPS) et un débit indépendamment pour vos applications, et vous adapter aux besoins de performances en constante évolution.

Cette option d'espace de stockage est compatible avec les clusters GKE Autopilot et Standard. Les volumes Hyperdisk sont des ressources zonales, sous réserve de disponibilité régionale. L'espace de stockage Hyperdisk sur GKE est persistant, ce qui signifie que les données stockées sur vos disques sont conservées même si le pod qui l'utilise est arrêté.

Pourquoi utiliser l'espace de stockage Hyperdisk

Utilisez l'espace de stockage Hyperdisk si vous devez redimensionner et ajuster dynamiquement les IOPS ou le débit. Un volume Hyperdisk est généralement associé à un seul pod. Cette option d'espace de stockage est compatible avec le mode d'accès ReadWriteOnce. Vous pouvez choisir parmi les options d'espace de stockage Hyperdisk suivantes pour GKE en fonction de vos besoins en termes de prix et de performances :

  • Hyperdisk Throughput : optimisés pour la rentabilité du débit, qui peut atteindre 3 Go/s (taille d'E/S supérieure ou égale à 128 Ko). Il s'agit d'une bonne option si votre cas d'utilisation cible les analyses à scaling horizontal (par exemple, Hadoop ou Kafka), la restauration des données inactives à partir de serveurs de sauvegarde et les charges de travail sensibles au coût. Cette option d'espace de stockage est compatible avec les clusters GKE Autopilot et Standard.
  • Hyperdisk Extreme : optimisé pour les performances d'IOPS, avec plus de 320 000 IOPS provisionnées et un débit supérieur à 4,8 Go/s. Il s'agit d'une bonne option si vous déployez des charges de travail hautes performances, telles que des systèmes de gestion de bases de données. Cette option de stockage n'est compatible qu'avec les clusters standards.

Pour commencer à utiliser cette option d'espace de stockage, consultez les ressources suivantes :

Espace de stockage éphémère et brut (Local SSD)

Les disques Local SSD sont des disques physiques directement associés à vos nœuds. Ils peuvent offrir de meilleures performances, mais sont éphémères. Chaque volume Local SSD est associé à un nœud spécifique. Vous ne pouvez pas déplacer le volume vers un autre nœud.

Cette option d'espace de stockage est compatible avec les clusters GKE Standard. Autopilot est compatible avec la fonctionnalité Local SSD sur les machines A2 Ultra A100, sur les clusters et les pools de nœuds exécutant GKE 1.27 ou une version ultérieure.

L'espace de stockage éphémère sauvegardé par l'espace de stockage Local SSD sur GKE est lié au cycle de vie d'un pod. Lorsque votre pod est arrêté, l'espace de stockage éphémère associé au pod est également supprimé.

Pourquoi utiliser des disques Local SSD

L'utilisation de l'espace de stockage Local SSD dans les clusters GKE convient si vous avez besoin d'une mise en cache à chaud pour des bases de données et pour des analyses en temps réel, ou pour un espace de stockage éphémère optimisé pour le Flash offrant les latences les plus faibles. L'espace de stockage Local SSD peut être particulièrement efficace en tant que couche de mise en cache devant Cloud Storage pour les cas d'utilisation de l'IA/du ML, du traitement par lot, des analyses et des bases de données en mémoire.

Pour commencer à utiliser cette option d'espace de stockage, consultez les ressources suivantes :

Stockage de fichiers

Filestore fournit un système de fichiers partagé dans le cloud pour les données non structurées, avec un accès NFS. Les instances Filestore fonctionnent comme des serveurs de fichiers sur Google Cloud qui fournissent un stockage durable avec un accès ReadWriteMany pour vos clusters GKE. Les instances Filestore sont découplées de l'hôte et nécessitent une opération manuelle minimale. Les basculements de charge de travail sont fluides, car il n'y a pas d'opérations d'infrastructure pour associer ou dissocier les volumes.

Cette option d'espace de stockage est compatible avec les clusters GKE Autopilot et Standard. L'espace de stockage Filestore avec le niveau de service d'entreprise est défini par défaut sur la disponibilité régionale, tandis que les autres niveaux de service ont une disponibilité zonale. L'espace de stockage Filestore sur GKE est persistant, ce qui signifie que les données stockées dans vos instances sont conservées même si le pod qui l'utilise est arrêté.

Pourquoi utiliser l'espace de stockage Filestore

Utilisez l'espace de stockage Filestore si vos applications nécessitent un accès NFS, ainsi que plusieurs lecteurs et rédacteurs. Cette option d'espace de stockage est adaptée si votre cas d'utilisation implique les systèmes de gestion de contenu, la migration d'applications, l'analyse de données, le rendu et le traitement multimédia.

Pour plus de rentabilité, les multipartages Filestore pour GKE vous permettent de partager une instance Filestore de niveau entreprise de 10 Gio ou plus avec jusqu'à 80 PersistentVolumes.

Pour commencer à utiliser cette option d'espace de stockage, consultez les ressources suivantes :

Stockage d'objets (Cloud Storage FUSE)

Cloud Storage est un magasin d'objets pour des données binaires et d'objets, des blobs et des données non structurées. Le pilote CSI Cloud Storage FUSE gère l'intégration de Cloud Storage FUSE aux API Kubernetes pour consommer les buckets Cloud Storage existants en tant que volumes. Vous pouvez utiliser le pilote CSI Cloud Storage FUSE pour installer des buckets en tant que systèmes de fichiers sur des nœuds GKE.

Le pilote CSI Cloud Storage FUSE est compatible avec les modes d'accès ReadWriteMany, ReadOnlyMany et ReadWriteOnce sur les clusters GKE Autopilot et Standard. Les objets Cloud Storage ont une disponibilité régionale. Les données Cloud Storage sur GKE sont persistantes, ce qui signifie que les données stockées dans vos buckets sont conservées, même si le pod qui l'utilise est arrêté.

Pourquoi utiliser Cloud Storage FUSE

L'option Cloud Storage FUSE est adaptée si vous avez besoin d'une sémantique de fichier devant Cloud Storage pour la portabilité. Cloud Storage FUSE est également un choix courant pour les développeurs qui souhaitent stocker et accéder à des entraînements de machine learning (ML) et modéliser des données en tant qu'objets dans Cloud Storage.

Pour commencer à utiliser cette option d'espace de stockage, consultez les ressources suivantes :

Bases de données gérées

Une base de données gérée, telle que Cloud SQL ou Spanner, permet de réduire les coûts opérationnels et elle est optimisée pour l'infrastructure Google Cloud. Les bases de données gérées demandent moins d'efforts en termes de maintenance et de fonctionnement qu'une base de données que vous déployez directement dans Kubernetes.

Pourquoi utiliser des bases de données gérées

L'utilisation d'une base de données gérée Google Cloud permet à vos charges de travail avec état sur GKE d'accéder aux données persistantes tout en automatisant des tâches de maintenance telles que les sauvegardes, l'application de correctifs et le scaling. Vous créez une base de données, compilez votre application et laissez Google Cloud la faire évoluer pour vous. Toutefois, cela signifie également que vous n'avez peut-être pas accès à la version exacte d'une base de données, à l'extension ou au type de base de données exact souhaité.

GKE permet de se connecter aux services de base de données gérés par Google Cloud, y compris :

Pour commencer à utiliser cette option d'espace de stockage, consultez les ressources suivantes :

Artefacts de build (Artifact Registry)

Artifact Registry est un gestionnaire de dépôts pour les images de conteneurs, les packages du système d'exploitation et les packages de langages que vous créez et déployez.

Pourquoi utiliser Artifact Registry

Artifact Registry est une option appropriée pour stocker vos images de conteneurs privées, vos graphiques Helm et d'autres artefacts de build.

Pour extraire des images de dépôts Docker Artifact Registry vers GKE, consultez la section Déployer sur Google Kubernetes Engine de la documentation Artifact Registry.

Étapes suivantes