Använda CSI-drivrutinen (Azure Files Container Storage Interface) i Azure Kubernetes Service (AKS)
Drivrutinen för Azure Files Container Storage Interface (CSI) är en CSI-kompatibel drivrutin som används av Azure Kubernetes Service (AKS) för att hantera livscykeln för Azure-filresurser. CSI är en standard för att exponera godtyckliga block- och fillagringssystem för containerbaserade arbetsbelastningar på Kubernetes.
Genom att implementera och använda CSI kan AKS nu skriva, distribuera och iterera plugin-program för att exponera nya eller förbättra befintliga lagringssystem i Kubernetes. Att använda CSI-drivrutiner i AKS undviker att behöva röra kubernetes-kärnkoden och vänta på dess lanseringscykler.
Information om hur du skapar ett AKS-kluster med stöd för CSI-drivrutiner finns i Aktivera CSI-drivrutiner på AKS.
Anteckning
In-tree-drivrutiner refererar till de aktuella lagringsdrivrutinerna som ingår i kubernetes-kärnkoden jämfört med de nya CSI-drivrutinerna, som är plugin-program.
Förutom de ursprungliga drivrutinsfunktionerna i trädet stöder Azure Files CSI-drivrutinen följande nya funktioner:
- NFS-version 4.1 (Network File System)
- Privat slutpunkt
- Skapar en stor montering av filresurser parallellt.
En beständig volym (PV) representerar en lagringsdel som har etablerats för användning med Kubernetes-poddar. En PV kan användas av en eller flera poddar och kan etableras dynamiskt eller statiskt. Om flera poddar behöver samtidig åtkomst till samma lagringsvolym kan du använda Azure Files för att ansluta med hjälp av SMB(Server Message Block) eller NFS-protokollet. Den här artikeln visar hur du dynamiskt skapar en Azure Files-resurs för användning av flera poddar i ett AKS-kluster. Statisk etablering finns i Skapa och använda en volym manuellt med en Azure Files-resurs.
Anteckning
Tänk på att Azure File CSI-drivrutinen endast tillåter montering av SMB-filresurser med hjälp av nyckelbaserad autentisering (NTLM v2) och därför inte stöder den maximala säkerhetsprofilen för Azure File Share-inställningar. Å andra sidan kräver montering av NFS-filresurser inte nyckelbaserad autentisering.
Med Azure Files-resurser finns det ingen gräns för hur många som kan monteras på en nod.
Mer information om Kubernetes-volymer finns i Lagringsalternativ för program i AKS.
En lagringsklass används för att definiera hur en Azure-filresurs skapas. Ett lagringskonto skapas automatiskt i nodresursgruppen för användning med lagringsklassen för att lagra Azure-filresursen. Välj någon av följande SKU:er för Azure Storage-redundans för skuName:
- Standard_LRS: Lokalt redundant standardlagring
- Standard_GRS: Geo-redundant standardlagring
- Standard_ZRS: Zonredundant standardlagring
- Standard_RAGRS: Geo-redundant standardlagring med läsåtkomst
- Standard_RAGZRS: Standardlagring med läsbehörighet för geo-zonredundant lagring
- Premium_LRS: Lokalt redundant Premium-lagring
- Premium_ZRS: Premium-zonredundant lagring
Anteckning
Azure Files stöder Azure Premium-filresurser. Den minsta filresurskapaciteten är 100 GiB. Vi rekommenderar att du använder Azure Premium-filresurser i stället för Standard-filresurser eftersom Premium-filresurser ger högre prestanda och diskstöd med låg svarstid för I/O-intensiva arbetsbelastningar.
När du använder CSI-drivrutiner för lagring i AKS finns det ytterligare två inbyggda som använder Azure Files CSI-lagringsdrivrutiner StorageClasses
. De andra CSI-lagringsklasserna skapas med klustret tillsammans med standardlagringsklasserna i trädet.
azurefile-csi
: Använder Azure Standard Storage för att skapa en Azure-filresurs.azurefile-csi-premium
: Använder Azure Premium Storage för att skapa en Azure-filresurs.
Återtagandeprincipen för båda lagringsklasserna säkerställer att den underliggande Azure-filresursen tas bort när respektive PV tas bort. Lagringsklasserna konfigurerar också filresurserna så att de kan expanderas. Du behöver bara redigera det beständiga volymanspråket (PVC) med den nya storleken.
Om du vill använda dessa lagringsklasser skapar du en PVC och respektive podd som refererar till och använder dem. En PVC används för att automatiskt etablera lagring baserat på en lagringsklass. En PVC kan använda en av de förskapade lagringsklasserna eller en användardefinierad lagringsklass för att skapa en Azure-filresurs för önskad SKU och storlek. När du skapar en podddefinition anges PVC för att begära önskad lagring.
Skapa ett exempel på PVC och podd som skriver ut det aktuella datumet till ett outfile
genom att köra kubectl apply-kommandona :
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/pvc-azurefile-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/nginx-pod-azurefile.yaml
Kommandots utdata liknar följande exempel:
persistentvolumeclaim/pvc-azurefile created
pod/nginx-azurefile created
När podden är i körningstillståndet kan du kontrollera att filresursen är korrekt monterad genom att köra följande kommando och kontrollera att utdata innehåller outfile
:
kubectl exec nginx-azurefile -- ls -l /mnt/azurefile
Kommandots utdata liknar följande exempel:
total 29
-rwxrwxrwx 1 root root 29348 Aug 31 21:59 outfile
Standardlagringsklasserna passar de vanligaste scenarierna, men inte alla. I vissa fall kanske du vill att din egen lagringsklass ska anpassas med dina egna parametrar. Använd till exempel följande manifest för att konfigurera filresursen mountOptions
.
Standardvärdet för fileMode och dirMode är 0777 för Kubernetes-monterade filresurser. Du kan ange de olika monteringsalternativen för lagringsklassobjektet.
Skapa en fil med namnet azure-file-sc.yaml
och klistra in följande exempelmanifest:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: my-azurefile
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
- dir_mode=0640
- file_mode=0640
- uid=0
- gid=0
- mfsymlinks
- cache=strict # https://linux.die.net/man/8/mount.cifs
- nosharesock
parameters:
skuName: Standard_LRS
Skapa lagringsklassen genom att köra kommandot kubectl apply :
kubectl apply -f azure-file-sc.yaml
Kommandots utdata liknar följande exempel:
storageclass.storage.k8s.io/my-azurefile created
Azure Files CSI-drivrutinen har stöd för att skapa ögonblicksbilder av beständiga volymer och underliggande filresurser.
Skapa en volymögonblicksbildklass med kommandot kubectl apply :
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshotclass-azurefile.yaml
Kommandots utdata liknar följande exempel:
volumesnapshotclass.snapshot.storage.k8s.io/csi-azurefile-vsc created
Skapa en ögonblicksbild av volymen från PVC:en som vi skapade dynamiskt i början av den här självstudien. pvc-azurefile
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshot-azurefile.yaml
Kommandots utdata liknar följande exempel:
volumesnapshot.snapshot.storage.k8s.io/azurefile-volume-snapshot created
Kontrollera att ögonblicksbilden skapades korrekt genom att köra följande kommando:
kubectl describe volumesnapshot azurefile-volume-snapshot
Kommandots utdata liknar följande exempel:
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: c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
Spec:
Source:
Persistent Volume Claim Name: pvc-azurefile
Volume Snapshot Class Name: csi-azurefile-vsc
Status:
Bound Volume Snapshot Content Name: snapcontent-c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
Ready To Use: false
Events: <none>
Du kan begära en större volym för en PVC. Redigera PVC-objektet och ange en större storlek. Den här ändringen utlöser expansionen av den underliggande volymen som stöder PV:en.
Anteckning
En ny PV skapas aldrig för att uppfylla anspråket. I stället ändras storlek på en befintlig volym.
Krympande beständiga volymer stöds inte för närvarande.
I AKS stöder den inbyggda azurefile-csi
lagringsklassen redan expansion, så använd DEN PVC som skapades tidigare med den här lagringsklassen. PVC begärde en 100 GiB-filresurs. Vi kan bekräfta detta genom att köra:
kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
Kommandots utdata liknar följande exempel:
Filesystem Size Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770 100G 128K 100G 1% /mnt/azurefile
Expandera PVC genom att öka fältet spec.resources.requests.storage
:
kubectl patch pvc pvc-azurefile --type merge --patch '{"spec": {"resources": {"requests": {"storage": "200Gi"}}}}'
Kommandots utdata liknar följande exempel:
persistentvolumeclaim/pvc-azurefile patched
Kontrollera att både PVC och filsystemet i podden visar den nya storleken:
kubectl get pvc pvc-azurefile
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-azurefile Bound pvc-5e5d9980-da38-492b-8581-17e3cad01770 200Gi RWX azurefile-csi 64m
kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
Filesystem Size Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770 200G 128K 200G 1% /mnt/azurefile
Om dina Azure Files-resurser skyddas med en privat slutpunkt måste du skapa en egen lagringsklass. Kontrollera att du har konfigurerat DNS-inställningarna för att matcha ip-adressen för den privata slutpunkten till det fullständiga domännamnet för anslutningssträng. Anpassa följande parametrar:
resourceGroup
: Resursgruppen där lagringskontot distribueras.storageAccount
: Namnet på lagringskontot.server
: FQDN för lagringskontots privata slutpunkt.
Skapa en fil med namnet private-azure-file-sc.yaml
och klistra sedan in följande exempelmanifest i filen. Ersätt värdena för <resourceGroup>
och <storageAccountName>
.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: private-azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
resourceGroup: <resourceGroup>
storageAccount: <storageAccountName>
server: <storageAccountName>.file.core.windows.net
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
- dir_mode=0777
- 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
Skapa lagringsklassen kubectl apply
med hjälp av kommandot :
kubectl apply -f private-azure-file-sc.yaml
Kommandots utdata liknar följande exempel:
storageclass.storage.k8s.io/private-azurefile-csi created
Skapa en fil med namnet private-pvc.yaml
och klistra sedan in följande exempelmanifest i filen:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: private-azurefile-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: private-azurefile-csi
resources:
requests:
storage: 100Gi
Skapa PVC med hjälp av kommandot kubectl apply :
kubectl apply -f private-pvc.yaml
Azure Files stöder NFS v4.1-protokollet. NFS version 4.1-stöd för Azure Files ger dig ett fullständigt hanterat NFS-filsystem som en tjänst som bygger på en högtillgänglig och mycket hållbar distribuerad elastisk lagringsplattform.
Det här alternativet är optimerat för arbetsbelastningar med slumpmässig åtkomst med datauppdateringar på plats och ger fullständigt stöd för POSIX-filsystem. Det här avsnittet visar hur du använder NFS-resurser med Azure File CSI-drivrutinen i ett AKS-kluster.
- AkS-klustrets kontrollplansidentitet (dvs. ditt AKS-klusternamn) läggs till i deltagarrollen i det virtuella nätverket och NetworkSecurityGroup.
- AKS-klustrets tjänsthuvudnamn eller hanterade tjänstidentitet (MSI) måste läggas till i deltagarrollen i lagringskontot.
Anteckning
Du kan använda en privat slutpunkt i stället för att tillåta åtkomst till det valda virtuella nätverket.
Det här avsnittet innehåller information om hur du närmar dig prestandajustering av NFS med CSI-drivrutinen för Azure Files med alternativen rsize och wsize . Alternativen rsize och wsize anger den maximala överföringsstorleken för en NFS-åtgärd. Om rsize eller wsize inte anges vid monteringen förhandlar klienten och servern om den största storlek som stöds av de två. För närvarande stöder både Azure NetApp Files och moderna Linux-distributioner läs- och skrivstorlekar så stora som 1 048 576 byte (1 MiB).
Optimala prestanda baseras på effektiv kommunikation mellan klient och server. Om du ökar eller minskar storleksvärdena för läs- och skrivalternativ kan NFS-prestanda förbättras. Standardstorleken för de läs-/skrivpaket som överförs mellan klienten och servern är 8 KB för NFS version 2 och 32 KB för NFS version 3 och 4. Dessa standardvärden kan vara för stora eller för små. Om du minskar storleken och storleken kan NFS-prestanda förbättras i ett överbelastat nätverk genom att mindre paket skickas för varje NFS-läs- och skrivbegäran. Detta kan dock öka antalet paket som behövs för att skicka data över nätverket, vilket ökar den totala nätverkstrafiken och CPU-användningen på klienten och servern.
Det är viktigt att du testar för att hitta en rsize och wsize som upprätthåller effektiv paketöverföring, där det inte minskar dataflödet och ökar svarstiden.
Mer information om hur du optimerar rsize och wsize finns i Metodtips för Linux NFS-monteringsalternativ för Azure NetApp Files.
Om du till exempel vill konfigurera en maximal rsize och wsize på 256-KiB konfigurerar du mountOptions
i lagringsklassen enligt följande:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
protocol: nfs
mountOptions:
- nconnect=4
- noresvport
- actimeo=30
- rsize=262144
- wsize=262144
Skapa en fil med namnet nfs-sc.yaml
och kopiera manifestet nedan. En lista över stödda finns mountOptions
i NFS-monteringsalternativ.
Anteckning
vers
, minorversion
, sec
konfigureras av Azure File CSI-drivrutinen. Det går inte att ange ett värde i manifestet för de här egenskaperna.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
protocol: nfs
mountOptions:
- nconnect=4
- noresvport
- actimeo=30
När du har redigerat och sparat filen skapar du lagringsklassen med kommandot kubectl apply :
kubectl apply -f nfs-sc.yaml
Kommandots utdata liknar följande exempel:
storageclass.storage.k8s.io/azurefile-csi-nfs created
Du kan distribuera ett exempel på tillståndskänslig uppsättning som sparar tidsstämplar i en fil data.txt
med kommandot kubectl apply :
kubectl apply -f
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-nfs
accessModes: ["ReadWriteMany"]
resources:
requests:
storage: 100Gi
Kommandots utdata liknar följande exempel:
statefulset.apps/statefulset-azurefile created
Verifiera innehållet i volymen genom att köra följande kommando:
kubectl exec -it statefulset-azurefile-0 -- df -h
Kommandots utdata liknar följande exempel:
Filesystem Size Used Avail Use% Mounted on
...
/dev/sda1 29G 11G 19G 37% /etc/hosts
accountname.file.core.windows.net:/accountname/pvc-fa72ec43-ae64-42e4-a8a2-556606f5da38 100G 0 100G 0% /mnt/azurefile
...
Anteckning
Observera att eftersom NFS-filresursen finns i ett Premium-konto är den minsta filresursstorleken 100 GiB. Om du skapar en PVC med en liten lagringsstorlek kan det uppstå ett fel som liknar följande: det gick inte att skapa filresursen ... storlek (5)....
Azure Files CSI-drivrutinen stöder även Windows-noder och -containrar. Om du vill använda Windows-containrar följer du snabbstarten windowscontainrar för att lägga till en Windows-nodpool.
När du har en Windows-nodpool använder du de inbyggda lagringsklasserna som azurefile-csi
eller skapar en anpassad. Du kan distribuera ett exempel på en Windows-baserad tillståndskänslig uppsättning som sparar tidsstämplar i en fil data.txt
genom att köra kommandot kubectl apply :
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/windows/statefulset.yaml
Kommandots utdata liknar följande exempel:
statefulset.apps/busybox-azurefile created
Verifiera innehållet i volymen genom att köra följande kubectl exec-kommando :
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
Utdata från kommandona liknar följande exempel:
2020-08-27 22:11:01Z
2020-08-27 22:11:02Z
2020-08-27 22:11:04Z
(...)
- Information om hur du använder CSI-drivrutin för Azure Disks finns i Använda Azure Disks med CSI-drivrutin.
- Information om hur du använder CSI-drivrutin för Azure Blob Storage finns i Använda Azure Blob Storage med CSI-drivrutin.
- Mer information om metodtips för lagring finns i Metodtips för lagring och säkerhetskopior i Azure Kubernetes Service.
Feedback om Azure Kubernetes Service
Azure Kubernetes Service är ett öppen källkod projekt. Välj en länk för att ge feedback: