Opslagconfiguratie

Artikel
10/24/2023

Concepten voor Kubernetes-opslag

Kubernetes biedt een infrastructuurabstractielaag over de onderliggende virtualisatietechnologiestack (optioneel) en hardware. De manier waarop Kubernetes opslag abstraheert, is via Opslagklassen. Wanneer u een pod inricht, kunt u een opslagklasse opgeven voor elk volume. Op het moment dat de pod is ingericht, wordt de opslagklasse-inrichting aangeroepen om de opslag in te richten. Vervolgens wordt er een permanent volume gemaakt op die ingerichte opslag en wordt de pod gekoppeld aan het permanente volume door een permanente volumeclaim.

Kubernetes biedt een manier voor opslaginfrastructuurproviders om stuurprogramma's (ook wel 'Addons' genoemd) aan te sluiten waarmee Kubernetes wordt uitgebreid. Opslaginvoegtoepassingen moeten voldoen aan de Container Storage Interface-standaard. Er zijn tientallen invoegtoepassingen die te vinden zijn in deze niet-definitieve lijst met CSI-stuurprogramma's. Het specifieke CSI-stuurprogramma dat u gebruikt, is afhankelijk van factoren zoals of u in een in de cloud gehoste, beheerde Kubernetes-service of welke OEM-provider u gebruikt voor uw hardware.

Voer deze opdracht uit om de opslagklassen weer te geven die zijn geconfigureerd in uw Kubernetes-cluster:

kubectl get storageclass

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

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 ingerichte 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 waarmee u rekening moet houden bij het kiezen van uw opslagconfiguratie

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

Over het algemeen zijn er twee soorten opslag:

Lokale opslag : opslag die is ingericht op lokale harde schijven op een bepaald knooppunt. Dit soort opslag kan ideaal zijn in termen van prestaties, maar vereist specifiek ontwerpen voor gegevensredundantie 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 soort opslag biedt over het algemeen automatisch gegevensredundantie, maar is niet zo snel als lokale opslag kan zijn.

Op NFS gebaseerde opslagklassen

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

De supplementalGroups eigenschap gebruikt een matrix met waarden die u tijdens de implementatie kunt instellen. Azure Arc-gegevenscontroller past deze toe op database-exemplaren die worden gemaakt.

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 geen mogelijkheid hebben om de gegevens te repliceren. Deze services zijn te vinden in het verzamelen van pods voor gegevenscontrollers:

Onderhoud	Permanente volumeclaims
Opensearch	`<namespace>/logs-logsdb-0`, `<namespace>/data-logsdb-0`
InstroomDB	`<namespace>/logs-metricsdb-0`, `<namespace>/data-metricsdb-0`
SQL-exemplaar van controller	`<namespace>/logs-controldb`, `<namespace>/data-controldb`
Controller-API-service	`<namespace>/data-controller`

Op het moment dat de gegevenscontroller is ingericht, wordt de opslagklasse die moet worden gebruikt voor elk van deze permanente volumes opgegeven door de --storage-class | -sc-parameter op de az arcdata dc create opdracht of door de opslagklassen in te stellen in het sjabloonbestand control.json-implementatie dat wordt gebruikt. Als u Azure Portal gebruikt om de gegevenscontroller te maken in de direct verbonden modus, heeft de implementatiesjabloon die u kiest de opslagklasse vooraf gedefinieerd in de sjabloon of kunt u een sjabloon selecteren die geen vooraf gedefinieerde opslagklasse heeft. Als uw sjabloon geen opslagklasse definieert, wordt u in de portal gevraagd om een klasse. Als u een aangepaste implementatiesjabloon gebruikt, kunt u de opslagklasse opgeven.

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

Als u de opslagklasse instelt met behulp van de --storage-class of -scparameter, wordt die opslagklasse gebruikt voor zowel logboek- als gegevensopslagklassen. Als u de opslagklassen in het implementatiesjabloonbestand instelt, kunt u verschillende opslagklassen opgeven voor logboeken en gegevens.

Belangrijke factoren waarmee u rekening moet houden bij het kiezen van een opslagklasse voor de pods van de gegevenscontroller:

U moet een externe, gedeelde opslagklasse gebruiken om de duurzaamheid van gegevens te waarborgen en dat als een pod of knooppunt sterft dat wanneer de pod wordt teruggezet, opnieuw verbinding kan maken met het permanente volume.
De gegevens die worden geschreven naar het SQL-exemplaar van de controller, metrische database en logboeken DB zijn doorgaans redelijk laag en niet gevoelig voor latentie, zodat ultrasnelle opslag van prestaties niet essentieel is. Als u gebruikers hebt die vaak gebruikmaken van de Grafana- en Kibana-interfaces en u een groot aantal database-exemplaren hebt, kunnen uw gebruikers profiteren van sneller presterende 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 gedurende twee (2) weken bewaard in de logboeken en de database met metrische gegevens voordat ze worden verwijderd.
Het wijzigen van de opslagklasse na de implementatie is moeilijk, niet gedocumenteerd en niet ondersteund. Zorg ervoor dat u de opslagklasse op de juiste manier 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 permanente volumes voor gegevens, logboeken en back-ups. 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 een van az sql mi-arc create beide of az postgres server-arc create, zijn er vier parameters die u kunt gebruiken om de opslagklassen in te stellen:

Parameternaam, korte naam	Gebruikt voor
`--storage-class-data`, `-d`	Opslagklasse voor alle gegevensbestanden (.mdf, ndf). Als dit niet is opgegeven, wordt standaard de opslagklasse voor de gegevenscontroller gebruikt.
`--storage-class-logs`, `-g`	Opslagklasse voor alle logboekbestanden. Als dit niet is opgegeven, wordt standaard de opslagklasse voor de gegevenscontroller gebruikt.
`--storage-class-data-logs`	Opslagklasse voor de transactielogboekbestanden van de database. Als dit niet is opgegeven, wordt standaard de opslagklasse voor de gegevenscontroller gebruikt.
`--storage-class-backups`	Opslagklasse voor alle back-upbestanden. Als dit niet is opgegeven, wordt standaard ingesteld op opslagklasse voor gegevens (`--storage-class-data`). Gebruik een opslagklasse die geschikt is voor ReadWriteMany (RWX) voor back-ups. Meer informatie over toegangsmodi.

Waarschuwing

Als u geen opslagklasse voor back-ups opgeeft, gebruikt de implementatie de opslagklasse die is opgegeven voor gegevens. Als deze opslagklasse niet geschikt is voor RWX, werkt het herstel naar een bepaald tijdstip mogelijk niet naar wens.

De onderstaande tabel bevat de paden in de Azure SQL Managed Instance-container die is toegewezen aan het permanente volume voor gegevens en logboeken:

Parameternaam, korte naam	Pad in `mssql-miaa` container	Beschrijving
`--storage-class-data`, `-d`	/var/opt	Bevat mappen voor de mssql-installatie en andere systeemprocessen. De mssql-map bevat standaardgegevens (inclusief transactielogboeken), foutenlogboeken en back-upmappen
`--storage-class-logs`, `-g`	/var/log	Bevat mappen waarin console-uitvoer (stderr, stdout) wordt opgeslagen, andere logboekgegevens van processen in de container

De onderstaande tabel bevat de paden in de PostgreSQL-exemplaarcontainer die is toegewezen aan het permanente volume voor gegevens en logboeken:

Parameternaam, korte naam	Pad binnen postgres-container	Beschrijving
`--storage-class-data`, `-d`	/var/opt/postgresql	Bevat gegevens en logboekmappen voor de postgres-installatie
`--storage-class-logs`, `-g`	/var/log	Bevat mappen waarin console-uitvoer (stderr, stdout) wordt opgeslagen, andere logboekgegevens van processen in de container

Elk database-exemplaar heeft een afzonderlijk permanent volume voor gegevensbestanden, logboeken en back-ups. Dit betekent dat er een scheiding is van de I/O voor elk van deze typen bestanden, afhankelijk van de wijze waarop de volumeinrichting opslag inricht. Elk database-exemplaar heeft zijn eigen permanente volumeclaims en permanente volumes.

Als er meerdere databases zijn op een bepaald database-exemplaar, gebruiken alle databases dezelfde permanente volumeclaim, permanent volume en opslagklasse. Alle back-ups: zowel differentiële logboekback-ups als volledige back-ups maken gebruik van 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	`<namespace>/logs-<instance name>-<ordinal>`, `<namespace>/data-<instance name>-0`

Belangrijke factoren waarmee u rekening moet houden bij het kiezen van een opslagklasse voor de pods van het database-exemplaar:

Vanaf de release van februari 2022 van Azure Arc-gegevensservices moet u een opslagklasse opgeven die geschikt is voor ReadWriteMany (RWX) voor back-ups. Meer informatie over toegangsmodi. Als er geen opslagklasse is opgegeven voor back-ups, wordt de standaardopslagklasse in kubernetes gebruikt en als dit niet geschikt is voor RWX, kan een implementatie van een met Azure SQL beheerd exemplaar mogelijk niet lukken.
Database-exemplaren kunnen worden geïmplementeerd in één podpatroon of in een patroon met meerdere pods. Een voorbeeld van één podpatroon is een prijscategorie algemeen gebruik van azure SQL Managed Instance. Een voorbeeld van een patroon met meerdere pods is een maximaal beschikbare Bedrijfskritiek prijscategorie azure SQL Managed Instance. Database-exemplaren die zijn geïmplementeerd met het patroon voor één pod, moeten een externe, gedeelde opslagklasse gebruiken om de duurzaamheid van gegevens te waarborgen en dat als een pod of knooppunt sterft dat wanneer de pod wordt teruggezet, opnieuw verbinding kan maken met het permanente volume. Een maximaal beschikbaar beheerd exemplaar van Azure SQL maakt daarentegen gebruik van AlwaysOn-beschikbaarheidsgroepen om de gegevens van het ene exemplaar synchroon of asynchroon te repliceren. Vooral 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 leesbewerkingen of zware schrijfbewerkingen heeft, moet u een opslagklasse kiezen met hardware die is ontworpen voor dat type werkbelasting. Als uw database bijvoorbeeld voornamelijk wordt gebruikt voor schrijfbewerkingen, kunt u lokale opslag kiezen met RAID 0. Als uw database voornamelijk wordt gebruikt voor leesbewerkingen van een kleine hoeveelheid 'dynamische gegevens', maar er een groot algemeen opslagvolume aan koude gegevens is, kunt u een SAN-apparaat kiezen dat geschikt is voor gelaagde opslag. Het kiezen van de juiste opslagklasse verschilt niet van het kiezen van het type opslag dat u voor elke database zou gebruiken.
Als u een lokale opslagvolumeinrichting gebruikt, moet u ervoor zorgen dat de lokale volumes die zijn ingericht voor gegevens, logboeken en back-ups, elke landing op verschillende onderliggende opslagapparaten zijn om conflicten op schijf-I/O te voorkomen. Het besturingssysteem moet zich ook op een volume bevinden dat is gekoppeld aan een afzonderlijke schijf(en). 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 opgeeft. Scheid indien mogelijk bezette databases op hun eigen database-exemplaren om I/O-conflicten te voorkomen. Gebruik verder het knooppuntlabel dat is gericht op het plaatsen van database-exemplaren op afzonderlijke knooppunten, zodat het totale I/O-verkeer over meerdere knooppunten wordt verdeeld. Als u virtualisatie gebruikt, moet u overwegen I/O-verkeer te distribueren, niet alleen op knooppuntniveau, maar ook de gecombineerde I/O-activiteit die wordt uitgevoerd door alle knooppunt-VM's op een bepaalde fysieke host.

Opslagvereisten schatten

Elke pod die stateful gegevens bevat, maakt gebruik van ten minste twee permanente volumes: één permanent volume voor gegevens en een ander permanent volume voor logboeken. De onderstaande tabel bevat 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 PostgreSQL	1	2

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 PostgreSQL	5	5 * 2 = 10
Totaal aantal permanente volumes		8 + 10 + 10 = 28

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

De juiste opslagklasse kiezen

On-premises en edge-sites

Microsoft en de oem-, besturingssysteem- en Kubernetes-partners hebben een validatieprogramma voor Azure Arc-gegevensservices. Dit programma biedt vergelijkbare testresultaten van een testtoolkit voor certificering. De tests evalueren functiecompatibiliteit, resultaten van stresstests en prestaties en schaalbaarheid. De testresultaten geven het gebruikte besturingssysteem, de Gebruikte Kubernetes-distributie, HW gebruikt, de gebruikte CSI-invoegtoepassing en de gebruikte opslagklassen aan. Dit helpt klanten bij het kiezen van de beste opslagklasse, besturingssysteem, Kubernetes-distributie en hardware voor hun vereisten. Meer informatie over dit programma en testresultaten vindt u hier.

Openbare cloud, beheerde Kubernetes-services

Voor openbare cloudgebaseerde beheerde Kubernetes-services 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 in AKS zijn `azurefile` dus (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 u moet overwegen. Voor productieworkloads met hoge prestatievereisten raden we u aan voor alle opslagklassen te gebruiken `managed-premium` . Voor ontwikkel-/testworkloads, proofs of concept, enzovoort, waarbij kosten een overweging zijn, is dit `azurefile` de minst dure optie. Alle vier de opties kunnen worden gebruikt voor situaties waarin externe, gedeelde opslag is vereist, omdat het allemaal netwerk-gekoppelde opslagapparaten in Azure zijn. Meer informatie over AKS Storage.
AWS Elastic Kubernetes Service (EKS)	Elastic Kubernetes Service van Amazon heeft één primaire opslagklasse, gebaseerd op het EBS CSI-opslagstuurprogramma. Dit wordt aanbevolen voor productieworkloads. Er is een nieuw opslagstuurprogramma - EFS CSI-opslagstuurprogramma - dat kan worden toegevoegd aan een EKS-cluster, maar het bevindt zich momenteel in een bètafase en kan worden gewijzigd. Hoewel AWS zegt dat dit opslagstuurprogramma wordt ondersteund voor productie, raden we u niet aan om het te gebruiken omdat het nog steeds in bèta is en onderhevig is aan wijzigingen. De EBS-opslagklasse is de standaardinstelling en wordt aangeroepen `gp2`. Lees meer over EKS Storage.
Google Kubernetes Engine (GKE)	Google Kubernetes Engine (GKE) heeft slechts één opslagklasse genaamd `standard`. Deze klasse wordt gebruikt voor permanente GCE-schijven. Als enige is het de enige, het is 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 niet aan deze te gebruiken omdat deze niet wordt onderhouden of ondersteund door Google. Lees meer over GKE-opslag.