Opslagconfiguratie

Kubernetes-opslagconcepten

Kubernetes biedt een infrastructuurabstringslaag over de onderliggende virtualisatie-techstack (optioneel) en hardware. De manier waarop Kubernetes opslag abstract maakt, is via Storage klassen. Wanneer u een pod inrichten, kunt u een opslagklasse opgeven voor elk volume. Op het moment dat de pod wordt ingericht, wordt de inrichting van de opslagklasse aangeroepen om de opslag in terichten. Vervolgens wordt er een permanent volume gemaakt op die inrichtende opslag. Vervolgens wordt de pod door een permanente volumeclaim aan het permanente volume bevestigd.

Kubernetes biedt providers van opslaginfrastructuur een manier om stuurprogramma's (ook wel 'Addons' genoemd) in te voegen die Kubernetes uitbreiden. Storage addons moeten voldoen aan de Container Storage Interface-standaard. Er zijn tientallen toevoegingen te vinden in deze niet-definitieve lijst met CSI-stuurprogramma's. Welk CSI-stuurprogramma u gebruikt, is afhankelijk van factoren zoals of u wordt uitgevoerd in een in de cloud gehoste, beheerde Kubernetes-service of welke OEM-provider u gebruikt voor uw hardware.

U kunt weergeven welke opslagklassen zijn geconfigureerd in uw Kubernetes-cluster door deze opdracht uit te voeren:

kubectl get storageclass

Voorbeelduitvoer van een Azure Kubernetes Service (AKS)-cluster:

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

U kunt details over een opslagklasse krijgen door deze opdracht uit te voeren:

kubectl describe storageclass/<storage class name>

Voorbeeld:

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>

U kunt de momenteel inrichtende permanente volumes en permanente volumeclaims zien door de volgende opdrachten uit te voeren:

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Voorbeeld van het weergeven van permanente volumes:


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

Voorbeeld van het weergeven van permanente volumeclaims:


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

Factoren om rekening mee te houden bij het kiezen van uw opslagconfiguratie

Het selecteren van de juiste opslagklasse is belangrijk voor de tolerantie en prestaties van gegevens. Als u de verkeerde opslagklasse kiest, kunnen uw gegevens risico lopen op totaal gegevensverlies in het geval van een hardwarestoring of leiden tot minder optimale prestaties.

Er zijn doorgaans twee soorten opslag:

  • Lokale opslag: opslag die is ingericht op lokale harde schijven op een bepaald knooppunt. Dit soort opslag kan ideaal zijn op het gebied van prestaties, maar vereist specifiek ontwerpen voor gegevens redundantie door de gegevens over meerdere knooppunten te repliceren.
  • Externe, gedeelde opslag: opslag die is ingericht op een extern opslagapparaat, bijvoorbeeld een SAN, NAS of cloudopslagservice zoals EBS of Azure Files. Dit type opslag biedt over het algemeen automatisch gegevens redundantie, maar is niet zo snel als lokale opslag.

Op NFS gebaseerde opslagklassen

Afhankelijk van de configuratie van uw NFS-server en opslagklasse-inrichting, moet u mogelijk de instellen in de podconfiguraties voor database-exemplaren en moet u mogelijk de configuratie van de NFS-server wijzigen om de groeps-id's te gebruiken die worden doorgegeven door de client (in plaats van groeps-id's op te zoeken op de server met behulp van de doorgegeven supplementalGroups gebruikers-id). Neem contact op met uw NFS-beheerder om te bepalen of dit het geval is.

De eigenschap maakt gebruik van een matrix met waarden en kan worden ingesteld als onderdeel van de implementatie van de Azure Arc-gegevenscontroller en wordt gebruikt door database-exemplaren die zijn geconfigureerd door de supplementalGroups Azure Arc-gegevenscontroller.

Voer de volgende opdracht uit om deze eigenschap in te stellen:

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

Opslagconfiguratie van gegevenscontroller

Sommige services in Azure Arc voor gegevensservices zijn afhankelijk van de configuratie voor het gebruik van externe, gedeelde opslag, omdat de services niet de mogelijkheid hebben om de gegevens te repliceren. Deze services vindt u in de verzameling gegevenscontrollerpods:

Service Permanente volumeclaims
ElasticSearch <namespace>/logs-logsdb-0, <namespace>/data-logsdb-0
InfluxDB <namespace>/logs-metricsdb-0, <namespace>/data-metricsdb-0
Controller SQL-exemplaar <namespace>/logs-controldb, <namespace>/data-controldb
Controller-API-service <namespace>/data-controller

Op het moment dat de gegevenscontroller wordt ingericht, wordt de opslagklasse die moet worden gebruikt voor elk van deze permanente volumes opgegeven door de opslagklasse --storage-class door te | -sc parameter voor de opdracht of door het instellen van de opslagklassen in de control.jsaz arcdata dc create implementatiesjabloonbestand dat wordt gebruikt. Als u de Azure Portal gebruikt om de gegevenscontroller te maken in de modus rechtstreeks verbonden, wordt in de implementatiesjabloon die u kiest de opslagklasse vooraf gedefinieerd in de sjabloon of als u een sjabloon selecteert die geen vooraf gedefinieerde opslagklasse heeft, wordt u gevraagd er een te maken. Als u een aangepaste implementatiesjabloon gebruikt, kunt u de opslagklasse opgeven.

Voor de implementatiesjablonen die standaard worden geleverd, is een standaardopslagklasse opgegeven die geschikt is voor de doelomgeving, maar deze kan tijdens de implementatie worden overschreven. Zie de gedetailleerde stappen voor het wijzigen van het implementatieprofiel om de configuratie van de opslagklasse voor de pods van de gegevenscontroller tijdens de implementatie te wijzigen.

Als u de opslagklasse in stelt met behulp van de | -sc parameter de opslagklasse wordt gebruikt voor logboek- en gegevensopslagklassen. Als u de opslagklassen in het implementatiesjabloonbestand in stelt, kunt u verschillende opslagklassen opgeven voor logboeken en gegevens.

Belangrijke factoren om rekening mee te houden bij het kiezen van een opslagklasse voor de gegevenscontrollerpods:

  • U moet een externe, gedeelde opslagklasse gebruiken om de duurzaamheid van gegevens te garanderen en om ervoor te zorgen dat als een pod of knooppunt uitkomt, deze opnieuw verbinding kan maken met het permanente volume wanneer de pod weer wordt gemaakt.
  • De gegevens die naar de controller worden geschreven SQL exemplaar, database met metrische gegevens en logboeken DB is doorgaans redelijk laag volume en niet gevoelig voor latentie, zodat ultrasnelle prestatieopslag niet essentieel is. Als u gebruikers hebt die vaak de Grafana- en Kibana-interfaces gebruiken en u een groot aantal database-exemplaren hebt, kunnen uw gebruikers profiteren van een snellere opslag.
  • De vereiste opslagcapaciteit is variabel met het aantal database-exemplaren dat u hebt geïmplementeerd, omdat logboeken en metrische gegevens worden verzameld voor elk database-exemplaar. Gegevens worden twee (2) weken bewaard in de database met logboeken en metrische gegevens voordat ze worden verwijderd.
  • Het wijzigen van de opslagklasse na de implementatie is moeilijk, niet gedocumenteerd en wordt niet ondersteund. Zorg ervoor dat u de opslagklasse juist kiest tijdens de implementatie.

Notitie

Als er geen opslagklasse is opgegeven, wordt de standaardopslagklasse gebruikt. Er kan slechts één standaardopslagklasse per Kubernetes-cluster zijn. U kunt de standaardopslagklasse wijzigen.

Opslagconfiguratie van database-exemplaar

Elk database-exemplaar heeft gegevens, logboeken en back-ups van permanente volumes. De opslagklassen voor deze permanente volumes kunnen tijdens de implementatie worden opgegeven. Als er geen opslagklasse is opgegeven, wordt de standaardopslagklasse gebruikt.

Wanneer u een exemplaar maakt met az sql mi-arc create of , zijn er vier parameters die kunnen worden gebruikt om de az postgres arc-server create opslagklassen in te stellen:

Parameternaam, korte naam Gebruikt voor
--storage-class-data, -d Wordt gebruikt om de opslagklasse op te geven voor alle gegevensbestanden, inclusief transactielogboekbestanden
--storage-class-logs, -g Wordt gebruikt om de opslagklasse voor alle logboekbestanden op te geven
--storage-class-data-logs Wordt gebruikt om de opslagklasse voor de logboekbestanden voor databasetransacties op te geven.
--storage-class-backups Wordt gebruikt om de opslagklasse voor alle back-upbestanden op te geven.

In de onderstaande tabel staan de paden in de Azure SQL Managed Instance-container die is toe te passen op het permanente volume voor gegevens en logboeken:

Parameternaam, korte naam Pad in de mssql-miaa-container Description
--storage-class-data, -d /var/opt Bevat directories voor de mssql-installatie en andere systeemprocessen. De mssql-map bevat standaardgegevens (inclusief transactielogboeken), foutenlogboeken & back-updirectory's
--storage-class-logs, -g /var/log Bevat directories waarin console-uitvoer wordt opgeslagen (stderr, stdout), andere logboekregistratiegegevens van processen in de container

In de onderstaande tabel staan de paden in de PostgreSQL-exemplaarcontainer die is toe te passen op het permanente volume voor gegevens en logboeken:

Parameternaam, korte naam Pad in postgres-container Description
--storage-class-data, -d /var/opt/postgresql Bevat gegevens en logboekdirecties voor de postgres-installatie
--storage-class-logs, -g /var/log Bevat directories waarin console-uitvoer wordt opgeslagen (stderr, stdout), andere logboekregistratiegegevens van processen in de container

Elk database-exemplaar heeft een afzonderlijk permanent volume voor gegevensbestanden, logboeken en back-ups. Dit betekent dat de I/O wordt gescheiden voor elk van deze typen bestanden, afhankelijk van de manier waarop de volume-inrichting opslag inrichten. Elk database-exemplaar heeft eigen permanente volumeclaims en permanente volumes.

Als er meerdere databases op een bepaald database-exemplaar staan, gebruiken alle databases dezelfde permanente volumeclaim, hetzelfde permanente volume en dezelfde opslagklasse. Alle back-ups: zowel differentiële logboekback-ups als volledige back-ups gebruiken dezelfde permanente volumeclaim en hetzelfde permanente volume. De permanente volumeclaims voor de pods van het database-exemplaar worden hieronder weergegeven:

Exemplaar Permanente volumeclaims
Azure SQL Managed Instance <namespace>/logs-<instance name>-0, <namespace>/data-<instance name>-0
Azure Database for PostgreSQL-exemplaar <namespace>/logs--<instance name>-0, <namespace>/data--<instance name>-0
Azure PostgreSQL HyperScale <namespace>/logs-<instance namme>-<ordinal>, <namespace>/data-<instance namme>-<ordinal> (Rangtellijk varieert van 0 tot W, waarbij W het aantal werksters is)

Belangrijke factoren om rekening mee te houden bij het kiezen van een opslagklasse voor de pods van het database-exemplaar:

  • Database-exemplaren kunnen worden geïmplementeerd in één podpatroon of in een patroon met meerdere pods. Een voorbeeld van één podpatroon is een prijscategorie voor algemeen gebruik van Azure SQL beheerd exemplaar. Een voorbeeld van een patroon met meerdere pods is een zeer beschikbare, bedrijfskritieke prijscategorie voor Azure SQL beheerd exemplaar. Database-exemplaren die zijn geïmplementeerd met het patroon voor één pod, moeten gebruikmaken van een externe, gedeelde opslagklasse om duurzaamheid van gegevens te garanderen en om ervoor te zorgen dat als een pod of knooppunt uit elkaar valt, deze opnieuw verbinding kan maken met het permanente volume wanneer de pod weer wordt gemaakt. Een azure SQL beheerd exemplaar met hoge beschikbaarheid maakt daarentegen gebruik van AlwaysOn-beschikbaarheidsgroepen om de gegevens synchroon of asynchroon van het ene naar het andere exemplaar te repliceren. Met name in het geval dat de gegevens synchroon worden gerepliceerd, zijn er altijd meerdere kopieën van de gegevens, meestal drie kopieën. Hierdoor is het mogelijk om lokale opslag of externe, gedeelde opslagklassen te gebruiken voor gegevens en logboekbestanden. Als u lokale opslag gebruikt, blijven de gegevens behouden, zelfs in het geval van een mislukte pod, knooppunt of opslaghardware, omdat er meerdere kopieën van de gegevens zijn. Gezien deze flexibiliteit kunt u ervoor kiezen om lokale opslag te gebruiken voor betere prestaties.
  • Databaseprestaties zijn grotendeels een functie van de I/O-doorvoer van een bepaald opslagapparaat. Als uw database veel lees- of schrijfwerk nodig heeft, moet u een opslagklasse kiezen met hardware die is ontworpen voor dat type werkbelasting. Als uw database bijvoorbeeld voornamelijk wordt gebruikt voor schrijf- of schrijfgegevens, kunt u lokale opslag met RAID 0 kiezen. Als uw database voornamelijk wordt gebruikt voor het lezen van een kleine hoeveelheid 'hot data', maar er sprake is van een grote totale hoeveelheid koude gegevens, kunt u een SAN-apparaat kiezen dat gelaagde opslag mogelijk maakt. Het kiezen van de juiste opslagklasse is niet anders dan het kiezen van het type opslag dat u voor elke database zou gebruiken.
  • Als u een lokale opslagvolume-inrichting gebruikt, moet u ervoor zorgen dat de lokale volumes die zijn ingericht voor gegevens, logboeken en back-ups elk op verschillende onderliggende opslagapparaten landen om te voorkomen dat er problemen zijn met de schijf-I/O. Het besturingssysteem moet zich ook op een volume dat is aan een afzonderlijke schijf(en) zijn bevestigd. Dit is in wezen dezelfde richtlijnen als voor een database-exemplaar op fysieke hardware.
  • Omdat alle databases op een bepaald exemplaar een permanente volumeclaim en een permanent volume delen, moet u ervoor zorgen dat u geen bezette database-exemplaren op hetzelfde database-exemplaar op dezelfde locatie hebt. Scheid indien mogelijk bezette databases op hun eigen database-exemplaren om I/O-problemen te voorkomen. Gebruik verder het doel van knooppuntlabels om database-exemplaren op afzonderlijke knooppunten te brengen, zodat al het I/O-verkeer over meerdere knooppunten wordt verdeeld. Als u virtualisatie gebruikt, moet u I/O-verkeer niet alleen op knooppuntniveau distribueren, maar ook de gecombineerde I/O-activiteit die door alle knooppunt-VM's op een bepaalde fysieke host wordt plaatsvinden.

Opslagvereisten schatten

Elke pod die stateful gegevens bevat, gebruikt ten minste twee permanente volumes: één permanent volume voor gegevens en een ander permanent volume voor logboeken. In de onderstaande tabel staat het aantal permanente volumes dat is vereist voor één gegevenscontroller, Azure SQL Managed instance, Azure Database for PostgreSQL-exemplaar en Azure PostgreSQL HyperScale-exemplaar:

Resourcetype Aantal stateful pods Vereist aantal permanente volumes
Gegevenscontroller 4 ( control , controldb , , logsdb metricsdb ) 4 * 2 = 8
Azure SQL Managed Instance 1 2
Azure Database for PostgreSQL-exemplaar 1 2
Azure PostgreSQL HyperScale 1 + W (W = aantal werknemers) 2 * (1 + W)

In de onderstaande tabel ziet u het totale aantal permanente volumes dat is vereist voor een voorbeeldimplementatie:

Resourcetype Aantal exemplaren Vereist aantal permanente volumes
Gegevenscontroller 1 4 * 2 = 8
Azure SQL Managed Instance 5 5 * 2 = 10
Azure Database for PostgreSQL-exemplaar 5 5 * 2 = 10
Azure PostgreSQL HyperScale 2 (aantal werknemers = 4 per exemplaar) 2 * 2 * (1 + 4) = 20
Totaal aantal permanente volumes 8 + 10 + 10 + 20 = 48

Deze berekening kan worden gebruikt om de opslag voor uw Kubernetes-cluster te plannen op basis van de opslag inrichtende omgeving. Als de lokale opslaginrichtende toepassing bijvoorbeeld wordt gebruikt voor een Kubernetes-cluster met vijf (5) knooppunten, is voor de voorbeeldimplementatie boven elk knooppunt ten minste opslag voor 10 permanente volumes vereist. Op dezelfde manier is het van essentieel belang bij het inrichten van een Azure Kubernetes Service-cluster (AKS) met vijf (5) knooppunten die een geschikte VM-grootte voor de knooppuntgroep kiezen, zodat er tien gegevensschijven kunnen worden gekoppeld. Meer informatie over het grootten van de knooppunten voor opslagbehoeften voor AKS-knooppunten vindt u hier.

De juiste opslagklasse kiezen

On-premises en edge-sites

Microsoft en haar OEM-, OS- en Kubernetes-partners hebben een validatieprogramma voor Azure Arc gegevensservices. Dit programma biedt klanten vergelijkbare testresultaten van een certificeringstesttoolkit. Met de tests worden de compatibiliteit van functies, stresstestresultaten en prestaties en schaalbaarheid geëvalueerd. Elk van deze testresultaten geeft het gebruikte besturingssysteem, de gebruikte Kubernetes-distributie, de gebruikte HW, de gebruikte CSI-invoegsel en de gebruikte opslagklassen aan. Hierdoor kunnen klanten de beste opslagklasse, het besturingssysteem, de Kubernetes-distributie en de hardware kiezen voor hun vereisten. Meer informatie over dit programma en de testresultaten vindt u hier.

Openbare cloud, beheerde Kubernetes-services

Voor beheerde Kubernetes-services in de openbare cloud kunnen we de volgende aanbevelingen doen:

Openbare cloudservice Aanbeveling
Azure Kubernetes Service (AKS) Azure Kubernetes Service (AKS) heeft twee typen opslag: Azure Files en Azure Managed Disks. Elk type opslag heeft twee prijs-/prestatielagen: Standard (HDD) en Premium (SSD). De vier opslagklassen die worden aangeboden in AKS zijn azurefile (Azure Files Standard-laag), azurefile-premium (Azure Files Premium-laag), default (Azure Disks Standard-laag) en managed-premium (Azure Disks Premium-laag). De standaardopslagklasse is default (Azure Disks Standard-laag). Er zijn aanzienlijke prijsverschillen tussen de typen en lagen die in uw beslissing moeten worden meegenomen. Voor productieworkloads met hoge prestatievereisten raden we u aan voor alle managed-premium opslagklassen te gebruiken. Voor werkbelastingen voor ontwikkelen/testen, testen van het concept, enzovoort, waarbij kosten een overweging azurefile zijn, is dat de minst dure optie. Alle vier de opties kunnen worden gebruikt in situaties waarin externe, gedeelde opslag is vereist, omdat ze alle network-attached storage apparaten in Azure. Meer informatie over AKS Storage.
AWS Elastic Kubernetes Service (EKS) De Elastische Kubernetes Service van Amazon heeft één primaire opslagklasse, op basis van het stuurprogramma voor EBS CSI-opslag. Dit wordt aanbevolen voor productieworkloads. Er is een nieuw opslag stuurprogramma - EFS CSI-opslag stuurprogramma - dat kan worden toegevoegd aan een EKS-cluster, maar het is momenteel in een bètafase en kan worden gewijzigd. Hoewel AWS zegt dat dit opslag stuurprogramma wordt ondersteund voor productie, raden we u aan dit niet te gebruiken omdat het nog in bètaversie is en kan worden gewijzigd. De EBS-opslagklasse is de standaardklasse en heet gp2 . Meer informatie over EKS Storage.
Google Kubernetes Engine (GKE) Google Kubernetes Engine (GKE) heeft slechts één opslagklasse met de naam , die wordt gebruikt voor standard permanente GCE-schijven. Omdat dit de enige is, is dit ook de standaardinstelling. Hoewel er een lokale, statische volume-inrichting voor GKE is die u kunt gebruiken met direct gekoppelde SSD's, raden we u af deze te gebruiken, omdat deze niet wordt onderhouden of ondersteund door Google. Meer informatie over GKE-opslag.