Tároló konfigurálása
A Kubernetes Storage fogalmai
A Kubernetes egy infrastruktúra absztrakciós réteget biztosít a mögöttes virtualizálási technológiai verem (nem kötelező) és hardver felett. A Kubernetes tárterülettől való absztrakciójának módja a tárolási osztályokon keresztül történik. Pod kiépítésekor minden kötethez megadhat egy tárolási osztályt. A pod kiépítésekor a rendszer meghívja a tárosztály-kiépítést, majd létrehoz egy állandó kötetet a kiépített tárolón, majd a podot egy állandó kötetjogcím csatlakoztatja az állandó kötethez.
A Kubernetes lehetővé teszi a tárolóinfrastruktúra-szolgáltatók számára a Kubernetes kiterjesztését lehetővé tevő illesztőprogramok (más néven "bővítmények") csatlakoztatását. A tárolóbőveknek meg kell felelniük a Container Storage Interface szabványnak. Több tucat bővítmény található a CSI-illesztőprogramok nem végleges listájában. A használt CSI-illesztőprogram olyan tényezőktől függ, mint például, hogy egy felhőben üzemeltetett, felügyelt Kubernetes-szolgáltatásban fut-e, vagy melyik OEM-szolgáltatót használja a hardverhez.
A Kubernetes-fürtben konfigurált tárolási osztályok megtekintéséhez futtassa ezt a parancsot:
kubectl get storageclass
Példakimenet egy Azure Kubernetes Service- (AKS-) fürtből:
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
A tárosztály részletei a következő parancs futtatásával szerezhetőek be:
kubectl describe storageclass/<storage class name>
Példa:
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>
A jelenleg kiosztott állandó köteteket és állandó kötet jogcímeket az alábbi parancsok futtatásával tekintheti meg:
kubectl get persistentvolumes -n <namespace>
kubectl get persistentvolumeclaims -n <namespace>
Példa az állandó kötetek megjelenítésére:
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
Példa az állandó kötet jogcímeinek megjelenítésére:
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
A tárolási konfiguráció kiválasztásakor figyelembe veendő tényezők
A megfelelő tárolási osztály kiválasztása fontos az adatrugalmasság és a teljesítmény érdekében. Ha nem megfelelő tárolási osztályt választ, az adatok teljes adatvesztésének kockázata fenyegetheti hardverhiba esetén, vagy kevésbé optimális teljesítményt eredményezhet.
A tárolásnak általában két típusa van:
- Helyi tároló – Egy adott csomópont helyi merevlemezeire kiépített tároló. Ez a fajta tárolás teljesítmény szempontjából ideális lehet, de kifejezetten az adatredundancia tervezését igényli az adatok több csomóponton történő replikálásával.
- Távoli, megosztott tároló – valamilyen távoli tárolóeszközön kiépített tároló – például san, NAS vagy felhőalapú tárolási szolgáltatás, például EBS vagy Azure Files. Ez a fajta tárolás általában automatikusan biztosítja az adatredundanciát, de nem olyan gyors, mint a helyi tárolás.
NFS-alapú tárolási osztályok
Az NFS-kiszolgáló és a tárosztály-kiépítés konfigurációjától függően előfordulhat, hogy be kell állítania az supplementalGroups adatbázispéldányok podkonfigurációit, és előfordulhat, hogy módosítania kell az NFS-kiszolgáló konfigurációját az ügyfél által átadott csoportazonosítók használatához (szemben azzal, hogy a csoportazonosítókat a kiszolgálón a továbbított felhasználói azonosító használatával keresi). Az NFS-rendszergazdától megtudhatja, hogy ez a helyzet-e.
A supplementalGroups tulajdonság az üzembe helyezéskor beállítható értékek tömbje. Az Azure Arc-adatkezelő ezeket alkalmazza az általa létrehozott adatbázispéldányokra.
A tulajdonság beállításához futtassa a következő parancsot:
az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'
Az adatkezelő tárolókonfigurációja
Az Adatszolgáltatásokhoz készült Azure Arc egyes szolgáltatásai attól függenek, hogy távoli, megosztott tárterület használatára vannak-e konfigurálva, mert a szolgáltatások nem tudják replikálni az adatokat. Ezek a szolgáltatások az adatkezelő podjainak gyűjteményében találhatók:
| Service | Állandó mennyiségi jogcímek |
|---|---|
| OpenSearch | <namespace>/logs-logsdb-0, <namespace>/data-logsdb-0 |
| InfluxDB | <namespace>/logs-metricsdb-0, <namespace>/data-metricsdb-0 |
| Vezérlő SQL-példánya | <namespace>/logs-controldb, <namespace>/data-controldb |
| Controller API-szolgáltatás | <namespace>/data-controller |
Az adatkezelő kiépítésekor az egyes állandó kötetekhez használandó tárolási osztályt a --storage-osztály | -sc paraméter a az arcdata dc create parancshoz, vagy a használt control.json telepítési sablonfájl tárolási osztályainak beállításával. Ha az Azure Portal használatával hozza létre az adatkezelőt a közvetlenül csatlakoztatott módban, a választott üzembehelyezési sablonban előre definiált tárolási osztály található, vagy választhat olyan sablont, amely nem rendelkezik előre definiált tárolási osztálysal. Ha a sablon nem határoz meg tárosztályt, a portál rákérdez. Ha egyéni üzembehelyezési sablont használ, megadhatja a tárolási osztályt.
A dobozon kívül megadott üzembehelyezési sablonokhoz egy alapértelmezett tárolási osztály van megadva, amely megfelel a célkörnyezetnek, de az üzembe helyezés során felülírható. Tekintse meg az egyéni konfigurációs sablonok létrehozásának részletes lépéseit az adatkezelő podjainak tárolási osztálykonfigurációjának módosításához az üzembe helyezéskor.
Ha a tárolási osztályt a --storage-class paraméterrel állítja -scbe, akkor a rendszer ezt a tárolási osztályt használja a napló- és adattárolási osztályokhoz is. Ha a tárolási osztályokat az üzembehelyezési sablonfájlban állítja be, különböző tárolási osztályokat adhat meg a naplókhoz és az adatokhoz.
Fontos tényezők, amelyeket figyelembe kell venni az adatkezelő podok tárolási osztályának kiválasztásakor:
- Távoli , megosztott tárolási osztályt kell használnia az adatok tartósságának biztosítása érdekében, és hogy ha egy pod vagy csomópont meghal, akkor a pod biztonsági mentésekor újra csatlakozhat az állandó kötethez.
- A vezérlő SQL-példányára, a metrikák adatbázisára és a naplók adatbázisára írt adatok általában meglehetősen alacsony kötetek, és nem érzékenyek a késésre, ezért az ultragyors teljesítménytárolás nem kritikus fontosságú. Ha olyan felhasználókat használ, amelyek gyakran használják a Grafana és a Kibana felületeket, és nagy számú adatbázispéldánysal rendelkezik, akkor a felhasználók számára előnyös lehet a gyorsabb tárolás.
- A szükséges tárkapacitás változó az üzembe helyezett adatbázispéldányok számával, mivel a rendszer naplókat és metrikákat gyűjt az egyes adatbázispéldányokhoz. A rendszer két (2) héttel a törlés előtt megőrzi az adatokat a naplókban és a metrikák adatbázisában.
- A tárolási osztály üzembe helyezés utáni módosítása nehéz, nem dokumentált és nem támogatott. Ügyeljen arra, hogy a tárolási osztályt az üzembe helyezéskor helyesen válassza ki.
Megjegyzés:
Ha nincs megadva tárolási osztály, a rendszer az alapértelmezett tárolási osztályt használja. Kubernetes-fürtönként csak egy alapértelmezett tárolási osztály lehet. Módosíthatja az alapértelmezett tárolási osztályt.
Adatbázispéldány tárolókonfigurációja
Minden adatbázispéldány rendelkezik állandó kötetekkel, naplókkal és biztonsági másolatokkal. Az állandó kötetek tárolási osztályai az üzembe helyezéskor adhatók meg. Ha nincs megadva tárolási osztály, a rendszer az alapértelmezett tárolási osztályt használja.
Ha egy példányt vagy azt az sql mi-arc createaz postgres server-arc createhasználja, négy paraméterrel állíthatja be a tárosztályokat:
Figyelmeztetés
Ha nem ad meg tárolási osztályt a biztonsági mentésekhez, az üzembe helyezés az adatokhoz megadott tárolási osztályt használja. Ha ez a tárolási osztály nem RWX-kompatibilis, előfordulhat, hogy az időponthoz kötött visszaállítás nem a kívánt módon működik.
Az alábbi táblázat a felügyelt Azure SQL-példány tárolójában található útvonalakat sorolja fel, amelyek az adatok és naplók állandó kötetére vannak leképezve:
| Paraméternév, rövid név | Tárolón belüli mssql-miaa elérési út |
Leírás |
|---|---|---|
--storage-class-data, -d |
/var/opt | Könyvtárakat tartalmaz az mssql-telepítéshez és más rendszerfolyamatokhoz. Az mssql-címtár alapértelmezett adatokat (beleértve a tranzakciónaplókat), hibanaplókat és biztonsági mentési könyvtárakat tartalmaz |
--storage-class-logs, -g |
/var/log | Olyan könyvtárakat tartalmaz, amelyek a konzol kimenetét (stderr, stdout) tárolják, a tárolón belüli folyamatok egyéb naplózási adatait |
Az alábbi táblázat a PostgreSQL-példánytárolón belüli elérési utakat sorolja fel, amelyek az adatok és naplók állandó kötetére vannak leképezve:
| Paraméternév, rövid név | Elérési út a postgres-tárolóban | Leírás |
|---|---|---|
--storage-class-data, -d |
/var/opt/postgresql | Adat- és naplókönyvtárakat tartalmaz a postgres-telepítéshez |
--storage-class-logs, -g |
/var/log | Olyan könyvtárakat tartalmaz, amelyek a konzol kimenetét (stderr, stdout) tárolják, a tárolón belüli folyamatok egyéb naplózási adatait |
Minden adatbázispéldány külön állandó kötetet tartalmaz az adatfájlokhoz, naplókhoz és biztonsági másolatokhoz. Ez azt jelenti, hogy az I/O minden ilyen típusú fájl esetében külön-külön van, annak függvényében, hogy a kötetkiosztó hogyan helyezi üzembe a tárterületet. Minden adatbázispéldány saját állandó kötet jogcímekkel és állandó kötetekkel rendelkezik.
Ha egy adott adatbázispéldányon több adatbázis is található, az összes adatbázis ugyanazt az állandó mennyiségi jogcímet, állandó kötetet és tárolási osztályt használja. Minden biztonsági mentés – a különbségnaplók biztonsági mentései és a teljes biztonsági másolatok ugyanazt az állandó mennyiségi jogcímet és állandó kötetet használják. Az adatbázispéldány podjaihoz tartozó állandó kötetjogcímek az alábbiakban láthatók:
| Példány | Állandó mennyiségi jogcímek |
|---|---|
| Felügyelt Azure SQL-példány | <namespace>/logs-<instance name>-0, <namespace>/data-<instance name>-0 |
| Azure Database for PostgreSQL-példány | <namespace>/logs--<instance name>-0, <namespace>/data--<instance name>-0 |
| Azure PostgreSQL | <namespace>/logs-<instance name>-<ordinal>, <namespace>/data-<instance name>-0 |
Fontos tényezők, amelyeket figyelembe kell venni az adatbázispéldány-podok tárolási osztályának kiválasztásakor:
- Az Azure Arc-adatszolgáltatások 2022. februári kiadásától kezdve meg kell adnia egy ReadWriteMany (RWX) képes tárolási osztályt a biztonsági mentésekhez. További információ a hozzáférési módokról. Ha nincs megadva tárolási osztály a biztonsági mentésekhez, a kubernetes alapértelmezett tárolási osztálya lesz használatban, és ha ez nem RWX-kompatibilis, előfordulhat, hogy egy Felügyelt Azure SQL-példány üzembe helyezése nem sikerül.
- Az adatbázispéldányok egyetlen vagy több podmintában helyezhetők üzembe. Egyetlen podmintára példa egy általános célú tarifacsomag, a felügyelt Azure SQL-példány. Több podmintára példa egy magas rendelkezésre állású üzletileg kritikus felügyelt Azure SQL-példány tarifacsomagja. Az egy podmintával üzembe helyezett adatbázispéldányoknak távoli, megosztott tárolási osztályt kell használniuk az adatok tartósságának biztosítása érdekében, és hogy ha egy pod vagy csomópont meghal, a pod biztonsági mentésekor újra csatlakozhat az állandó kötethez. Ezzel szemben egy magas rendelkezésre állású felügyelt Azure SQL-példány always on rendelkezésre állási csoportokkal replikálja az adatokat az egyik példányból a másikba szinkron vagy aszinkron módon. Különösen abban az esetben, ha az adatokat szinkron módon replikálják, az adatoknak mindig több példánya van – általában három példány. Emiatt helyi vagy távoli, megosztott tárolási osztályokat is használhat az adatokhoz és a naplófájlokhoz. Ha helyi tárolást használ, az adatok még akkor is megmaradnak, ha meghibásodott pod, csomópont vagy tárolóhardver található, mert az adatok több példánya is létezik. Ezt a rugalmasságot figyelembe véve dönthet úgy, hogy helyi tárolót használ a jobb teljesítmény érdekében.
- Az adatbázis teljesítménye nagyrészt egy adott tárolóeszköz I/O-átviteli sebességének függvénye. Ha az adatbázis olvasási vagy írási nehézkes, akkor az ilyen típusú számítási feladatokhoz tervezett hardveres tárolási osztályt kell választania. Ha például az adatbázist többnyire íráshoz használják, akkor a RAID 0-val választhat helyi tárolót. Ha az adatbázist többnyire kis mennyiségű "gyakori adatok" olvasására használják, de nagy mennyiségű ritka elérésű adat van, akkor választhat egy tárolóhálózati eszközt, amely képes rétegzett tárolásra. A megfelelő tárolási osztály kiválasztása nem különbözik attól, hogy milyen típusú tárolót használna egy adatbázishoz.
- Ha helyi tárolókötet-kiépítőt használ, győződjön meg arról, hogy az adatokhoz, naplókhoz és biztonsági másolatokhoz kiépített helyi kötetek mindegyike különböző mögöttes tárolóeszközökre kerül, hogy elkerülje a lemez I/O-ján való versengést. Az operációs rendszernek egy külön lemezre(ek)re csatlakoztatott köteten is kell lennie. Ez lényegében ugyanaz az útmutató, mint amelyet egy fizikai hardveren lévő adatbázispéldány esetében követnénk.
- Mivel egy adott példány összes adatbázisa rendelkezik állandó mennyiségi jogcímekkel és állandó kötetekkel, ügyeljen arra, hogy ne helyezzen el foglalt adatbázispéldányokat ugyanazon az adatbázispéldányon. Ha lehetséges, különítse el az elfoglalt adatbázisokat a saját adatbázispéldányaiktól az I/O-versengés elkerülése érdekében. Emellett használja a csomópontcímkék célzását az adatbázispéldányok különálló csomópontokra való elhelyezéséhez, hogy a teljes I/O-forgalmat több csomópont között eloszthassa. Ha virtualizálást használ, fontolja meg az I/O-forgalom elosztását nem csak a csomópont szintjén, hanem az adott fizikai gazdagép összes csomópont virtuális gépe által végzett összevont I/O-tevékenységet is.
Tárolási követelmények becslése
Az állapotalapú adatokat tartalmazó podok legalább két állandó kötetet használnak: egy állandó kötetet az adatokhoz, egy másik állandó kötetet a naplókhoz. Az alábbi táblázat az egyetlen adatkezelőhöz, a felügyelt Azure SQL-példányhoz, az Azure Database for PostgreSQL-példányhoz és az Azure PostgreSQL HyperScale-példányhoz szükséges állandó kötetek számát sorolja fel:
| Erőforrás típusa | Állapotalapú podok száma | Állandó kötetek szükséges száma |
|---|---|---|
| Adatkezelő | 4 (control, controldb, , logsdbmetricsdb) |
4 * 2 = 8 |
| Azure SQL Managed Instance | 1 | 2 |
| Azure PostgreSQL | 1 | 2 |
Az alábbi táblázat a mintatelepítéshez szükséges állandó kötetek teljes számát mutatja:
| Erőforrás típusa | Példányok száma | Állandó kötetek szükséges száma |
|---|---|---|
| Adatkezelő | 1 | 4 * 2 = 8 |
| Azure SQL Managed Instance | 5 | 5 * 2 = 10 |
| Azure PostgreSQL | 5 | 5 * 2 = 10 |
| Állandó kötetek teljes száma | 8 + 10 + 10 = 28 |
Ezzel a számítással megtervezheti a Kubernetes-fürt tárolóját a tárolókiépítési vagy -környezet alapján. Ha például egy öt (5) csomópontot tartalmazó Kubernetes-fürthöz helyi tárolókiépítést használnak, akkor a fenti mintatelepítéshez minden csomóponthoz legalább 10 állandó kötet tárolására van szükség. Hasonlóképpen, ha egy Öt (5) csomóponttal rendelkező Azure Kubernetes Service-fürtöt épít ki, amely a csomópontkészlethez megfelelő virtuálisgép-méretet választ, így 10 adatlemez csatolható, kritikus fontosságú. Az AKS-csomópontok tárolási igényeihez tartozó csomópontok méretéről itt talál további információt.
A megfelelő tárolási osztály kiválasztása
Helyszíni és peremhálózati helyek
A Microsoft és oem, operációs rendszere és Kubernetes-partnerei rendelkeznek egy érvényesítési programmal az Azure Arc-adatszolgáltatásokhoz. Ez a program összehasonlítható teszteredményeket biztosít egy tanúsítási tesztelési eszközkészletből. A tesztek kiértékelik a funkciók kompatibilitását, a stressztesztek eredményeit, valamint a teljesítményt és a méretezhetőséget. A teszteredmények a használt operációs rendszert, a használt Kubernetes-eloszlást, a használt HW-t, a használt CSI-bővítményt és a használt tárolási osztályokat jelölik. Ez segít az ügyfeleknek kiválasztani a legjobb tárolási osztályt, operációs rendszert, Kubernetes-disztribúciót és hardvert a követelményeknek megfelelően. Erről a programról és a tesztelési eredményekről itt talál további információt.
Nyilvános felhő, felügyelt Kubernetes-szolgáltatások
Nyilvános felhőalapú, felügyelt Kubernetes-szolgáltatások esetén a következő javaslatokat tehetjük:
| Nyilvános felhőszolgáltatás | Recommendation |
|---|---|
| Azure Kubernetes Service (AKS) | Az Azure Kubernetes Service (AKS) kétféle tárolóval rendelkezik: Azure Files és Azure Managed Disks. Minden tárolótípus két tarifacsomagot és teljesítményszintet biztosít : standard (HDD) és prémium (SSD). Így az AKS-ben biztosított négy tárolási osztály a következő azurefile : (Azure Files standard szint), azurefile-premium (Prémium szintű Azure Files), default (Azure Disks standard szint) és managed-premium (Prémium szintű Azure Disks). Az alapértelmezett tárolási osztály ( default az Azure Disks standard szintje). Jelentős díjszabási különbségek vannak a figyelembe veendő típusok és szintek között. A nagy teljesítményű követelményekkel rendelkező éles számítási feladatokhoz minden tárolási osztályhoz ajánlott használni managed-premium . A fejlesztési/tesztelési számítási feladatok, a koncepció igazolásai stb. esetében, ahol a költségek megfontolandók, akkor azurefile a legkevésbé költséges megoldás. Mind a négy lehetőség használható távoli, megosztott tárterületet igénylő helyzetekben, mivel ezek az Azure-ban minden hálózathoz csatlakoztatott tárolóeszköz. További információ az AKS Storage-ról. |
| AWS Elastic Kubernetes Service (EKS) | Az Amazon Elastic Kubernetes Szolgáltatása egy elsődleges tárolási osztálysal rendelkezik – az EBS CSI tárolóillesztő alapján. Ez éles számítási feladatokhoz ajánlott. Van egy új tárolóillesztő – EFS CSI-tárolóillesztő –, amely hozzáadható egy EKS-fürthöz, de jelenleg béta fázisban van, és változhat. Bár az AWS azt mondja, hogy ez a tárolóillesztő támogatott az éles környezetben, nem javasoljuk a használatát, mert még bétaverzióban van, és változhat. Az EBS storage osztály az alapértelmezett, és a neve gp2. További információ az EKS Storage-ról. |
| Google Kubernetes Engine (GKE) | A Google Kubernetes Engine (GKE) csak egy úgynevezett tárosztálysal standardrendelkezik. Ez az osztály A GCE állandó lemezeihez használatos. Mivel ez az egyetlen, ez is az alapértelmezett. Bár a GKE-hez van egy helyi, statikus kötetkiépítési eszköz , amelyet közvetlenül csatlakoztatott SSD-kkel használhat, nem javasoljuk a használatát, mivel a Google nem tartja karban vagy támogatja. További információ a GKE-tárolóról. |