Tárolási lehetőségek alkalmazásokhoz az Azure Kubernetes Service-ben (AKS)

  • Cikk

Előfordulhat, hogy az Azure Kubernetes Service-ben (AKS) futó alkalmazásoknak adatokat kell tárolniuk és lekérnie. Míg egyes alkalmazás-számítási feladatok helyi, gyors tárolást használhatnak szükségtelen, kiürített csomópontokon, másoknak olyan tárterületre van szükségük, amely az Azure-platform rendszeresebb adatköteteinél is megmarad.

Előfordulhat, hogy több podnak:

  • Azonos adatköteteket oszthat meg.
  • Adatkötetek újbóli csatlakoztatása, ha a pod másik csomópontra van ütemezve.

Előfordulhat, hogy bizalmas adatokat vagy alkalmazáskonfigurációs adatokat kell összegyűjtenie és podokban tárolnia.

Ez a cikk bemutatja azokat az alapvető fogalmakat, amelyek tárolót biztosítanak az alkalmazások számára az AKS-ben:

Az Azure Kubernetes Services-fürtben (AKS) lévő alkalmazások tárolási lehetőségeinek diagramja.

Rövid élettartamú operációsrendszer-lemez

Alapértelmezés szerint az Azure automatikusan replikálja egy virtuális gép operációsrendszer-lemezét az Azure Storage-ba, hogy elkerülje az adatvesztést, amikor a virtuális gépet egy másik gazdagépre helyezik át. Mivel azonban a tárolók nem úgy vannak kialakítva, hogy a helyi állapot megmaradjon, ez a viselkedés korlátozott értéket kínál, ugyanakkor hátrányokat is biztosít. Ezek a hátrányok közé tartozik, de nem korlátozódik a lassabb csomópontok kiépítésére és a nagyobb olvasási/írási késésre.

Ezzel szemben a rövid élettartamú operációsrendszer-lemezek csak a gazdaszámítógépen vannak tárolva, csakúgy, mint egy ideiglenes lemez. Ezzel a konfigurációval alacsonyabb olvasási/írási késést, valamint gyorsabb csomópontméretezést és fürtfrissítéseket kaphat.

Feljegyzés

Ha nem kér kifejezetten azure-beli felügyelt lemezeket az operációs rendszerhez, az AKS alapértelmezés szerint rövid élettartamú operációs rendszert ad meg, ha lehetséges egy adott csomópontkészlet-konfigurációhoz.

A rövid élettartamú operációsrendszer-lemezekre vonatkozó méretkövetelmények és javaslatok az Azure-beli virtuális gépek dokumentációjában érhetők el. Az alábbiakban néhány általános méretezési szempontot vizsgáljuk meg:

  • Ha az AKS alapértelmezett virtuálisgép-méretét Standard_DS2_v2 termékváltozatot használja az alapértelmezett 100 GiB-os operációsrendszer-lemezmérettel, az alapértelmezett virtuálisgép-méret támogatja a rövid élettartamú operációs rendszert, de csak 86 GiB gyorsítótármérettel rendelkezik. Ez a konfiguráció alapértelmezés szerint felügyelt lemezekre vonatkozik, ha nem adja meg explicit módon. Ha rövid élettartamú operációs rendszert kér, érvényesítési hiba jelenik meg.

  • Ha ugyanazt a Standard_DS2_v2 termékváltozatot kéri egy 60 GiB-os operációsrendszer-lemezzel, ez a konfiguráció alapértelmezés szerint rövid élettartamú operációs rendszer lesz. A kért mérete 60 GiB kisebb, mint a gyorsítótár maximális mérete 86 GiB.

  • Ha a 100 GB-os operációsrendszer-lemezzel rendelkező Standard_D8s_v3 termékváltozatot választja, ez a virtuálisgép-méret támogatja a rövid élettartamú operációs rendszert, és 200 GiB gyorsítótárterülettel rendelkezik. Ha nem adja meg az operációsrendszer-lemez típusát, a csomópontkészlet alapértelmezés szerint rövid élettartamú operációs rendszert kap.

A virtuálisgép-sorozat legújabb generációja nem rendelkezik dedikált gyorsítótárral, csak ideiglenes tárhellyel. Ha például a Standard_E2bds_v5 virtuálisgép-méretet választotta az alapértelmezett 100 GiB-os operációsrendszer-lemezmérettel, az támogatja a rövid élettartamú operációsrendszer-lemezeket, de csak 75 GB ideiglenes tárterülettel rendelkezik. Ez a konfiguráció alapértelmezés szerint a felügyelt operációsrendszer-lemezekre vonatkozik, ha nem adja meg explicit módon. Ha rövid élettartamú operációsrendszer-lemezt kér, érvényesítési hiba jelenik meg.

  • Ha ugyanazt a Standard_E2bds_v5 virtuálisgép-méretet kéri egy 60 GiB-os operációsrendszer-lemezzel, ez a konfiguráció alapértelmezés szerint rövid élettartamú operációsrendszer-lemezekre vonatkozik. A kért 60 GiB-méret kisebb, mint a 75 GiB maximális ideiglenes tárterülete.

  • Ha Standard_E4bds_v5 termékváltozatot választja 100 GiB OS-lemezzel, ez a virtuálisgép-méret támogatja a rövid élettartamú operációs rendszert, és 150 GiB ideiglenes tárhellyel rendelkezik. Ha nem adja meg az operációsrendszer-lemez típusát, az Azure alapértelmezés szerint kiépít egy rövid élettartamú operációsrendszer-lemezt a csomópontkészletbe.

Felhasználó által kezelt kulcsok

A rövid élettartamú operációsrendszer-lemez titkosítását saját kulcsokkal kezelheti egy AKS-fürtön. További információ: Ügyfél által felügyelt kulcs használata azure-lemezzel az AKS-en.

Mennyiségek

A Kubernetes általában az egyes podokat rövid élettartamú, eldobható erőforrásként kezeli. Az alkalmazások különböző megközelítésekkel rendelkeznek az adatok használatához és megőrzéséhez. A kötetek az adatok podokon és az alkalmazás életciklusán keresztül történő tárolásának, lekérésének és megőrzésének módját jelentik.

A hagyományos kötetek az Azure Storage által támogatott Kubernetes-erőforrásokként jönnek létre. Manuálisan létrehozhat olyan adatköteteket, amelyek közvetlenül podokhoz rendelhetők, vagy a Kubernetes automatikusan létrehozhatja őket. Adatkötetek használhatók: Azure Disk, Azure Files, Azure NetApp Files vagy Azure Blobs.

Feljegyzés

A használt virtuálisgép-termékváltozattól függően előfordulhat, hogy az Azure Disk CSI-illesztőprogram csomópontonkénti kötetkorláttal rendelkezik. Néhány nagy teljesítményű virtuális gép (például 16 mag) esetében a korlát csomópontonként 64 kötet. A virtuálisgép-termékváltozatonkénti korlát azonosításához tekintse át az egyes kínált virtuálisgép-termékváltozatok Maximális adatlemezek oszlopát. A kínált virtuálisgép-termékváltozatok listáját és azok részletes kapacitáskorlátjait az általános célú virtuálisgép-méretek című témakörben találja.

Az Azure Files és az Azure NetApp Files közötti számítási feladatokhoz leginkább illeszkedő beállítás meghatározásához tekintse át az Azure Files és az Azure NetApp Files összehasonlítása című cikkben található információkat.

Azure-lemez

Kubernetes DataDisk-erőforrás létrehozása az Azure Disk használatával. A lemeztípusok a következők:

  • Ultralemezek
  • Prémium SSD-k
  • Standard szintű SSD-k
  • Standard HDD-k

Tipp.

A legtöbb éles és fejlesztési számítási feladathoz használja a Premium SSD-t.

Mivel az Azure Disk ReadWriteOnce-ként van csatlakoztatva, csak egyetlen csomóponton érhetők el. Több csomópont podjai által egyszerre elérhető tárkötetek esetében használja az Azure Filest.

Azure Files

Az Azure Files használatával csatlakoztathat egy Kiszolgálói üzenetblokk (SMB) 3.1.1-es verziójú megosztást vagy egy Azure Storage-fiók által támogatott hálózati fájlrendszer -megosztást (NFS) a podokhoz. Az Azure Files segítségével több csomóponton és podon oszthat meg adatokat, és használhatja az alábbiakat:

  • Nagy teljesítményű SSD-k által támogatott Azure Premium Storage
  • Normál HDD-k által támogatott Azure Standard Storage

Azure NetApp Files

  • Ultra tárhely
  • Prémium szintű Storage
  • Standard szintű Storage

Azure Blob Storage

Az Azure Blob Storage használatával hozzon létre egy blobtárolót, és csatlakoztassa az NFS v3.0 protokoll vagy a BlobFuse használatával.

  • Blokkblobok

Kötettípusok

A Kubernetes-kötetek nem csupán egy hagyományos lemezt képviselnek az információk tárolásához és lekéréséhez. A Kubernetes-kötetek arra is használhatók, hogy adatokat fecskendezhessenek egy podba a tárolók számára.

A Kubernetes gyakori kötettípusai a következők:

emptyDir

Gyakran használják ideiglenes helyként egy pod számára. A podon belüli összes tároló hozzáférhet a köteten lévő adatokhoz. Az erre a kötettípusra írt adatok csak a pod élettartamára maradnak meg. A pod törlése után a kötet törlődik. Ez a kötet általában a mögöttes helyi csomópont lemeztárolóját használja, de csak a csomópont memóriájában is létezhet.

titkos kód

Titkos kötetekkel bizalmas adatokat szúrhat be podokba, például jelszavakba.

  1. Hozzon létre egy titkos kulcsot a Kubernetes API használatával.
  2. Határozza meg a podot vagy az üzembe helyezést, és kérjen egy adott titkos kulcsot.
    • A titkos kulcsokat csak olyan ütemezett podokkal rendelkező csomópontok számára biztosítjuk, amelyekhez szükség van rájuk.
    • A titkos kód tmpf-ben van tárolva, nem lemezre írva.
  3. Amikor egy titkos kulcsot igénylő csomópont utolsó podját törli, a titkos kód törlődik a csomópont tmpf-jeiből.
    • A titkos kulcsok egy adott névtérben vannak tárolva, és csak az azonos névtérben lévő podok férnek hozzá.

configMap

A configMap használatával kulcs-érték pár tulajdonságokat szúrhat be podokba, például alkalmazáskonfigurációs információkat. Az alkalmazáskonfigurációs információkat Kubernetes-erőforrásként definiálhatja, amelyeket üzembe helyezésükkor egyszerűen frissíthet és alkalmazhat a podok új példányaira.

Például egy titkos kód használata:

  1. Hozzon létre egy ConfigMap-et a Kubernetes API használatával.
  2. Pod vagy üzembe helyezés definiálásakor kérje le a ConfigMap-et.
    • A konfiguráció Térképek egy adott névtérben vannak tárolva, és csak az azonos névtérben lévő podok férnek hozzá.

Tartós kötetek

A pod életciklusának részeként definiált és létrehozott kötetek csak a pod törléséig léteznek. A podok gyakran elvárják, hogy a tárterületük megmaradjon, ha egy podot egy másik gazdagépre ütemeznek egy karbantartási esemény során, különösen a StatefulSets esetén. Az állandó kötet (PV) a Kubernetes API által létrehozott és felügyelt tárolási erőforrás, amely az egyes podok élettartamán túl is létezhet.

A PersistentVolume biztosításához az alábbi Azure Storage-adatszolgáltatások használhatók:

Ahogy a Kötetek szakaszban is említettük , a lemezek vagy fájlok kiválasztását gyakran az határozza meg, hogy az adatokhoz vagy a teljesítményszinthez való egyidejű hozzáférésre van szükség.

Az Azure Kubernetes Services -fürtök állandó köteteinek diagramja.

A fürtadminisztrátor statikusan létrehozhat egy PersistentVolume-t, vagy a kötetet dinamikusan hozza létre a Kubernetes API-kiszolgáló. Ha egy pod ütemezve van, és a kérések jelenleg nem érhetők el, a Kubernetes létrehozhatja a mögöttes Azure Disk- vagy Fájltárolót, és csatolhatja a podhoz. A dinamikus kiépítés egy StorageClass használatával azonosítja, hogy milyen típusú Azure Storage-tárolót kell létrehozni.

Fontos

Az állandó köteteket a Windows és a Linux podok nem oszthatják meg a két operációs rendszer fájlrendszerbeli támogatásának különbségei miatt.

Tárolási osztályok

A különböző tárolási szintek( például a Prémium és a Standard) definiálásához létrehozhat egy StorageClass-ot.

A StorageClass a reclaimPolicy-t is meghatározza. Az állandó kötet törlésekor a reclaimPolicy szabályozza a mögöttes Azure Storage-erőforrás viselkedését. A mögöttes tárolási erőforrás törölhető vagy megőrizhető egy jövőbeli podhoz való használatra.

A tárolótároló-illesztőt (CSI) használó fürtök esetében a következő extra StorageClasses jön létre:

Tárolási osztály Leírás
managed-csi Felügyelt lemez létrehozásához az Azure StandardSSD helyileg redundáns tárolót (LRS) használja. A visszaigénylési szabályzat biztosítja, hogy a mögöttes Azure Disk törlődik, amikor az azt használó állandó kötet törlődik. A tárolási osztály az állandó köteteket is bővíthetőre konfigurálja, csak az új mérettel kell szerkesztenie az állandó kötet jogcímét.
managed-csi-premium Az Azure Premium helyileg redundáns tárolást (LRS) használ felügyelt lemez létrehozásához. A visszaigénylési szabályzat ismét biztosítja, hogy a mögöttes Azure Disk törlődjön, amikor az azt használó állandó kötet törlődik. Hasonlóképpen, ez a tárolási osztály lehetővé teszi az állandó kötetek bővítését.
azurefile-csi Azure-fájlmegosztás létrehozása az Azure Standard Storage használatával. A visszaigénylési szabályzat biztosítja, hogy a mögöttes Azure-fájlmegosztás törlődik az azt használó állandó kötet törlésekor.
azurefile-csi-premium Azure-fájlmegosztás létrehozása az Azure Premium Storage használatával. A visszaigénylési szabályzat biztosítja, hogy a mögöttes Azure-fájlmegosztás törlődik, amikor az azt használó állandó kötet törlődik.
azureblob-nfs-premium Az Azure Premium Storage használatával hozzon létre egy Azure Blob Storage-tárolót, és csatlakozzon az NFS v3 protokoll használatával. A visszaigénylési szabályzat biztosítja, hogy a mögöttes Azure Blob Storage-tároló törlődik a használt állandó kötet törlésekor.
azureblob-fuse-premium Az Azure Premium Storage használatával hozzon létre egy Azure Blob Storage-tárolót, és csatlakozzon a BlobFuse használatával. A visszaigénylési szabályzat biztosítja, hogy a mögöttes Azure Blob Storage-tároló törlődik a használt állandó kötet törlésekor.

Ha nem ad meg StorageClass értéket egy állandó kötethez, a rendszer az alapértelmezett StorageClass-ot használja. Győződjön meg arról, hogy a kötetek a megfelelő tárterületet használják az állandó kötetek kéréséhez.

Fontos

A Kubernetes 1.21-es verziójától kezdve az AKS alapértelmezés szerint csak CSI-illesztőprogramokat használ, és a CSI-migrálás engedélyezve van. Bár a meglévő, faalapú állandó kötetek továbbra is működnek, az 1.26-os verziótól kezdve az AKS már nem támogatja a fájlokhoz és lemezekhez kiépített faillesztővel és tárolóval létrehozott köteteket.

Az default osztály ugyanaz lesz, mint managed-csia .

A StorageClass-ot más igényekhez is létrehozhatja a következővel kubectl: . Az alábbi példa prémium szintű felügyelt lemezeket használ, és meghatározza, hogy a pod törlésekor a mögöttes Azure Disket meg kell őrizni :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Feljegyzés

Az AKS egyezteti az alapértelmezett tárolási osztályokat, és felülírja a tárosztályokon végzett módosításokat.

A tárosztályokról további információt a Kubernetes StorageClass című témakörben talál.

Tartóskötet-jogcímek

A PersistentVolumeClaim egy adott StorageClass, hozzáférési mód és méret tárolását kéri. A Kubernetes API-kiszolgáló dinamikusan kiépítheti a mögöttes Azure Storage-erőforrást, ha egy meglévő erőforrás sem tudja teljesíteni a jogcímet a megadott StorageClass alapján.

A poddefiníció tartalmazza a kötet csatlakoztatását, miután a kötet csatlakoztatva lett a podhoz.

Az Azure Kubernetes Services -fürtök állandó mennyiségi jogcímeinek diagramja.

Miután hozzárendelt egy rendelkezésre álló tárolási erőforrást a tárolót kérő podhoz, a PersistentVolume egy PersistentVolumeClaim-hez lesz kötve . Az állandó kötetek 1:1-re vannak leképezve a jogcímekhez.

Az alábbi PÉLDA YAML-jegyzék egy állandó mennyiségi jogcímet mutat be, amely a felügyelt prémium szintű StorageClass szolgáltatást használja, és 5Gi méretű lemezt kér:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Poddefiníció létrehozásakor a következőket is meg kell adnia:

  • Az állandó kötet azt állítja, hogy a kívánt tárterületet kéri.
  • A volumeMount az alkalmazások számára az adatok olvasásához és írásához.

Az alábbi PÉLDA YAML-jegyzék bemutatja, hogyan használható az előző állandó kötetkövetelés egy kötet csatlakoztatásához az /mnt/azure címen:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Kötet Windows-tárolóban való csatlakoztatásához adja meg a meghajtó betűjelét és elérési útját. Példa:

...      
       volumeMounts:
        - mountPath: "d:"
          name: volume
        - mountPath: "c:\k"
          name: k-dir
...

Következő lépések

A kapcsolódó ajánlott eljárásokért tekintse meg az ajánlott tárolási és biztonsági mentési eljárásokat az AKS-ben és az AKS Storage-ban.

A CSI-illesztőprogramok használatáról az alábbi útmutató cikkekben olvashat:

Az alapvető Kubernetes- és AKS-fogalmakkal kapcsolatos további információkért tekintse meg az alábbi cikkeket: