Dela via

Lagringsalternativ för program i Azure Kubernetes Service (AKS)

  • Artikel

Program som körs i Azure Kubernetes Service (AKS) kan behöva lagra och hämta data. Vissa programarbetsbelastningar kan använda lokal, snabb lagring på onödiga, tömda noder, men andra kräver lagring som bevaras på mer regelbundna datavolymer på Azure-plattformen.

Flera poddar kan behöva:

  • Dela samma datavolymer.
  • Koppla om datavolymer om podden schemaläggs om på en annan nod.

Du kan också behöva samla in och lagra känslig information eller programkonfigurationsinformation i poddar.

Den här artikeln beskriver de grundläggande begreppen som tillhandahåller lagring till dina program i AKS:

Diagram över lagringsalternativ för program i ett AKS-kluster (Azure Kubernetes Services).

Standardstorlek för OS-disk

När du skapar ett nytt kluster eller lägger till en ny nodpool i ett befintligt kluster avgör numret för vCPU:er som standard os-diskstorleken. Antalet virtuella processorer baseras på den virtuella datorns SKU. I följande tabell visas standardstorleken för OS-disken för varje VM-SKU:

VM SKU Cores (vCPU:er) Standardnivå för OS-disk Etablerad IOPS Etablerat dataflöde (Mbit/s)
1 - 7 P10/128G 500 100
8 - 15 P15/256G 1100 125
16 - 63 P20/512G 2 300 150
64+ P30/1024G 5000 200

Viktigt!

Standardstorleken för OS-diskar används endast i nya kluster eller nodpooler när tillfälliga OS-diskar inte stöds och ingen standardstorlek för OS-disken anges. Standardstorleken för OS-disken kan påverka prestandan eller kostnaden för klustret. Du kan inte ändra operativsystemets diskstorlek när klustret eller nodpoolen har skapats. Den här standardstorleken för diskar påverkar kluster eller nodpooler som skapades i juli 2022 eller senare.

Obeständig OS-disk

Som standard replikerar Azure automatiskt operativsystemdisken för en virtuell dator till Azure Storage för att undvika dataförlust när den virtuella datorn flyttas till en annan värd. Men eftersom containrar inte är utformade för att ha kvar lokal status, erbjuder det här beteendet ett begränsat värde samtidigt som det ger vissa nackdelar. Dessa nackdelar omfattar, men är inte begränsade till, långsammare nodetablering och högre svarstid för läsning/skrivning.

Tillfälliga OS-diskar lagras däremot bara på värddatorn, precis som en tillfällig disk. Med den här konfigurationen får du lägre svarstid för läsning/skrivning, tillsammans med snabbare nodskalning och klusteruppgraderingar.

Kommentar

När du inte uttryckligen begär Azure-hanterade diskar för operativsystemet är AKS som standard tillfälliga operativsystem om möjligt för en viss nodpoolskonfiguration.

Storlekskrav och rekommendationer för tillfälliga OS-diskar finns i dokumentationen om virtuella Azure-datorer. Följande är några allmänna storleksöverväganden:

  • Om du väljer att använda AKS standardstorlek för virtuella datorer Standard_DS2_v2 SKU med standardstorleken för OS-disken på 100 GiB stöder den virtuella datorns standardstorlek tillfälliga operativsystem, men har bara 86 GiB-cachestorlekar. Den här konfigurationen skulle som standard vara hanterade diskar om du inte uttryckligen anger den. Om du begär ett tillfälliga operativsystem får du ett verifieringsfel.

  • Om du begär samma Standard_DS2_v2 SKU med en 60-GiB OS-disk skulle den här konfigurationen som standard vara tillfälliga operativsystem. Den begärda storleken på 60 GiB är mindre än den maximala cachestorleken på 86 GiB.

  • Om du väljer Standard_D8s_v3 SKU med 100 GB OS-disk stöder den här VM-storleken tillfälliga operativsystem och har 200 GiB cacheutrymme. Om du inte anger operativsystemdisktypen får nodpoolen tillfälliga operativsystem som standard.

Den senaste generationen av VM-serien har inte en dedikerad cache, utan endast tillfällig lagring. Om du till exempel har valt den Standard_E2bds_v5 VM-storleken med standardstorleken på 100 GiB stöder den tillfälliga OS-diskar, men har bara 75 GB temporär lagring. Den här konfigurationen skulle som standard vara hanterade OS-diskar om du inte uttryckligen anger den. Om du begär en tillfällig OS-disk får du ett verifieringsfel.

  • Om du begär samma Standard_E2bds_v5 VM-storlek med en 60-GiB OS-disk är den här konfigurationen standard för tillfälliga OS-diskar. Den begärda storleken på 60 GiB är mindre än den maximala tillfälliga lagringen på 75 GiB.

  • Om du väljer Standard_E4bds_v5 SKU med 100-GiB OS-disk stöder den här VM-storleken tillfälliga operativsystem och har 150 GiB tillfällig lagring. Om du inte anger operativsystemdisktypen etablerar Azure som standard en tillfällig OS-disk till nodpoolen.

Kundhanterade nycklar

Du kan hantera kryptering för din tillfälliga OS-disk med dina egna nycklar i ett AKS-kluster. Mer information finns i Använda kundhanterad nyckel med Azure-disk på AKS.

Volymer

Kubernetes behandlar vanligtvis enskilda poddar som tillfälliga, disponibla resurser. Program har olika metoder som är tillgängliga för att använda och bevara data. En volym representerar ett sätt att lagra, hämta och spara data mellan poddar och genom programmets livscykel.

Traditionella volymer skapas som Kubernetes-resurser som backas upp av Azure Storage. Du kan manuellt skapa datavolymer som ska tilldelas till poddar direkt eller låta Kubernetes skapa dem automatiskt. Datavolymer kan använda: Azure Disk, Azure Files, Azure NetApp Files eller Azure Blobs.

Kommentar

Beroende på vilken VM SKU du använder kan Azure Disk CSI-drivrutinen ha en volymgräns per nod. För vissa virtuella datorer med höga prestanda (till exempel 16 kärnor) är gränsen 64 volymer per nod. Om du vill identifiera gränsen per VM SKU läser du kolumnen Max datadiskar för varje VM SKU som erbjuds. En lista över vm-SKU:er som erbjuds och deras motsvarande detaljerade kapacitetsgränser finns i Storlekar på virtuella datorer för generell användning.

För att avgöra om arbetsbelastningen passar bäst mellan Azure Files och Azure NetApp Files kan du läsa informationen i artikeln Jämförelse mellan Azure Files och Azure NetApp Files.

Azure Disk

Använd Azure Disk för att skapa en Kubernetes DataDisk-resurs . Bland disktyperna finns:

  • Premium SSD (rekommenderas för de flesta arbetsbelastningar)
  • Ultradiskar
  • Standard SSD:er
  • Standard HDD

Dricks

För de flesta produktions- och utvecklingsarbetsbelastningar använder du Premium-SSD:er.

Eftersom en Azure Disk är monterad som ReadWriteOnce är den bara tillgänglig för en enda nod. För lagringsvolymer som är tillgängliga för poddar på flera noder samtidigt använder du Azure Files.

Azure Files

Använd Azure Files för att montera en SMB-version (Server Message Block) version 3.1.1-resurs eller NFS-version 4.1-resurs (Network File System). Med Azure Files kan du dela data över flera noder och poddar och använda:

  • Azure Premium-lagring som backas upp av högpresterande SSD
  • Azure Standard Storage som backas upp av vanliga hårddiskar

Azure NetApp Files

  • Ultra Storage
  • Premium Storage
  • Standardlagring

Azure Blob Storage

Använd Azure Blob Storage för att skapa en bloblagringscontainer och montera den med hjälp av NFS v3.0-protokollet eller BlobFuse.

  • Blockblobar

Volymtyper

Kubernetes-volymer representerar mer än bara en traditionell disk för att lagra och hämta information. Kubernetes-volymer kan också användas som ett sätt att mata in data i en podd för användning av dess containrar.

Vanliga volymtyper i Kubernetes är:

emptyDir

Används ofta som tillfälligt utrymme för en podd. Alla containrar i en podd kan komma åt data på volymen. Data som skrivs till den här volymtypen bevaras endast under poddens livslängd. När du har tagit bort podden tas volymen bort. Den här volymen använder vanligtvis den underliggande lokala noddisklagringen, även om den bara kan finnas i nodens minne.

hemlighet

Du kan använda hemliga volymer för att mata in känsliga data i poddar, till exempel lösenord.

  1. Skapa en hemlighet med kubernetes-API:et.
  2. Definiera din podd eller distribution och begär en specifik hemlighet.
    • Hemligheter tillhandahålls endast till noder med en schemalagd podd som kräver dem.
    • Hemligheten lagras i tmpfs, inte skrivs till disk.
  3. När du tar bort den sista podden på en nod som kräver en hemlighet tas hemligheten bort från nodens tmpfs.
    • Hemligheter lagras i ett angivet namnområde och nås endast av poddar inom samma namnområde.

configMap

Du kan använda configMap för att mata in nyckel/värde-paregenskaper i poddar, till exempel programkonfigurationsinformation. Definiera programkonfigurationsinformation som en Kubernetes-resurs, enkelt uppdaterad och tillämpad på nya instanser av poddar när de distribueras.

Som att använda en hemlighet:

  1. Skapa en ConfigMap med kubernetes-API:et.
  2. Begär ConfigMap när du definierar en podd eller distribution.
    • ConfigMaps lagras i ett angivet namnområde och nås endast av poddar inom samma namnområde.

Beständiga volymer

Volymer som definierats och skapats som en del av poddens livscykel finns bara tills du tar bort podden. Poddar förväntar sig ofta att deras lagring ska finnas kvar om en podd schemaläggs om på en annan värd under en underhållshändelse, särskilt i StatefulSets. En beständig volym (PV) är en lagringsresurs som skapats och hanteras av Kubernetes-API:et som kan finnas bortom livslängden för en enskild podd.

Du kan använda följande Azure Storage-datatjänster för att tillhandahålla den beständiga volymen:

Som du ser i avsnittet Volymer bestäms valet av Azure Disks eller Azure Files ofta av behovet av samtidig åtkomst till data eller prestandanivån.

Diagram över beständiga volymer i ett AKS-kluster (Azure Kubernetes Services).

En klusteradministratör kan statiskt skapa en beständig volym, eller så kan en volym skapas dynamiskt av Kubernetes API-servern. Om en podd har schemalagts och begär lagring som för närvarande inte är tillgänglig kan Kubernetes skapa den underliggande Azure-disken eller fillagringen och koppla den till podden. Dynamisk etablering använder en lagringsklass för att identifiera vilken typ av resurs som behöver skapas.

Viktigt!

Beständiga volymer kan inte delas av Windows- och Linux-poddar på grund av skillnader i filsystemstöd mellan de två operativsystemen.

Lagringsklasser

Om du vill ange olika lagringsnivåer, till exempel premium eller standard, kan du skapa en lagringsklass.

En lagringsklass definierar också en återställningsprincip. När du tar bort den beständiga volymen styr återtagandeprincipen beteendet för den underliggande Azure Storage-resursen. Den underliggande resursen kan antingen tas bort eller behållas för användning med en framtida podd.

För kluster som använder CSI-drivrutiner (Container Storage Interface) skapas följande extra lagringsklasser:

Lagringsklass beskrivning
managed-csi Använder Azure Standard SSD lokalt redundant lagring (LRS) för att skapa en hanterad disk. Återtagandeprincipen säkerställer att den underliggande Azure Disk tas bort när den beständiga volymen som använde den tas bort. Lagringsklassen konfigurerar också beständiga volymer så att de kan expanderas. Du kan redigera det beständiga volymanspråket för att ange den nya storleken. Från och med Kubernetes version 1.29, i AKS-kluster (Azure Kubernetes Service) som distribuerats över flera tillgänglighetszoner, använder den här lagringsklassen Azure Standard SSD zone-redundant lagring (ZRS) för att skapa hanterade diskar.
managed-csi-premium Använder Azure Premium lokalt redundant lagring (LRS) för att skapa en hanterad disk. Återtagandeprincipen säkerställer återigen att den underliggande Azure Disk tas bort när den beständiga volymen som använde den tas bort. På samma sätt gör den här lagringsklassen att beständiga volymer kan utökas. Från och med Kubernetes version 1.29, i AKS-kluster (Azure Kubernetes Service) som distribuerats i flera tillgänglighetszoner, använder den här lagringsklassen Azure Premium zonredundant lagring (ZRS) för att skapa hanterade diskar.
azurefile-csi Använder Azure Standard Storage för att skapa en Azure-filresurs. Återtagandeprincipen säkerställer att den underliggande Azure-filresursen tas bort när den beständiga volymen som använde den tas bort.
azurefile-csi-premium Använder Azure Premium Storage för att skapa en Azure-filresurs. Återtagandeprincipen säkerställer att den underliggande Azure-filresursen tas bort när den beständiga volymen som använde den tas bort.
azureblob-nfs-premium Använder Azure Premium Storage för att skapa en Azure Blob Storage-container och ansluta med hjälp av NFS v3-protokollet. Återtagandeprincipen säkerställer att den underliggande Azure Blob Storage-containern tas bort när den beständiga volymen som använde den tas bort.
azureblob-fuse-premium Använder Azure Premium Storage för att skapa en Azure Blob Storage-container och ansluta med BlobFuse. Återtagandeprincipen säkerställer att den underliggande Azure Blob Storage-containern tas bort när den beständiga volymen som använde den tas bort.

Om du inte anger en lagringsklass för en beständig volym används standardlagringsklassen. Se till att volymerna använder den lagring du behöver när du begär beständiga volymer.

Viktigt!

Från och med Kubernetes version 1.21 använder AKS endast CSI-drivrutiner som standard och CSI-migrering är aktiverat. Medan befintliga beständiga volymer i träd fortsätter att fungera, från och med version 1.26, stöder AKS inte längre volymer som skapats med drivrutinen i trädet och lagring som etablerats för filer och diskar.

Klassen default kommer att vara samma som managed-csi.

Från och med Kubernetes version 1.29, när du distribuerar Azure Kubernetes Service-kluster (AKS) över flera tillgänglighetszoner, använder AKS nu zonredundant lagring (ZRS) för att skapa hanterade diskar i inbyggda lagringsklasser. ZRS säkerställer synkron replikering av dina Azure-hanterade diskar över flera Azure-tillgänglighetszoner i den valda regionen. Den här redundansstrategin förbättrar återhämtningsförmågan för dina program och skyddar dina data mot datacenterfel.

Det är dock viktigt att observera att zonredundant lagring (ZRS) har en högre kostnad jämfört med lokalt redundant lagring (LRS). Om kostnadsoptimering är en prioritet kan du skapa en ny lagringsklass med parametern inställd på skuname LRS. Du kan sedan använda den nya lagringsklassen i ditt beständiga volymanspråk (PVC).

Du kan skapa en lagringsklass för andra behov med hjälp av kubectl. I följande exempel används premiumhanterade diskar och anger att den underliggande Azure Disk ska behållas när du tar bort podden:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Kommentar

AKS avstäms av standardlagringsklasserna och skriver över alla ändringar du gör i dessa lagringsklasser.

Mer information om lagringsklasser finns i StorageClass i Kubernetes.

Beständiga volymanspråk

Ett beständigt volymanspråk (PVC) begär lagring av en viss lagringsklass, åtkomstläge och storlek. Kubernetes API-servern kan dynamiskt etablera den underliggande Azure Storage-resursen om ingen befintlig resurs kan uppfylla anspråket baserat på den definierade lagringsklassen.

Podddefinitionen innehåller volymmonteringen när volymen har anslutits till podden.

Diagram över beständiga volymanspråk i ett AkS-kluster (Azure Kubernetes Services).

När en tillgänglig lagringsresurs har tilldelats den podd som begär lagring, är den beständiga volymen bunden till ett beständigt volymanspråk. Beständiga volymer mappas till anspråk i en 1:1-mappning.

Följande YAML-exempelmanifest visar ett beständigt volymanspråk som använder lagringsklassen managed-premium och begär en Azure Disk som är 5Gi i storlek:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

När du skapar en podddefinition anger du även:

  • Det beständiga volymanspråket för att begära önskad lagring.
  • Volymmonteringen för dina program för att läsa och skriva data.

Följande YAML-exempelmanifest visar hur det tidigare beständiga volymanspråket kan användas för att montera en volym på /mnt/azure:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Om du vill montera en volym i en Windows-container anger du enhetsbeteckningen och sökvägen. Till exempel:

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

Nästa steg

Rekommenderade metoder finns i Metodtips för lagring och säkerhetskopior i AKS - och AKS-lagringsöverväganden.

Mer information om hur du använder CSI-drivrutiner finns i följande instruktionsartiklar:

Mer information om grundläggande Kubernetes- och AKS-begrepp finns i följande artiklar: