Redigera

Dela via

Överväganden för Azure Kubernetes Service (AKS) för flera klientorganisationer

Azure
Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) förenklar distributionen av ett hanterat Kubernetes-kluster i Azure genom att avlasta driftkostnaderna till Azure-molnplattformen. Som värdbaserad Kubernetes-tjänst hanterar Azure viktiga uppgifter, till exempel hälsoövervakning och underhåll. Azure-plattformen hanterar AKS-kontrollplanet och du betalar bara för DE AKS-noder som kör dina program.

AKS-kluster kan delas mellan flera klienter i olika scenarier och på olika sätt. I vissa fall kan olika program köras i samma kluster. I andra fall kan flera instanser av samma program köras i samma delade kluster, en för varje klientorganisation. Alla dessa typer av delning beskrivs ofta med hjälp av paraplytermen multitenancy. Kubernetes har inte ett förstklassigt koncept för slutanvändare eller klientorganisationer. Ändå finns det flera funktioner som hjälper dig att hantera olika innehavarkrav.

I den här artikeln beskriver vi några av funktionerna i AKS som är användbara när du skapar system med flera klientorganisationer. Allmän vägledning och metodtips för kubernetes-flera klientorganisationer finns i Multi-tenancy i Kubernetes-dokumentationen.

Typer av flera innehavare

Det första steget för att avgöra hur du delar ett AKS-kluster mellan flera klienter är att utvärdera de mönster och verktyg som står till ditt förfogande. I allmänhet ingår flera klientorganisationer i Kubernetes-kluster i två huvudkategorier, även om många varianter fortfarande är möjliga. Kubernetes-dokumentationen beskriver två vanliga användningsfall för flera klientorganisationer: flera team och flera kunder.

Flera team

En vanlig form av multitenancy är att dela ett kluster mellan flera team inom en organisation. Varje team kan distribuera, övervaka och använda en eller flera lösningar. Dessa arbetsbelastningar behöver ofta kommunicera med varandra och med andra interna eller externa program som finns på samma kluster eller andra värdplattformar.

Dessutom måste dessa arbetsbelastningar kommunicera med tjänster, till exempel en relationsdatabas, en NoSQL-lagringsplats eller ett meddelandesystem som finns i samma kluster eller körs som PaaS-tjänster i Azure.

I det här scenariot har medlemmar i teamen ofta direkt åtkomst till Kubernetes-resurser via verktyg, till exempel kubectl. Eller så har medlemmar indirekt åtkomst via GitOps-styrenheter, till exempel Flux och Argo CD, eller via andra typer av verktyg för versionsautomatisering.

Mer information om det här scenariot finns i Flera team i Kubernetes-dokumentationen.

Flera kunder

En annan vanlig form av flera klientorganisationer omfattar ofta en SaaS-leverantör (software-as-a-service). Eller så kör en tjänstleverantör flera instanser av en arbetsbelastning för sina kunder, som anses vara separata klienter. I det här scenariot har kunderna inte direkt åtkomst till AKS-klustret, men de har bara åtkomst till sitt program. Dessutom vet de inte ens att deras program körs på Kubernetes. Kostnadsoptimering är ofta ett kritiskt problem. Tjänsteleverantörer använder Kubernetes-principer, till exempel resurskvoter och nätverksprinciper, för att säkerställa att arbetsbelastningarna är starkt isolerade från varandra.

Mer information om det här scenariot finns i Flera kunder i Kubernetes-dokumentationen.

Isoleringsmodeller

Enligt Kubernetes-dokumentationen delas ett Kubernetes-kluster med flera klienter av flera användare och arbetsbelastningar som ofta kallas klientorganisationer. Den här definitionen innehåller Kubernetes-kluster som olika team eller divisioner delar inom en organisation. Den innehåller också kluster som delas av instanser per kund av ett SaaS-program (software-as-a-service).

Kluster med flera klientorganisationer är ett alternativ till att hantera många dedikerade kluster med en enda klientorganisation. Operatorerna för ett Kubernetes-kluster med flera klienter måste isolera klienter från varandra. Den här isoleringen minimerar den skada som en komprometterad eller skadlig klientorganisation kan orsaka klustret och andra klienter.

När flera användare eller team delar samma kluster med ett fast antal noder finns det en oro för att ett team kan använda mer än sin beskärda del av resurser. Resurskvoter är ett verktyg för administratörer för att åtgärda detta problem.

Baserat på den säkerhetsnivå som tillhandahålls av isolering kan vi skilja mellan mjuk och hård multitenancy.

  • Mjuk multitenancy är lämplig inom ett enda företag där klientorganisationer är olika team eller avdelningar som litar på varandra. I det här scenariot syftar isoleringen till att garantera arbetsbelastningens integritet, samordna klusterresurser i olika interna användargrupper och skydda mot möjliga säkerhetsattacker.
  • Hård multi-innehavare används för att beskriva scenarier där heterogena klienter inte litar på varandra, ofta ur säkerhets- och resursdelningsperspektiv.

När du planerar att skapa ett AKS-kluster (Multitenant Azure Kubernetes Service) bör du överväga de lager av resursisolering och flera klientorganisationer som tillhandahålls av Kubernetes:

  • Kluster
  • Namnområde
  • Nodpool eller nod
  • Podd
  • Container

Dessutom bör du överväga säkerhetskonsekvenserna av att dela olika resurser mellan flera klienter. Schemaläggning av poddar från olika klientorganisationer på samma nod kan till exempel minska antalet datorer som behövs i klustret. Å andra sidan kan du behöva förhindra att specifika arbetsbelastningar samverkar. Du kanske till exempel inte tillåter att obetrodd kod utanför organisationen körs på samma nod som containrar som bearbetar känslig information.

Kubernetes kan inte garantera en helt säker isolering mellan klienter, men erbjuder funktioner som kan vara tillräckliga för specifika användningsfall. Vi rekommenderar att du separerar varje klientorganisation och dess Kubernetes-resurser i deras namnområden. Du kan sedan använda Rollbaserad åtkomstkontroll i Kubernetes (RBAC) och Nätverksprinciper för att framtvinga klientisolering. Följande bild visar till exempel den typiska SaaS-providermodellen som är värd för flera instanser av samma program i samma kluster, en för varje klientorganisation. Varje program finns i ett separat namnområde.

Diagram som visar en SaaS-providermodell som är värd för flera instanser av samma program i samma kluster.

Det finns flera sätt att utforma och skapa lösningar för flera klientorganisationer med Azure Kubernetes Service (AKS). Var och en av dessa metoder har en egen uppsättning kompromisser när det gäller infrastrukturdistribution, nätverkstopologi och säkerhet. Dessa metoder påverkar isoleringsnivå, implementeringsarbete, driftkomplexitet och kostnad. Du kan använda klientisolering i kontroll- och dataplanen baserat på dina krav.

Kontrollplanisolering

Om du har isolering på kontrollplansnivå garanterar du att olika klienter inte kan komma åt eller påverka varandras resurser, till exempel poddar och tjänster. Dessutom kan de inte påverka prestandan för andra klientorganisationers program. Mer information finns i Kontrollera planisolering i Kubernetes-dokumentationen. Det bästa sättet att implementera isolering på kontrollplansnivå är att separera varje klientorganisations arbetsbelastning och dess Kubernetes-resurser i ett separat namnområde.

Enligt Kubernetes-dokumentationen är ett namnområde en abstraktion som används för att stödja isolering av grupper av resurser i ett enda kluster. Namnområden kan användas för att isolera klientarbetsbelastningar som delar ett Kubernetes-kluster:

  • Med namnrymder kan distinkta klientarbetsbelastningar finnas på deras egen virtuella arbetsyta, utan risk för att påverka varandras arbete. Separata team i en organisation kan använda namnområden för att isolera sina projekt från varandra, eftersom de kan använda samma resursnamn i olika namnområden utan att risken för att namnet överlappar varandra.
  • RBAC-roller och rollbindningar är namnområdesomfångsbegränsade resurser som team kan använda för att begränsa klientanvändare och processer för åtkomst till resurser och tjänster endast i deras namnområden. Olika team kan definiera roller för att gruppera listor med behörigheter eller förmågor under ett enda namn. De tilldelar sedan dessa roller till användarkonton och tjänstkonton för att säkerställa att endast de behöriga identiteterna har åtkomst till resurserna i ett givet namnområde.
  • Resurskvoter för CPU och minne är namnrymdsobjekt. Teams kan använda dem för att säkerställa att arbetsbelastningar som delar samma kluster är starkt isolerade från en systemresursförbrukning. Den här metoden kan säkerställa att varje klientprogram som körs i ett separat namnområde har de resurser som krävs för att köra och undvika problem med bullriga grannar, vilket kan påverka andra klientprogram som delar samma kluster.
  • Nätverksprinciper är namnområdesobjekt som team kan använda för att framtvinga vilken nätverkstrafik som tillåts för ett visst klientprogram. Du kan använda nätverksprinciper för att separera distinkta arbetsbelastningar som delar samma kluster ur ett nätverksperspektiv.
  • Teamprogram som körs i olika namnområden kan använda olika tjänstkonton för att få åtkomst till resurser i samma kluster, externa program eller hanterade tjänster.
  • Använd namnrymder för att förbättra prestanda på kontrollplansnivå. Om arbetsbelastningar i ett delat kluster är ordnade i flera namnområden har Kubernetes API färre objekt att söka efter när åtgärder körs. Den här organisationen kan minska svarstiden för anrop mot API-servern och öka dataflödet för kontrollplanet.

Mer information om isoleringen på namnområdesnivå finns i följande resurser i Kubernetes-dokumentationen:

Isolering av dataplan

Isolering av dataplan garanterar att poddar och arbetsbelastningar för distinkta klienter är tillräckligt isolerade från varandra. Mer information finns i Isolering av dataplan i Kubernetes-dokumentationen.

Nätverksisolering

När du kör moderna mikrotjänstbaserade program i Kubernetes vill du ofta styra vilka komponenter som kan kommunicera med varandra. Som standard kan alla poddar i ett AKS-kluster skicka och ta emot trafik utan begränsningar, inklusive andra program som delar samma kluster. För att förbättra säkerheten kan du definiera nätverksregler för att styra trafikflödet. Nätverksprincip är en Kubernetes-specifikation som definierar åtkomstprinciper för kommunikation mellan poddar. Du kan använda nätverksprinciper för att separera kommunikationen mellan klientprogram som delar samma kluster.

Azure Kubernetes Service (AKS) tillhandahåller två sätt att implementera nätverksprinciper:

  1. Azure har sin implementering för nätverksprinciper som kallas Azure-nätverksprinciper.
  2. Calico-nätverksprinciper är en nätverks- och nätverkssäkerhetslösning med öppen källkod som grundades av Tigera.

Båda implementeringarna använder Linux IPTables för att framtvinga de angivna principerna. Nätverksprinciper översätts till uppsättningar med tillåtna och otillåtna IP-par. Dessa par programmeras sedan som IPTable-filterregler. Du kan bara använda Azure-nätverksprinciper med AKS-kluster som har konfigurerats med plugin-programmet för Azure CNI-nätverket . Calico-nätverksprinciper stöder dock både Azure CNI och kubenet. Mer information finns i Skydda trafik mellan poddar med hjälp av nätverksprinciper i Azure Kubernetes Service.

Mer information finns i Nätverksisolering i Kubernetes-dokumentationen.

Lagringsisolering

Azure tillhandahåller en omfattande uppsättning hanterade paaS-datalagringsplatser (plattform som en tjänst), till exempel Azure SQL Database och Azure Cosmos DB och andra lagringstjänster som du kan använda som beständiga volymer för dina arbetsbelastningar. Klientprogram som körs i ett delat AKS-kluster kan dela en databas eller fillagringsplats, eller så kan de använda en dedikerad datalagringsplats och lagringsresurs. Mer information om olika strategier och metoder för att hantera data i ett scenario med flera klienter finns i Arkitekturmetoder för lagring och data i lösningar för flera klienter.

Arbetsbelastningar som körs på Azure Kubernetes Service (AKS) kan också använda beständiga volymer för att lagra data. I Azure kan du skapa beständiga volymer som Kubernetes-resurser som backas upp av Azure Storage. Du kan skapa datavolymer manuellt och tilldela dem till poddar direkt, eller så kan du låta AKS skapa dem automatiskt med hjälp av beständiga volymanspråk. AKS tillhandahåller inbyggda lagringsklasser för att skapa beständiga volymer som backas upp av Azure Disks, Azure Files och Azure NetApp Files. Mer information finns i Lagringsalternativ för program i Azure Kubernetes Service (AKS). Av säkerhets- och återhämtningsskäl bör du undvika att använda lokal lagring på agentnoder via emptyDir och hostPath.

När inbyggda AKS-lagringsklasser inte passar för en eller flera klienter kan du skapa anpassade lagringsklasser för att uppfylla olika klientkrav. Dessa krav omfattar volymstorlek, lagrings-SKU, ett serviceavtal (SLA), säkerhetskopieringsprinciper och prisnivån.

Du kan till exempel konfigurera en anpassad lagringsklass för varje klientorganisation. Du kan sedan använda den för att tillämpa taggar på alla beständiga volymer som skapas i deras namnområde för att debitera tillbaka sina kostnader till dem. Mer information om det här scenariot finns i Använda Azure-taggar i Azure Kubernetes Service (AKS).

Mer information finns i Lagringsisolering i Kubernetes-dokumentationen.

Nodisolering

Du kan konfigurera klientarbetsbelastningar så att de körs på separata agentnoder för att undvika problemet Med bullriga grannar och minska risken för avslöjande av information. I AKS kan du skapa ett separat kluster, eller bara en dedikerad nodpool, för klienter som har strikta krav för isolering, säkerhet, regelefterlevnad och prestanda.

Du kan använda taints, toleranser, nodetiketter, nodväljare och nodtillhörighet för att begränsa klienternas poddar att endast köras på en viss uppsättning noder eller nodpooler.

I allmänhet tillhandahåller AKS arbetsbelastningsisolering på olika nivåer:

  • På kernelnivå genom att köra klientarbetsbelastningar på lätta virtuella datorer på delade agentnoder och använda Pod Sandboxing baserat på Kata Containers.
  • På den fysiska nivån genom att vara värd för klientprogram i dedikerade kluster eller nodpooler.
  • På maskinvarunivå genom att köra klientarbetsbelastningar på dedikerade Azure-värdar som garanterar att virtuella agentnoddatorer kör dedikerade fysiska datorer. Maskinvaruisolering säkerställer att inga andra virtuella datorer placeras på de dedikerade värdarna, vilket ger ytterligare ett lager av isolering för klientarbetsbelastningar.

Du kan kombinera dessa tekniker. Du kan till exempel köra kluster per klientorganisation och nodpooler i en Azure Dedicated Host-grupp för att uppnå arbetsbelastningssegregering och fysisk isolering på maskinvarunivå. Du kan också skapa delade nodpooler eller nodpooler per klientorganisation som stöder FIPS (Federal Information Process Standard), konfidentiella virtuella datorer (CVM) eller värdbaserad kryptering.

Med nodisolering kan du enkelt associera och debitera kostnaden för en uppsättning noder eller nodpooler till en enda klientorganisation. Det är strikt relaterat till innehavarmodellen som används av din lösning.

Mer information finns i Nodisolering i Kubernetes-dokumentationen.

Innehavsmodeller

Azure Kubernetes Service (AKS) tillhandahåller fler typer av nodisolering och innehavarmodeller.

Automatiserade distributioner med en enda klientorganisation

I en automatiserad distributionsmodell för en klientorganisation distribuerar du en dedikerad uppsättning resurser för varje klientorganisation, enligt följande exempel:

Diagram som visar tre klienter, var och en med separata distributioner.

Varje klientarbetsbelastning körs i ett dedikerat AKS-kluster och har åtkomst till en distinkt uppsättning Azure-resurser. Vanligtvis använder flera klientlösningar som skapas med den här modellen en omfattande användning av infrastruktur som kod (IaC). Till exempel hjälper Bicep, Azure Resource Manager, Terraform eller Azure Resource Manager REST API:er till att initiera och samordna distributionen på begäran av klientspecifika resurser. Du kan använda den här metoden när du behöver etablera en helt separat infrastruktur för var och en av dina kunder. När du planerar distributionen bör du överväga att använda mönstret Distributionsstämplar.

Fördelar:

  • En viktig fördel med den här metoden är att API-servern för varje KLIENT-AKS-kluster är separat. Den här metoden garanterar fullständig isolering mellan klienter från en säkerhets-, nätverks- och resursförbrukningsnivå. En angripare som lyckas få kontroll över en container har bara åtkomst till containrar och volymer monterade som tillhör en enda klientorganisation. En fullständig isoleringsmodell är viktig för vissa kunder med höga regelefterlevnadskostnader.
  • Klientorganisationer kommer sannolikt inte att påverka varandras systemprestanda, vilket gör att du kan undvika problem med den bullriga grannen. Detta inkluderar trafik mot API-servern. API-servern är en delad, kritisk komponent i alla Kubernetes-kluster. Anpassade styrenheter, som genererar oreglerad trafik med hög volym mot API-servern, kan orsaka instabilitet i klustret. Den här instabiliteten leder till begärandefel, tidsgränser och API-omförsöksstormar. Med funktionen Drifttids-SLA (serviceavtal) kan du skala ut kontrollplanet för ett AKS-kluster för att möta trafikefterfrågan. Ändå kan etablering av ett dedikerat kluster vara en bättre lösning för de kunder som har starka krav när det gäller arbetsbelastningsisolering.
  • Uppdateringar och ändringar kan distribueras progressivt mellan klienter, vilket minskar sannolikheten för ett systemomfattande avbrott. Azure-kostnader kan enkelt debiteras tillbaka till klientorganisationer eftersom varje resurs används av en enda klientorganisation.

Risker:

  • Kostnadseffektiviteten är låg eftersom varje klientorganisation använder en dedikerad uppsättning resurser.
  • Pågående underhåll kommer sannolikt att vara tidskrävande eftersom det måste replikeras över flera AKS-kluster, ett för varje klientorganisation. Överväg att automatisera dina operativa processer och tillämpa ändringar progressivt i dina miljöer. Det skulle vara till hjälp om du även övervägde andra åtgärder för korsdistribution, till exempel rapportering och analys i hela din egendom. På samma sätt ser du till att du planerar hur du frågar efter och manipulerar data i flera distributioner.

Fullständigt multitenantdistributioner

I en fullständigt multitenantdistribution hanterar ett enda program begäranden från alla klienter och alla Azure-resurser delas, inklusive AKS-klustret. I det här sammanhanget har du bara en uppsättning infrastruktur att distribuera, övervaka och underhålla. Alla klienter använder resursen enligt följande diagram:

Diagram som visar tre klienter, alla med en enda delad distribution.

Fördelar:

  • Den här modellen är attraktiv på grund av den lägre kostnaden för att använda en lösning med delade komponenter. När du använder den här innehavarmodellen kan du behöva distribuera ett större AKS-kluster och använda en högre SKU för alla delade datalagringsplatser för att upprätthålla den trafik som genereras av alla klientorganisationers resurser, till exempel datalagringsplatser.

Risker:

  • I det här sammanhanget hanterar ett enda program alla klientorganisationers begäranden. Du bör utforma och implementera säkerhetsåtgärder för att förhindra att klientorganisationer översvämmar programmet med anrop. De här anropen kan göra hela systemet långsammare och påverka alla klienter.
  • Om trafikprofilen är mycket varierande bör du konfigurera autoskalning av AKS-kluster så att det varierar antalet poddar och agentnoder. Basera konfigurationen på systemresursanvändningen, till exempel CPU och minne. Du kan också skala ut och skala in antalet poddar och klusternoder baserat på anpassade mått. Du kan till exempel utforska antalet väntande begäranden eller måtten för ett externt meddelandesystem som använder Kubernetes Händelsedriven autoskalning (KEDA).
  • Se till att du separerar data för varje klientorganisation och implementerar skydd för att undvika dataläckage mellan olika klienter.
  • Se till att spåra och associera Azure-kostnader med enskilda klientorganisationer baserat på deras faktiska användning. Lösningar från tredje part, till exempel kubecost, kan hjälpa dig att beräkna och dela upp kostnader mellan olika team och klienter.
  • Underhåll kan vara enklare med en enda distribution eftersom du bara behöver uppdatera en uppsättning Azure-resurser och underhålla ett enda program. Men det är också ofta mer riskabelt eftersom ändringar i infrastrukturen eller programkomponenterna kan påverka hela kundbasen.
  • Du bör också överväga skalningsbegränsningar. Det är mer troligt att du når azure-resursskalningsgränserna när du har en delad uppsättning resurser. För att undvika att nå en resurskvotgräns kan du överväga att distribuera dina klienter över flera Azure-prenumerationer.

Horisontellt partitionerade distributioner

Du kan också överväga att horisontellt partitionera ditt Kubernetes-program för flera klienter. Den här metoden består i att dela vissa lösningskomponenter mellan alla klienter och distribuera dedikerade resurser för enskilda klientorganisationer. Du kan till exempel skapa ett enda Kubernetes-program med flera klienter och sedan skapa enskilda databaser, en för varje klientorganisation, som du ser i den här bilden:

Diagram som visar tre klienter, var och en med hjälp av en dedikerad databas och ett enda, delat Kubernetes-program.

Fördelar:

  • Horisontellt partitionerade distributioner kan hjälpa dig att åtgärda problemet med den bullriga grannen. Tänk på den här metoden om du har upptäckt att den största delen av trafikbelastningen i kubernetes-programmet beror på specifika komponenter, som du kan distribuera separat, för varje klientorganisation. Dina databaser kan till exempel absorbera det mesta av systemets belastning, eftersom frågebelastningen är hög. Om en enskild klientorganisation skickar ett stort antal begäranden till din lösning kan prestandan för en databas påverkas negativt, men andra klientdatabaser (och delade komponenter, till exempel programnivån) påverkas inte.

Risker:

  • Med en horisontellt partitionerad distribution behöver du fortfarande överväga den automatiserade distributionen och hanteringen av dina komponenter, särskilt de komponenter som används av en enda klientorganisation.
  • Den här modellen kanske inte tillhandahåller den isoleringsnivå som krävs för de kunder som inte har råd att dela resurser med andra klienter, av interna principer eller efterlevnadsskäl.

Vertikalt partitionerade distributioner

Du kan dra nytta av fördelarna med modeller med en enda klientorganisation och helt flera klientorganisationer genom att använda en hybridmodell som vertikalt partitioner klientorganisationer över flera AKS-kluster eller nodpooler. Den här metoden ger följande fördelar jämfört med de föregående två innehavarmodellerna:

  • Du kan använda en kombination av distributioner med en enda klientorganisation och flera klienter. Du kan till exempel låta de flesta av dina kunder dela ett AKS-kluster och en databas i en infrastruktur med flera klientorganisationer. Ändå kan du även distribuera infrastrukturer för en enda klientorganisation för de kunder som behöver högre prestanda och isolering.
  • Du kan distribuera klienter till flera regionala AKS-kluster, eventuellt med olika konfigurationer. Den här tekniken är mest effektiv när du har klienter spridda över olika geografiska områden.

Du kan implementera olika varianter av den här innehavarmodellen. Du kan till exempel välja att erbjuda din lösning för flera klientorganisationer med olika funktionsnivåer till en annan kostnad. Din prismodell kan ge flera SKU:er, som var och en ger en inkrementell nivå av prestanda och isolering, när det gäller resursdelning, prestanda, nätverk och datasegregering. Överväg följande nivåer:

  • Grundläggande nivå: Klientbegäranden hanteras av ett enda Kubernetes-program med flera klienter som delas med andra klienter. Data lagras i en eller flera databaser som delas av alla klientorganisationer på Basic-nivån.
  • Standardnivå: Klientbegäranden hanteras av ett dedikerat Kubernetes-program som körs i ett separat namnområde, vilket ger isoleringsgränser när det gäller säkerhet, nätverk, resursförbrukning. Alla klientorganisationers program, ett för varje klientorganisation, delar samma AKS-kluster och nodpool med andra kunder på standardnivå.
  • Premiumnivå: Klientprogrammet körs i en dedikerad nodpool eller ETT AKS-kluster för att garantera ett högre serviceavtal, bättre prestanda och en högre grad av isolering. Den här nivån kan tillhandahålla en flexibel kostnadsmodell baserat på antalet och SKU:n för agentnoderna som används som värd för klientprogrammet. Du kan använda Pod Sandboxing som en alternativ lösning för att använda dedikerade kluster eller nodpooler för att isolera distinkta klientarbetsbelastningar.

Följande diagram visar ett scenario där klientorganisationer A och B körs på ett delat AKS-kluster, medan klient-C körs på ett separat AKS-kluster.

Diagram som visar tre klienter. Klientorganisationer A och B delar ett AKS-kluster. Klientorganisation C har ett dedikerat AKS-kluster.

På samma sätt visar följande diagram ett scenario där klientorganisationer A och B körs på samma nodpool, medan klientorganisation C körs på en dedikerad nodpool.

Diagram som visar tre klienter. Klientorganisationer A och B delar en nodpool. Klientorganisation C har en dedikerad nodpool.

Den här modellen kan också erbjuda olika serviceavtal för olika nivåer. Till exempel kan den grundläggande nivån erbjuda 99,9 % drifttid, standardnivån kan erbjuda 99,95 % drifttid och premiumnivån kan erbjuda 99,99 %. Det högre serviceavtalet (SLA) kan implementeras med hjälp av tjänster och funktioner som möjliggör högre tillgänglighetsmål.

Fördelar:

  • Eftersom du fortfarande delar infrastruktur kan du fortfarande få några av kostnadsfördelarna med att ha delade distributioner med flera klientorganisationer. Du kan distribuera kluster och nodpooler som delas mellan flera klientprogram på basic-nivå och standardnivå, som använder en billigare VM-storlek för agentnoder. Den här metoden garanterar bättre densitet och kostnadsbesparingar. För premiumkunder kan du distribuera AKS-kluster och nodpooler med en högre VM-storlek och ett maximalt antal poddrepliker och noder till ett högre pris.
  • Du kan köra systemtjänster, till exempel CoreDNS, Konnectivity eller Azure Application Gateway Ingress Controller, i en dedikerad nodpool i systemläge. Du kan använda taints, toleranser, nodetiketter, nodväljare och nodtillhörighet för att köra ett klientprogram i en eller flera nodpooler i användarläge.
  • Du kan använda taints, toleranser, nodetiketter, nodväljare och nodtillhörighet för att köra delade resurser. Du kan till exempel ha en ingresskontrollant eller ett meddelandesystem i en dedikerad nodpool med en specifik VM-storlek, autoskalningsinställningar och stöd för tillgänglighetszoner.

Risker:

  • Du måste utforma kubernetes-programmet så att det stöder både distributioner med flera klienter och en enda klientorganisation.
  • Om du planerar att tillåta migrering mellan infrastrukturer måste du överväga hur du migrerar kunder från en distribution med flera klienter till en egen distribution med en enda klientorganisation.
  • Du behöver en konsekvent strategi och en enda fönsterruta (en synvinkel) för att övervaka och hantera fler AKS-kluster.

Automatisk skalning

Om du vill hålla jämna steg med trafikbehovet som genereras av klientprogram kan du aktivera autoskalning av klustret för att skala agentnoderna i din Azure Kubernetes Service (AKS). Autoskalning hjälper system att förbli dynamiska under följande omständigheter:

  • Trafikbelastningen ökar under specifika arbetstider eller perioder på året.
  • Klientorganisation eller delade tunga belastningar distribueras till ett kluster.
  • Agentnoder blir otillgängliga på grund av zonindefinerade avbrott.

När du aktiverar automatisk skalning för en nodpool anger du ett minimum och ett maximalt antal noder baserat på de förväntade arbetsbelastningsstorlekarna. Genom att konfigurera ett maximalt antal noder kan du säkerställa tillräckligt med utrymme för alla klientpoddar i klustret, oavsett vilket namnområde de körs i.

När trafiken ökar lägger kluster autoskalning till nya agentnoder för att undvika att poddar hamnar i ett väntande tillstånd på grund av brist på resurser när det gäller processor och minne.

På samma sätt minskar antalet agentnoder i en nodpool när belastningen minskar, baserat på de angivna gränserna, vilket minskar driftskostnaderna.

Du kan använda automatisk skalning av poddar för att skala poddar automatiskt, baserat på resurskrav. HPA (Horizontal Pod Autoscaler) skalar automatiskt antalet poddrepliker baserat på processor-/minnesanvändning eller anpassade mått. Med Kubernetes Händelsedriven autoskalning (KEDA) kan du öka skalningen av alla containrar i Kubernetes, baserat på antalet händelser i externa system, till exempel Azure Event Hubs eller Azure Service Bus, som används av klientprogram.

Underhåll

För att minska risken för avbrott som kan påverka klientprogram under kluster- eller nodpoolsuppgraderingar, schemalägger du planerat AKS-underhåll under låg belastning. Med planerat underhåll kan du schemalägga veckovisa underhållsperioder för att uppdatera kontrollplanet för DE AKS-kluster som kör klientprogram och nodpooler, vilket minimerar påverkan på arbetsbelastningen. Du kan schemalägga ett eller flera veckovisa underhållsperioder i klustret genom att ange ett dag- eller tidsintervall för en viss dag. Alla underhållsåtgärder utförs under de schemalagda fönstren.

Säkerhet

Klusteråtkomst

När du delar ett AKS-kluster mellan flera team inom en organisation måste du implementera principen om minsta behörighet för att isolera olika klienter från varandra. I synnerhet måste du se till att användarna bara har åtkomst till sina Kubernetes-namnområden och resurser när de använder verktyg som kubectl, Helm, Flux, Argo CD eller andra typer av verktyg.

Mer information om autentisering och auktorisering med AKS finns i följande artiklar:

Arbetsbelastningsidentitet

Om du är värd för flera klientprogram i ett enda AKS-kluster och var och en finns i ett separat namnområde, bör varje arbetsbelastning använda ett annat Kubernetes-tjänstkonto och autentiseringsuppgifter för att komma åt de underordnade Azure-tjänsterna. Tjänstkonton är en av de primära användartyperna i Kubernetes. Kubernetes API innehåller och hanterar tjänstkonton. Autentiseringsuppgifter för tjänstkonton lagras som Kubernetes-hemligheter, vilket gör att de kan användas av auktoriserade poddar för att kommunicera med API-servern. De flesta API-begäranden tillhandahåller en autentiseringstoken för ett tjänstkonto eller ett normalt användarkonto.

Klientarbetsbelastningar som distribueras till AKS-kluster kan använda Microsoft Entra-programautentiseringsuppgifter för att komma åt Microsoft Entra ID-skyddade resurser, till exempel Azure Key Vault och Microsoft Graph. Microsoft Entra-arbetsbelastnings-ID för Kubernetes integreras med kubernetes interna funktioner för att federera med externa identitetsprovidrar.

Sandbox-miljöer för poddar

AKS innehåller en mekanism som kallas Pod Sandboxing som ger en isoleringsgräns mellan containerprogrammet och den delade kerneln och beräkningsresurserna för containervärden, till exempel CPU, minne och nätverk. Poddsandboxning kompletterar andra säkerhetsåtgärder eller dataskyddskontroller som hjälper klientorganisationer att skydda känslig information och uppfylla efterlevnadskrav för reglering, bransch eller styrning, till exempel PCI DSS (Payment Card Industry Data Security Standard), International Organization for Standardization (ISO) 27001 och Health Insurance Portability and Accountability Act (HIPAA).

Genom att distribuera program i separata kluster eller nodpooler kan du starkt isolera klientarbetsbelastningarna för olika team eller kunder. Att använda flera kluster och nodpooler kan vara lämpligt för isoleringskraven för många organisationer och SaaS-lösningar, men det finns scenarier där ett enda kluster med delade VM-nodpooler är mer effektivt, till exempel när du kör obetrodda och betrodda poddar på samma nod eller samlokaliserar DaemonSets och privilegierade containrar på samma nod för snabbare lokal kommunikation och funktionell gruppering. Poddsandboxning kan hjälpa dig att starkt isolera klientprogram på samma klusternoder utan att behöva köra dessa arbetsbelastningar i separata kluster eller nodpooler. Andra metoder kräver att du omkompilerar din kod eller orsakar andra kompatibilitetsproblem, men Pod Sandboxing i AKS kan köra valfri container som inte har modifierats inuti en förbättrad säkerhetsgräns för virtuella datorer.

Poddsandboxning på AKS baseras på Kata-containrar som körs på Azure Linux-containervärden för AKS-stacken för att tillhandahålla maskinvaruisolering. Kata Containers på AKS bygger på en säkerhetshärdad Azure-hypervisor. Isoleringen per podd uppnås via en kapslad enkel Kata VM som använder resurser från en överordnad VM-nod. I den här modellen får varje Kata-podd sin egen kernel i en kapslad virtuell Kata-gästdator. Med den här modellen kan du placera många Kata-containrar på en enda virtuell gästdator samtidigt som du fortsätter att köra containrar på den överordnade virtuella datorn. Modellen ger en stark isoleringsgräns i ett delat AKS-kluster.

Mer information finns i:

Azure Dedicated Host

Azure Dedicated Host är en tjänst som tillhandahåller fysiska servrar som är dedikerade till en enda Azure-prenumeration och tillhandahåller maskinvaruisolering på fysisk servernivå. Dessa dedikerade värdar kan etableras inom en region, tillgänglighetszon och feldomän, och du kan placera virtuella datorer direkt i de etablerade värdarna.

Du kan uppnå flera fördelar med hjälp av Azure Dedicated Host med AKS, inklusive följande:

  • Maskinvaruisolering säkerställer att inga andra virtuella datorer placeras på de dedikerade värdarna, vilket ger ytterligare ett lager av isolering för klientarbetsbelastningar. Dedikerade värdar distribueras i samma datacenter och delar samma nätverk och underliggande lagringsinfrastruktur som andra icke-isolerade värdar.

  • Azure Dedicated Host ger kontroll över underhållshändelser som initieras av Azure-plattformen. Du kan välja ett underhållsperiod för att minska påverkan på tjänster och säkerställa tillgänglighet och sekretess för klientarbetsbelastningar.

Azure Dedicated Host kan hjälpa SaaS-leverantörer att se till att klientprogram uppfyller regel-, bransch- och styrningsefterlevnadskrav för att skydda känslig information. Mer information finns i Lägga till Azure Dedicated Host i ett AKS-kluster (Azure Kubernetes Service).

Konfidentiella virtuella datorer

Du kan använda konfidentiella virtuella datorer (CVM) för att lägga till en eller flera nodpooler i AKS-klustret för att hantera klienternas strikta isolerings-, sekretess- och säkerhetskrav. CVM:er använder en maskinvarubaserad betrodd körningsmiljö (TEE). AMD Secure Encrypted Virtualization – Konfidentiella virtuella datorer med säker kapslad växling (SEV-SNP) nekar hypervisor-programmet och annan värdhanteringskod åtkomst till vm-minne och -tillstånd, vilket lägger till ett lager skydd på djupet mot operatörsåtkomst. Mer information finns i Använda CVM:er i ett AKS-kluster.

Fips (Federal Information Process Standards)

FIPS 140-3 är en amerikansk myndighetsstandard som definierar minimikrav för säkerhet för kryptografiska moduler i produkter och system för informationsteknik. Genom att aktivera FIPS-efterlevnad för AKS-nodpooler kan du förbättra isoleringen, sekretessen och säkerheten för dina klientarbetsbelastningar. FIPS-efterlevnad säkerställer användningen av validerade kryptografiska moduler för kryptering, hashning och andra säkerhetsrelaterade åtgärder. Med FIPS-aktiverade AKS-nodpooler kan du uppfylla regel- och branschefterlevnadskrav genom att använda robusta kryptografiska algoritmer och mekanismer. Azure tillhandahåller dokumentation om hur du aktiverar FIPS för AKS-nodpooler så att du kan stärka säkerhetsstatusen för dina AKS-miljöer med flera klientorganisationer. Mer information finns i Aktivera FIPS för AKS-nodpooler.

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:

Värdbaserad kryptering

Värdbaserad kryptering på AKS stärker ytterligare klientorganisationens arbetsbelastningsisolering, sekretess och säkerhet. När du aktiverar värdbaserad kryptering krypterar AKS vilande data på de underliggande värddatorerna, vilket hjälper till att säkerställa att känslig klientinformation skyddas mot obehörig åtkomst. Tillfälliga diskar och tillfälliga OS-diskar krypteras i vila med plattformshanterade nycklar när du aktiverar kryptering från slutpunkt till slutpunkt.

I AKS använder operativsystem och datadiskar kryptering på serversidan med plattformshanterade nycklar som standard. Cacheminnena för dessa diskar krypteras i vila med plattformshanterade nycklar. Du kan ange din egen nyckelkrypteringsnyckel (KEK) för att kryptera dataskyddsnyckeln (DEK) med hjälp av kuvertkryptering, även kallat omslutning. Cachen för operativsystemet och datadiskarna krypteras också via den BYOK som du anger.

Värdbaserad kryptering lägger till ett säkerhetslager för miljöer med flera klientorganisationer. Varje klients data i operativsystemet och datadiskcachen krypteras i vila med antingen kundhanterade eller plattformshanterade nycklar, beroende på den valda diskkrypteringstypen. Mer information finns i:

Nätverk

Begränsa nätverksåtkomsten till API-servern

I Kubernetes tar API-servern emot begäranden om att utföra åtgärder i klustret, till exempel att skapa resurser eller skala antalet noder. När du delar ett AKS-kluster mellan flera team i en organisation ska du skydda åtkomsten till kontrollplanet med hjälp av någon av följande lösningar.

Privata AKS-kluster

Genom att använda ett privat AKS-kluster kan du se till att nätverkstrafiken mellan API-servern och nodpoolerna finns kvar i det virtuella nätverket. I ett privat AKS-kluster har kontrollplanet eller API-servern en intern IP-adress som endast är tillgänglig via en privat Azure-slutpunkt, som finns i samma virtuella nätverk i AKS-klustret. På samma sätt kan alla virtuella datorer i samma virtuella nätverk kommunicera privat med kontrollplanet via den privata slutpunkten. Mer information finns i Skapa ett privat Azure Kubernetes Service-kluster.

Auktoriserade IP-adresser

Det andra alternativet för att förbättra klustersäkerheten och minimera attacker är att använda auktoriserade IP-adresser. Den här metoden begränsar åtkomsten till kontrollplanet för ett offentligt AKS-kluster till en välkänd lista över IP-adresser (Internet Protocol) och CIDR (Classless Inter-Domain Routing). När du använder auktoriserade IP-adresser exponeras de fortfarande offentligt, men åtkomsten är begränsad till en uppsättning IP-intervall. Mer information finns i Säker åtkomst till API-servern med hjälp av auktoriserade IP-adressintervall i Azure Kubernetes Service (AKS).

Azure Private Link Service (PLS) är en infrastrukturkomponent som gör att program kan ansluta privat till en tjänst via en privat Azure-slutpunkt (PE) som definieras i ett virtuellt nätverk och som är ansluten till klientdelens IP-konfiguration för en Azure Load Balancer-instans (ALB). Med Azure Private Link kan tjänsteleverantörer på ett säkert sätt tillhandahålla sina tjänster till sina klienter som kan ansluta inifrån Azure eller lokalt, utan dataexfiltreringsrisker.

Du kan använda Azure Private Link-tjänstintegrering för att ge klientorganisationer privat anslutning till sina AKS-värdbaserade arbetsbelastningar på ett säkert sätt, utan att behöva exponera någon offentlig slutpunkt på det offentliga Internet.

Allmän vägledning om hur du kan konfigurera Private Link för en Azure-värdbaserad lösning för flera klientorganisationer finns i Multitenancy och Azure Private Link.

Omvända proxyservrar

En omvänd proxy är en lastbalanserare och en API-gateway som vanligtvis används framför klientprogram för att skydda, filtrera och skicka inkommande begäranden. Populära omvända proxyservrar stöder funktioner som belastningsutjämning, SSL-avslutning och layer 7-routning. Omvända proxyservrar implementeras vanligtvis för att öka säkerhet, prestanda och tillförlitlighet. Populära omvända proxyservrar för Kubernetes innehåller följande implementeringar:

När du använder en AKS-värdbaserad omvänd proxy för att skydda och hantera inkommande begäranden till flera klientprogram bör du överväga följande rekommendationer:

  • Värd för den omvända proxyn på en dedikerad nodpool som är konfigurerad för att använda en VM-storlek med hög nätverksbandbredd och accelererat nätverk aktiverat.
  • Konfigurera nodpoolen som är värd för den omvända proxyn för automatisk skalning.
  • För att undvika ökad svarstid och tidsgränser för klientprogram definierar du en princip för automatisk skalning så att antalet ingresskontrollantpoddar omedelbart kan expanderas och kontrakteras för att matcha trafikfluktuationer.
  • Överväg att partitionera inkommande trafik till klientprogram, över flera instanser av din ingresskontrollant, för att öka skalbarheten och segregationsnivån.

När du använder ingresskontrollanten för Azure Application Gateway (AGIC) bör du överväga att implementera följande metodtips:

  • Konfigurera den Application Gateway som används av ingresskontrollanten för autoskalning. Med automatisk skalning aktiverat skalar Application Gateway och WAF v2 SKU:er ut eller in, baserat på kraven för programtrafik. Det här läget ger bättre elasticitet för ditt program och eliminerar behovet av att gissa storleken på programgatewayen eller antalet instanser. Med det här läget kan du också spara kostnader genom att inte kräva att gatewayen körs med hög allokerad kapacitet för den förväntade maximala trafikbelastningen. Du måste ange ett minsta (och valfritt högsta) instansantal.
  • Överväg att distribuera flera instanser av Application Gateway Ingress Controller (AGIC) som var och en är associerad med en separat Application Gateway, när antalet klientprogram överskrider den maximala mängden platser. Förutsatt att varje klientprogram körs i ett dedikerat namnområde använder du stöd för flera namnområden för att sprida klientprogram över fler instanser av Application Gateway Ingress Controller (AGIC).

Integrering med Azure Front Door

Azure Front Door är en global layer-7-lastbalanserare och Microsofts moderna molnnätverk för innehållsleverans (CDN) som ger snabb, tillförlitlig och säker åtkomst mellan användare och webbprogram över hela världen. Azure Front Door stöder funktioner som acceleration av begäranden, SSL-avslutning, cachelagring av svar, WAF vid gränsen, URL-baserad routning, omskrivning och omdirigeringar som du kan utnyttja när du exponerar AKS-värdbaserade program för flera klienter på det offentliga Internet.

Du kanske till exempel vill använda ett AKS-värdbaserat program för flera klienter för att hantera alla kunders begäranden. I det här sammanhanget kan du använda Azure Front Door för att hantera flera anpassade domäner, en för varje klientorganisation. Du kan avsluta SSL-anslutningar på gränsen och dirigera all trafik till det AKS-värdbaserade multitenantprogrammet som har konfigurerats med ett enda värdnamn.

Diagram som visar hur Azure Front Door och AKS ansluter.

Du kan konfigurera Azure Front Door för att ändra värdhuvudet för ursprungsbegäran så att det matchar domännamnet för serverdelsprogrammet. Det ursprungliga Host huvudet som skickas av klienten sprids via X-Forwarded-Host huvudet, och koden för programmet för flera klienter kan använda den här informationen för att mappa den inkommande begäran till rätt klientorganisation.

Azure Web Application Firewall (WAF) på Azure Front Door ger ett centraliserat skydd för webbprogram. Du kan använda Azure WAF för att försvara AKS-värdbaserade klientprogram som exponerar en offentlig slutpunkt på Internet från skadliga attacker.

Du kan konfigurera Azure Front Door Premium för privat anslutning till ett eller flera klientprogram som körs i ett AKS-kluster, via ett internt lastbalanserarens ursprung, med hjälp av Azure Private Link Service. Mer information finns i Ansluta Azure Front Door Premium till en intern lastbalanserare med Private Link.

Utgående anslutningar

När AKS-värdbaserade program ansluter till ett stort antal databaser eller externa tjänster kan klustret riskera SNAT-portöverbelastning. SNAT-portar genererar unika identifierare som används för att underhålla distinkta flöden som initieras av program som körs på samma uppsättning beräkningsresurser. Genom att köra flera klientprogram i ett delat AKS-kluster (Azure Kubernetes Service) kan du göra ett stort antal utgående anrop, vilket kan leda till en SNAT-portöverbelastning. Ett AKS-kluster kan hantera utgående anslutningar på tre olika sätt:

  • Azure Public Load Balancer: Som standard etablerar AKS en Standard SKU Load Balancer som ska konfigureras och användas för utgående anslutningar. Standardkonfigurationen kanske dock inte uppfyller kraven i alla scenarier, om offentliga IP-adresser inte tillåts eller om ytterligare hopp krävs för utgående trafik. Som standard skapas den offentliga lastbalanseraren med en offentlig STANDARD-IP-adress som används av reglerna för utgående trafik. Med regler för utgående trafik kan du uttryckligen definiera SNAT (Source Network Address Translation) för en offentlig standardlastbalanserare. Med den här konfigurationen kan du använda de offentliga IP-adresserna för lastbalanseraren för att tillhandahålla utgående Internetanslutning för dina serverdelsinstanser. Om det behövs kan du konfigurera utgående regler för den offentliga lastbalanseraren för att använda ytterligare offentliga IP-adresser för att undvika SNAT-portöverbelastning. Mer information finns i Använda klientdelens IP-adress för en lastbalanserare för utgående trafik via utgående regler.
  • Azure NAT Gateway: Du kan konfigurera ett AKS-kluster för att använda Azure NAT Gateway för att dirigera utgående trafik från klientprogram. NAT Gateway tillåter upp till 64 512 utgående UDP- och TCP-trafikflöden per offentlig IP-adress, med högst 16 IP-adresser. För att undvika risken för SNAT-portöverbelastning när du använder en NAT Gateway för att hantera utgående anslutningar från ett AKS-kluster kan du associera fler offentliga IP-adresser eller ett offentligt IP-adressprefix till gatewayen. Mer information finns i Överväganden för Azure NAT Gateway för flera klientorganisationer.
  • Användardefinierad väg (UDR): Du kan anpassa ett AKS-klusters utgående väg för att stödja anpassade nätverksscenarier, till exempel sådana som inte tillåter offentliga IP-adresser och kräver att klustret sitter bakom en virtuell nätverksinstallation (NVA). När du konfigurerar ett kluster för användardefinierad routning konfigurerar AKS inte automatiskt utgående sökvägar. Utgående konfiguration måste utföras av dig. Du kan till exempel dirigera utgående trafik via en Azure Firewall. AKS-klustret måste distribueras till ett befintligt virtuellt nätverk med ett undernät som tidigare har konfigurerats. När du inte använder en standardarkitektur för lastbalanserare (SLB) måste du upprätta explicit utgående trafik. Därför kräver den här arkitekturen att utgående trafik uttryckligen skickas till en installation, till exempel en brandvägg, gateway eller proxy. Eller så tillåter arkitekturen att nätverksadressöversättningen (NAT) görs av en offentlig IP-adress som har tilldelats till standardlastbalanseraren eller installationen.

Övervakning

Du kan använda Azure Monitor och Container Insights för att övervaka klientprogram som körs i ett delat AKS-kluster och för att beräkna kostnadsuppdelningar på enskilda namnområden. Med Azure Monitor kan du övervaka hälsotillståndet och prestandan för Azure Kubernetes Service (AKS). Den innehåller insamling av loggar och mått, telemetrianalys och visualiseringar av insamlade data, för att identifiera trender och för att konfigurera aviseringar för att proaktivt meddela dig om kritiska problem. Du kan aktivera containerinsikter för att utöka den här övervakningen.

Du kan också använda verktyg med öppen källkod, till exempel Prometheus och Grafana, som används i stor utsträckning av communityn för Kubernetes-övervakning. Eller så kan du använda andra verktyg från tredje part för övervakning och observerbarhet.

Kostnader

Kostnadsstyrning är den kontinuerliga processen för att implementera principer för att kontrollera kostnaderna. I Kubernetes-kontexten finns det flera sätt för organisationer att styra och optimera kostnader. Dessa inkluderar inbyggda Kubernetes-verktyg för att hantera och styra resursanvändning och förbrukning och för att proaktivt övervaka och optimera den underliggande infrastrukturen. När du beräknar kostnader per klientorganisation bör du överväga de kostnader som är associerade med alla resurser som används av ett klientprogram. Vilken metod du använder för att ta ut avgifter tillbaka till klientorganisationen beror på vilken innehavarmodell som har antagits av din lösning. Mer information förklaras med följande innehavarmodeller:

  • Fullständigt multitenant: När ett enda program med flera klienter hanterar alla klientbegäranden är det ditt ansvar att hålla reda på resursförbrukningen och antalet begäranden som genereras av varje klientorganisation. Sedan debiterar du dina kunder i enlighet med detta.
  • Dedikerat kluster: När ett kluster är dedikerat till en enda klientorganisation är det enkelt att debitera kostnader för Azure-resurser tillbaka till kunden. Den totala ägandekostnaden beror på många faktorer, bland annat antalet och storleken på virtuella datorer, nätverkskostnaderna på grund av nätverkstrafik, offentliga IP-adresser, lastbalanserare, lagringstjänster, till exempel hanterade diskar eller Azure-filer som används av klientlösningen och så vidare. Du kan tagga ett AKS-kluster och dess resurser i nodresursgruppen för att underlätta kostnadsladdningsåtgärder. Mer information finns i Lägga till taggar i klustret.
  • Dedikerad nodpool: Du kan använda en Azure-tagg för en ny eller befintlig nodpool som är dedikerad till en enda klientorganisation. Taggar som tillämpas på en nodpool tillämpas på varje nod i nodpoolen och sparas genom uppgraderingar. Taggar tillämpas också på nya noder som läggs till i en nodpool under utskalningsåtgärder. Att lägga till en tagg kan vara till hjälp med uppgifter som principspårning eller kostnadsladdning. Mer information finns i Lägga till taggar i nodpooler.
  • Andra resurser: du kan använda taggar för att associera kostnader för dedikerade resurser till en viss klientorganisation. I synnerhet kan du tagga offentliga IP-adresser, filer och diskar med hjälp av ett Kubernetes-manifest. Taggar som anges på det här sättet behåller Kubernetes-värdena, även om du uppdaterar dem senare med hjälp av en annan metod. När offentliga IP-adresser, filer eller diskar tas bort via Kubernetes tas alla taggar som anges av Kubernetes bort. Taggar på de resurser som inte spåras av Kubernetes påverkas inte. Mer information finns i Lägga till taggar med kubernetes.

Du kan använda verktyg med öppen källkod, till exempel KubeCost, för att övervaka och styra en AKS-klusterkostnad. Kostnadsallokering kan begränsas till en distribution, tjänst, etikett, podd och namnrymd, vilket ger dig flexibilitet i hur du debiterar eller visar tillbaka användare av klustret. Mer information finns i Kostnadsstyrning med Kubecost.

Mer information om mätning, allokering och optimering av kostnader för ett program med flera klientorganisationer finns i Arkitekturmetoder för kostnadshantering och allokering i en lösning med flera klientorganisationer. Allmän vägledning om kostnadsoptimering finns i artikeln Azure Well-Architected Framework, Översikt över grundpelare för kostnadsoptimering

Deltagare

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

Huvudförfattare:

Övriga medarbetare:

Nästa steg

Granska Resurser för arkitekter och utvecklare av lösningar för flera klientorganisationer.