Vytváření a správa trvalých svazků pomocí Azure Files v Azure Kubernetes Service (AKS)

Pokud více podů potřebuje souběžný přístup ke stejnému svazku úložiště, můžete se pomocí Azure Files připojit pomocí protokolu Server Message Block (SMB) nebo NFS. V tomto článku se dozvíte, jak dynamicky a staticky vytvořit sdílenou složku Azure pro použití více podů v clusteru Azure Kubernetes Service (AKS).

Poznámka:

Ovladač Azure File CSI umožňuje připojení sdílených složek SMB pouze pomocí ověřování na bázi klíče (NTLM v2), a proto nepodporuje maximální profil zabezpečení nastavení sdílení souborů Azure. Připojení sdílených složek NFS nevyžaduje ověřování založené na klíčích.

Poznámka:

Při spouštění srovnávacích testů doporučujeme FIO. Další informace najdete v tématu Srovnávací nástroje a testy.

Předpoklady

• Azure CLI nainstalovaná a nakonfigurovaná verze 2.0.59 nebo novější. Najděte verzi pomocí az --version příkazu. Pokud chcete nainstalovat nebo upgradovat, přečtěte si téma Instalace Azure CLI.
• Ovladač Azure Files CSI povolený v clusteru AKS.
• Účet Azure storage.
• Při výběru mezi sdílenými složkami SSD (Premium) a HDD (Standard) je důležité porozumět modelu zřizování a požadavkům očekávaného způsobu použití, který plánujete spustit na Azure Files. Azure Files má tři fakturační modely: provisioned v2 (doporučeno), pay-as-you-go a starší verze provisioned v1. Další informace najdete v tématu Volba úrovně výkonu Azure Files na základě vzorů využití.

Použití integrovaných tříd úložiště k vytváření dynamických virtuálních počítačů s Azure Files

Třídy úložiště definují, jak se dynamicky vytváří jednotka úložiště s trvalým svazkem. Účet úložiště se automaticky vytvoří ve skupině prostředků node pro použití s třídou úložiště k uložení sdílené složky Azure Files. Pokud používáte ovladače CSI v AKS, existují dvě další předdefinované StorageClasses, které používají ovladače úložiště Azure Files CSI (ostatní třídy úložiště CSI se vytvářejí s clusterem spolu s výchozími třídami úložiště ve stromu):

• azurefile-csi: Vytvoří sdílenou složku Azure v úložišti HDD.
• azurefile-csi-premium: Vytvoří sdílenou složku Azure v úložišti SSD.

Zásady uvolnění prostředků v obou třídách úložiště zajišťují, že příslušné Azure sdílení souborů je odstraněno, když je odstraněn příslušný PV. Třídy úložiště také nakonfigurují sdílené složky tak, aby byly rozšiřitelné, stačí upravit trvalou deklaraci identity svazku (PVC) s novou velikostí.

Jako parametr v definici třídy úložiště můžete vybrat jednu z následujících úrovní skuname:

• PremiumV2_LRS (doporučeno): Zřízeno SSD v2, místně redundantní úložiště
• PremiumV2_ZRS (doporučeno): Zřízeno SSD v2, zónově redundantní úložiště
• Premium_LRS: Ssd zřízená verze 1 (starší verze), místně redundantní úložiště
• Premium_ZRS: Zřízení SSD v1 (starší verze), zónově redundantní úložiště
• StandardV2_LRS: HDD předem nakonfigurované verze 2, místně redundantní úložiště
• StandardV2_ZRS: Zřízené pevné disky v2, zónově redundantní úložiště
• StandardV2_GRS: Předem přidělené HDD v2, geograficky redundantní úložiště
• StandardV2_GZRS: Disky HDD v2 s geograficky zónově redundantním úložištěm
• Standard_LRS: HDD platba podle využití, místně redundantní úložiště
• Standard_GRS: HDD platba dle spotřeby, geograficky redundantní úložiště
• Standard_ZRS: HDD platba za použití, úložiště se zónovou redundancí

Důležité

Pokud chcete pro Azure Files použít model fakturace zřízené verze 2, musíte použít ovladač Azure Files CSI version 1.35.0 nebo novější.

Poznámka:

Pro nová nasazení doporučujeme pro většinu úloh zřídit SSD v2 (PremiumV2_LRS nebo PremiumV2_ZRS). Sdílené složky SSD nabízejí vyšší výkon a podporu disků s nízkou latencí pro úlohy náročné na vstupně-výstupní operace. Minimální kapacita sdílené složky pro účty Premium je 100 GiB.

Vytváření vlastních tříd úložiště pro dynamické virtuální počítače s využitím Azure Files

Výchozí třídy úložiště jsou vhodné pro většinu scénářů. V některých případech můžete chtít mít vlastní třídu úložiště přizpůsobenou vlastními parametry. Můžete například chtít nakonfigurovat mountOptions sdílení souborů.

1. Vytvořte soubor s názvem azure-file-sc.yaml a vložte ho do následujícího ukázkového manifestu:

   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. Pomocí příkazu vytvořte třídu kubectl apply úložiště:

   kubectl apply -f azure-file-sc.yaml
   

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu:

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

Parametry třídy úložiště pro dynamické PV s Azure Files

Následující tabulka obsahuje parametry, které můžete použít k definování vlastní třídy úložiště pro nároky na trvalý svazek (PVCs) s Azure Files:

Název	Význam	Dostupné hodnoty	Povinné	Výchozí hodnota
accountAccessTier	Úroveň přístupu pro účet úložiště	Účet úrovně Standard může zvolit Hot nebo Cool, a účet Premium může zvolit pouze Premium.	Ne	Empty. Pro různé typy účtů úložiště použijte výchozí nastavení.
accountQuota	Omezuje kvótu pro účet. Maximální kvótu můžete zadat v GB (ve výchozím nastavení 102400 GB). Pokud účet překročí zadanou kvótu, ovladač přeskočí výběr účtu.		Ne	102400
allowBlobPublicAccess	Povolí nebo zakáže veřejný přístup ke všem objektům blob nebo kontejnerům pro účet úložiště vytvořený ovladačem.	true nebo false	Ne	false
disableDeleteRetentionPolicy	Zadejte, zda chcete zakázat politiku uchovávání odstraněných dat pro účet úložiště, který byl vytvořen ovladačem.	true nebo false	Ne	false
folderName	Zadejte název složky ve sdílené složce Azure.	Název existující složky v úložišti souborů Azure.	Ne	Pokud název složky ve sdílené složce neexistuje, připojení selže.
getLatestAccount	Určuje, jestli se má na základě času vytvoření získat nejnovější klíč účtu. Tento ovladač ve výchozím nastavení získá první klíč.	true nebo false	Ne	false
location	Zadejte oblast Azure pro Azure úložného účtu.	Například: eastus.	Ne	Pokud je prázdný, ovladač používá stejný název umístění jako aktuální cluster AKS.
matchTags	Sladí značky, když se ovladač pokusí najít vhodný účet úložiště.	true nebo false	Ne	false
networkEndpointType	Zadejte typ koncového bodu sítě pro účet úložiště vytvořený ovladačem. Pokud privateEndpoint je zadaný, vytvoří se pro účet úložiště privátní koncový bod. V jiných případech se ve výchozím nastavení vytvoří koncový bod služby.	"",privateEndpoint	Ne	""
protocol	Zadejte protokol sdílené složky.	smb, nfs	Ne	smb
requireInfraEncryption	Určete, jestli služba použije sekundární vrstvu šifrování s klíči spravovanými platformou pro neaktivní uložená data pro účet úložiště vytvořený ovladačem.	true nebo false	Ne	false
resourceGroup	Zadejte skupinu prostředků pro disky Azure.	Název existující skupiny prostředků	Ne	Pokud je prázdný, ovladač použije název skupiny prostředků, který je stejný jako u aktuálního clusteru AKS.
selectRandomMatchingAccount	Určuje, zda se má náhodně vybrat odpovídající účet. Ve výchozím nastavení ovladač vždy vybere první odpovídající účet v abecedním pořadí (Poznámka: Tento ovladač používá mezipaměť vyhledávání účtů, což vede k nerovnoměrné distribuci vytváření souborů napříč více účty).	true nebo false	Ne	false
server	Zadejte Azure adresu serveru účtu úložiště.	Existující adresa serveru, například accountname.privatelink.file.core.windows.net.	Ne	Pokud je prázdný, ovladač používá výchozí accountname.file.core.windows.net nebo jinou adresu účtu suverénního cloudu.
shareAccessTier	Úroveň přístupu pro sdílenou složku	Účet pro obecné účely verze 2 si může vybrat mezi TransactionOptimized (výchozí) Hota Cool. Typ účtu služby Premium Storage pouze pro sdílené složky.	Ne	Empty. Pro různé typy účtů úložiště použijte výchozí nastavení.
shareName	Zadejte název sdílené složky Azure.	Název existující nebo nové sdílené složky Azure.	Ne	Pokud je prázdný, ovladač vygeneruje název sdílené složky Azure.
shareNamePrefix	Zadejte předponu názvu sdílené složky Azure vytvořenou ovladačem.	Název sdílené složky může obsahovat jenom malá písmena, číslice, pomlčky a délku kratší než 21 znaků.	Ne
skuName	typ účtu úložiště Azure Files (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	Ne	Standard_LRS Minimální velikost sdílené složky pro typ účtu Premium je 100 GB. Typ účtu ZRS se podporuje v omezených oblastech. Sdílená složka NFS podporuje pouze typ účtu Premium. Názvy skladových položek Standard V2 jsou určené pro Azure Files zřízený model v2.
storageAccount	Zadejte název účtu úložiště Azure.	názevÚložištěÚčtu	Ne	Pokud není zadaný konkrétní název účtu úložiště, ovladač vyhledá vhodný účet úložiště, který odpovídá nastavení účtu ve stejné skupině prostředků. Pokud se nepodaří najít odpovídající účet úložiště, vytvoří nový účet. Pokud je však zadaný název účtu úložiště, účet úložiště už musí existovat.
storageEndpointSuffix	Zadejte suffix koncového bodu úložiště Azure.	core.windows.net, core.chinacloudapi.cnatd.	Ne	Pokud je prázdný, ovladač použije výchozí příponu koncového bodu úložiště v závislosti na cloudovém prostředí. Například: core.windows.net.
subscriptionID	Zadejte ID předplatného Azure, kde je vytvořen sdílený soubor Azure.	ID předplatného Azure	Ne	Pokud není prázdný, resourceGroup je nutné zadat.
tags	Značky se vytvářejí v novém úložišti.	Formát značky: 'foo=aaa,bar=bbb'	Ne	""
---	Následující parametry jsou určené pouze pro protokol SMB.	---	---	---
storeAccountKey	Určete, jestli se má klíč účtu ukládat do tajného kódu Kubernetes.	true nebo false false znamená, že ovladač používá k získání klíče účtu kubelet identitu.	Ne	true
secretName	Zadejte název tajného kódu pro uložení klíče účtu.		Ne
secretNamespace	Zadejte obor názvů tajného kódu pro uložení klíče účtu. Poznámka: Pokud secretNamespace není zadaný, tajný klíč se vytvoří ve stejném oboru názvů jako pod.	default kube-system, etc.	Ne	Jmenný prostor PVC, například csi.storage.k8s.io/pvc/namespace
useDataPlaneAPI	Určete, jestli se má použít rozhraní API roviny dat pro vytvoření, odstranění nebo změnu velikosti sdílené složky, což by mohlo vyřešit problém s omezováním rozhraní API protokolu SRP, protože rozhraní API roviny dat nemá téměř žádný limit, zatímco při nastavení brány firewall nebo virtuální sítě v účtu úložiště dojde k selhání.	true nebo false	Ne	false
---	Následující parametry jsou určené pouze pro protokol NFS.	---	---	---
mountPermissions	Oprávnění připojené složky. Výchozí hodnota je 0777. Pokud je nastaveno na 0, ovladač neprovádí chmod po připojení.	0777	Ne
rootSquashType	Zadejte chování kořenového squashingu ve sdílené složce. Výchozí hodnota je NoRootSquash.	AllSquash NoRootSquash, RootSquash	Ne
---	Následující parametry jsou určené pouze pro nastavení virtuální sítě (například NFS, privátní koncový bod).	---	---	---
fsGroupChangePolicy	Určuje, jak řadič přebírá vlastnictví svazku. Pod securityContext.fsGroupChangePolicy je ignorován.	OnRootMismatch (výchozí), Always, None	Ne	OnRootMismatch
subnetName	Název podsítě	Název existující podsítě uzlu agenta	Ne	Pokud je prázdný, ovladač použije hodnotu subnetName v konfiguračním souboru Azure cloudu.
vnetName	Název virtuální sítě	Název existující virtuální sítě	Ne	Pokud je prázdný, ovladač aktualizuje všechny podsítě ve virtuální síti clusteru.
vnetResourceGroup	Zadejte skupinu prostředků virtuální sítě, ve které je definována virtuální síť.	Název existující skupiny prostředků	Ne	Pokud je prázdný, ovladač použije hodnotu vnetResourceGroup v konfiguračním souboru Azure cloudu.

Důležité

Parametr třídy úložiště tags se použije na účet úložiště, když Azure Files CSI driver provádí provisioning svazku. Po vytvoření trvalého svazku PersistentVolume je specifikace neměnná, takže úprava nebo oprava PV pro změnu značek nebo jiných atributů svazku selže. Aktualizace třídy úložiště později ovlivní pouze nově zřízené svazky.

Pokud chcete aktualizovat značky na existujícím svazku, změňte je v příslušném účtu úložiště v Azure. Pokud vaše úložná třída používá existující účet úložiště, aktualizujte tagy tohoto účtu. Tato operace nepřeruší stávající připojení, pody ani přístup k datům a aktualizované Azure tagy se nesynchronizují zpět do YAML nebo metadat Kubernetes PV. Například:

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

Poznámka:

Pokud je účet úložiště vytvořen ovladačem, stačí zadat networkEndpointType: privateEndpoint parametr pouze ve třídě úložiště. Ovladač CSI vytvoří privátní koncový bod a privátní zónu DNS (pojmenovanou privatelink.file.core.windows.net) společně s účtem. Pokud používáte vlastní účet úložiště, musíte pro účet úložiště vytvořit privátní koncový bod . Pokud používáte úložiště Azure Files v izolovaném síťovém clusteru, musíte vytvořit vlastní třídu úložiště s typem networkEndpointType: privateEndpoint. Jako odkaz můžete použít následující ukázkový manifest:

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

Vytvořte PVC pomocí Azure Files

PVC používá objekt třídy úložiště k dynamickému zřizování sdílené složky Azure. Pomocí ukázkového manifestu YAML v této části můžete vytvořit PVC, který má velikost 100 GB s přístupem ReadWriteMany . Další informace o režimech přístupu najdete v tématu Kubernetes PV access modes.

1. Vytvořte soubor s názvem azure-file-pvc.yaml a vložte ho do následujícího YAML. Ujistěte se, storageClassName že odpovídá názvu vaší existující třídy úložiště.

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

   Poznámka:

   Pokud pro třídu úložiště používáte SKU Premium_LRS, musí být minimální hodnota pro storage100Gi.

2. Vytvořte PVC pomocí příkazu kubectl apply.

   kubectl apply -f azure-file-pvc.yaml
   

3. Pomocí příkazu zobrazte stav PVC kubectl get :

   kubectl get pvc my-azurefile
   

   Výstup by měl vypadat podobně jako v následujícím příkladu, který ukazuje, že PVC je ve Bound stavu a PV byl dynamicky vytvořen k uspokojení požadavku.

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

Použití PVC s Azure Files ve podu

Ukázkový manifest YAML v této části vytvoří pod, který používá PVC my-azurefile pro připojení sdílené složky Azure Files k cestě /mnt/azure. Pro kontejnery Windows Server zadejte mountPath pomocí konvence cesty Windows, například 'D:'.

1. Vytvořte soubor s názvem azure-pvc-files.yamla vložte následující YAML. Ujistěte se, že claimName odpovídá názvu existujícího PVC.

   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. Vytvořte pod pomocí příkazu kubectl apply.

   kubectl apply -f azure-pvc-files.yaml
   

3. Pomocí příkazu zobrazte stav podu kubectl describe :

   kubectl describe pod mypod
   

   Výstup by měl vypadat podobně jako následující příklad, který ukazuje, že pod běží a svazek je připojen ke správné cestě.

   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
   [...]
   

Možnosti připojení pro Azure Files

Umístění pro konfiguraci možností připojení (mountOptions) závisí na tom, jestli zřizujete dynamické nebo statické trvalé svazky:

• Pokud dynamicky zřizujete svazek s třídou úložiště, zadejte možnosti připojení k objektu třídy úložiště (druh: StorageClass).
• Pokud staticky zřizujete svazek, zadejte možnosti připojení k objektu PV (druh: PersistentVolume).
• Pokud sdílenou složku připojujete jako vložený svazek, zadejte možnosti připojení objektu Pod (druh: Pod).

Další informace najdete v tématu Možnosti připojení.

Výchozí hodnota fileMode pro Kubernetes verze 1.13.0 a dirMode vyšší je 0777 . Následující příklad nastaví 0777:

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)

Doporučené možnosti připojení pro sdílené složky SMB

Doporučené možnosti připojení pro sdílené složky SMB jsou k dispozici v následujícím příkladu třídy úložiště:

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

Pokud používáte sdílené složky SSD (Premium) s protokolem SMB a vaše úlohy jsou náročné na metadata, zaregistrujte se pro využití funkce ukládání metadat do mezipaměti ke zlepšení výkonu.

Další informace najdete v tématu Zlepšení výkonu sdílených složek SMB Azure.

Doporučené možnosti připojení pro sdílené složky NFS

Doporučené možnosti připojení pro sdílené složky NFS jsou k dispozici v následujícím příkladu třídy úložiště:

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

Zvyšte velikost čtení dopředu , aby se zlepšila propustnost čtení.

I když Azure Files podporuje nastavení nconnect až k maximálnímu nastavení 16, doporučujeme nakonfigurovat možnosti připojení s optimálním nastavením nconnect=4. V současné době neexistují žádná vylepšení nad rámec čtyř kanálů pro implementaci Azure Files nconnect.

Vytvořte snímek svazku z PVC pomocí Azure Files

Ovladač CSI Azure Files podporuje vytváření snapshotů trvalých svazků a podkladových sdílených souborů.

1. Vytvořte třídu snímků svazku pomocí příkazu kubectl apply.

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

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu:

   volumesnapshotclass.snapshot.storage.k8s.io/csi-azurefile-vsc created
   

2. Pomocí příkazu vytvořte snímek svazku z dynamického PVC, který jste vytvořili dříve v tomto kurzu kubectl apply :

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

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu:

   volumesnapshot.snapshot.storage.k8s.io/azurefile-volume-snapshot created
   

3. Pomocí příkazu kubectl describe zobrazte stav snímku svazku:

   kubectl describe volumesnapshot azurefile-volume-snapshot
   

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který ukazuje, že snímek svazku není připravený k použití, protože ovladač stále vytváří snímek podkladové sdílené složky Azure:

   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>
   

Změna velikosti trvalého svazku pomocí Azure Files

Poznámka:

Zmenšení dlouhodobých svazků v současnosti není podporováno. Pokus o opravu existujícího PVC s menší velikostí, než je aktuální, vede k následující chybové zprávě:

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

Pro PVC můžete požádat o větší objem úpravou objektu PVC a určit tak větší velikost. Tato změna aktivuje rozšíření podkladového svazku, který zálohuje trvalý svazek. Nový trvalý svazek (PV) se nikdy nevytváří, aby uspokojil požadavek. Místo toho se změní velikost existujícího svazku.

V AKS integrovaná managed-csi třída úložiště již podporuje rozšíření, takže můžete použít dynamické PVC, které jste vytvořili dříve v tomto kurzu. PVC požádal o sdílení souborů 100 GiB.

1. Ověřte aktuální velikost PVC a souborového systému uvnitř podu pomocí příkazu kubectl exec ke spuštění příkazu df -h uvnitř podu:

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

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který ukazuje, že systém souborů má velikost 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. Rozbalte PVC zvětšením pole spec.resources.requests.storage pomocí příkazu kubectl patch. V tomto příkladu zvýšíme sdílenou složku na 200 GiB:

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

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který ukazuje, že PVC byl úspěšně opraven:

   persistentvolumeclaim/pvc-azurefile patched
   

3. Pomocí příkazu kubectl get pvc a příkazu df -h ověřte, že se velikost PVC úspěšně změnila a nová velikost je zobrazena uvnitř podu.

   kubectl get pvc pvc-azurefile
   

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který ukazuje, že PVC je stále ve Bound stavu a kapacita byla aktualizována na 200 GiB:

   NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
   pvc-azurefile   Bound    pvc-00aa00aa-bb11-cc22-dd33-44ee44ee44ee   200Gi      RWX            azurefile-csi   64m
   

4. Ověřte novou velikost souborového systému uvnitř podu pomocí příkazu kubectl exec k provedení df -h příkazu uvnitř podu.

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

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který ukazuje, že systém souborů má teď velikost 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
   

Použití trvalého svazku s privátním úložištěm Azure Files (privátní koncový bod)

Pokud jsou vaše Azure Files prostředky chráněné privátním koncovým bodem, musíte vytvořit vlastní třídu úložiště. Ujistěte se, že vaše nastavení DNS je nakonfigurováno tak, aby překladalo IP adresu privátního koncového bodu na plně kvalifikovaný název domény connection string. Při vytváření třídy úložiště pomocí ovladače Azure Files CSI je nutné zadat parametr networkEndpointType s hodnotou privateEndpoint a zadat následující parametry:

• resourceGroup: Skupina prostředků, ve které je nasazený účet úložiště.
• storageAccount: Název účtu úložiště.
• server: Plně kvalifikovaný název domény privátního koncového bodu účtu úložiště.

1. Vytvořte soubor s názvem private-azure-file-sc.yaml a vložte ho do následujícího manifestu. Nezapomeňte nahradit zástupné symboly pro <resourceGroup> a <storageAccountName>.

   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. Pomocí příkazu vytvořte třídu kubectl apply úložiště:

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

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu:

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

3. Vytvořte soubor s názvem private-pvc.yaml a vložte ho do následujícího manifestu. Ujistěte se, storageClassName že odpovídá názvu vaší existující třídy úložiště.

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

4. Vytvořte PVC pomocí příkazu kubectl apply.

   kubectl apply -f private-pvc.yaml
   

Použití Azure Files s kontejnery Windows

Ovladač csi Azure Files podporuje také uzly a kontejnery Windows. Pokud chcete používat kontejnery Windows, přidejte fond Windows uzlů pomocí rychlého startu Windows kontejnerů. Jakmile máte fond uzlů Windows, můžete použít předdefinované třídy úložiště, jako je azurefile-csi, nebo vytvořit vlastní. Příklad Windows stavové sady v této části ukládá časová razítka každou sekundu do souboru data.txt, který je připojený ke sdílené složce Azure pomocí ovladače Azure Files CSI.

1. Pomocí příkazu vytvořte stavovou sadu kubectl apply :

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

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu:

   statefulset.apps/busybox-azurefile created
   

2. Ověřte, že se časové razítka zapisují do sdílené složky, pomocí následujících kubectl exec příkazů spusťte cat příkaz uvnitř podu:

   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
   

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který ukazuje, že časová razítka se zapisují do sdílené složky každou sekundu:

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

Použití protokolu NFS s Azure Files

Azure Files podporuje protokol NFS verze 4.1. Podpora systému souborů NFS verze 4.1 pro Azure Files poskytuje plně spravovaný systém souborů NFS jako službu postavenou na vysoce dostupné a vysoce odolné platformě distribuovaného úložiště.

Tato možnost je optimalizovaná pro úlohy náhodného přístupu s místní aktualizací dat a poskytuje úplnou podporu systému souborů POSIX. V této části se dozvíte, jak používat sdílené složky NFS s ovladačem csI souboru Azure v clusteru AKS.

Předpoklady pro použití sdílených složek NFS s Azure Files

• Systém souborů NFS vyžaduje sdílené složky SSD (například PremiumV2_LRS, PremiumV2_ZRS, Premium_LRS, nebo Premium_ZRS) a účet úložiště s podporou virtuální sítě.
• Identita řídicí roviny clusteru AKS (tj. název clusteru AKS) se přidá do role Přispěvatel ve virtuální síti a skupině NetworkSecurityGroup.
• Instanční objekt nebo identita spravované služby (MSI) vašeho clusteru AKS musí být přidána do role Přispěvatel do účtu úložiště.

Poznámka:

Místo povolení přístupu k vybrané virtuální síti můžete použít privátní koncový bod.

Optimalizace možností velikosti čtení a zápisu

Tato část obsahuje informace o přístupu k ladění výkonu systému souborů NFS pomocí ovladače csi Azure Files s možnostmi rsize a wsize. Možnosti rsize a wsize nastavení maximální velikosti přenosu operace NFS. Pokud rsize nebo wsize nejsou zadané při připojení, klient a server vyjednávají největší velikost podporovanou dvěma servery. V současné době Azure Files i moderní linuxové distribuce podporují velikosti čtení a zápisu tak velké jako 1 048 576 bajtů (1 MiB).

Optimální výkon je založený na efektivní komunikaci mezi klientem a serverem. Zvýšení nebo snížení hodnot velikosti čtení a zápisu mountu může zlepšit výkon systému souborů NFS. Výchozí velikost paketů pro čtení a zápis přenášených mezi klientem a serverem je 8 kB pro systém souborů NFS verze 2 a 32 kB pro systém souborů NFS verze 3 a 4. Tyto výchozí hodnoty můžou být příliš velké nebo příliš malé. Snížením rsize a wsize by mohlo zlepšit výkon systému souborů NFS v přetížené síti tím, že odesílá menší pakety pro každou odpověď NFS na čtení a požadavek na zápis. To ale může zvýšit počet paketů potřebných k odesílání dat přes síť, což zvyšuje celkový síťový provoz a využití procesoru na klientovi a serveru.

Je důležité provést testování, abyste zjistili rsize a wsize, které umožňují efektivní přenos paketů, nezmenšují propustnost a nezvyšují latenci.

Následující ukázkový manifest nakonfiguruje mountOptions oddíl třídy úložiště na maximum rsize a wsize 256-KiB:

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

Pro seznam podporovaných mountOptions, viz možnosti připojení NFS.

Vytvořte třídu úložiště pro sdílený soubor NFS

Poznámka:

vers, minorversion, sec jsou nakonfigurovány ovladačem Azure File CSI. Zadání hodnoty v manifestu pro tyto vlastnosti se nepodporuje.

1. Vytvořte soubor s názvem nfs-sc.yaml a vložte ho do následujícího manifestu. Nezapomeňte zadat protocol: nfs v sekci parametrů a podle potřeby upravit mountOptions pracovní zátěže.

   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. Po úpravách a uložení souboru vytvořte třídu úložiště pomocí kubectl apply příkazu.

   kubectl apply -f nfs-sc.yaml
   

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu:

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

Vytvoření stavové sady se sdílenou složkou se systémem souborů NFS

1. Vytvořte soubor s názvem nfs-ss.yaml a vložte ho do následujícího manifestu. Tato konfigurace ukládá časová razítka do souboru data.txt.

   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. Pomocí příkazu vytvořte stavovou sadu kubectl apply .

   kubectl apply -f nfs-ss.yaml
   

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu:

   statefulset.apps/statefulset-azurefile created
   

3. Pomocí následujícího příkazu kubectl exec ověřte obsah svazku spuštěním příkazu df -h uvnitř podu:

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

   Výstup by měl vypadat podobně jako v následujícím příkladu výstupu, který ukazuje, že sdílená složka NFS je připojená ke správné cestě se správnou velikostí:

   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
   ...
   

   Protože sdílená složka NFS je v účtu služby Premium Storage, minimální velikost sdílené složky je 100 GiB. Pokud vytvoříte PVC s malým úložným prostorem, může dojít k chybě podobné následující: nepodařilo se vytvořit sdílení souborů ... velikost (5)....

Šifrování při přenosu (EiT) pro sdílené složky NFS (preview)

Poznámka:

Funkce EiT je nyní dostupná ve verzi Preview od AKS verze 1.33. Uzly Ubuntu 20.04, Azure Linux, arm64 a Windows se v současné době nepodporují.

Tato funkce se podporuje ve všech oblastech Azure, které podporují sdílené složky SSD Azure.

Šifrování při přenosu (EiT) zajišťuje, že všechny sdílené složky NFS a zápisy do sdílených složek NFS v rámci virtuální sítě jsou šifrované a poskytují další vrstvu zabezpečení.

encryptInTransit: "true" Nastavením parametrů StorageClass nebo PersistentVolume volumeAttributesmůžete povolit šifrování dat při přenosu pro sdílené složky Azure NFS.

Dynamické zřizování (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

Existující trvalé svazky

U persistentních svazků, které byly vytvořeny bez šifrování během přenosu, nastavte encryptInTransit: "true" v volumeAttributes:

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}"

Použití spravované identity pro přístup k úložišti Azure Files (Preview)

Azure Files teď podporuje ověřování na základě spravované identity pro přístup k protokolu SMB. To umožňuje aplikacím bezpečně přistupovat k Azure Files bez ukládání nebo správy přihlašovacích údajů.

Poznámka:

Podpora spravované identity pro Azure Files v AKS je dostupná ve verzi Preview počínaje AKS verze 1.34 na linuxových uzlech.

Předpoklady pro použití spravované identity pro přístup k úložišti Azure Files

• Ujistěte se, že identita Kubelet přiřazená uživatelem má Storage File Data SMB MI Admin roli v účtu úložiště.
  • Pokud používáte vlastní účet úložiště, musíte pro identitu Kubelet, která je uživatelsky přiřazená, na tomto účtu úložiště přiřadit roli Storage File Data SMB MI Admin.
  • Pokud je účet úložiště vytvořený ovladačem CSI, udělte Storage File Data SMB MI Admin roli skupině prostředků, ve které se nachází účet úložiště.

Povolení spravované identity pro dynamické virtuální počítače s Azure Files

Pokud chcete povolit spravovanou identitu pro dynamicky zřízené svazky, musíte vytvořit novou třídu úložiště s mountWithManagedIdentity: "true" a nasadit stavovou sadu pomocí této třídy úložiště.

Následující ukázkový manifest konfiguruje třídu úložiště tak, aby používala spravovanou identitu pro přístup k Azure Files:

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

Povolení spravované identity pro statické virtuální počítače s Azure Files

Pokud chcete používat spravovanou identitu se staticky zřízenými Azure Files trvalými svazky, ujistěte se, že máte následující konfiguraci:

1. Spuštěním následujícího příkazu povolte SMBOauth v účtu úložiště:

   az storage account update --name <account-name> --resource-group <resource-group-name> --enable-smb-oauth true
   

2. Vytvořte PV s mountWithManagedIdentity: "true" a připojte PV k podu vaší aplikace.

Následující ukázkový manifest konfiguruje pv pro použití spravované identity pro přístup k Azure Files:

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"

Použití identity úloh pro přístup k úložišti Azure Files (Preview)

Azure Files teď podporuje ověřování založené na identitách úloh pro přístup k protokolu SMB. Identita úloh umožňuje přístup k Azure Files s nejnižšími oprávněními na úrovni podů bez přivazování identity aplikace k životnímu cyklu uzlu.

Poznámka:

Podpora identit úloh pro Azure Files v AKS je dostupná ve verzi preview počínaje verzí AKS 1.35.0 na Linuxových uzlech.

Předpoklady pro použití identity úloh pro přístup k Azure Files úložišti

Před použitím identity pracovní zátěže pro přístup k souborům Azure z AKS splňte následující předpoklady.

1. Vytvořte cluster s povoleným oidc-issuer a získejte přihlašovací údaje pro cluster AKS

Vytvořte nový cluster AKS s povoleným vystavitelem OIDC nebo ověřte, že už je povolený. Postupujte podle oficiální dokumentace k vytvoření nového clusteru AKS s parametrem --enable-oidc-issuer a načtěte přihlašovací údaje clusteru. A nastavte následující proměnné prostředí:

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

2. Příprava účtu úložiště

Vytvořte nový účet úložiště a sdílenou složku nebo použijte existující. Podrobné pokyny najdete v Azure Files dokumentaci. Nastavte následující proměnné prostředí:

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

3. Vytvoření nebo opětovné použití spravované identity a udělení požadovaných oprávnění

Vytvořte spravovanou identitu přiřazenou uživatelem nebo znovu použijte existující identitu (například spravovanou identitu přidruženou ke skupině prostředků uzlu AKS). A získejte požadované podrobnosti o identitě a prostředcích:

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)

Udělte roli Storage File Data SMB MI Admin spravované identitě. Tato role umožňuje připojování Azure Files pouze pomocí tokenů identity úloh, bez spoléhání se na klíče účtu úložiště.

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

4. Vytvoření účtu služby Kubernetes ServiceAccount

Vytvořte účet Služby Kubernetes, který bude vaše úloha používat.

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. Vytvoření přihlašovacích údajů federované identity

Pomocí příkazu az identity federated-credential create vytvořte přihlašovací údaje federované identity mezi spravovanou identitou, vystavitelem účtu služby a předmětem.

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}

Po dokončení těchto kroků se úlohy spuštěné se zadaným služebním účtem mohou autentizovat v Azure Files pomocí Microsoft Entra identita zátěže, a to bez použití klíčů účtu úložiště nebo spravovaných identit na úrovni uzlu.

Povolit identitu úloh pro dynamické PV s Azure Files

Pokud chcete používat identitu úloh s dynamicky zřízenými Azure Files trvalými svazky, ujistěte se, že máte následující konfiguraci:

1. Udělit oprávnění identitě řídicí roviny ovladače CSI

   • Storage Account Contributor Přiřaďte roli identitě používané řídicí rovinou ovladače CSI pro cílový účet úložiště.
   • Pokud se účet úložiště vytváří dynamicky ovladačem CSI, udělte roli Storage Account Contributor skupině prostředků uzlu.
   • Ve výchozím nastavení je identita řídicí roviny clusteru AKS již přiřazena do role Storage Account Contributor ve skupině prostředků uzlu pro vytvoření účtu úložiště.

2. Vytvořte novou třídu úložiště s mountWithWorkloadIdentityToken: "true" a nasaďte stavovou sadu pomocí této třídy úložiště.

Následující ukázkový manifest konfiguruje třídu úložiště tak, aby používala identitu úlohy pro přístup k Azure Files:

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

Povolení identity úloh pro statické virtuální počítače s Azure Files

Pokud chcete používat identitu úloh se staticky zřízenými Azure Files trvalými svazky, ujistěte se, že máte následující konfiguraci:

1. Spuštěním následujícího příkazu povolte SMBOauth v účtu úložiště:

   az storage account update --name <account-name> --resource-group <resource-group-name> --enable-smb-oauth true
   

2. Vytvořte PV se zadanými parametry mountWithWorkloadIdentityToken: "true" a připojte ho k podu aplikace.

Následující ukázkový manifest konfiguruje PV tak, aby pro přístup k Azure Files používal identitu úlohy:

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"

Vytvořte statické PV pomocí Azure Files

Následující části obsahují pokyny k vytvoření statické pv s Azure Files. Statický svazek PV je trvalý svazek, který správce vytvoří ručně. Tento PV je k dispozici pro použití pody v clusteru. Chcete-li použít statickou PV, vytvořte PVC, které odkazuje na PV, a poté vytvořte pod, který odkazuje na PVC.

Parametry třídy úložiště pro statické virtuální počítače s Azure Files

Následující tabulka obsahuje parametry, které můžete použít k definování vlastní třídy úložiště pro statické pvcs pomocí Azure Files:

Název	Význam	Dostupné hodnoty	Povinné	Výchozí hodnota
volumeAttributes.resourceGroup	Zadejte název skupiny prostředků Azure.	myResourceGroup	Ne	Pokud je prázdný, ovladač použije stejný název skupiny prostředků jako aktuální klastr.
volumeAttributes.storageAccount	Zadejte název existujícího účtu úložiště Azure.	názevÚložištěÚčtu	Ano
volumeAttributes.shareName	Zadejte název sdílené složky Azure.	fileShareName	Ano
volumeAttributes.folderName	Zadejte název složky ve sdílené složce Azure.	folderName	Ne	Pokud název složky ve sdílené složce neexistuje, připojení selže.
volumeAttributes.protocol	Zadejte protokol sdílené složky.	smb, nfs	Ne	smb
volumeAttributes.server	Zadání adresy serveru účtu úložiště Azure	Existující adresa serveru, například accountname.privatelink.file.core.windows.net.	Ne	Pokud je prázdný, ovladač používá výchozí accountname.file.core.windows.net nebo jinou adresu účtu suverénního cloudu.
---	Následující parametry jsou určené pouze pro protokol SMB.	---	---	---
volumeAttributes.secretName	Zadejte tajný název, který ukládá název a klíč účtu úložiště.		Ne
volumeAttributes.secretNamespace	Zadejte obor názvů tajných kódů.	default kube-system, etc.	Ne	Obor názvů PVC (csi.storage.k8s.io/pvc/namespace)
nodeStageSecretRef.name	Zadejte tajný název, který ukládá název a klíč účtu úložiště.	Existující tajný název.	Ne	Pokud je prázdný, ovladač k získání klíče účtu používá identitu kubeletu.
nodeStageSecretRef.namespace	Zadejte obor názvů tajných kódů.	Namespace Kubernetes	Ne
---	Následující parametry jsou určené pouze pro protokol NFS.	---	---	---
volumeAttributes.fsGroupChangePolicy	Určuje, jak ovladač změní vlastnictví svazku. Pod securityContext.fsGroupChangePolicy je ignorován.	OnRootMismatch (výchozí), Always, None	Ne	OnRootMismatch
volumeAttributes.mountPermissions	Zadejte oprávnění připojené složky. Výchozí hodnota je 0777.		Ne

Vytvořit sdílenou složku Azure

Než budete moct použít sdílenou složku Azure Files jako svazek Kubernetes, musíte vytvořit účet Azure Storage a sdílenou složku.

1. Pomocí příkazu az aks show s parametrem --query nodeResourceGroup získejte název skupiny prostředků uzlu pro váš cluster AKS.

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

   Výstup příkazu se podobá následujícímu příkladu:

   MC_myResourceGroup_myAKSCluster_eastus
   

2. Vytvořte účet úložiště pomocí az storage account create příkazu s parametrem --sku . Následující příkaz vytvoří účet úložiště pomocí skladové Standard_LRS položky. Nezapomeňte nahradit následující zástupné symboly:

   • myAKSStorageAccount s názvem účtu úložiště
   • nodeResourceGroupName s názvem skupiny prostředků, ve které jsou uzly clusteru AKS hostované
   • location s názvem oblasti, ve které se má prostředek vytvořit. Měla by to být stejná oblast jako uzly clusteru AKS.

   az storage account create --name myAKSStorageAccount --resource-group nodeResourceGroupName --location location --sku Standard_LRS
   

3. Exportujte connection string jako proměnnou prostředí, kterou použijete k vytvoření sdílené složky, pomocí příkazu [az storage account show-connection-string][az-storage-account-show-connection-string]. Ujistěte se, že zaměníte storageAccountName za název účtu úložiště a resourceGroupName za název skupiny prostředků.

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

   Poznámka:

   Připojovací stringy musí být chráněny pomocí rotace klíčů nebo uložením v Azure Key Vault. Další informace o připojovacích řetězcích najdete v tématu Konfigurování připojovacích řetězců Azure Storage a Vstupní klíče účtu úložiště. V produkčních prostředích Microsoft doporučuje používat ověřování Microsoft Entra ID. Další informace najdete v tématu Authorize přístupu k datům v Azure Storage.

4. Vytvořte sdílený adresář pomocí příkazu az storage share create. Nezapomeňte nahradit shareName názvem sdílené složky.

   az storage share create --name shareName --connection-string $AZURE_STORAGE_CONNECTION_STRING
   

5. Pomocí příkazu [az storage account keys list][az-storage-account-keys-list] exportujte klíč účtu úložiště jako proměnnou prostředí. Ujistěte se, že zaměníte storageAccountName za název účtu úložiště a resourceGroupName za název skupiny prostředků.

   STORAGE_KEY=$(az storage account keys list --resource-group nodeResourceGroupName --account-name myAKSStorageAccount --query "[0].value" -o tsv)
   

6. Pomocí následujícího příkazu zobrazte název a klíč účtu úložiště. Poznamenejte si klíč účtu úložiště, který použijete k vytvoření tajného kódu Kubernetes v dalším kroku.

   echo Storage account key: $STORAGE_KEY
   

Vytvoření tajného kódu Kubernetes

Kubernetes potřebuje přihlašovací údaje pro přístup ke sdílené složce vytvořené v předchozím kroku. Tyto přihlašovací údaje se ukládají do tajného kódu Kubernetes, na který se odkazuje při vytváření podu Kubernetes.

• Vytvořte tajný kód pomocí kubectl create secret příkazu. Následující příklad vytvoří tajemství s názvem azure-secret a naplní hodnoty pro azurestorageaccountname a azurestorageaccountkey pomocí údajů z předchozího kroku. Pokud chcete použít existující účet úložiště Azure, zadejte název a klíč účtu.

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

Připojení sdílené složky jako trvalého svazku

1. Vytvořte nový soubor s názvem azurefiles-pv.yaml a zkopírujte do něj následující obsah. V části csi aktualizujte resourceGroup, volumeHandle, a shareName. Pro mountovací možnosti je výchozí hodnota fileModedirMode0777.

   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. Vytvořte PV pomocí příkazu kubectl create.

   kubectl create -f azurefiles-pv.yaml
   

3. Vytvořte nový soubor s názvem azurefiles-mount-options-pvc.yaml a vložte do něj následující obsah. Ujistěte se, že storageClassName odpovídá názvu vaší existující třídy úložiště a volumeName odpovídá názvu pv, který jste vytvořili v předchozím kroku.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azurefile
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: azurefile-csi
     volumeName: azurefile
     resources:
       requests:
         storage: 5Gi
   

4. Vytvořte PVC pomocí příkazu kubectl apply.

   kubectl apply -f azurefiles-mount-options-pvc.yaml
   

5. Pomocí příkazu kubectl get se přesvědčte, že váš PVC je vytvořen a svázán s PV.

   kubectl get pvc azurefile
   

   Výstup by měl vypadat podobně jako v následujícím příkladu, který ukazuje, že PVC je ve stavu Bound a je přiřazen k PV s názvem azurefile.

   NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
   

6. Aktualizujte specifikaci kontejneru tak, aby odkazoval na váš PVC a pod v souboru YAML. Například:

   ...
     volumes:
     - name: azure
       persistentVolumeClaim:
         claimName: azurefile
   

7. Specifikace podu se nedá aktualizovat na místě, proto pod odstraňte pomocí kubectl delete příkazu a znovu vytvořte pomocí kubectl apply příkazu.

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

Připojení souborového podílu jako integrovaného svazku

Poznámka:

Pokud se chcete vyhnout problémům s výkonem, doporučujeme místo vloženého svazku použít trvalý svazek, když ke stejné sdílené složce přistupuje mnoho podů. Vložený svazek má přístup pouze k tajným kódům ve stejném oboru názvů jako pod. Pokud chcete zadat jiný obor názvů tajných kódů, použijte trvalý svazek.

Pokud chcete připojit sdílenou složku Azure Files k podu, nakonfigurujte svazek v technické specifikaci kontejneru.

1. Vytvořte nový soubor s názvem azure-files-pod.yaml a zkopírujte do něj následující obsah. Pokud jste změnili název sdílené složky nebo názvu tajného kódu, aktualizujte soubor shareName a secretName. Můžete také aktualizovat mountPath, což je cesta, kde je sdílená složka připojena v podu. Pro kontejnery Windows Server zadejte mountPath pomocí konvence cesty Windows, například '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. Vytvořte pod pomocí příkazu kubectl apply.

   kubectl apply -f azure-files-pod.yaml
   

3. Pomocí příkazu zobrazte stav podu kubectl describe :

   kubectl describe pod mypod
   

Související obsah

• Použití značek Azure v Azure Kubernetes Service (AKS)