Állandó kötetek (PV-k) létrehozása és kezelése az Azure Files az Azure Kubernetes Service-ben (AKS)

Ha több podnak egyidejű hozzáférésre van szüksége ugyanahhoz a tárkötethez, a Azure Files használatával csatlakozhat a kiszolgálói üzenetblokk (SMB) vagy NFS protokoll használatával. Ez a cikk bemutatja, hogyan hozhat létre dinamikusan és statikusan Azure fájlmegosztást egy Azure Kubernetes Service (AKS)-fürt több podja számára.

Megjegyzés:

A Azure fájlCSI-illesztő csak kulcsalapú (NTLM v2) hitelesítéssel engedélyezi az SMB-fájlmegosztások csatlakoztatását, ezért nem támogatja Azure fájlmegosztási beállítások maximális biztonsági profilját. Az NFS-fájlmegosztások csatlakoztatásához nincs szükség kulcsalapú hitelesítésre.

Megjegyzés:

Teljesítményértékelési tesztek futtatásakor a FIO-t javasoljuk. További információ: teljesítményértékelési eszközök és tesztek.

Előfeltételek

Beépített tárolóosztályok használata dinamikus PV-k létrehozására az Azure Files-szal

A tárolási osztályok meghatározzák, hogyan jön létre dinamikusan egy tárolóegység egy állandó kötettel. A rendszer automatikusan létrehoz egy tárfiókot a csomópont erőforráscsoportban a tárosztályhoz a Azure Files fájlmegosztás tárolásához. Ha CSI-illesztőprogramokat használ az AKS-en, két további beépített StorageClasses van, amelyek az Azure Files CSI-tárolóillesztőket használják (a többi CSI-tárolóosztály a fürttel együtt jön létre, az alapértelmezett tárolási osztályokkal együtt).

  • azurefile-csi: Létrehoz egy Azure fájlmegosztást a HDD-tárolóban.
  • azurefile-csi-premium: Létrehoz egy Azure fájlmegosztást az SSD-tárolón.

Mindkét tárolási osztály visszaigénylési szabályzata biztosítja, hogy az alapul szolgáló Azure fájlmegosztás törlődik a megfelelő PV törlésekor. A tárolási osztályok úgy is konfigurálják a fájlmegosztásokat, hogy bővíthetők legyenek, csak szerkesztenie kell az állandó kötet jogcímét (PVC) az új mérettel.

A következő Azure storage redundancia termékváltozatok közül választhat a skuname paraméterhez a tárolási osztály definíciójában:

  • PremiumV2_LRS (ajánlott): SSD kiépített v2, helyileg redundáns tárolás
  • PremiumV2_ZRS (ajánlott): v2 méretezett SSD, zónaredundáns tárolás
  • Premium_LRS: SSD kiépített v1 (örökölt), helyileg redundáns tárolás
  • Premium_ZRS: SSD konfigurálva v1 (régebbi verzió), zónaredundáns tárolás
  • StandardV2_LRS: HDD kiépített v2, helyileg redundáns tárolás
  • StandardV2_ZRS: HDD kiépített v2, zónaredundáns tárolás
  • StandardV2_GRS: HDD kiépített v2, georedundáns tárolás
  • StandardV2_GZRS: Kiépített v2 HDD, földrajzi zónával redundáns tárolás
  • Standard_LRS: HDD használatalapú fizetés, helyileg redundáns tárolás
  • Standard_GRS: HDD használatarányos fizetés, georedundáns tárolás
  • Standard_ZRS: HDD használatalapú fizetés, zónaredundáns tárolás

Fontos

Az Azure Files kiosztott v2 számlázási modelljének használatához a Azure Files CSI-illesztőt version 1.35.0 vagy újabb verziót kell használnia.

Megjegyzés:

Új üzemelő példányok esetén a legtöbb számítási feladathoz javasoljuk az SSD kiépített v2 (PremiumV2_LRS vagy PremiumV2_ZRS) verziót. Az SSD-fájlmegosztások nagyobb teljesítményt és alacsony késésű lemeztámogatást biztosítanak az I/O-igényes számítási feladatokhoz. A prémium szintű fiókok minimális fájlmegosztási kapacitása 100 GiB.

Egyéni tárolóosztályok létrehozása dinamikus PV-khez Azure Files esetén

Az alapértelmezett tárolási osztályok a legtöbb forgatókönyvhöz megfelelőek. Bizonyos esetekben előfordulhat, hogy saját tárolóosztályt szeretne testreszabni a saját paramétereivel. Előfordulhat például, hogy konfigurálnia kell a mountOptions fájlmegosztást.

  1. Hozzon létre egy fájlt, azure-file-sc.yaml és illessze be a következő példajegyzékbe:

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: my-azurefile
    provisioner: file.csi.azure.com
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    allowVolumeExpansion: true
    mountOptions:
      # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
      # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
      - dir_mode=0755
      - file_mode=0755
      - uid=1000
      - gid=1000
      - mfsymlinks
      - cache=strict
      - actimeo=30
      - nosharesock
    parameters:
      skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS (SSD v1), StandardV2_LRS (HDD v2), Standard_LRS (HDD pay-as-you-go)
    
  2. Hozza létre a tárosztályt a kubectl apply következő paranccsal:

    kubectl apply -f azure-file-sc.yaml
    

    A kimenetnek a következő példakimenethez kell hasonlítania:

    storageclass.storage.k8s.io/my-azurefile created
    

Tárolási osztály paraméterei dinamikus PV-khez Azure Files

Az alábbi táblázat olyan paramétereket tartalmaz, amelyekkel az Azure Files szolgáltatással egyéni tárolási osztályt határozhat meg tartós kötetigényekhez (PVC-k).

Név Meaning Elérhető értékek Kötelező Alapértelmezett érték
accountAccessTier Tárolási fiók hozzáférési szintje A standard fiók választhat Hot vagy Cool, a Prémium fiók pedig csak Premium közül választhat. Nem Empty. Használja az alapértelmezett beállítást a különböző tárfióktípusokhoz.
accountQuota Egy fiók kvótájának korlátozása. A maximális kvótát GB-ban (alapértelmezés szerint 102400 GB) adhatja meg. Ha a fiók túllépi a megadott kvótát, a program kihagyja a fiók kiválasztását. Nem 102400
allowBlobPublicAccess Az illesztőprogram által létrehozott tárfiók összes blobjának vagy tárolójának nyilvános hozzáférésének engedélyezése vagy letiltása. true vagy false Nem false
disableDeleteRetentionPolicy Adja meg, hogy letiltsa-e a DeleteRetentionPolicy funkciót az illesztőprogram által létrehozott tárfiókhoz. true vagy false Nem false
folderName Adja meg a mappa nevét Azure fájlmegosztásban. Meglévő mappanév Azure fájlmegosztásban. Nem Ha a mappanév nem létezik a fájlmegosztásban, a csatlakoztatás sikertelen lesz.
getLatestAccount Meghatározza, hogy a létrehozási idő alapján lekérje-e a legújabb fiókkulcsot. Alapértelmezés szerint ez az illesztőprogram kapja meg az első kulcsot. true vagy false Nem false
location Adja meg a Azure tárfiók Azure régióját. Például: eastus. Nem Ha üres, a meghajtó ugyanazt a helynevet használja, mint az aktuális AKS-fürt.
matchTags A címkék egyezése, amikor az illesztőprogram megfelelő tárfiókot próbál megtalálni. true vagy false Nem false
networkEndpointType Adja meg az illesztőprogram által létrehozott tárfiók hálózati végponttípusát. Ha privateEndpoint meg van adva, létrejön egy privát végpont a tárfiókhoz. Más esetekben alapértelmezés szerint létrejön egy szolgáltatásvégpont. "",privateEndpoint Nem ""
protocol Adja meg a fájlmegosztási protokollt. smb, nfs Nem smb
requireInfraEncryption Adja meg, hogy a szolgáltatás egy másodlagos titkosítási réteget alkalmaz-e platform által felügyelt kulcsokkal a inaktív adatokhoz az illesztőprogram által létrehozott tárfiókhoz. true vagy false Nem false
resourceGroup Adja meg a Azure lemezek erőforráscsoportját. Meglévő erőforráscsoport neve Nem Ha üres, az illesztőprogram ugyanazt az erőforráscsoportnevet használja, mint az aktuális AKS-fürt.
selectRandomMatchingAccount Meghatározza, hogy véletlenszerűen válasszon-e egy egyező fiókot. Alapértelmezés szerint az illesztőprogram mindig betűrendben választja ki az első egyező fiókot (megjegyzés: Ez az illesztőprogram fiókkeresési gyorsítótárat használ, ami a fájllétrehozás több fiók közötti egyenlőtlen elosztását eredményezi). true vagy false Nem false
server Adja meg Azure tárfiók kiszolgálói címét. Meglévő kiszolgáló címe, például accountname.privatelink.file.core.windows.net. Nem Ha üres, az illesztőprogram alapértelmezett accountname.file.core.windows.net vagy más szuverén felhőfiók-címet használ.
shareAccessTier A fájlmegosztás hozzáférési szintje Az általános célú v2-fiók választhat TransactionOptimized (alapértelmezett), Hot vagy Cool között. Prémium szintű tárfióktípus csak fájlmegosztásokhoz. Nem Empty. Használja az alapértelmezett beállítást a különböző tárfióktípusokhoz.
shareName Adja meg Azure fájlmegosztás nevét. Meglévő vagy új Azure fájlmegosztás neve. Nem Ha üres, az illesztőprogram létrehoz egy Azure fájlmegosztási nevet.
shareNamePrefix Adja meg Azure illesztőprogram által létrehozott fájlmegosztásnév-előtagot. A megosztási név csak kisbetűket, számokat, kötőjeleket tartalmazhat, és kevesebb, mint 21 karakter hosszú lehet. Nem
skuName Azure Files tárfiók típusa (alias: storageAccountType) Standard_LRS, Standard_ZRS, Standard_GRS, Standard_RAGRS, Standard_RAGZRS, Premium_LRS, Premium_ZRS, StandardV2_LRS, StandardV2_ZRS, StandardV2_GRS, StandardV2_GZRS, PremiumV2_LRS, PremiumV2_ZRS Nem Standard_LRS
A prémium szintű fióktípus minimális fájlmegosztási mérete 100 GB.
A ZRS-fiók típusa korlátozott régiókban támogatott.
Az NFS-fájlmegosztás csak a Prémium fióktípust támogatja.
A v2 verziójú szabványos SKU nevek az Azure Files ellátott v2 modelljére vonatkoznak.
storageAccount Adjon meg egy Azure tárfióknevet. tárolófiókneve Nem Ha nincs megadva egy adott tárfiók neve, az illesztőprogram egy megfelelő tárfiókot keres, amely megfelel az ugyanazon erőforráscsoport fiókbeállításainak. Ha nem talál egyező tárfiókot, újat hoz létre. Ha azonban a tárfiók neve meg van adva, a tárfióknak már léteznie kell.
storageEndpointSuffix Adja meg Azure tárolási végpont utótagját. core.windows.net, stb core.chinacloudapi.cn. Nem Ha üres, az illesztőprogram az alapértelmezett tárolási végpont utótagját használja a felhőkörnyezetnek megfelelően. Például: core.windows.net.
subscriptionID Adja meg Azure előfizetés-azonosítót, ahol Azure fájlmegosztás jön létre. Azure előfizetés azonosítója Nem Ha nem üres, resourceGroup meg kell adni.
tags A címkék új tárfiókban jönnek létre. Címkeformátum: 'foo=aaa,bar=bbb' Nem ""
--- Az alábbi paraméterek csak az SMB protokollhoz tartoznak --- --- ---
storeAccountKey Adja meg, hogy a kubernetes titkos kulcsában tárolja-e a fiókkulcsot. true vagy false
false azt jelenti, hogy az illesztőprogram kubelet-identitást használ a fiókkulcs lekéréséhez.
Nem true
secretName Adja meg a fiókkulcs tárolásához használt titkos nevet. Nem
secretNamespace Adja meg a fiókkulcs tárolására használt titkos kód névterét.

Megjegyzés:
Ha secretNamespace nincs megadva, a titkos kód ugyanabban a névtérben jön létre, mint a pod.
defaultstbkube-system. Nem PVC névtér, például csi.storage.k8s.io/pvc/namespace
useDataPlaneAPI Adja meg, hogy a data plane API-t használják-e a fájlmegosztás létrehozásához/törléséhez/átméretezéséhez. Ez megoldhatja az SRP API korlátozásával kapcsolatos problémát, mivel a data plane API-nak szinte nincs korlátja. Azonban sikertelen lehet, ha a tárfiók tűzfal- vagy Vnet-beállításai vannak érvényben. true vagy false Nem false
--- Az alábbi paraméterek csak az NFS protokollhoz tartoznak --- --- ---
mountPermissions Csatlakoztatott mappaengedélyek. Az alapértelmezett érték a 0777. Ha 0 van beállítva, az illesztőprogram nem hajt végre chmod a csatlakoztatás után. 0777 Nem
rootSquashType Adja meg a megosztás root squashing, azaz a felhasználói jogosultságokat korlátozó viselkedését. Az alapértelmezett érték: NoRootSquash \, \, \ Nem
--- A következő paraméterek csak a virtuális hálózat beállítására használhatók (például: NFS, privát végpont) --- --- ---
fsGroupChangePolicy Azt jelzi, hogy a vezérlőprogram hogyan változtatja meg a kötet tulajdonjogát. A pod securityContext.fsGroupChangePolicy figyelmen kívül lesz hagyva. OnRootMismatch (alapértelmezett), Always, None Nem OnRootMismatch
subnetName Alhálózat neve Az ügynökcsomópont meglévő alhálózati neve. Nem Ha üres, az illesztőprogram a subnetName értéket használja Azure felhőkonfigurációs fájlban.
vnetName Virtuális hálózat neve Meglévő virtuális hálózat neve. Nem Ha üres, az illesztőprogram frissíti a fürt virtuális hálózatának összes alhálózatát.
vnetResourceGroup Adja meg a virtuális hálózati erőforráscsoportot, ahol a virtuális hálózat definiálva van. Meglévő erőforráscsoport neve. Nem Ha üres, az illesztőprogram a vnetResourceGroup értéket használja Azure felhőkonfigurációs fájlban.

Fontos

A tags tárosztály paraméter a tárfiókra lesz alkalmazva, amikor a Azure Files CSI-illesztőprogram kiépíti a kötetet. Az állandó kötet létrehozása után a PersistentVolume specifikáció nem módosítható, ezért a PV szerkesztése vagy javítása sikertelen a címkék vagy más kötetattribútumok módosításához. A tárolási osztály későbbi frissítése csak az újonnan kiépített köteteket érinti.

Meglévő kötet címkéinek frissítéséhez módosítsa őket a Azure mögöttes tárfiókjában. Ha a tárosztály meglévő tárfiókot használ, frissítse a címkéket a fiókon. Ez a művelet nem szakítja meg a meglévő csatlakoztatásokat, podokat vagy adathozzáférést, és a frissített Azure címkék nem szinkronizálódnak vissza a Kubernetes PV YAML-hez vagy metaadatokhoz. Például:

az storage account update \
    --name mystorageaccount \
    --resource-group MC_myResourceGroup_myAKSCluster_eastus \
    --set tags.abc=ABC123

Megjegyzés:

Ha a tárfiókot az illesztőprogram hozza létre, akkor csak a tárolási osztály paraméterét kell megadnia networkEndpointType: privateEndpoint . A CSI-illesztő létrehozza a privát végpontot és a privát DNS-zónát (neve) privatelink.file.core.windows.neta fiókkal együtt. Ha saját tárfiókot hoz létre, létre kell hoznia a tárfiók privát végpontját . Ha az Azure Files tárolót használja egy hálózatilag elszigetelt fürtben, akkor létre kell hoznia egy egyéni tárolási osztályt a "networkEndpointType: privateEndpoint" beállítással. Hivatkozásként a következő példajegyzéket használhatja:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-private-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, StandardV2_LRS, Standard_LRS
  networkEndpointType: privateEndpoint
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
  # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
  - dir_mode=0755
  - file_mode=0755
  - uid=1000
  - gid=1000
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

PVC létrehozása Azure Files segítségével

A PVC a tárolási osztály objektumával dinamikusan épít ki egy Azure fájlmegosztást. Az ebben a szakaszban található YAML-jegyzékfájllal létrehozhat egy 100 GB méretű, ReadWriteMany-hozzáféréssel rendelkező PVC-t . A hozzáférési módokkal kapcsolatos további információkért lásd a Kubernetes PV hozzáférési módokat.

  1. Hozzon létre egy azure-file-pvc.yaml nevű fájlt, és illessze be a következő YAML-t. Győződjön meg arról, hogy a storageClassName név megegyezik a meglévő tárosztály nevével.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: my-azurefile
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: my-azurefile
      resources:
        requests:
          storage: 100Gi
    

    Megjegyzés:

    Ha a Premium_LRS tárolási osztály termékváltozatát használja, akkor a storage minimális értékének 100Gi-nek kell lennie.

  2. Hozza létre a PVC-t a kubectl apply paranccsal.

    kubectl apply -f azure-file-pvc.yaml
    
  3. Tekintse meg a PVC állapotát a kubectl get következő paranccsal:

    kubectl get pvc my-azurefile
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy a PVC Bound állapotban van, és dinamikusan létrehoztak egy PV-t a jogcím kielégítése érdekében.

    NAME           STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
    my-azurefile   Bound     pvc-aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb   100Gi       RWX            my-azurefile      5m
    

Egy PVC használata az Azure Files egy podban

Az ebben a szakaszban szereplő YAML-jegyzékfájl létrehoz egy podot, amely a PVC my-azurefile használatával csatlakoztatja a Azure Files fájlmegosztást a /mnt/azure elérési úthoz. Windows Server tárolók esetében adjon meg egy mountPath a Windows elérésiút-konvencióval, például 'D:'.

  1. Hozzon létre egy fájlt, azure-pvc-files.yaml és illessze be a következő YAML szöveget. Győződjön meg arról, hogy az claimName egyezik a meglévő PVC nevével.

    kind: Pod
    apiVersion: v1
    metadata:
      name: mypod
    spec:
      containers:
        - name: mypod
          image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi
          volumeMounts:
            - mountPath: /mnt/azure
              name: volume
              readOnly: false
      volumes:
       - name: volume
         persistentVolumeClaim:
           claimName: my-azurefile
    
  2. Hozza létre a podot a kubectl apply paranccsal.

    kubectl apply -f azure-pvc-files.yaml
    
  3. Tekintse meg a pod állapotát a kubectl describe következő paranccsal:

    kubectl describe pod mypod
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy a pod fut, és a kötet a megfelelő útvonalon van csatlakoztatva:

    Containers:
      mypod:
        Container ID:   docker://BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
        Image:          mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
        Image ID:       docker-pullable://nginx@sha256:AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
        State:          Running
          Started:      Fri, 01 Mar 2019 23:56:16 +0000
        Ready:          True
        Mounts:
          /mnt/azure from volume (rw)
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-8rv4z (ro)
    [...]
    Volumes:
      volume:
        Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
        ClaimName:  my-azurefile
        ReadOnly:   false
    [...]
    

Csatlakoztatási lehetőségek Azure Files

A csatlakoztatási beállítások konfigurálásának helye (mountOptions) attól függ, hogy dinamikus vagy statikus perzisztens köteteket épít ki.

  • Ha dinamikusan épít ki egy kötetet egy tárolási osztálysal, adja meg a tárolási osztály objektumának csatlakoztatási beállításait (típusa: StorageClass).
  • Ha statikusan helyez el egy kötetet, adja meg a csatolási beállításokat a PV objektumon (típus: PersistentVolume).
  • Ha beágyazott kötetként csatlakoztatja a fájlmegosztást, adja meg a podobjektum csatlakoztatási beállításait (típus: Pod).

További információ: Csatlakoztatási beállítások.

A Kubernetes 1.13.0-s és újabb verzióinak alapértelmezett értéke fileModedirMode0777 . A következő példa a 0777-et állítja be:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com
allowVolumeExpansion: true
mountOptions:
  # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
  # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
  - dir_mode=0755
  - file_mode=0755
  - uid=1000
  - gid=1000
  - mfsymlinks
  - cache=strict
  - actimeo=30
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
parameters:
  skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS (SSD v1), StandardV2_LRS (HDD v2), Standard_LRS (HDD pay-as-you-go)

Az SMB-megosztásokhoz ajánlott csatlakoztatási beállításokat a következő tárosztály-példában adhatja meg:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
    skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, StandardV2_LRS, Standard_LRS, Standard_ZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
    # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
    # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
    - dir_mode=0755
    - file_mode=0755
    - uid=1000
    - gid=1000
    - mfsymlinks    # support symbolic links
    - cache=strict  # https://linux.die.net/man/8/mount.cifs
    - nosharesock  # reduces probability of reconnect race
    - actimeo=30  # reduces latency for metadata-heavy workload
    - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Ha prémium szintű (SSD) fájlmegosztásokat használ az SMB protokollal, és a számítási feladat metaadat-intenzív, iratkozzon fel a metaadatok gyorsítótárazási funkció használatára a teljesítmény javítása érdekében.

További információ: Az SMB-Azure fájlmegosztások teljesítménye.

Az NFS-megosztásokhoz javasolt csatlakoztatási beállításokat a következő tárosztály-példában adhatja meg:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
parameters:
    protocol: nfs
    skuName: PremiumV2_LRS     # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_ZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
    - nconnect=4  # improves performance by enabling multiple connections to share
    - noresvport  # improves availability
    - actimeo=30  # reduces latency for metadata-heavy workloads

A előolvasási méret növelése az olvasási sávszélesség növelése érdekében.

Bár Azure Files támogatja az nconnect beállítását a 16-os maximális értékre, javasoljuk, hogy konfigurálja a csatlakoztatási beállításokat az nconnect=4 optimális beállításával. Jelenleg az nconnect Azure Files megvalósításának négy csatornán kívül nincs nyeresége.

Mennyiségi pillanatkép létrehozása PVC-ről Azure Files

A Azure Files CSI-illesztőprogram támogatja az állandó kötetek és a mögöttes fájlmegosztások napshotjainak létrehozását.

  1. Hozzon létre egy mennyiségi pillanatkép-osztályt a kubectl apply következő paranccsal:

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshotclass-azurefile.yaml
    

    A kimenetnek a következő példakimenethez kell hasonlítania:

    volumesnapshotclass.snapshot.storage.k8s.io/csi-azurefile-vsc created
    
  2. Hozzon létre egy mennyiségi pillanatképet az oktatóanyag korábbi részében létrehozott dinamikus PVC-ből a kubectl apply következő paranccsal:

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshot-azurefile.yaml
    

    A kimenetnek a következő példakimenethez kell hasonlítania:

    volumesnapshot.snapshot.storage.k8s.io/azurefile-volume-snapshot created
    
  3. Tekintse meg a kötet pillanatképének állapotát a kubectl describe következő paranccsal:

    kubectl describe volumesnapshot azurefile-volume-snapshot
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy a kötet pillanatképe nem áll készen a használatra, mert az illesztőprogram még mindig létrehozza az alapul szolgáló Azure fájlmegosztás pillanatképét:

    Name:         azurefile-volume-snapshot
    Namespace:    default
    Labels:       <none>
    Annotations:  API Version:  snapshot.storage.k8s.io/v1beta1
    Kind:         VolumeSnapshot
    Metadata:
      Creation Timestamp:  2020-08-27T22:37:41Z
      Finalizers:
        snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
        snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
      Generation:        1
      Resource Version:  955091
      Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/azurefile-volume-snapshot
      UID:               00aa00aa-bb11-cc22-dd33-44ee44ee44ee
    Spec:
      Source:
        Persistent Volume Claim Name:  pvc-azurefile
      Volume Snapshot Class Name:      csi-azurefile-vsc
    Status:
      Bound Volume Snapshot Content Name:  snapcontent-00aa00aa-bb11-cc22-dd33-44ee44ee44ee
      Ready To Use:                        false
    Events:                                <none>
    

Állandó kötet átméretezése az Azure Files használatával

Megjegyzés:

Az állandó kötetek zsugorítása jelenleg nem támogatott. Ha egy meglévő, az aktuálisnál kisebb méretű PVC-t próbál kijavítani, az a következő hibaüzenethez vezet:

The persistentVolumeClaim "pvc-azurefile" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

A PVC-objektum szerkesztésével nagyobb méretet kérhet a PVC számára. Ez a módosítás elindítja a PV-t (állandó kötetet) támogató mögöttes kötet kiterjesztését. A rendszer soha nem hoz létre új PV-t a jogcím kielégítése érdekében. Ehelyett a rendszer átméretez egy meglévő kötetet.

Az AKS-ben a beépített managed-csi tárolási osztály már támogatja a bővítést, így használhatja az oktatóanyag korábbi részében létrehozott dinamikus PVC-t. A PVC 100 GiB-fájlmegosztást kért.

  1. Ellenőrizze a PVC és a podon belüli fájlrendszer aktuális méretét a kubectl exec parancs használatával a df -h podon belüli parancs futtatásához:

    kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy a fájlrendszer mérete 100 GB:

    Filesystem                                                                                      Size  Used Avail Use% Mounted on
    //a123b4c567de89fghi01jk2.file.core.windows.net/pvc-00aa00aa-bb11-cc22-dd33-44ee44ee44ee  100G  128K  100G   1% /mnt/azurefile
    
  2. Növelje a PVC-t a spec.resources.requests.storage mező bővítésével a kubectl patch parancs segítségével. Ebben a példában a fájlmegosztást 200 GiB-ra növeljük:

    kubectl patch pvc pvc-azurefile --type merge --patch '{"spec": {"resources": {"requests": {"storage": "200Gi"}}}}'
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy a PVC-t sikeresen javították:

    persistentvolumeclaim/pvc-azurefile patched
    
  3. Ellenőrizze, hogy a PVC sikeresen átméretezve lett-e, és az új méret tükröződik-e a podban azáltal, hogy használja a kubectl get pvc és a df -h parancsokat a podban:

    kubectl get pvc pvc-azurefile
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy a PVC még mindig állapotban Bound van, és a kapacitás 200 GiB-ra frissült:

    NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
    pvc-azurefile   Bound    pvc-00aa00aa-bb11-cc22-dd33-44ee44ee44ee   200Gi      RWX            azurefile-csi   64m
    
  4. Ellenőrizze a fájlrendszer új méretét a podon belül a kubectl exec parancs segítségével úgy, hogy a df -h parancsot futtatja a podban.

    kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy a fájlrendszer mérete most már 200 GB:

    Filesystem                                                                                Size  Used Avail Use% Mounted on
    //a123b4c567de89fghi01jk2.file.core.windows.net/pvc-bbbbbbbb-1111-2222-3333-cccccccccccc  200G  128K  200G   1% /mnt/azurefile
    

Állandó kötet használata privát Azure Files tárolóval (privát végpont)

Ha a Azure Files-erőforrások privát végponttal vannak védve, létre kell hoznia egy saját tárosztályt. Győződjön meg arról, hogy konfigurálta a DNS-beállításokat a privát végpont IP-címének az FQDN-re, vagyis a teljes tartománynevére való feloldásához a kapcsolati karakterláncban. Amikor a Azure Files CSI-illesztőprogrammal hozza létre a tárosztályt, meg kell adnia a networkEndpointType paramétert a privateEndpoint értékkel, és meg kell adnia a következő paramétereket:

  • resourceGroup: Az az erőforráscsoport, amelyben a tárfiók üzembe van helyezve.
  • storageAccount: A tárfiók neve.
  • server: A tárfiók privát végpontjának teljes tartományneve.
  1. Hozzon létre egy elnevezett private-azure-file-sc.yaml fájlt, majd illessze be a következő jegyzékbe. Győződjön meg arról, hogy lecseréli a <resourceGroup> és <storageAccountName> helyőrzőket.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: azurefile-csi-private-custom
    provisioner: file.csi.azure.com
    allowVolumeExpansion: true
    parameters:
      skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, StandardV2_LRS
      resourceGroup: <resourceGroup>
      storageAccount: <storageAccountName>
      server: <storageAccountName>.file.core.windows.net
      networkEndpointType: privateEndpoint
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    mountOptions:
      # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
      # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
      - dir_mode=0755
      - file_mode=0755
      - uid=1000
      - gid=1000
      - mfsymlinks
      - cache=strict  # https://linux.die.net/man/8/mount.cifs
      - nosharesock  # reduce probability of reconnect race
      - actimeo=30  # reduce latency for metadata-heavy workload
      - nobrl
    
  2. Hozza létre a tárosztályt a kubectl apply következő paranccsal:

    kubectl apply -f private-azure-file-sc.yaml
    

    A kimenetnek a következő példakimenethez kell hasonlítania:

    storageclass.storage.k8s.io/private-azurefile-csi created
    
  3. Nevezze el a fájlt private-pvc.yaml névvel és másolja be az alábbi állományba. Győződjön meg arról, hogy a storageClassName név megegyezik a meglévő tárosztály nevével.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: private-azurefile-pvc
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: private-azurefile-csi
      resources:
        requests:
          storage: 100Gi
    
  4. Hozza létre a PVC-t a kubectl apply paranccsal.

    kubectl apply -f private-pvc.yaml
    

Azure Files használata Windows tárolókkal

A Azure Files CSI-illesztőprogram Windows csomópontokat és tárolókat is támogat. A Windows tárolók használatához kövesse a Windows tárolók rövid útmutatót egy Windows csomópontkészlet hozzáadásához. Miután rendelkezik egy Windows csomópontkészletével, használhatja a beépített tárolási osztályokat, például azurefile-csi, vagy létrehozhat egy egyénit. A példa Windows-alapú állapotalapú készlet ebben a szakaszban másodpercenként menti az időbélyegeket egy data.txt fájlba, amely egy Azure fájlmegosztásra van csatlakoztatva a Azure Files CSI-illesztőprogram használatával.

  1. Hozza létre az állapotalapú készletet a kubectl apply következő paranccsal:

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/windows/statefulset.yaml
    

    A kimenetnek a következő példakimenethez kell hasonlítania:

    statefulset.apps/busybox-azurefile created
    
  2. Ellenőrizze, hogy az időbélyegek a fájlmegosztásba vannak-e írva a következő kubectl exec parancsokkal a cat parancs podon belüli futtatásához:

    kubectl exec -it busybox-azurefile-0 -- cat c:\\mnt\\azurefile\\data.txt # on Linux/MacOS Bash
    kubectl exec -it busybox-azurefile-0 -- cat c:\mnt\azurefile\data.txt # on Windows Powershell/CMD
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy az időbélyegek minden másodpercben a fájlmegosztásba vannak írva:

    2020-08-27 22:11:01Z
    2020-08-27 22:11:02Z
    2020-08-27 22:11:04Z
    (...)
    

Azure Files használata az NFS protokollal

Azure Files támogatja az NFS v4.1 protokollt. A Azure Files NFS 4.1-es verziójának támogatása teljes körűen felügyelt NFS-fájlrendszert biztosít egy magas rendelkezésre állású és rendkívül tartós elosztott rugalmas tárolási platformra épülő szolgáltatásként.

Ez a beállítás véletlenszerű hozzáférésű számítási feladatokhoz van optimalizálva helyszíni adatfrissítésekkel, és teljes POSIX-fájlrendszer-támogatást nyújt. Ez a szakasz bemutatja, hogyan használhat NFS-megosztásokat egy AKS-fürtön az Azure File CSI-illesztőprogrammal.

Az NFS-megosztások Azure Files való használatának előfeltételei

  • Az NFS-hez SSD-fájlmegosztásokra (például PremiumV2_LRS, PremiumV2_ZRS, Premium_LRSvagy Premium_ZRS) és virtuális hálózatra kompatibilis tárfiókra van szükség.
  • Az AKS-fürt vezérlősíkjának identitása (vagyis az AKS-fürt neve) hozzá lesz adva a közreműködői szerepkörhöz a virtuális hálózaton és a NetworkSecurityGroupban.
  • Az AKS-fürt szolgáltatásnevét vagy felügyeltszolgáltatás-identitását (MSI) hozzá kell adni a közreműködői szerepkörhöz a tárfiókhoz.

Megjegyzés:

A kijelölt virtuális hálózathoz való hozzáférés engedélyezése helyett privát végpontot is használhat.

Olvasási és írási méret beállításainak optimalizálása

Ez a szakasz bemutatja, hogyan közelítheti meg az NFS teljesítményhangolását a Azure Files CSI-illesztővel a rsize és wsize beállításokkal. Az rsize és wsize a beállítások az NFS-műveletek maximális átviteli méretét adják meg. Ha rsize vagy wsize egyike sincs megadva a csatlakoztatáskor, akkor az ügyfél és a kiszolgáló egyezteti a kettő által támogatott legnagyobb méretet. A Azure Files és a modern Linux-disztribúciók jelenleg 1 048 576 bájt (1 MiB) méretű olvasási és írási méretet támogatnak.

Az optimális teljesítmény a hatékony ügyfél-kiszolgáló kommunikáción alapul. A csatlakoztatási olvasási és írási beállítás méretének növelése vagy csökkentése javíthatja az NFS teljesítményét. Az ügyfél és a kiszolgáló között átvitt olvasási/írási csomagok alapértelmezett mérete 8 KB az NFS 2-es verziójához, az NFS 3- és 4-es verziójához pedig 32 KB. Ezek az alapértelmezett értékek túl nagyok vagy túl kicsiek lehetnek. rsize A wsize csökkentése javíthatja a túlterhelt hálózatok NFS-teljesítményét azáltal, hogy az egyes NFS-olvasási válasz- és írási kérelmekhez kisebb csomagokat küld. Ez azonban növelheti az adatok hálózaton keresztüli küldéséhez szükséges csomagok számát, ezáltal növelve a teljes hálózati forgalmat és a cpu-kihasználtságot az ügyfélen és a kiszolgálón.

Fontos, hogy tesztelést végezzen olyan rsize és wsize megtalálása érdekében, amelyek fenntartják a hatékony csomagátvitelt, és ne csökkentsék az átviteli teljesítményt, illetve ne növeljék a késleltetést.

Az alábbi példajegyzék egy mountOptions tárolási osztály szakaszát legfeljebb rsizewsize 256 KiB értékre konfigurálja:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-premiumv2-custom
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
  skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_ZRS
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30
  - rsize=262144
  - wsize=262144

A támogatottak mountOptionslistájáért tekintse meg az NFS csatlakoztatási beállításait.

NFS-fájlmegosztási tárosztály létrehozása

Megjegyzés:

vers, minorversion, sec az Azure fájl CSI-illesztőprogramja konfigurálja. A jegyzékben a megadott tulajdonságokhoz értékek megadása nem támogatott.

  1. Nevezze el a fájlt nfs-sc.yaml névvel és másolja be az alábbi állományba. Ügyeljen arra, hogy a paraméterek szakaszban adja meg protocol: nfs , és módosítsa a mountOptions számítási feladathoz szükséges értéket.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: azurefile-csi-premiumv2-custom
    provisioner: file.csi.azure.com
    allowVolumeExpansion: true
    parameters:
      protocol: nfs
      skuName: PremiumV2_LRS  # SSD provisioned v2 (recommended). Alternatives: Premium_LRS, Premium_ZRS, PremiumV2_ZRS
    mountOptions:
      - nconnect=4
      - noresvport
      - actimeo=30
    
  2. A fájl szerkesztése és mentése után hozza létre a tárosztályt a kubectl apply paranccsal.

    kubectl apply -f nfs-sc.yaml
    

    A kimenetnek a következő példakimenethez kell hasonlítania:

    storageclass.storage.k8s.io/azurefile-csi-nfs created
    

Állapotalapú készlet létrehozása NFS-alapú fájlmegosztással

  1. Nevezze el a fájlt nfs-ss.yaml névvel és másolja be az alábbi állományba. Ez a konfiguráció az időbélyegeket fájlba data.txtmenti.

    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: statefulset-azurefile
      labels:
        app: nginx
    spec:
      podManagementPolicy: Parallel  # default is OrderedReady
      serviceName: statefulset-azurefile
      replicas: 1
      template:
        metadata:
          labels:
            app: nginx
        spec:
          nodeSelector:
            "kubernetes.io/os": linux
          containers:
            - name: statefulset-azurefile
              image: mcr.microsoft.com/oss/nginx/nginx:1.19.5
              command:
                - "/bin/bash"
                - "-c"
                - set -euo pipefail; while true; do echo $(date) >> /mnt/azurefile/outfile; sleep 1; done
              volumeMounts:
                - name: persistent-storage
                  mountPath: /mnt/azurefile
      updateStrategy:
        type: RollingUpdate
      selector:
        matchLabels:
          app: nginx
      volumeClaimTemplates:
        - metadata:
            name: persistent-storage
          spec:
            storageClassName: azurefile-csi-premiumv2-custom
            accessModes: ["ReadWriteMany"]
            resources:
              requests:
                storage: 100Gi
    
  2. Hozza létre az állapotalapú készletet a kubectl apply paranccsal.

    kubectl apply -f nfs-ss.yaml
    

    A kimenetnek a következő példakimenethez kell hasonlítania:

    statefulset.apps/statefulset-azurefile created
    
  3. Ellenőrizze a kötet tartalmát a következő kubectl exec paranccsal a df -h podon belüli parancs futtatásához:

    kubectl exec -it statefulset-azurefile-0 -- df -h
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy az NFS-fájlmegosztás a megfelelő elérési úthoz van csatlakoztatva a megfelelő mérettel:

    Filesystem      Size  Used Avail Use% Mounted on
    ...
    /dev/sda1                                                                                 29G   11G   19G  37% /etc/hosts
    accountname.file.core.windows.net:/accountname/pvc-cccccccc-2222-3333-4444-dddddddddddd  100G     0  100G   0% /mnt/azurefile
    ...
    

    Mivel az NFS-fájlmegosztás prémium szintű tárfiókban található, a fájlmegosztás minimális mérete 100 GiB. Ha kis méretű PVC-t hoz létre, az alábbihoz hasonló hibaüzenet jelenhet meg: nem sikerült létrehozni a fájlmegosztást ... méret (5)....

Titkosítás átvitel közben (EiT) NFS-fájlmegosztásokhoz (előzetes verzió)

Megjegyzés:

Az EiT funkció már előzetes verzióban is elérhető az AKS 1.33-mal kezdődően. Az Ubuntu 20.04, Azure Linux, arm64 és Windows csomópontok jelenleg nem támogatottak.

A szolgáltatás minden olyan Azure régióban támogatott, amelyek támogatják az SSD-Azure fájlmegosztásokat.

Az átvitel közbeni titkosítás (EiT) biztosítja, hogy a virtuális hálózaton belüli NFS-fájlmegosztások összes olvasása és írása titkosítva legyen, ami további biztonsági réteget biztosít.

A StorageClass paraméterek encryptInTransit: "true" vagy a PersistentVolume beállítások volumeAttributes használatával engedélyezheti az adattitkosítást az NFS Azure fájlmegosztások átvitel közben.

Dinamikus ellátás (StorageClass)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-premiumv2-eit
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
  skuName: PremiumV2_LRS
  encryptInTransit: "true"
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30

Meglévő állandó kötetek

Az átvitel közben titkosítás nélkül létrehozott virtuális gépek esetében a következő értékre encryptInTransit: "true"kell beállítanivolumeAttributes:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-azurefile-eit
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  mountOptions:
    - nconnect=4
    - noresvport
    - actimeo=30
  csi:
    driver: file.csi.azure.com
    volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"
    volumeAttributes:
      protocol: nfs
      encryptInTransit: "true"
      resourceGroup: "{resource-group-name}"
      storageAccount: "{account-name}"
      shareName: "{file-share-name}"

Felügyelt identitás használata Azure Files tárterület eléréséhez (előzetes verzió)

Azure Files mostantól támogatja a felügyelt identitásalapú hitelesítést az SMB-hozzáféréshez. Ez lehetővé teszi, hogy az alkalmazások biztonságosan elérhessék Azure Files a hitelesítő adatok tárolása és kezelése nélkül.

Megjegyzés:

Az AKS Azure Files felügyelt identitástámogatása előzetes verzióban érhető el, kezdve az AKS 1.34-es verziójával Linux-csomópontokon.

A felügyelt identitás Azure Files tárterület eléréséhez való használatának előfeltételei

  • Győződjön meg arról, hogy a felhasználó által hozzárendelt Kubelet-identitás rendelkezik a Storage File Data SMB MI Admin tárfiók szerepkörével.
    • Ha saját tárfiókot használ, szerepkört kell hozzárendelnie Storage File Data SMB MI Admin a felhasználó által hozzárendelt Kubelet-identitáshoz a tárfiókon.
    • Ha a tárfiókot a CSI-illesztőprogram hozza létre, adjon Storage File Data SMB MI Admin szerepkört annak az erőforráscsoportnak, amelyben a tárfiók található.

A felügyelt identitás engedélyezése dinamikus PV-khez az Azure Fájlokkal

A dinamikusan kiosztott kötetek felügyelt identitásának engedélyezéséhez létre kell hoznia egy új tárosztályt a következővel mountWithManagedIdentity: "true" és ezzel a tárolási osztálysal kell üzembe helyeznie az állapotalapú készletet.

Az alábbi példajegyzék egy tárosztályt konfigurál, hogy felügyelt identitást használjon a Azure Files eléréséhez:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: azurefile-csi
provisioner: file.csi.azure.com
parameters:
   resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
   storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
   mountWithManagedIdentity: "true"
   # optional, clientID of the managed identity, kubelet identity would be used by default if it's not provided
   clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
   # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
   # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
   - dir_mode=0755
   - file_mode=0755
   - uid=1000
   - gid=1000
   - mfsymlinks
   - cache=strict  # https://linux.die.net/man/8/mount.cifs
   - nosharesock  # reduce probability of reconnect race
   - actimeo=30  # reduce latency for metadata-heavy workload
   - nobrl  # disable sending byte range lock requests to the server

Statikus tartós kötetek felügyelt identitásának engedélyezése az Azure Fájlokhoz

Ha a felügyelt identitást statikusan kiépített Azure Files állandó kötetekkel szeretné használni, győződjön meg a következő konfigurációról:

  1. Engedélyezze az SMBOauthot a tárfiókon a következő futtatásával:
    az storage account update --name <account-name> --resource-group <resource-group-name> --enable-smb-oauth true
    
  2. Hozzon létre egy PV-t a következővel mountWithManagedIdentity: "true" és csatlakoztassa a PV-t az alkalmazás podjához.

Az alábbi példajegyzék egy PV-t konfigurál, hogy felügyelt identitást használjon a Azure Files eléréséhez:

apiVersion: v1
kind: PersistentVolume
metadata:
   name: pv-azurefile
spec:
   capacity:
   storage: 100Gi
   accessModes:
   - ReadWriteMany
   persistentVolumeReclaimPolicy: Retain
   storageClassName: azurefile-csi
   mountOptions:
   # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
   # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
   - dir_mode=0755
   - file_mode=0755
   - uid=1000
   - gid=1000
   - mfsymlinks
   - cache=strict  # https://linux.die.net/man/8/mount.cifs
   - nosharesock  # reduce probability of reconnect race
   - actimeo=30  # reduce latency for metadata-heavy workload
   - nobrl  # disable sending byte range lock requests to the server
   csi:
   driver: file.csi.azure.com
   # make sure volumeHandle is unique for every identical share in the cluster
   volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"
   volumeAttributes:
       resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
       storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
       shareName: EXISTING_FILE_SHARE_NAME
       mountWithManagedIdentity: "true"
       # optional, clientID of the managed identity, kubelet identity would be used by default if it's empty
       clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"

Számítási feladatok identitásának használata Azure Files tárterület eléréséhez (előzetes verzió)

Azure Files mostantól támogatja a számítási feladatok identitásalapú hitelesítését az SMB-hozzáféréshez. A számítási feladatok identitása lehetővé teszi a podszintű, minimális jogosultsági szintű hozzáférést a Azure Files anélkül, hogy az alkalmazásidentitást a csomópont életciklusához kell volna hozzákenni.

Megjegyzés:

Az AKS-ben Azure Files számítási feladatok identitásának támogatása előzetes verzióban érhető el, kezdve az AKS 1.35.0-s verziójával Linux-csomópontokon.

A munkaterhelési identitás használatának előfeltételei az Azure Files tárterülethez való hozzáféréshez.

Mielőtt az Azure Files eléréséhez az AKS-ből, a munkaterhelés-identitást használná, teljesítse az alábbi előfeltételeket.

1. Hozzon létre egy fürtöt, amelyen engedélyezve van az oidc-kiállító, és kérje le az AKS-fürt hitelesítő adatait

Hozzon létre egy új AKS-fürtöt, amelyen engedélyezve van az OIDC-kiállító, vagy ellenőrizze, hogy engedélyezve van-e. Kövesse a hivatalos dokumentációt az --enable-oidc-issuer paraméterrel új AKS-fürt létrehozásához és a fürt hitelesítő adatainak lekéréséhez. És állítsa be a következő környezeti változókat:

export RESOURCE_GROUP=<your resource group name>
export CLUSTER_NAME=<your cluster name>
export REGION=<your region>

2. A tárfiók előkészítése

Hozzon létre egy új tárfiókot és fájlmegosztást, vagy használjon egy meglévőt. Részletes útmutatásért tekintse meg a Azure Files documentation. Állítsa be a következő környezeti változókat:

export STORAGE_RESOURCE_GROUP=<your storage account resource group>
export ACCOUNT=<your storage account name>
export SHARE=<your fileshare name> # optional

3. Felügyelt identitás létrehozása vagy újrafelhasználása, valamint a szükséges engedélyek megadása

Hozzon létre egy felhasználó által hozzárendelt felügyelt identitást, vagy használjon újra egy meglévőt (például az AKS-csomópont erőforráscsoporthoz társított felügyelt identitást ). És kérje le a szükséges identitás- és erőforrásadatokat:

export UAMI=<your managed identity name>
az identity create --name $UAMI --resource-group $RESOURCE_GROUP

export USER_ASSIGNED_CLIENT_ID="$(az identity show -g $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"
export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)
export ACCOUNT_SCOPE=$(az storage account show --name $ACCOUNT --query id -o tsv)

Adja meg a szerepkört Storage File Data SMB MI Admin a felügyelt identitásnak. Ez a szerepkör lehetővé teszi, hogy Azure Files csak számítási feladatok identitásjogkivonatait használja, tárfiókkulcsok használata nélkül.

az role assignment create --role "Storage File Data SMB MI Admin" --assignee $USER_ASSIGNED_CLIENT_ID --scope $ACCOUNT_SCOPE

4. Kubernetes ServiceAccount létrehozása

Hozzon létre egy Kubernetes ServiceAccount-fiókot, amelyet a számítási feladat használni fog.

export SERVICE_ACCOUNT_NAME=<your sa name>
export SERVICE_ACCOUNT_NAMESPACE=<your sa namespace>

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

5. Az összevont identitás hitelesítő adatainak létrehozása

Hozza létre a federált identitáshitelesítő adatot a felügyelt identitás, a szolgáltatásfiók kiállítója és az alany között a az identity federated-credential create parancs használatával.

export FEDERATED_IDENTITY_NAME=<your federated identity name>
export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"

az identity federated-credential create --name $FEDERATED_IDENTITY_NAME \
--identity-name $UAMI \
--resource-group $RESOURCE_GROUP \
--issuer $AKS_OIDC_ISSUER \
--subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}

A lépések elvégzése után a megadott ServiceAccount használatával futó számítási feladatok a tárfiókkulcsok vagy csomópontszintű felügyelt identitások használata nélkül hitelesíthetők Azure Files Microsoft Entra számítási feladat identitásával.

A feladat identitásának engedélyezése dinamikus PVC-khez az Azure Files használatával

Ha dinamikusan kiosztott Azure Files állandó kötetekkel szeretné használni a számítási feladat identitását, győződjön meg a következő konfigurációról:

  1. Engedélyek megadása a CSI-illesztőprogram vezérlősíkjának identitásához

    • Rendelje hozzá a Storage Account Contributor szerepkört a céltárfiók CSI-illesztőprogram-vezérlősíkja által használt identitáshoz.
    • Ha a tárfiókot a CSI-illesztőprogram dinamikusan hozza létre, adjon Storage Account Contributor szerepkört a csomópont erőforráscsoportjának.
    • Alapértelmezés szerint az AKS-fürt vezérlősík-identitása már hozzá van rendelve a Storage Account Contributor szerepkörhöz a csomópont erőforráscsoportjában, amely a tárfiók létrehozására szolgál.
  2. Hozzon létre egy új tárolási osztályt a következővel mountWithWorkloadIdentityToken: "true" és helyezze üzembe az állapotalapú készletet ezzel a tárolási osztálysal.

Az alábbi példajegyzék egy tárolási osztályt konfigurál a számítási feladatok identitásának használatára a Azure Files eléréséhez:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-wi
provisioner: file.csi.azure.com
parameters:
  resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
  storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
  mountWithWorkloadIdentityToken: "true"
    # optional, clientID of the managed identity, kubelet identity would be used by default if it's not provided
  clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload
  - nobrl  # disable sending byte range lock requests to the server

Statikus perzisztens kötetekhez tartozó munkaterhelés-identitás engedélyezése az Azure Files használatával

Ha statikusan kiosztott Azure Files állandó kötetekkel szeretné használni a munkaterhelési identitást, győződjön meg arról, hogy a következő konfiguráció be van állítva:

  1. Engedélyezze az SMBOauthot a tárfiókon a következő futtatásával:
    az storage account update --name <account-name> --resource-group <resource-group-name> --enable-smb-oauth true
    
  2. Hozzon létre egy PV-t a következővel mountWithWorkloadIdentityToken: "true" megadva, és csatlakoztassa a PV-t az alkalmazás podjához.

Az alábbi példajegyzék egy PV-t konfigurál a számítási feladatok identitásának használatára a Azure Files eléréséhez:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-azurefile
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: azurefile-csi
  mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload
  - nobrl  # disable sending byte range lock requests to the server
  csi:
    driver: file.csi.azure.com
    # make sure volumeHandle is unique for every identical share in the cluster
    volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"
    volumeAttributes:
      resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
      storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
      shareName: EXISTING_FILE_SHARE_NAME
      mountWithWorkloadIdentityToken: "true"
      # optional, clientID of the managed identity, kubelet identity would be used by default if it's empty
      clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"

Statikus PV létrehozása Azure Files

Az alábbi szakaszok útmutatást nyújtanak a statikus PV (Persistent Volume) létrehozásához Azure Files használatával. A statikus PV egy állandó kötet, amelyet a rendszergazda manuálisan hoz létre. Ez a PV a fürt podjai számára érhető el. Statikus PV használatához hozzon létre egy PVC-t, amely a PV-re hivatkozik, majd hozzon létre egy podot, amely a PVC-re hivatkozik.

Statikus tartós kötetek tárolási osztályparaméterei az Azure Files-hoz

Az alábbi táblázat olyan paramétereket tartalmaz, amelyekkel egyéni tárolási osztályt határozhat meg a statikus PVC-k számára Azure Files:

Név Meaning Elérhető értékek Kötelező Alapértelmezett érték
volumeAttributes.resourceGroup Adjon meg egy Azure erőforráscsoport nevét. myResourceGroup Nem Ha üres, az illesztőprogram ugyanazt az erőforráscsoportnevet használja, mint az aktuális fürt esetében.
volumeAttributes.storageAccount Adjon meg egy meglévő Azure tárfióknevet. tárolófiókneve Igen
volumeAttributes.shareName Adjon meg egy Azure fájlmegosztásnevet. fileShareName Igen
volumeAttributes.folderName Adjon meg egy mappanevet Azure fájlmegosztásban. folderName Nem Ha a mappanév nem létezik a fájlmegosztásban, a csatlakoztatás sikertelen lesz.
volumeAttributes.protocol Adja meg a fájlmegosztási protokollt. smb, nfs Nem smb
volumeAttributes.server Azure tárfiók kiszolgálói címének megadása Meglévő kiszolgáló címe, például accountname.privatelink.file.core.windows.net. Nem Ha üres, az illesztőprogram alapértelmezett accountname.file.core.windows.net vagy más szuverén felhőfiók-címet használ.
--- Az alábbi paraméterek csak az SMB protokollhoz tartoznak --- --- ---
volumeAttributes.secretName Adjon meg egy titkos nevet, amely tárolja a tárfiók nevét és kulcsát. Nem
volumeAttributes.secretNamespace Adjon meg egy titkos névteret. defaultstbkube-system. Nem PVC-névtér (csi.storage.k8s.io/pvc/namespace)
nodeStageSecretRef.name Adjon meg egy titkos nevet, amely tárolja a tárfiók nevét és kulcsát. Meglévő titkos név. Nem Ha üres, a meghajtó a kubelet identitását használva szerzi meg a fiókkulcsot.
nodeStageSecretRef.namespace Adjon meg egy titkos névteret. Kubernetes-névtér Nem
--- Az alábbi paraméterek csak az NFS protokollhoz tartoznak --- --- ---
volumeAttributes.fsGroupChangePolicy Azt jelzi, hogy az illesztőprogram hogyan módosítja a kötet tulajdonjogát. A pod securityContext.fsGroupChangePolicy figyelmen kívül lesz hagyva. OnRootMismatch (alapértelmezett), Always, None Nem OnRootMismatch
volumeAttributes.mountPermissions A csatlakoztatott mappák engedélyeinek megadása. Az alapértelmezett érték: 0777 Nem

Azure fájlmegosztás létrehozása

Ahhoz, hogy kubernetes-kötetként Azure Files fájlmegosztást használhasson, létre kell hoznia egy Azure Storage fiókot és a fájlmegosztást.

  1. Az AKS-fürt csomópont-erőforráscsoportjának nevét a az aks show paranccsal és a --query nodeResourceGroup paraméterrel kérheti le.

    az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
    

    A parancs kimenete a következő példához hasonlít:

    MC_myResourceGroup_myAKSCluster_eastus
    
  2. Hozzon létre egy tárfiókot a az storage account create paraméterrel rendelkező --sku paranccsal. Az alábbi parancs létrehoz egy tárfiókot az Standard_LRS SKU használatával. Mindenképpen cserélje le a következő helyőrzőket:

    • myAKSStorageAccount a tárfiók nevével
    • nodeResourceGroupName az AKS-fürtcsomópontok által üzemeltetett erőforráscsoport nevével
    • location a régió nevével, amelyben létre kívánja hozni az erőforrást. Ennek az AKS-fürtcsomópontokkal megegyező régiónak kell lennie.
    az storage account create --name myAKSStorageAccount --resource-group nodeResourceGroupName --location location --sku Standard_LRS
    
  3. Exportálja a kapcsolati karakterláncot környezeti változóként, amelyet a fájlmegosztás létrehozásához az [az storage account show-connection-string][az-storage-account-show-connection-string] paranccsal használ. Ügyeljen arra, hogy a storageAccountName helyett a tárfiók nevét, és a resourceGroupName helyett az erőforráscsoport nevét írja.

    export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string --name storageAccountName --resource-group resourceGroupName -o tsv)
    

    Megjegyzés:

    A kapcsolati sztringeket kulcsforgatással vagy tárolással kell védeni az Azure Key Vaultban. További információ a kapcsolati sztringekről: Konfigurálás Azure Storage kapcsolati sztringek és A tárfiók hozzáférési kulcsainak kezelése. Éles környezetekben Microsoft Microsoft Entra ID hitelesítés használatát javasolja. További információ: A Azure Storage adatokhoz való hozzáférésének engedélyezése.

  4. Hozza létre a fájlmegosztást a az storage share create paranccsal. Ügyeljen arra, hogy lecserélje shareName a megosztás nevére.

    az storage share create --name shareName --connection-string $AZURE_STORAGE_CONNECTION_STRING
    
  5. Exportálja a tárfiókkulcsot környezeti változóként a [az storage account keys list][az-storage-account-keys-list] paranccsal. Ügyeljen arra, hogy a storageAccountName helyett a tárfiók nevét, és a resourceGroupName helyett az erőforráscsoport nevét írja.

    STORAGE_KEY=$(az storage account keys list --resource-group nodeResourceGroupName --account-name myAKSStorageAccount --query "[0].value" -o tsv)
    
  6. Az alábbi paranccsal adja vissza a tárfiók nevét és kulcsát. Jegyezze fel a tárfiókkulcsot, amellyel a következő lépésben kubernetes-titkos kulcsot hoz létre.

    echo Storage account key: $STORAGE_KEY
    

Kubernetes-titkos kód létrehozása

A Kubernetesnek hitelesítő adatokra van szüksége az előző lépésben létrehozott fájlmegosztás eléréséhez. Ezek a hitelesítő adatok egy Kubernetes-titkos kódban vannak tárolva, amelyre egy Kubernetes-pod létrehozásakor hivatkozunk.

  • Hozza létre a titkos kulcsot a kubectl create secret paranccsal. Az alábbi példa létrehoz egy azure-secret nevű titkos kulcsot, és feltölti az azurestorageaccountname és az azurestorageaccountkey nevet az előző lépésből. Meglévő Azure tárfiók használatához adja meg a fiók nevét és kulcsát.

    kubectl create secret generic azure-secret --from-literal=azurestorageaccountname=myAKSStorageAccount --from-literal=azurestorageaccountkey=$STORAGE_KEY
    

Fájlmegosztás csatlakoztatása állandó kötetként

  1. Hozzon létre egy új, elnevezett azurefiles-pv.yaml fájlt, és másolja a következő tartalomba. Alatt csi, frissítés resourceGroup, volumeHandleés shareName. Csatlakoztatási beállítások esetén az alapértelmezett érték fileMode és dirMode esetén 0777.

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      annotations:
        pv.kubernetes.io/provisioned-by: file.csi.azure.com
      name: azurefile
    spec:
      capacity:
        storage: 5Gi
      accessModes:
        - ReadWriteMany
      persistentVolumeReclaimPolicy: Retain
      storageClassName: azurefile-csi
      csi:
        driver: file.csi.azure.com
        volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"  # make sure this volumeid is unique for every identical share in the cluster
        volumeAttributes:
          shareName: aksshare
        nodeStageSecretRef:
          name: azure-secret
          namespace: default
      mountOptions:
        # Canonical permissions: 0755/uid=1000/gid=1000 for least privilege.
        # Use 0777/uid=0/gid=0 only if app requires root or broad write access.
        - dir_mode=0755
        - file_mode=0755
        - uid=1000
        - gid=1000
        - mfsymlinks
        - cache=strict
        - nosharesock
        - actimeo=30
        - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
    
  2. Hozza létre a PV-t a kubectl create paranccsal.

    kubectl create -f azurefiles-pv.yaml
    
  3. Hozzon létre egy azurefiles-mount-options-pvc.yaml nevű új fájlt, és illessze be a következő tartalmat. Győződjön meg arról, hogy az storageClassName egyezik a meglévő tárosztály nevével, és az volumeName előző lépésben létrehozott PV nevével.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: azurefile
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: azurefile-csi
      volumeName: azurefile
      resources:
        requests:
          storage: 5Gi
    
  4. Hozza létre a PVC-t a kubectl apply paranccsal.

    kubectl apply -f azurefiles-mount-options-pvc.yaml
    
  5. Használja a kubectl get parancsot annak ellenőrzésére, hogy a PVC létrejött-e, és hozzá van-e kötve a PV-hez.

    kubectl get pvc azurefile
    

    A kimenetnek a következő példakimenethez kell hasonlítania, amely azt mutatja, hogy a PVC állapotban Bound van, és az azurefile nevű PV-hez van kötve:

    NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
    
  6. Frissítse a tároló specifikációját, hogy hivatkozzon a PVC-re és a podra a YAML-fájlban. Például:

    ...
      volumes:
      - name: azure
        persistentVolumeClaim:
          claimName: azurefile
    
  7. A pod specifikációja nem frissíthető a helyén, ezért törölje a podot a kubectl delete paranccsal, és hozza létre újra a kubectl apply parancs használatával.

    kubectl delete pod mypod
    kubectl apply -f azure-files-pod.yaml
    

Fájlmegosztás csatolása beágyazott kötetként

Megjegyzés:

A teljesítményproblémák elkerülése érdekében javasoljuk, hogy használjon állandó kötetet beágyazott kötet helyett, ha több pod is hozzáfér ugyanahhoz a fájlmegosztáshoz. A beágyazott kötet csak a pod névterében fér hozzá a titkos kulcsokhoz. Egy másik titkos névtér megadásához használjon perzisztens kötetet.

Ha az Azure Files fájlmegosztást csatlakoztatni szeretné a podhoz, konfigurálja a kötetet a tároló specifikációjában.

  1. Hozzon létre egy új, elnevezett azure-files-pod.yaml fájlt, és másolja a következő tartalomba. Ha módosította a fájlmegosztás vagy titkos név nevét, frissítse a shareName és secretName. A mountPath értékét is módosíthatja, amely az elérési útvonal, ahol a fájlmegosztás csatlakozik a podhoz. Windows Server tárolók esetében adjon meg egy mountPath a Windows elérésiút-konvencióval, például 'D:'.

    apiVersion: v1
    kind: Pod
    metadata:
      name: mypod
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - image: 'mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine'
          name: mypod
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi
          volumeMounts:
            - name: azure
              mountPath: /mnt/azure
              readOnly: false
      volumes:
        - name: azure
          csi:
            driver: file.csi.azure.com
            volumeAttributes:
              secretName: azure-secret  # required
              shareName: aksshare  # required
              mountOptions: 'dir_mode=0755,file_mode=0755,uid=1000,gid=1000,cache=strict,actimeo=30,nosharesock,nobrl'  # optional
    
  2. Hozza létre a podot a kubectl apply paranccsal.

    kubectl apply -f azure-files-pod.yaml
    
  3. Tekintse meg a pod állapotát a kubectl describe következő paranccsal:

    kubectl describe pod mypod