Configuration du stockage
Concepts du stockage Kubernetes
Kubernetes fournit une couche d’abstraction de l’infrastructure sur la pile technique de virtualisation sous-jacente (facultatif) et le matériel. Kubernetes rend abstrait le stockage via des classes de stockage. Lorsque vous approvisionnez un pod, vous pouvez spécifier une classe de stockage pour chaque volume. Au moment du provisionnement du pod, le provisionneur de la classe de stockage est appelé pour approvisionner le stockage, puis un volume persistant est créé sur ce stockage provisionné et enfin, le pod est monté sur le volume persistant par une revendication de volume persistant.
Kubernetes offre aux fournisseurs d’infrastructure de stockage un moyen d’introduire des pilotes (également appelés « modules complémentaires » ou « add-ons ») qui étendent Kubernetes. Les modules complémentaires de stockage sont conformes au standard de Container Storage Interface. Vous trouverez des dizaines de modules complémentaires dans cette liste des pilotes CSI non définitive. Le pilote CSI spécifique que vous utilisez dépend de facteurs tels que le fait que vous exécutiez un service Kubernetes géré et hébergé dans le cloud ou le fournisseur OEM que vous utilisez pour votre matériel.
Pour afficher les classes de stockage configurées dans votre cluster Kubernetes, exécutez cette commande :
kubectl get storageclass
Exemple de sortie d’un cluster Azure Kubernetes Service (AKS) :
NAME PROVISIONER AGE
azurefile kubernetes.io/azure-file 15d
azurefile-premium kubernetes.io/azure-file 15d
default (default) kubernetes.io/azure-disk 4d3h
managed-premium kubernetes.io/azure-disk 4d3h
Vous pouvez obtenir des détails sur une classe de stockage en exécutant la commande suivante :
kubectl describe storageclass/<storage class name>
Exemple :
kubectl describe storageclass/azurefile
Name: azurefile
IsDefaultClass: No
Annotations: kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}
Provisioner: kubernetes.io/azure-file
Parameters: skuName=Standard_LRS
AllowVolumeExpansion: True
MountOptions: <none>
ReclaimPolicy: Delete
VolumeBindingMode: Immediate
Events: <none>
Vous pouvez voir les volumes persistants actuellement provisionnés et les revendications de volume persistant en exécutant les commandes suivantes :
kubectl get persistentvolumes -n <namespace>
kubectl get persistentvolumeclaims -n <namespace>
Exemple d’affichage de volumes persistants :
kubectl get persistentvolumes -n arc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da 15Gi RWO Delete Bound arc/sqldemo11-data-claim default 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa 15Gi RWO Delete Bound arc/data-metricsdb-0 default 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665 10Gi RWO Delete Bound arc/sqldemo11-logs-claim default 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad 15Gi RWO Delete Bound arc/data-controller default 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91 10Gi RWO Delete Bound arc/logs-controller default 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493 10Gi RWO Delete Bound arc/logs-metricsdb-0 default 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c 10Gi RWO Delete Bound arc/sqldemo10-logs-claim default 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513 15Gi RWO Delete Bound arc/sqldemo10-data-claim default 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5 15Gi RWO Delete Bound arc/data-controldb default 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb 10Gi RWO Delete Bound arc/logs-controldb default 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4 10Gi RWO Delete Bound arc/logs-logsdb-0 default 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd 15Gi RWO Delete Bound arc/data-logsdb-0 default 7d14h
Exemple d’affichage de revendications de volume persistant :
kubectl get persistentvolumeclaims -n arc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-controldb Bound pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5 15Gi RWO default 7d14h
data-controller Bound pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad 15Gi RWO default 7d14h
data-logsdb-0 Bound pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd 15Gi RWO default 7d14h
data-metricsdb-0 Bound pvc-3e772f20-ed89-4642-b34d-8bb11b088afa 15Gi RWO default 7d14h
logs-controldb Bound pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb 10Gi RWO default 7d14h
logs-controller Bound pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91 10Gi RWO default 7d14h
logs-logsdb-0 Bound pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4 10Gi RWO default 7d14h
logs-metricsdb-0 Bound pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493 10Gi RWO default 7d14h
sqldemo10-data-claim Bound pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513 15Gi RWO default 7d14h
sqldemo10-logs-claim Bound pvc-8e2cacbc-e953-4901-8591-e77df9af309c 10Gi RWO default 7d14h
sqldemo11-data-claim Bound pvc-07fc7b9f-9a37-4796-9442-4405147120da 15Gi RWO default 7d4h
sqldemo11-logs-claim Bound pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665 10Gi RWO default 7d4h
Facteurs à prendre en compte lors du choix de la configuration de votre stockage
La sélection de la classe de stockage appropriée est importante pour la résilience et les performances des données. Si vous choisissez une classe de stockage incorrecte, vous risquez de perdre des données en cas de panne matérielle ou d’obtenir de moins bonnes performances.
Il existe en général deux types de stockage :
- Stockage local - stockage provisionné sur des disques durs locaux sur un nœud donné. Ce type de stockage peut être idéal en termes de performances, mais il demande une conception spécifique de la redondance des données via la réplication des données sur plusieurs nœuds.
- Stockage partagé distant - stockage provisionné sur un dispositif de stockage distant, par exemple un SAN, un NAS ou un service de stockage cloud, comme EBS ou Azure Files. Ce type de stockage fournit généralement une redondance des données automatique, mais il n’est généralement pas aussi rapide que le stockage local.
Classes de stockage NFS
Selon la configuration de votre serveur NFS et de votre provisionneur de classe de stockage, vous devrez peut-être définir supplementalGroups dans les configurations de pod pour les instances de base de données et vous devrez peut-être modifier la configuration du serveur NFS pour utiliser les ID de groupe transmis par le client (par opposition à l’examen des ID de groupe sur le serveur à l’aide de l’ID d’utilisateur transmis). Consultez votre administrateur NFS pour déterminer si c’est le cas.
La propriété supplementalGroups prend un tableau de valeurs que vous pouvez définir lors du déploiement. Le contrôleur de données Azure Arc les applique à toutes les instances de base de données qu’il crée.
Pour définir cette propriété, exécutez la commande suivante :
az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'
Configuration du stockage du contrôleur de données
Certains services dans Azure Arc pour les services de données dépendent de la configuration pour utiliser un stockage partagé distant, car les services n’ont pas la capacité de répliquer les données. Ces services se trouvent dans la collection de pods du contrôleur de données :
| service | Revendications de volume persistant |
|---|---|
| OpenSearch | <namespace>/logs-logsdb-0, <namespace>/data-logsdb-0 |
| InfluxDB | <namespace>/logs-metricsdb-0, <namespace>/data-metricsdb-0 |
| Instance SQL du contrôleur | <namespace>/logs-controldb, <namespace>/data-controldb |
| Service d’API du contrôleur | <namespace>/data-controller |
Au moment où le contrôleur de données est provisionné, la classe de stockage à utiliser pour chacun de ces volumes persistants est spécifiée en passant le paramètre --storage-class | -sc à la commande az arcdata dc create ou en définissant les classes de stockage dans le fichier de modèle de déploiement control.json utilisé. Si vous utilisez le portail Azure pour créer le contrôleur de données en mode directement connecté, le modèle de déploiement que vous choisissez possède la classe de stockage prédéfinie dans le modèle ou vous pouvez sélectionner un modèle qui n'a pas de classe de stockage prédéfinie. Si votre modèle ne définit pas de classe de stockage, le portail vous en demande une. Si vous utilisez un modèle de déploiement personnalisé, vous pouvez spécifier la classe de stockage.
Les modèles de déploiement fournis d’origine spécifient une classe de stockage par défaut appropriée pour l’environnement cible, mais elle peut être remplacée au moment du déploiement. Pour modifier la configuration de la classe de stockage pour les pods de contrôleur de données au moment du déploiement, consultez les étapes détaillées pour créer des modèles de configuration personnalisés.
Si vous définissez la classe de stockage à l'aide du paramètre --storage-class ou -sc, cette classe de stockage est utilisée à la fois pour les classes de stockage de journaux et de données. Si vous définissez les classes de stockage dans le fichier de modèle de déploiement, vous pouvez spécifier des classes de stockage différentes pour les journaux et pour les données.
Voici les facteurs importants à prendre en compte lors du choix d’une classe de stockage pour les pods de contrôleur de données :
- Vous devez utiliser une classe de stockage partagée distante afin de garantir la durabilité des données et que, si un pod ou un nœud est défaillant, quand le pod est rétabli, il peut se reconnecter au volume persistant.
- Les données écrites dans l’instance SQL du contrôleur, dans la base de données des métriques et dans la base de données des journaux sont généralement relativement peu volumineuses et ne sont pas sensibles à la latence : un stockage avec des performances ultrarapides n’est donc pas critique. Si vous avez des utilisateurs qui utilisent fréquemment les interfaces Grafana et Kibana, et que vous avez un grand nombre d’instances de base de données, vos utilisateurs pourraient tirer un bénéfice d’un stockage plus rapide.
- La capacité de stockage nécessaire varie en fonction du nombre d’instances de base de données que vous avez déployées, car les journaux et les métriques sont collectés pour chaque instance de base de données. Les données sont conservées dans les bases de données des journaux et des métriques pendant deux (2) semaines avant d’être supprimées.
- Changer la classe de stockage après le déploiement est difficile, non documenté et non pris en charge. Veillez à choisir la classe de stockage correctement au moment du déploiement.
Remarque
Si aucune classe de stockage n'est spécifiée, la classe de stockage par défaut est utilisée. Il ne peut y avoir qu’une seule classe de stockage par défaut par cluster Kubernetes. Vous pouvez changer la classe de stockage par défaut.
Configuration du stockage de l’instance de base de données
Chaque instance de base de données a des volumes persistants pour les données, pour les journaux et pour les sauvegardes. Les classes de stockage de ces volumes persistants peuvent être spécifiées au moment du déploiement. Si aucune classe de stockage n'est spécifiée, la classe de stockage par défaut est utilisée.
Lorsque vous créez une instance à l'aide de az sql mi-arc create ou az postgres server-arc create, vous pouvez utiliser quatre paramètres pour définir les classes de stockage :
| Nom du paramètre, nom abrégé | Utilisé pour |
|---|---|
--storage-class-data, -d |
Classe de stockage pour tous les fichiers de données (.mdf, ndf). Si elle n’est pas spécifiée, la valeur par défaut est la classe de stockage pour le contrôleur de données. |
--storage-class-logs, -g |
Classe de stockage pour tous les fichiers journaux. Si elle n’est pas spécifiée, la valeur par défaut est la classe de stockage pour le contrôleur de données. |
--storage-class-data-logs |
Classe de stockage pour les fichiers journaux de transactions de la base de données. Si elle n’est pas spécifiée, la valeur par défaut est la classe de stockage pour le contrôleur de données. |
--storage-class-backups |
Classe de stockage pour tous les fichiers de sauvegarde. Si elle n’est pas spécifiée, la valeur par défaut est la classe de stockage pour les données (--storage-class-data).Utilisez une classe de stockage compatible ReadWriteMany (RWX) pour les sauvegardes. En savoir plus sur le modes d'accès. |
Avertissement
Si vous ne spécifiez pas de classe de stockage pour les sauvegardes, le déploiement utilise la classe de stockage spécifiée pour les données. Si cette classe de stockage n’est pas compatible RWX, la restauration à un instant dans le passé peut ne pas fonctionner comme vous le souhaitez.
Le tableau ci-dessous liste les chemins dans le conteneur Azure SQL Managed Instance qui est mappé au volume persistant pour les données et les journaux :
| Nom du paramètre, nom abrégé | Chemin dans le conteneur mssql-miaa |
Description |
|---|---|---|
--storage-class-data, -d |
/var/opt | Contient des répertoires pour l’installation de mssql et d’autres processus système. Le répertoire mssql contient les données par défaut (y compris les journaux des transactions), le journal des erreurs et les répertoires de sauvegarde |
--storage-class-logs, -g |
/var/log | Contient des répertoires qui stockent la sortie de la console (stderr, stdout) ainsi que d’autres informations de journalisation des processus au sein du conteneur |
Le tableau ci-dessous liste les chemins dans le conteneur de l’instance PostgreSQL qui est mappé au volume persistant pour les données et les journaux :
| Nom du paramètre, nom abrégé | Chemin au sein du conteneur postgres | Description |
|---|---|---|
--storage-class-data, -d |
/var/opt/postgresql | Contient des répertoires de données et de journaux pour l’installation de postgres |
--storage-class-logs, -g |
/var/log | Contient des répertoires qui stockent la sortie de la console (stderr, stdout) ainsi que d’autres informations de journalisation des processus au sein du conteneur |
Chaque instance de base de données dispose d'un volume persistant distinct pour les fichiers de données, les journaux et les sauvegardes. Cela signifie qu'il existe une séparation des E/S pour chacun de ces types de fichiers, en fonction de la manière dont le fournisseur de volume provisionne le stockage. Chaque instance de base de données a ses propres revendications de volume persistant et ses propres volumes persistants.
S'il existe plusieurs bases de données sur une instance de base de données donnée, toutes les bases de données utilisent la même revendication de volume persistant, le même volume persistant et la même classe de stockage. Toutes les sauvegardes – les sauvegardes différentielles de journaux et les sauvegardes complètes utilisent la même revendication de volume persistant et le même volume persistant. Les revendications de volume persistant pour les pods d’instances de base de données sont présentées ci-dessous :
| Instance | Revendications de volume persistant |
|---|---|
| Azure SQL Managed Instance | <namespace>/logs-<instance name>-0, <namespace>/data-<instance name>-0 |
| Instance Azure Database pour PostgreSQL | <namespace>/logs--<instance name>-0, <namespace>/data--<instance name>-0 |
| Azure PostgreSQL | <namespace>/logs-<instance name>-<ordinal>, <namespace>/data-<instance name>-0 |
Voici les facteurs importants à prendre en compte lors du choix d’une classe de stockage pour les pods d’instances de base de données :
- À compter de la version de février 2022 des services de données Azure Arc, vous devez spécifier une classe de stockage compatible ReadWriteMany (RWX) pour les sauvegardes. En savoir plus sur le modes d'accès. Si aucune classe de stockage n’est spécifiée pour les sauvegardes, la classe de stockage par défaut dans Kubernetes est utilisée et, si elle n’est pas RWX, le déploiement d’une instance gérée Azure SQL peut échouer.
- Les instances de base de données peuvent être déployées dans un modèle de pod unique ou dans un modèle à plusieurs pods. Une instance d’Azure SQL Managed Instance de niveau tarifaire Usage général est un exemple de modèle de pod unique. Une instance d’Azure SQL Managed Instance de niveau tarifaire Critique pour l’entreprise est un exemple de modèle à plusieurs pods. Les instances de base de données déployées avec le modèle de pod unique doivent utiliser une classe de stockage partagée distante afin de garantir la durabilité des données et que, si un pod ou un nœud est défaillant, quand le pod est rétabli, il peut se reconnecter au volume persistant. En revanche, une instance managée Azure SQL à haute disponibilité utilise des groupes de disponibilité Always On pour répliquer les données d’une instance vers une autre de façon synchrone ou asynchrone. En particulier dans le cas où les données sont répliquées de façon synchrone, il y a toujours plusieurs copies des données, en général trois copies. Pour cette raison, il est possible d’utiliser un stockage local ou des classes de stockage partagé distant pour les fichiers de données et les fichiers journaux. Si vous utilisez un stockage local, les données sont toujours préservées, même dans le cas de la défaillance d’un pod, d’un nœud ou d’un matériel de stockage, car il existe plusieurs copies des données. Étant donné cette flexibilité, vous pouvez choisir d’utiliser un stockage local pour de meilleures performances.
- Les performances de la base de données sont en grande partie fonction du débit d’E/S d’un dispositif de stockage donné. Si votre base de données fait l’objet de lectures ou d’écritures intensives, vous devez choisir une classe de stockage qui a un matériel conçu pour ce type de charge de travail. Par exemple, si votre base de données est principalement utilisée pour des écritures, vous pouvez choisir un stockage local avec un niveau RAID 0. Si votre base de données est principalement utilisée pour des lectures d’une petite quantité de « données chaudes », mais qu’il existe un grand volume de stockage global des données froides, vous pouvez choisir un périphérique SAN avec des capacités de stockage hiérarchisé. Le choix de la classe de stockage appropriée n’est pas très différent du choix du type de stockage que vous utiliseriez pour une base de données.
- Si vous utilisez un fournisseur de volumes de stockage local, assurez-vous que les volumes locaux provisionnés pour les données, les journaux et les sauvegardes atterrissent chacun sur des périphériques de stockage sous-jacents différents afin d'éviter les conflits sur les E/S de disque. Le système d’exploitation doit également se trouver sur un volume monté sur un ou plusieurs disques distincts. Il s’agit essentiellement des mêmes conseils que ceux qui seraient à suivre pour une instance de base de données sur un matériel physique.
- Étant donné que toutes les bases de données sur une instance spécifique partagent une revendication de volume persistant et un volume persistant, veillez à ne pas colocaliser les instances de base de données occupées sur la même instance de base de données. Si possible, placez séparément les bases de données occupées dans leurs propres instances de base de données pour éviter la contention des E/S. En outre, utilisez le ciblage des étiquettes de nœud pour placer les instances de base de données sur des nœuds distincts afin de distribuer le trafic d’E/S global entre plusieurs nœuds. Si vous utilisez la virtualisation, veillez à envisager de distribuer le trafic d'E/S non seulement au niveau du nœud, mais également à l'activité d'E/S combinée effectuée par toutes les machines virtuelles de nœud sur un hôte physique donné.
Estimation des besoins en stockage
Chaque pod qui contient des données avec état utilise au moins deux volumes persistants : un volume persistant pour les données et un autre pour les journaux. Le tableau ci-dessous indique le nombre de volumes persistants nécessaires pour un seul contrôleur de données, une instance Azure SQL Managed Instance, une instance Azure Database pour PostgreSQL et une instance Azure PostgreSQL Hyperscale :
| Type de ressource | Nombre de pods avec état | Nombre de volumes persistants nécessaires |
|---|---|---|
| Contrôleur de données | 4 (control, controldb, logsdb, metricsdb) |
4 * 2 = 8 |
| Azure SQL Managed Instance | 1 | 2 |
| Azure PostgreSQL | 1 | 2 |
Le tableau ci-dessous indique le nombre total de volumes persistants requis pour un exemple de déploiement :
| Type de ressource | Nombre d’instances | Nombre de volumes persistants nécessaires |
|---|---|---|
| Contrôleur de données | 1 | 4 * 2 = 8 |
| Azure SQL Managed Instance | 5 | 5 * 2 = 10 |
| Azure PostgreSQL | 5 | 5 * 2 = 10 |
| Nombre total de volumes persistants | 8 + 10 + 10 = 28 |
Ce calcul peut être utilisé pour planifier le stockage de votre cluster Kubernetes en fonction de l’environnement ou du provisionneur de stockage. Par exemple, si le provisionneur de stockage local est utilisé pour un cluster Kubernetes avec cinq (5) nœuds, pour l’exemple de déploiement ci-dessus, chaque nœud nécessite du stockage pour au moins 10 volumes persistants. De même, lors du provisionnement d’un cluster Azure Kubernetes Service (AKS) avec cinq (5) nœuds, il est important de choisir une taille de machine virtuelle appropriée pour le pool de nœuds pour que 10 disques de données puissent y être attachés. Vous trouverez plus d’informations sur la taille des nœuds pour les besoins en stockage des nœuds AKS ici.
Choix de la classe de stockage appropriée
Sites locaux et périphériques
Microsoft et ses partenaires OEM, OS et Kubernetes ont un programme de validation pour les services de données Azure Arc. Ce programme fournit des résultats de tests comparables à partir d’une boîte à outils de tests de certification. Les tests évaluent la compatibilité des fonctionnalités, les résultats des tests de résistance, ainsi que les performances et l'évolutivité. Les résultats des tests indiquent le système d'exploitation utilisé, la distribution Kubernetes utilisée, le matériel utilisé, le module complémentaire CSI utilisé et les classes de stockage utilisées. Cela aide les clients à choisir la classe de stockage, le système d'exploitation, la distribution Kubernetes et le matériel les mieux adaptés à leurs besoins. Vous trouverez plus d’informations sur ce programme et les résultats des tests ici.
Cloud public, services Kubernetes managés
Pour les services Kubernetes managés et basés sur le cloud public, nous pouvons formuler les recommandations suivantes :
| Service cloud public | Recommandation |
|---|---|
| Azure Kubernetes Service (AKS) | Azure Kubernetes Service (AKS) a deux types de stockage : Azure Files et Disques managés Azure. Chaque type de stockage a deux niveaux tarifaires/de performance : Standard (HDD) et Premium (SSD). Ainsi, les quatre classes de stockage fournies dans AKS sont azurefile (niveau Standard d’Azure Files), azurefile-premium (niveau Premium d’Azure Files), default (niveau Standard de Disques Azure) et managed-premium (niveau Premium de Disques Azure). La classe de stockage par défaut est default (niveau Standard de Disques Azure). Il existe des différences de prix substantielles entre les types et les niveaux que vous devriez prendre en compte. Pour les charges de travail de production avec des exigences de performances élevées, nous vous recommandons d’utiliser managed-premium pour toutes les classes de stockage. Pour les charges de travail de développement/test, les preuves de concept, etc., où le coût est un critère important, azurefile est l’option la moins coûteuse. Ces quatre options peuvent être utilisées dans les situations nécessitant un stockage partagé distant, car toutes les quatre correspondent à des dispositifs de stockage attachés à un réseau dans Azure. Pour plus d’informations, consultez Stockage AKS. |
| AWS Elastic Kubernetes Service (EKS) | Le service Elastic Kubernetes Service d’Amazon a une classe de stockage principale basée sur le pilote de stockage EBS CSI. Ceci est recommandé pour les charges de travail de production. Il existe un nouveau pilote de stockage, Pilote de stockage EFS CSI, qui peut être ajouté à un cluster EKS, mais il est actuellement en phase bêta et susceptible d’être modifié. Bien qu’AWS indique que ce pilote de stockage est pris en charge pour la production, nous ne recommandons pas de l’utiliser, car il est toujours en version bêta et susceptible d’être modifié. La classe de stockage EBS est la classe par défaut et elle est appelée gp2. Pour plus d’informations, consultez Stockage EKS. |
| Moteur Google Kubernetes (GKE) | Google Kubernetes Engine (GKE) n'a qu'une seule classe de stockage appelée standard. Cette classe est utilisée pour les disques persistants GCE. Comme c’est la seule, elle est également la classe de stockage par défaut. Bien qu’il existe un provisionneur de volume statique local pour GKE que vous pouvez utiliser avec des disques SSD en attachement direct, nous vous déconseillons de l’utiliser, car il n’est pas maintenu ni pris en charge par Google. Pour plus d’informations, consultez Stockage GKE. |
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour