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

A következőkre vonatkozik: AKS on Azure Stack HCI 22H2, AKS on Windows Server

Előfordulhat, hogy az Azure Arc által engedélyezett Azure Kubernetes Service-t használó 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 szükségtelen 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 marad. 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 információkat 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:

• Mennyiségek
• Tartós kötetek
• Tárolási osztályok
• Állandó mennyiségi jogcímek (PVC)

Mennyiségek

Az alkalmazásoknak gyakran kell tudniuk tárolni és lekérni az adatokat. Mivel a Kubernetes általában ideiglenes, eldobható erőforrásként kezeli az egyes podokat, különböző módszerek á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ül történő tárolásának, lekérésének és megőrzésének módját jelentik.

A Kubernetesben a kötetek nem csupán egy hagyományos információt tárolhatnak és kérdezhetnek le. A Kubernetes-kötetek adatbeszúráshoz is használhatók 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.

• titkos kód – 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, igényelhet 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á, és a titkos kód tmpf-ben van tárolva, nem lemezre írva. Ha egy titkos kulcsot igénylő csomópont utolsó podja törlődik, a titkos kulcs törlődik a csomópont tmpfs-jeiből. A titkos kulcsok 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, például alkalmazáskonfigurációs információkba való injektálására szolgál. A tárolólemezképen belüli alkalmazáskonfigurációs információk 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ódokhoz hasonlóan először létre kell hoznia egy ConfigMap-et a Kubernetes API használatával. Ez a ConfigMap ezután kérhető 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 névtérben lévő podok férhetnek 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 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.

Használhatja a VHDX által támogatott AKS-lemezköteteket, amelyek ReadWriteOnce-ként vannak csatlakoztatva, és egyszerre egyetlen csomóponthoz érhetők el. SMB- vagy NFS-fájlmegosztások által támogatott AKS-fájlköteteket is használhat. Ezek ReadWriteMany-ként vannak csatlakoztatva, és egyszerre több csomóponton is elérhetők.

A fürtgazdák statikusan hozhatnak létre állandó köteteket, 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örölve legyen az azt használó állandó kötet törlésekor. A tárolási osztály az állandó köteteket is bővíthetőnek állítja be, ezért csak az új mérettel kell szerkesztenie az állandó kötet jogcímét.

Ha nincs megadva StorageClass egy állandó kötethez, a rendszer az alapértelmezett StorageClass-ot használja. Állandó kötetek kérésekor győződjön meg arról, hogy a megfelelő tárolót használják. További igényeknek megfelelő StorageClass-ot is létrehozhat.

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ím teljesítéséhez a definiált StorageClass alapján. A poddefiníció tartalmazza a kötet csatlakoztatását, miután a kötet csatlakoztatva lett a podhoz.

A PersistentVolume egy PersistentVolumeClaim-hez van kötve, amint 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ó mennyiségi jogcímet mutat be, amely az alapértelmezett StorageClass-ot 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 meg kell adnia az állandó kötet jogcímét a kívánt tárterület kéréséhez. Ezután meg kell adnia az alkalmazások számára az volumeMount adatok olvasásához és írásához szükséges adatokat. Az alábbi PÉLDA YAML-jegyzék bemutatja, hogyan használható az előző állandó mennyiségi jogcím a kötet csatlakoztatásához 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óban, é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 lemeztároló-illesztő (CSI) illesztőprogramjaihoz.