Dela via

Lagringsalternativ för ett Kubernetes-kluster

  • Artikel

Den här artikeln jämför lagringsfunktionerna i Amazon Elastic Kubernetes Service (Amazon EKS) och Azure Kubernetes Service (AKS) och beskriver alternativen för att lagra arbetsbelastningsdata på AKS.

Kommentar

Den här artikeln är en del av en serie artiklar som hjälper proffs som är bekanta med Amazon EKS att förstå Azure Kubernetes Service (AKS).

Amazon EKS-lagringsalternativ

När du kör program som kräver datalagring erbjuder Amazon EKS olika typer av volymer för både tillfällig och långvarig lagring.

Tillfälliga volymer

För program som kräver tillfälliga lokala volymer men inte behöver spara data efter omstarter kan tillfälliga volymer användas. Kubernetes stöder olika typer av tillfälliga volymer, till exempel emptyDir, configMap, downwardAPI, secretoch hostPath. För att säkerställa kostnadseffektivitet och prestanda är det viktigt att välja den lämpligaste värdvolymen. I Amazon EKS kan du använda gp3 som värdrotvolym, vilket ger lägre priser jämfört med gp2-volymer.

Ett annat alternativ för tillfälliga volymer är Amazon EC2-instanslager, som tillhandahåller tillfällig lagring på blocknivå för EC2-instanser. Dessa volymer är fysiskt kopplade till värdarna och finns bara under instansens livslängd. Användning av lokala lagringsvolymer i Kubernetes kräver partitionering, konfiguration och formatering av diskarna med hjälp av Amazon EC2-användardata.

Beständiga volymer

Kubernetes är vanligtvis associerat med att köra tillståndslösa program, men det finns fall där beständig datalagring krävs. Kubernetes Persistent Volumes (PV: er) kan användas för att lagra data oberoende av poddar, vilket gör att data kan sparas längre än livslängden för en viss podd. Amazon EKS stöder olika typer av lagringsalternativ för PV:er, inklusive Amazon EBS, Amazon EFS, Amazon FSx for Lustreoch Amazon FSx för NetApp ONTAP.

Amazon EBS volymer är lämpliga för lagring på blocknivå och passar bra för databaser och dataflödesintensiva program. Amazon EKS-användare kan använda den senaste generationen av blocklagring gp3- för en balans mellan pris och prestanda. För applikationer med högre prestanda kan io2 block express-volymer och användas.

Amazon EFS är ett serverlöst, elastiskt filsystem som kan delas mellan flera containrar och noder. Den växer och krymper automatiskt när filer läggs till eller tas bort, vilket eliminerar behovet av kapacitetsplanering. Drivrutinen Amazon Elastic File System Container Storage Interface (CSI) används för att integrera Amazon EFS med Kubernetes.

Amazon FSx for Lustre tillhandahåller parallell fillagring med höga prestanda, perfekt för scenarier som kräver högt dataflöde och operationer med låg fördröjning. Den kan länkas till en Amazon S3-datalagringsplats för att lagra stora datamängder. Amazon FSx för NetApp ONTAP är en fullständigt hanterad delad lagringslösning som bygger på NetApps ONTAP-filsystem.

Amazon EKS-användare kan använda verktyg som AWS Compute Optimizer och Velero för att optimera lagringskonfigurationer och hantera säkerhetskopior och ögonblicksbilder.

ALTERNATIV för AKS-lagring

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 enheter kan behöva:

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

Den här artikeln beskriver lagringsalternativ och grundläggande begrepp som tillhandahåller lagring till dina program i AKS.

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 EmptyDirs, Secretoch ConfigMaps.

EmptyDirs

För en podd som definierar en emptyDir volym skapas volymen när podden tilldelas till en nod. Som namnet antyder är den emptyDir volymen ursprungligen tom. Alla containrar i podden kan läsa och skriva samma filer i emptyDir-volymen, även om den här volymen kan monteras på samma eller olika stigar i varje container. När en podd tas bort från en nod av någon anledning tas data i emptyDir bort permanent.

Hemligheter

En Hemlighet är ett objekt som innehåller en liten mängd känslig data, till exempel ett lösenord, en token eller en nyckel. Den här informationen skulle annars ingå i en poddspecifikation eller containeravbildning. Genom att använda en hemlighet undviker du att bädda in konfidentiella data direkt i programkoden. Eftersom hemligheter kan skapas oberoende av poddar som använder dem, finns det en minskad risk att exponera hemligheten (och dess data) under processerna för att skapa, visa och redigera poddar. Kubernetes, tillsammans med de program som körs i klustret, kan också vidta extra försiktighetsåtgärder med Hemligheter, till exempel förhindra att känsliga data skrivs till icke-volatil lagring. Hemligheter liknar ConfigMaps, men de är särskilt utformade för att lagra konfidentiella data.

Du kan använda hemligheter i följande syften:

Kubernetes-kontrollplanet använder också Hemligheter, till exempel bootstrap-token Hemligheter, som är en mekanism för att automatisera nodregistreringen.

ConfigMaps

En ConfigMap- är ett Kubernetes-objekt som används för att lagra icke-konfidentiella data i nyckel/värde-par. Poddar kan använda ConfigMaps som miljövariabler, kommandoradsargument eller som konfigurationsfiler i en volym. Med en ConfigMap kan du frikoppla miljöspecifik konfiguration från dina container-images, så att dina program enkelt kan flyttas.

ConfigMap tillhandahåller inte sekretess eller kryptering. Om de data som du vill lagra är konfidentiella använder du en Hemlig i stället för en ConfigMap eller använder ytterligare verktyg (tredje part) för att hålla dina data privata.

Du kan använda en ConfigMap för att ställa in konfigurationsdata separat från programkoden. Anta till exempel att du utvecklar ett program som du kan köra på din egen dator (för utveckling) och i molnet (för att hantera verklig trafik). Du skriver koden för att titta i en miljövariabel med namnet DATABASE_HOST. Lokalt anger du variabeln till localhost. I molnet anger du att den ska referera till en Kubernetes Service- som exponerar databaskomponenten för klustret. På så sätt kan du hämta en containeravbildning som körs i molnet och felsöka exakt samma kod lokalt om det behövs.

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 längre än livslängden för en enskild podd. Du kan använda följande Azure Storage-tjänster för att tillhandahålla den beständiga volymen:

Som anges 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 det underliggande Azure-disklagret eller fildisklagret och koppla det till podden. Dynamisk etablering använder en lagringsklass för att identifiera vilken typ av resurs som behöver skapas.

Viktig

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

Om du vill ha en fullständigt hanterad lösning för åtkomst på blocknivå till data kan du överväga att använda Azure Container Storage i stället för CSI-drivrutiner. Azure Container Storage integreras med Kubernetes, vilket möjliggör dynamisk och automatisk etablering av beständiga volymer. Azure Container Storage stöder Azure Disks, tillfälliga diskar och Azure Elastic SAN (förhandsversion) som stöd för lagring, vilket ger flexibilitet och skalbarhet för tillståndskänsliga program som körs i Kubernetes-kluster.

Lagringsklasser

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

En lagringsklass definierar också en återvinningspolicy. 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 pod.

För kluster som använder Azure Container Storagevisas ytterligare en lagringsklass med namnet acstor-<storage-pool-name>. En intern lagringsklass skapas också.

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 den beständiga volymbegäran för att specificera 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-lagring för att skapa en Azure-filresursdelning. Å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-fildelning. Å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. Säkerställ att volymerna använder rätt lagring när du begär persistenta volymer.

Viktigt: Från och med Kubernetes version 1.21 använder AKS CSI-drivrutiner som standard och CSI-migrering är aktiverat. Även om befintliga persistenta volymer i trädet fortsätter att fungera, kommer AKS från och med version 1.26 inte längre att stödja volymer som skapats med in-tree-drivaren och lagring som tillhandahållits för filer och diskar.

Klassen default är 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 skuname inställd på 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

Tänk på att AKS stämmer av de förvalda lagringsklasserna och skriver över eventuella ändringar du gör i lagringsklasserna.

Mer information om lagringsklasser finns i StorageClass i Kubernetes.

Fasta volymbegäran

En beständig volymbegäran (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 inkluderar volymmonteringen när volymen väl är ansluten 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ändiga volymanspråk. Beständiga volymer mappas till anspråk i en 1:1-mappning.

I följande exempel visar YAML-manifestet 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:

  • Den beständiga volymbegäran för att begära den önskade lagringen.
  • Den volymmonteringen så att dina program kan läsa och skriva data.

I följande exempel visar YAML-manifestet 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
...

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.

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 är tillgängliga 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 denna konfiguration som standard vara en tillfällig OS-disk. Den begärda storleken på 60 GiB är mindre än den maximala cachestorleken på 86 GiB.
  • Om du väljer den Standard_D8s_v3 SKU:n med 100 GB OS-disk har den här VM-storleken stöd för tillfälliga operativsystem och 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 tillfällig lagring. Den här konfigurationen skulle som standard använda hanterade OS-diskar om du inte uttryckligen anger något annat. 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. För mer information, se Använd 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 Fileseller 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 högpresterande virtuella datorer (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 Maximalt antal 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.

Om du vill hjälpa dig att fastställa den bästa passformen för din arbetsbelastning mellan Azure Files och Azure NetApp Files kan du läsa informationen i artikeln Jämförelse av Azure Files och Azure NetApp Files.

Azure Disk

Som standard levereras ett AKS-kluster med förskapade managed-csi klasser och managed-csi-premium lagringsklasser som använder Disk Storage. På samma sätt som Amazon EBS skapar dessa klasser en hanterad disk eller blockenhet som är ansluten till noden för poddåtkomst.

Diskklasserna tillåter både statisk och dynamisk volymetablering. Återkräva principen säkerställer att disken tas bort med den beständiga volymen. Du kan expandera disken genom att redigera det beständiga volymanspråket.

Dessa lagringsklasser använder Azure-hanterade diskar med lokalt redundant lagring (LRS). LRS innebär att data har tre synkrona kopior på en enda fysisk plats i en primär Azure-region. LRS är det billigaste replikeringsalternativet, men erbjuder inte skydd mot ett datacenterfel. Du kan definiera anpassade lagringsklasser som använder ZRS-hanterade diskar (Zonredundant lagring). Zonredundant lagring (ZRS) replikerar synkront din Azure-hanterade disk över tre Azure-tillgänglighetszoner i den region du väljer. Varje tillgänglighetszon är en separat fysisk plats med oberoende ström, kylning och nätverk. ZRS-diskar ger minst 99,99999999999999% (12 9:e) hållbarhet under ett visst år. En ZRS-hanterad disk kan anslutas till en virtuell dator i en annan tillgänglighetszon. ZRS-diskar är för närvarande inte tillgängliga i alla Azure-regioner. Mer information om ZRS-diskar finns i alternativet Zonredundant lagring (ZRS) för Azure Disks för hög tillgänglighet. För att minska risken för dataförlust kan du dessutom göra regelbundna säkerhetskopieringar eller ögonblicksbilder av disklagringsdata med hjälp av Azure Kubernetes Service Backup eller lösningar från tredje part som Velero eller Azure Backup- som kan använda inbyggda tekniker för ögonblicksbilder.

Du kan använda Azure Disk för att skapa en Kubernetes DataDisk- resurs. Bland disktyperna finns:

Tips

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 kan användas av poddar på flera noder samtidigt, använd Azure Files.

Azure Premium SSD v2-diskar

Azure Premium SSD v2-diskar erbjuder IO-intensiva företagsarbetsbelastningar, en konsekvent disksvarstid på undermillisekunder och hög IOPS och dataflöde. Prestanda (kapacitet, dataflöde och IOPS) för Premium SSD v2-diskar kan konfigureras oberoende när som helst, vilket gör det enklare för fler scenarier att bli kostnadseffektiva samtidigt som prestandabehoven uppfylls. Mer information om hur du konfigurerar ett nytt eller befintligt AKS-kluster för användning av Azure Premium SSD v2-diskar finns i Använda Azure Premium SSD v2-diskar på Azure Kubernetes Service.

Ultra Disk Storage

Ultra Disk Storage är en Azure-hanterad disknivå som erbjuder högt dataflöde, hög IOPS och konsekvent disklagring med låg svarstid för virtuella Azure-datorer. Ultra Disk Storage är avsett för arbetsbelastningar som är data- och transaktionsintensiva. Precis som andra SKU:er för disklagring och Amazon EBS monterar Ultra Disk Storage en podd i taget och ger inte samtidig åtkomst.

Använd flaggan --enable-ultra-ssd för att aktivera Ultra Disk Storage i AKS-klustret.

Om du väljer Ultra Disk Storage bör du vara medveten om dess begränsningar och se till att välja en kompatibel VM-storlek. Ultra Disk Storage är tillgängligt med lokalt redundant lagringsreplikering (LRS).

Byok (Bring Your Own Keys)

Azure krypterar alla data på en hanterad disk i vila. Som standard krypteras data med Microsoft-hanterade nycklar. Om du vill ha mer kontroll över krypteringsnycklar kan du ange kundhanterade nycklar som ska användas för kryptering i vila för både operativsystemet och datadiskarna för dina AKS-kluster. Mer information finns i Bring your own keys (BYOK) with Azure managed disks in Azure Kubernetes Service (AKS).

Azure Files

Disk Storage kan inte ge samtidig åtkomst till en volym, men du kan använda Azure Files för att montera en SMB-version (Server Message Block) version 3.1.1-resurs eller NFS-version 4.1-resurs som backas upp av Azure Storage. Den här processen tillhandahåller en nätverksansluten lagring som liknar Amazon EFS. Precis som med disklagring finns det två alternativ:

  • Azure Files Standard Storage backas upp av vanliga hårddiskar (HDD).
  • Azure Files Premium Storage säkerhetskopierar filresursen med högpresterande SSD-enheter. Den minsta filresursstorleken för Premium är 100 GB.

Azure Files har följande alternativ för replikering av lagringskonton för att skydda dina data vid fel:

Om du vill optimera kostnaderna för Azure Files köper du kapacitetsreservationer för Azure Files.

Azure NetApp Files

Azure NetApp Files är en fillagringstjänst i företagsklass med höga prestanda som körs på Azure och stöder volymer med NFS- (NFSv3 eller NFSv4.1), SMB-och med dubbla protokoll (NFSv3 och SMB eller NFSv4.1 och SMB). Kubernetes-användare har två alternativ för att använda Azure NetApp Files-volymer för Kubernetes-arbetsbelastningar:

  • Skapa Azure NetApp Files-volymer statiskt. I det här scenariot sker skapandet av volymer utanför AKS. Volymer skapas med hjälp av Azure CLI eller från Azure-portalen och exponeras sedan för Kubernetes när en PersistentVolumeskapas. Statiskt skapade Azure NetApp Files-volymer har många begränsningar (till exempel oförmåga att expanderas, behöver vara överetablerade och så vidare). Statiskt skapade volymer rekommenderas inte för de flesta användningsfall.
  • Skapa Azure NetApp Files-volymer dynamisktoch dirigera via Kubernetes. Den här metoden är det föredragna sätt att skapa flera volymer direkt via Kubernetes och uppnås med hjälp av Astra Trident. Astra Trident är en CSI-kompatibel dynamisk lagringsorkestrator som hjälper till att etablera volymer internt via Kubernetes.

Mer information finns i Konfigurera Azure NetApp Files för Azure Kubernetes Service.

Azure Blob-lagring

Drivrutinen Azure Blob Storage Container Storage Interface (CSI) är en CSI-specifikation-kompatibel drivrutin som används av Azure Kubernetes Service (AKS) för att hantera livscykeln för Azure Blob Storage. 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.

När du monterar Azure Blob Storage som ett filsystem i en container eller podd kan du använda bloblagring med ett antal program som arbetar med enorma mängder ostrukturerade data. Till exempel:

  • Loggfildata
  • Bilder, dokument och strömmande video eller ljud
  • Haveriberedskapsdata

Data i objektlagringen kan nås av program med hjälp av BlobFuse eller NFS 3.0-protokoll. Före introduktionen av CSI-drivrutinen för Azure Blob Storage var det enda alternativet att manuellt installera en drivrutin som inte stöds för åtkomst till Blob Storage från ditt program som körs på AKS. När CSI-drivrutinen för Azure Blob Storage är aktiverad i AKS finns det två inbyggda lagringsklasser: azureblob-fuse-premium och azureblob-nfs-premium.

Information om hur du skapar ett AKS-kluster med stöd för CSI-drivrutiner finns i CSI-drivrutiner på AKS-. Mer information om skillnaderna i åtkomst mellan var och en av Azure-lagringstyperna med hjälp av NFS-protokollet finns i Jämför åtkomst till Azure Files, Blob Storage och Azure NetApp Files med NFS.

Azure HPC Cache

Azure HPC Cache påskyndar åtkomsten till dina data för HPC-uppgifter, med all skalbarhet för molnlösningar. Om du väljer den här lagringslösningen ska du distribuera DITT AKS-kluster i en region som stöder Azure HPC-cache.

NFS-server

Det bästa alternativet för delad NFS-åtkomst är att använda Azure Files eller Azure NetApp Files. Du kan också skapa en NFS-server på en virtuell Azure-dator som exporterar volymer.

Tänk på att det här alternativet endast stöder statisk etablering. Du måste etablera NFS-resurserna manuellt på servern och kan inte göra det automatiskt från AKS.

Den här lösningen baseras på infrastruktur som en tjänst (IaaS) i stället för PaaS (plattform som en tjänst). Du ansvarar för att hantera NFS-servern, inklusive OS-uppdateringar, hög tillgänglighet, säkerhetskopior, haveriberedskap och skalbarhet.

Byok (Bring Your Own Keys) med Azure-diskar

Azure Storage krypterar alla data i ett lagringskonto i vila, inklusive operativsystemet och datadiskarna i ett AKS-kluster. Som standard krypteras data med Microsoft-hanterade nycklar. Om du vill ha mer kontroll över krypteringsnycklar kan du ange kundhanterade nycklar som ska användas för kryptering i resten av operativsystemet och datadiskarna i dina AKS-kluster. Mer information finns i:

Azure Container Storage

Azure Container Storage är en molnbaserad volymhanterings-, distributions- och orkestreringstjänst som skapats internt för containrar. Det är integrerat med Kubernetes så att du dynamiskt och automatiskt kan etablera beständiga volymer för att lagra data för tillståndskänsliga program som körs i Kubernetes-kluster.

Azure Container Storage använder befintliga Azure Storage-erbjudanden för faktisk datalagring och erbjuder en volymorkestrerings- och hanteringslösning som är specialbyggd för containrar. Alternativ för säkerhetskopiering av lagring som stöds är:

  • Azure Disks: Detaljerad kontroll över lagrings-SKU:er och konfigurationer. De är lämpliga för databaser på nivå 1 och för generell användning.
  • Tillfälliga diskar: Använder lokala lagringsresurser på AKS-noder (NVMe eller temp SSD). Passar bäst för program utan krav på datahållbarhet eller med inbyggt stöd för datareplikering. AKS identifierar den tillgängliga tillfälliga lagringen på AKS-noder och hämtar dem för volymdistribution.
  • Azure Elastic SAN: Etablera en fullständigt hanterad resurs på begäran. Lämplig för allmänna databaser, strömnings- och meddelandetjänster, CD/CI-miljöer och andra arbetsbelastningar på nivå 1/nivå 2. Flera kluster kan komma åt ett enda SAN samtidigt, men beständiga volymer kan bara kopplas av en konsument i taget.

Hittills har tillhandahållande av molnlagring för containrar som krävs med hjälp av enskilda CSI-drivrutiner (Container Storage Interface) för att använda lagringstjänster avsedda för IaaS-arbetsbelastningar (infrastruktur som en tjänst) och få dem att fungera för containrar. Detta skapar driftkostnader och ökar risken för problem med programtillgänglighet, skalbarhet, prestanda, användbarhet och kostnad.

Azure Container Storage härleds från OpenEBS, en lösning med öppen källkod som tillhandahåller containerlagringsfunktioner för Kubernetes. Genom att erbjuda en hanterad volymorkestreringslösning via mikrotjänstbaserade lagringsstyrenheter i en Kubernetes-miljö möjliggör Azure Container Storage sann containerbaserad lagring.

Azure Container Storage är lämpligt i följande scenarier:

  • Påskynda initiativ för vm-till-container: Azure Container Storage visar hela spektrumet av Azure-blocklagringserbjudanden som tidigare endast var tillgängliga för virtuella datorer och gör dem tillgängliga för containrar. Detta inkluderar tillfälliga diskar som ger extremt låg svarstid för arbetsbelastningar som Cassandra, samt Azure Elastic SAN som tillhandahåller interna iSCSI- och delade etablerade mål.

  • Förenkla volymhanteringen med Kubernetes: Genom att tillhandahålla volymorkestrering via Kubernetes-kontrollplanet gör Azure Container Storage det enkelt att distribuera och hantera volymer i Kubernetes – utan att behöva flytta fram och tillbaka mellan olika kontrollplan.

  • Minska den totala ägandekostnaden (TCO): Förbättra kostnadseffektiviteten genom att öka skalan för beständiga volymer som stöds per podd eller nod. Minska de lagringsresurser som behövs för etablering genom att dynamiskt dela lagringsresurser. Observera att uppskalningsstöd för själva lagringspoolen inte stöds.

Azure Container Storage ger följande viktiga fördelar:

  • Snabb utskalning av tillståndskänsliga poddar: Azure Container Storage monterar beständiga volymer över protokoll för lagring av nätverksblock (NVMe-oF eller iSCSI), vilket ger snabb koppling och frånkoppling av beständiga volymer. Du kan starta små och distribuera resurser efter behov samtidigt som du ser till att dina program inte är utsvultna eller störda, antingen under initieringen eller i produktion. Programåterhämtningen förbättras med podd-respawns i klustret, vilket kräver snabb förflyttning av beständiga volymer. Med hjälp av fjärrnätverksprotokoll är Azure Container Storage nära kopplat till poddlivscykeln för att stödja mycket motståndskraftiga, högskaliga tillståndskänsliga program i AKS.

  • Förbättrad prestanda för tillståndskänsliga arbetsbelastningar: Azure Container Storage ger överlägsen läsprestanda och ger skrivprestanda nära disk med hjälp av NVMe-oF via RDMA. På så sätt kan kunderna kostnadseffektivt uppfylla prestandakraven för olika containerarbetsbelastningar, inklusive nivå 1-I/O-intensiv, generell användning, dataflödeskänslig och utvecklings-/test. Påskynda anslutnings-/frånkopplingstiden för beständiga volymer och minimera redundanstiden för poddar.

  • Kubernetes-intern volymorkestrering: Skapa lagringspooler och beständiga volymer, avbilda ögonblicksbilder och hantera hela livscykeln för volymer med hjälp kubectl av kommandon utan att växla mellan verktygsuppsättningar för olika kontrollplansåtgärder.

Lösningar från tredje part

Precis som Amazon EKS är AKS en Kubernetes-implementering och du kan integrera Kubernetes-lagringslösningar från tredje part. Här är några exempel på lagringslösningar från tredje part för Kubernetes:

  • Rook omvandlar distribuerade lagringssystem till självhanterade lagringstjänster genom att automatisera lagringsadministratörsuppgifter. Rook levererar sina tjänster via en Kubernetes-operatör för varje lagringsprovider.
  • GlusterFS är ett kostnadsfritt och skalbart nätverksfilsystem med öppen källkod som använder vanlig maskinvara för att skapa stora, distribuerade lagringslösningar för dataintensiva och bandbreddsintensiva uppgifter.
  • Ceph tillhandahåller en tillförlitlig och skalbar enhetlig lagringstjänst med objekt-, block- och filgränssnitt från ett enda kluster som skapats av maskinvarukomponenter av råvaror.
  • Med MinIO-objektlagring i flera moln kan företag skapa en AWS S3-kompatibel datainfrastruktur i alla moln, vilket ger ett konsekvent, portabelt gränssnitt för dina data och program.
  • Portworx är en lösning för lagring och datahantering från slutpunkt till slutpunkt för Kubernetes-projekt och containerbaserade initiativ. Portworx erbjuder containergranular lagring, haveriberedskap, datasäkerhet och multimolnmigreringar.
  • Quobyte tillhandahåller fil- och objektlagring med höga prestanda som du kan distribuera på valfri server eller i molnet för att skala prestanda, hantera stora mängder data och förenkla administrationen.
  • Ondat levererar ett konsekvent lagringslager över alla plattformar. Du kan köra en databas eller en beständig arbetsbelastning i en Kubernetes-miljö utan att behöva hantera lagringsskiktet.

Överväganden för Kubernetes-lagring

Tänk på följande faktorer när du väljer en lagringslösning för Amazon EKS eller AKS.

Åtkomstlägen för lagringsklass

I Kubernetes version 1.21 och senare använder AKS- och Amazon EKS-lagringsklasser endast CSI-drivrutiner (Container Storage Interface) och som standard.

Olika tjänster stöder lagringsklasser som har olika åtkomstlägen.

Tjänst ReadWriteOnce ReadOnlyMany ReadWriteMany
Azure-diskar X
Azure Files X X X
Azure NetApp Files X X X
NFS-server X X X
Azure HPC Cache X X X

Dynamisk eller statisk etablering

Etablera volymer dynamiskt för att minska hanteringskostnaderna för statiskt skapande av beständiga volymer. Ange en korrekt återtagandeprincip för att undvika oanvända diskar när du tar bort poddar.

Backup

Välj ett verktyg för att säkerhetskopiera beständiga data. Verktyget ska matcha din lagringstyp, till exempel ögonblicksbilder, Azure Backup, Velero eller Kasten.

Kostnadsoptimering

Om du vill optimera Azure Storage-kostnader använder du Azure-reservationer. Kontrollera vilka tjänster som stöder Azure-reservationer. Se även Kostnadshantering för ett Kubernetes-kluster.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg