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

I Amazon EKS, efter Kubernetes version 1.11, har klustret en standardlagringsklass som kallas gp2 för beständiga volymanspråk. Administratörer kan lägga till drivrutiner för att definiera fler lagringsklasser, till exempel:

  • Amazon EBS CSI-drivrutin som ett Amazon EKS-tillägg
  • Amazon EBS CSI självhanterat tillägg
  • Amazon EFS CSI-drivrutin
  • Amazon FSx for Lustre CSI-drivrutin
  • Amazon FSx för NetApp ONTAP CSI-drivrutin

Genom att lägga till drivrutiner och lagringsklasser kan du använda lagringstjänster som:

  • Amazon Elastic Block Store (Amazon EBS), en lagringslösning på blocknivå som används med Amazon Elastic Compute Cloud-instanser (EC2) för att lagra beständiga data. Den här tjänsten liknar Azure Disk Storage, som har flera SKU:er som Standard SSD, Premium SSD eller Ultra Disk Storage, beroende på vilken prestanda som krävs.

  • Amazon Elastic File System (Amazon EFS) , som ger nätverksfilsystem åtkomst till externa filsystem som kan delas mellan instanser. Motsvarande Azure-lösning är Azure Files och Azure Files Premium med både servermeddelandeblock (SMB) 3.0 och NFS-åtkomst.

  • Lustre, ett filsystem med öppen källkod som ofta används vid högpresterande databehandling (HPC). I Azure kan du använda Ultra Disk Storage eller Azure HPC Cache för arbetsbelastningar där hastigheten är viktig, till exempel maskininlärning och HPC.

  • NetApp ONTAP, fullständigt hanterad DELAD ONTAP-lagring i Amazon Web Services (AWS). Azure NetApp Files är en liknande fillagringstjänst i Azure som bygger på NetApp-teknik.

ALTERNATIV för AKS-lagring

Varje AKS-kluster innehåller följande förskapade lagringsklasser som standard:

  • Standardlagringsklassen, managed-csi, använder Standard SSD för disklagring. Standard SSD är ett kostnadseffektivt lagringsalternativ som är optimerat för arbetsbelastningar som behöver konsekventa prestanda vid lägre indatautdataåtgärder per sekund (IOPS).
  • Klassen managed-csi-premium använder Disk Storage Premium SSD-hanterade diskar.
  • Klassen azurefile-csi använder Azure Files för att ge samtidig delad åtkomst till samma lagringsvolym med hjälp av SMB eller NFS.
  • Klassen azurefile-csi-premium använder Azure Files Premium för filresurser med IOPS-intensiva arbetsbelastningar. Azure Files Premium ger låg svarstid och högt dataflöde som backas upp av SSD-lagring.

Du kan utöka dessa alternativ genom att lägga till andra lagringsklasser och integrera med andra tillgängliga lagringslösningar, till exempel:

  • Ultra Disk Storage
  • Azure NetApp Files
  • HPC Cache
  • NFS-server
  • Lagringslösningar från tredje part

Azure-disklagring

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 minska den här risken genom att göra regelbundna säkerhetskopieringar eller ögonblicksbilder av disklagringsdata med hjälp av lösningar som Velero eller Azure Backup som kan använda inbyggda tekniker för ögonblicksbilder.

Båda lagringsklasserna backas upp av hanterade diskar och båda använder SSD-enheter (Solid State Disk). Det är viktigt att förstå skillnaderna mellan Standard- och Premium-diskar:

  • Standarddiskar prissätts baserat på storleks- och lagringstransaktioner.
  • Premiumdiskar debiteras endast efter storlek, vilket kan göra dem billigare för arbetsbelastningar som kräver ett stort antal transaktioner.
  • Premium SSD ger ett högre maximalt dataflöde och IOPS, som du ser i den här jämförelsen.
  • Premium Storage rekommenderas för de flesta produktions- och utvecklingsarbetsbelastningar.

Om du använder Azure-hanterade diskar som primär lagringsklass bör du överväga den virtuella dator-SKU som du väljer för ditt Kubernetes-kluster. Virtuella Azure-datorer begränsar antalet diskar som du kan ansluta till dem, och gränsen varierar med storleken på den virtuella datorn. Eftersom Azure-diskar är monterade som ReadWriteOnceär de bara tillgängliga för en enda podd.

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 ansluta med hjälp av SMB-protokollet och sedan montera en delad volym 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 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.

Azure NetApp Files

Precis som AWS NetApp ONTAP är Azure NetApp Files en fillagringstjänst i företagsklass med höga prestanda och datamätare. Azure NetApp Files hanteras fullständigt i Azure med hjälp av NetApp-lösningar. Precis som Azure Files låter Azure NetApp Files flera poddar montera en volym. Du kan använda Astra Trident, en dynamisk lagringsorkestrator med öppen källkod för Kubernetes, för att konfigurera AKS-klustret så att det använder Azure NetApp Files.

Tänk på resursgränserna för Azure NetApp Files. Den minsta storleken på en kapacitetspool för Azure NetApp Files är 4 TiB. Azure NetApp Files debiterar efter etablerad storlek i stället för använd kapacitet.

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.

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.

Mer information finns i:

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