Az Azure Arc által engedélyezett AKS-alkalmazások tárolási lehetőségei

A következőkre vonatkozik: AKS az Azure Stack HCI 22H2-ben, AKS Windows Serveren

Előfordulhat, hogy az Azure Arc által engedélyezett Azure Kubernetes Service használatával futó AKS-környezetekben futó alkalmazásoknak adatokat kell tárolniuk és lekérnie. Egyes alkalmazás-számítási feladatok esetében az adatok helyi, gyors tárolást használhatnak egy felesleges csomóponton a podok törlésekor (a Kubernetes podokkal futtat egy alkalmazáspéldányt).

Más számítási feladatokhoz olyan tárterületre lehet szükség, amely rendszeresebb adatköteteken is megmarad. Előfordulhat, hogy több podnak is meg kell osztania ugyanazokat az adatköteteket, vagy újra kell kapcsolnia az adatköteteket, ha a podot egy másik csomóponton ütemezik újra. Emellett szükség lehet egy tárolási beállításra, ha a podok bizalmas adatokat vagy alkalmazáskonfigurációs adatokat tartalmaznak.

Ez a cikk bemutatja azokat az alapvető fogalmakat, amelyek tárolót biztosítanak az alkalmazások számára az AKS Arcban, beleértve a következőket:

• Kötetek
• Tartós kötetek
• Tárolási osztályok
• Állandó kötetjogcímek (PVC)

Kötetek

Az alkalmazásoknak gyakran képesnek kell lenniük az adatok tárolására és lekérésére. Mivel a Kubernetes általában ideiglenes, eldobható erőforrásként kezeli az egyes podokat, különböző megközelítések állnak rendelkezésre az alkalmazások számára az adatok használatához és megőrzéséhez. A kötetek az adatok podokon és az alkalmazás életciklusán keresztüli tárolásának, lekérésének és megőrzésének módját jelentik.

A Kubernetesben a kötetek többre képesek, mint a hagyományos adatok tárolására és lekérésére. A Kubernetes-kötetek felhasználhatók adatok podba való beszúrására is a tárolók számára. Néhány gyakori Kubernetes-kötettípus:

• emptyDir – Ezt a kötetet 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ésekor a kötet törlődik. Ez a kötet általában az alapul szolgáló helyi csomópontlemez-tárolót használja, bár csak a csomópont memóriájában is létezhet.

• secret – Ez a kötet bizalmas adatok, például jelszavak podokba való belefoglalására szolgál. Először hozzon létre egy titkos kulcsot a Kubernetes API használatával. Ha meghatározza a podot vagy az üzembe helyezést, kérhet egy adott titkos kulcsot. A titkos kulcsokat csak olyan ütemezett podokkal rendelkező csomópontok kapják meg, amelyekhez szükség van rá, és a titkos kód tmpf-ben van tárolva, nem pedig lemezre írva. Amikor egy titkos kulcsot igénylő csomópont utolsó podja törlődik, a titkos kód törlődik a csomópont tmpf-jeiből. A titkos kódok egy adott névtérben vannak tárolva, és csak ugyanazon a névtéren belüli podok férhetnek hozzá.

• configMap – Ez a kötettípus a kulcs-érték pár tulajdonságainak podokba való beszúrására szolgál, például az alkalmazáskonfigurációs adatokba. Az alkalmazáskonfigurációs adatok tárolólemezképen belüli definiálása helyett kubernetes-erőforrásként definiálhatja, amely az üzembe helyezésükkor egyszerűen frissíthető és alkalmazható a podok új példányaira. A titkos kódhoz hasonlóan először létre kell hoznia egy konfigurációtérképet a Kubernetes API használatával. Ezt a konfigurációtérképet ezután kérheti egy pod vagy üzembe helyezés definiálásakor. A konfigurációtérképek egy adott névtérben vannak tárolva, és csak ugyanazon a névtéren belüli podok érhetők el.

Tartós kötetek

A pod életciklusa 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árolójuk megmaradjon, ha egy podot egy másik gazdagépre ütemeznek egy karbantartási esemény során, különösen a StatefulSets esetében. Az állandó kötet 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 VHDX által támogatott AKS-lemezköteteket használhatja, amelyek ReadWriteOnce néven vannak csatlakoztatva, és egyszerre egyetlen csomóponthoz érhetők el. Az SMB- vagy NFS-fájlmegosztások által támogatott AKS-fájlköteteket is használhatja. Ezek ReadWriteMany néven vannak csatlakoztatva, és egyszerre több csomópont számára is elérhetők.

A fürtgazdák statikusan hozhatnak létre állandó kötetet, vagy a kötetet dinamikusan hozhatja létre a Kubernetes API-kiszolgáló. Ha egy pod ütemezett, és olyan tárolót kér, amely jelenleg nem érhető el, a Kubernetes létrehozhatja a mögöttes VHDX-fájlt, majd csatolhatja a podhoz. A dinamikus kiépítés egy StorageClass használatával azonosítja, hogy milyen típusú tárolót kell létrehozni.

Tárolási osztályok

A tárterület különböző szintjeinek (és helyének) meghatározásához létrehozhat egy StorageClass-ot. A StorageClass a reclaimPolicy-t is meghatározza. Ez a reclaimPolicy szabályozza a mögöttes tárolási erőforrás viselkedését a pod törlésekor, és előfordulhat, hogy az állandó kötetre már nincs szükség. A mögöttes tárolási erőforrás törölhető vagy megőrizhető egy jövőbeli podhoz való használatra.

Az AKS Arcban a rendszer automatikusan létrehozza az alapértelmezett tárolási osztályt, és CSV használatával hoz létre VHDX-alapú köteteket. A visszaigénylési szabályzat biztosítja, hogy a mögöttes VHDX törlődjön a használt állandó kötet törlésekor. A tárolási osztály az állandó köteteket is bővíthetőre konfigurálja, ezért csak az új mérettel kell szerkesztenie az állandó kötet jogcímét.

Ha egy állandó kötethez nincs megadva StorageClass , a rendszer az alapértelmezett StorageClass értéket használja. Állandó kötetek kérésekor győződjön meg arról, hogy a megfelelő tárterületet használják. További igényekhez létrehozhat egy StorageClass osztályt.

Tartóskötet-jogcímek

A PersistentVolumeClaim egy adott StorageClass és méretű ReadWriteOnce vagy ReadWriteMany tárterületet kér. A Kubernetes API-kiszolgáló dinamikusan kiépítheti a mögöttes tárolási erőforrást az AKS Arcban, ha nincs meglévő erőforrás a jogcímnek a definiált StorageClass alapján való teljesítéséhez. A poddefiníció tartalmazza a kötet csatlakoztatását, miután a kötet csatlakozott a podhoz.

A PersistentVolume egy PersistentVolumeClaim-hez lesz kötve, miután egy rendelkezésre álló tárerőforrás hozzá van rendelve az azt kérő podhoz. Az állandó kötetek jogcímekhez való leképezése 1:1.

Az alábbi példa YAML-jegyzék egy állandó kötetjogcímet mutat be, amely az alapértelmezett StorageClassot használja, és 5Gi-lemezt kér:

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
  name: aks-hci-vhdx 
spec: 
  accessModes: 
  - ReadWriteOnce 
  storageClassName: default 
  resources: 
    requests: 
      storage: 5Gi 

Poddefiníció létrehozásakor a rendszer megadja az állandó kötetjogcímet a kívánt tárterület kéréséhez. Ezután meg kell adnia az volumeMount alkalmazások számára az adatok olvasásához és írásához. Az alábbi YAML-jegyzékfájl bemutatja, hogy az előző állandó kötetjogcím hogyan csatlakoztatható a kötethez a következő helyen /mnt/aks-hci:

kind: Pod 
apiVersion: v1 
metadata: 
  name: nginx 
spec: 
  containers: 
    - name: myfrontend 
      image: k8s.gcr.io/nginx 
      volumeMounts: 
      - mountPath: "/mnt/aks-hci" 
        name: volume
  nodeSelector:
      kubernetes.io/os: linux
  volumes: 
    - name: volume 
      persistentVolumeClaim: 
        claimName: aks-hci-vhdx 

Az alábbi példa bemutatja, hogyan csatlakoztathat kötetet egy Windows-tárolóhoz, és hogyan adhatja meg a meghajtó betűjelét és elérési útját:

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

Következő lépések

• Használja az AKS-t az Azure Stack HCI disk Container Storage Interface (CSI) illesztőprogramjaihoz.