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. Eftersom AKS är en värdbaserad Kubernetes-tjänst hanterar Azure viktiga uppgifter som hälsoövervakning och underhåll och kontrollplanet.

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. Termen flera klientorganisationer ofta beskriver alla dessa typer av delning. 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.

Den här artikeln beskriver några av funktionerna i AKS som du kan använda när du skapar system med flera klientorganisationer. Allmän vägledning och metodtips för Kubernetes-flera klientorganisationer finns i för flera innehavare 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 är tillgängliga att använda. I allmänhet ingår flera klientorganisationer i Kubernetes-kluster i två huvudkategorier, men många varianter är fortfarande möjliga. Dokumentationen om Kubernetes 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 (plattform som en tjänst) 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 (programvara som en tjänst). Eller så kör en tjänstleverantör flera instanser av en arbetsbelastning, som anses vara separata klientorganisationer, för sina kunder. 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änstleverantö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-dokumentationendelas ett Kubernetes-kluster med flera klienter av flera användare och arbetsbelastningar som vanligtvis kallas klienter. Den här definitionen innehåller Kubernetes-kluster som olika team eller divisioner delar inom en organisation. Den innehåller också kluster som per kund instanser av en SaaS-programresurs.

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 kan ett team använda mer än sin beskärda del av resurser. Administratörer kan använda resurskvoter för att åtgärda problemet.

Baserat på den säkerhetsnivå som isolering ger kan du 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 isolering till att garantera arbetsbelastningsintegritet, samordna klusterresurser i olika interna användargrupper och skydda mot möjliga säkerhetsattacker.
  • Hård multitenancy beskriver scenarier där heterogena klienter inte litar på varandra, ofta ur säkerhets- och resursdelningsperspektiv.

När du planerar att skapa ett AKS-kluster med flera klientorganisationer bör du överväga de lager av resursisolering och flera klientorganisationer som Kubernetes tillhandahåller, inklusive:

  • Kluster
  • Namespace
  • Nodpool eller nod
  • Balja
  • Behållare

Dessutom bör du överväga säkerhetskonsekvenserna av att dela olika resurser mellan flera klienter. Du kan till exempel minska antalet datorer som behövs i klustret genom att schemalägga poddar från olika klienter på samma nod. Å 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 för Kubernetes (RBAC) och nätverksprinciper för att framtvinga klientisolering. Följande diagram 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 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 Kontrollplanisolering 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 du använder för att stödja isolering av grupper av resurser i ett enda kluster. Du kan använda namnområden 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 namn överlappar varandra.
  • RBAC-roller och rollbindningar är namnområdesomfångsresurser 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 auktoriserade identiteterna har åtkomst till resurserna i ett visst namnområde.
  • Resurskvoter för PROCESSOR och minne är namnområdesobjekt. Teams kan använda dem för att säkerställa att arbetsbelastningar som delar samma kluster är starkt isolerade från systemets resursförbrukning. Den här metoden kan se till att alla 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 komma åt 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 isolering 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.

AKS tillhandahåller två sätt att implementera nätverksprinciper:

  • Azure har sin implementering för nätverksprinciper som kallas Azure-nätverksprinciper.
  • 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 iptables-filterregler. Du kan bara använda Azure-nätverksprinciper med AKS-kluster som har konfigurerats med Azure CNI- nätverksinsticksprogram. Calico-nätverksprinciper stöder dock både Azure CNI- och kubenet. Mer information finns i Säker 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, till exempel Azure SQL Database och Azure Cosmos DBoch 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 ett fillager, 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 med flera klienter.

Arbetsbelastningar som körs på 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 Azure Storage stöder. 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 Azure Disks, Azure Filesoch stöd för Azure NetApp Files. Mer information finns i Lagringsalternativ för program i AKS. Av säkerhetsskäl bör du undvika att använda lokal lagring på agentnoder via emptyDir- och hostPath-.

När AKS inbyggda lagringsklasser inte passar för en eller flera klienter kan du skapa anpassade lagringsklasser för att uppfylla olika klientorganisationers krav. 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 finns i Använda Azure-taggar i AKS.

Mer information finns i Storage-isolering i Kubernetes-dokumentationen.

Nodisolering

Du kan konfigurera klientarbetsbelastningar så att de körs på separata agentnoder för att undvika störningar i grannens problem och minska risken för att information avslöjas. 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äljareoch nodtillhörighet för att begränsa klienternas poddar så att de endast körs på en viss uppsättning noder eller nodpooler.

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

  • På kernelnivå genom att köra klientarbetsbelastningar på lätta virtuella datorer (VM) på delade agentnoder och med hjälp av 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 ett extra lager av isolering för klientarbetsbelastningar.

Du kan kombinera dessa tekniker. Du kan till exempel köra kluster och nodpooler per klientorganisation 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 datorereller värdbaserad kryptering.

Använd nodisolering för att 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 Node-isolering i Kubernetes-dokumentationen.

Innehavarmodeller

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 du skapar med hjälp av den här modellen en omfattande användning av infrastruktur som kod (IaC). Till exempel Bicep, Azure Resource Manager, Terraformeller REST API:er för Azure Resource Manager hjälpa 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 monterade volymer 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, så du undviker störningar i grannens problem. 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. Använd funktionen drifttids-SLA för att skala ut kontrollplanet för ett AKS-kluster för att möta trafikefterfrågan. Etablering av ett dedikerat kluster kan dock vara en bättre lösning för de kunder som har starka krav när det gäller arbetsbelastningsisolering.
  • Du kan distribuera uppdateringar och ändringar 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 är sannolikt tidskrävande eftersom du behöver upprepa underhållsaktiviteter i flera AKS-kluster, ett för varje klientorganisation. Överväg att automatisera dina operativa processer och tillämpa ändringar progressivt i dina miljöer. Andra åtgärder för korsdistribution, till exempel rapportering och analys i hela din egendom, kan också vara till hjälp. Se 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 infrastruktur att distribuera, övervaka och underhålla. Alla klienter använder resursen enligt följande diagram:

Ett diagram som visar tre klienter som alla använder 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. Dessa ändringar bidrar till att upprätthålla den trafik som alla klientorganisationers resurser, till exempel datalagringsplatser, genererar.

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. Dessa anrop 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 använda antalet väntande begäranden eller måtten för ett externt meddelandesystem som använder Kubernetes-baserad KEDA (Event Driven Autoscaler).
  • 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 till enskilda klienter baserat på deras faktiska användning. Lösningar som inte kommer från Microsoft, till exempel kubecost, kan hjälpa dig att beräkna och dela upp kostnader för 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. Det kan dock också vara mer riskabelt eftersom eventuella ändringar av 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änser när du har en delad uppsättning resurser. För att undvika att nå en resurskvotgräns kan du 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 delar vissa lösningskomponenter i alla klienter och distribuerar 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:

Ett diagram som visar tre klienter. Var och en använder en dedikerad databas och ett enda, delat Kubernetes-program.

fördelar:

  • Horisontellt partitionerade distributioner kan hjälpa dig att minska problem med bullriga grannar. Tänk på den här metoden om du identifierar 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 klientorganisationers databaser och delade komponenter, till exempel programnivån, påverkas inte.

risker:

  • Med en horisontellt partitionerad distribution måste du fortfarande överväga den automatiserade distributionen och hanteringen av dina komponenter, särskilt de komponenter som en enskild klientorganisation använder.
  • Den här modellen kanske inte tillhandahåller den isoleringsnivå som krävs för kunder som inte kan dela resurser med andra klienter av interna princip- 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. Du kan också 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 tillhandahålla 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 alla klientorganisationer på Basic-nivå delar.
  • 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 och 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 ge en flexibel kostnadsmodell baserat på antalet och SKU:n för agentnoderna som är värdar för klientprogrammet. Du kan använda poddsandboxning som en alternativ lösning för 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.

Följande diagram visar 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 basnivån erbjuda 99,9% drifttid, standardnivån kan erbjuda 99,95% drifttid och premiumnivån kan erbjuda 99,99% drifttid. Du kan implementera det högre serviceavtalet 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, Konnectivityeller Azure Application Gateway Ingress Controlleri en dedikerad nodpool i systemläge. Du kan använda taints, toleranser, nodetiketter, nodväljareoch 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äljareoch nodtillhörighet för att köra delade resurser. Du kan till exempel ha en ingresskontrollant eller meddelandesystem i en dedikerad nodpool som har en specifik VM-storlek, inställningar för automatisk skalning 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, eller en synpunkt, för att övervaka och hantera fler AKS-kluster.

Autoskalning

Om du vill hänga med i trafikbehovet som klientprogram genererar kan du aktivera autoskalning av kluster för att skala agentnoderna i 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 avbrott i en tillgänglighetszon.

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 förhindra att poddar hamnar i ett väntande tillstånd på grund av resursbrist som PROCESSOR och minne.

När belastningen minskar minskar autoskalning av kluster antalet agentnoder i en nodpool 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. HorizontalPodAutoscaler skalar automatiskt antalet poddrepliker baserat på PROCESSOR- eller minnesanvändning eller anpassade mått. Med hjälp av KEDA-kan du öka skalningen av alla containrar i Kubernetes baserat på antalet händelser från externa system, till exempel Azure Event Hubs eller Azure Service Bus, som klientprogram använder.

VPA (Vertical Pod Autoscaler) möjliggör effektiv resurshantering för poddar. Genom att justera den processor och det minne som allokerats till poddar hjälper VPA dig att minska antalet noder som krävs för att köra klientprogram. Att ha färre noder minskar den totala ägandekostnaden och hjälper dig att undvika problem med bullriga grannar.

Tilldela Kapacitetsreservationsgrupper till nodpooler för att ge bättre resursallokering och isolering för olika klienter.

Underhåll

För att minska risken för stilleståndstid som kan påverka klientprogram under uppgraderingar av kluster- eller nodpooler schemalägger du AKS planerat underhåll under låg belastning. Schemalägg veckovisa underhållsperioder för att uppdatera kontrollplanet för DE AKS-kluster som kör klientprogram och nodpooler för att minimera 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

I följande avsnitt beskrivs metodtips för säkerhet för lösningar med flera klientorganisationer med AKS.

Klusteråtkomst

När du delar ett AKS-kluster mellan flera team i en organisation måste du implementera principen 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, Fluxeller Argo CD.

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 varje program finns i ett separat namnområde bör varje arbetsbelastning använda olika Kubernetes-tjänstkonto och autentiseringsuppgifter för att få åtkomst till 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, så auktoriserade poddar kan använda dem 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 du distribuerar 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.

Poddsandboxning

AKS innehåller en mekanism som kallas Pod Sandboxing som tillhandahåller en isoleringsgräns mellan containerprogrammet och den delade kerneln och beräkningsresurserna för containervärden, till exempel PROCESSOR, 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 effektivare. Du kan till exempel använda ett enda kluster 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. Pod Sandboxing kan hjälpa dig att 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 Containers som körs på Azure Linux-containervärd för AKS stack för att tillhandahålla maskinvaruisolering. Kata Containers på AKS bygger på en säkerhetshärdad Azure-hypervisor. Den uppnår isolering per podd via en kapslad, lätt 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. Använd den här modellen om du vill placera många Kata-containrar på en enda virtuell gästdator medan du fortsätter att köra containrar på den överordnade virtuella datorn. Den här modellen ger en stark isoleringsgräns i ett delat AKS-kluster.

Mer information finns i:

Dedikerad Azure-värd

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å. Du kan etablera dessa dedikerade värdar inom en region, tillgänglighetszon och feldomän, och du kan placera virtuella datorer direkt i de etablerade värdarna.

Det finns flera fördelar med att använda Azure Dedicated Host med AKS, bland annat:

  • Maskinvaruisolering säkerställer att inga andra virtuella datorer placeras på de dedikerade värdarna, vilket ger ett extra 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 Azure-plattformen initierar. 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ägg till en dedikerad Azure-värd i ett AKS-kluster.

Karpenter

Karpenter är ett projekt för nodlivscykelhantering med öppen källkod som skapats för Kubernetes. Genom att lägga till Karpenter i ett Kubernetes-kluster kan du förbättra effektiviteten och kostnaden för att köra arbetsbelastningar i klustret. Karpenter bevakar poddar som Kubernetes-schemaläggaren markerar som oplanerade. Den etablerar och hanterar även dynamiskt noder som kan uppfylla poddkraven.

Karpenter ger detaljerad kontroll över nodetablering och arbetsbelastningsplacering i ett hanterat kluster. Den här kontrollen förbättrar flera klientorganisationer genom att optimera resursallokering, säkerställa isolering mellan varje klientorganisations program och minska driftskostnaderna. När du skapar en lösning för flera klienter på AKS tillhandahåller Karpenter användbara funktioner som hjälper dig att hantera olika programkrav för att stödja olika klientorganisationer. Du kan till exempel behöva vissa klientprogram för att köras på GPU-optimerade nodpooler och andra för att köras på minnesoptimerade nodpooler. Om ditt program kräver låg svarstid för lagring kan du använda Karpenter för att ange att en podd kräver en nod som körs i en specifik tillgänglighetszon så att du kan samplacera lagrings- och programnivån.

AKS möjliggör automatisk avetablering av noder i AKS-kluster via Karpenter. De flesta användare bör använda autoetableringsläget för noder för att aktivera Karpenter som ett hanterat tillägg. Mer information finns i Node autoprovisioning. Om du behöver mer avancerad anpassning kan du välja att själv vara värd för Karpenter. Mer information finns i AKS Karpenter-providern.

Konfidentiella virtuella datorer

Du kan använda konfidentiella virtuella datorer för att lägga till en eller flera nodpooler i AKS-klustret för att hantera klienternas strikta krav på isolering, sekretess och säkerhet. konfidentiella virtuella datorer använda en maskinvarubaserad betrodd körningsmiljö. AMD Secure Encrypted Virtualization – Säker kapslad växling (SEV-SNP) konfidentiella virtuella datorer nekar hypervisor-programmet och annan kod för värdhantering åtkomst till vm-minne och -tillstånd, vilket lägger till ett lager av skydd och djupgående skydd mot operatörsåtkomst. Mer information finns i Använda konfidentiella virtuella datorer i ett AKS-kluster.

Fips (Federal Information Process Standards)

FIPS 140-3 är en amerikansk myndighetsstandard som definierar minimikrav för kryptografiska moduler i produkter och system för informationsteknik. Genom att aktivera FIPS-efterlevnad för AKS-nodpoolerkan 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, vilket gör 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 klientorganisations arbetsbelastningsisolering, sekretess och säkerhet. När du aktiverar värdbaserad kryptering krypterar AKS vilande data på de underliggande värddatorerna, vilket säkerställer 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 för att kryptera dataskyddsnyckeln med hjälp av kuvertkryptering, även kallat omslutning. Cachen för operativsystemet och datadiskarna krypteras också via 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ätverkande

I följande avsnitt beskrivs metodtips för nätverk för lösningar med flera klientorganisationer med AKS.

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 skyddar du å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 AKS-kluster.

Auktoriserade IP-adressintervall

Det andra alternativet för att förbättra klustersäkerheten och minimera attacker är att använda auktoriserade IP-adressintervall. Den här metoden begränsar åtkomsten till kontrollplanet för ett offentligt AKS-kluster till en välkänd lista över IP-adresser och CIDR-intervall (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 intervall. Mer information finns i Säker åtkomst till API-servern med hjälp av auktoriserade IP-adressintervall i AKS.

Azure Private Link-tjänsten är en infrastrukturkomponent som gör att program kan ansluta privat till en tjänst via en privat Azure-slutpunkt som definieras i ett virtuellt nätverk och som är ansluten till klientdelens IP-konfiguration för en Azure Load Balancer-instans. Med Private Link-kan tjänstleverantö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 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.

Mer information om hur du kan konfigurera Private Link för en Azure-värdbaserad lösning för flera klientorganisationer finns i Multitenancy och 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 i 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 Azure Application Gateway Ingress Controller (AGIC)bör du överväga att implementera följande metodtips:

  • Konfigurera den programgatewayen som ingresskontrollanten använder för automatisk skalning. Med automatisk skalning aktiverat skalas programgatewayen och brandväggen för webbprogram (WAF) v2 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. Det här läget hjälper dig också att spara på kostnaderna 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 AGIC-, var och en associerad till en separat programgateway, när antalet klientprogram överskrider den maximala mängden webbplatser. 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 AGIC-.

Integrering med Azure Front Door

Azure Front Door är en global layer-7-lastbalanserare och ett modernt molnnätverk för innehållsleverans (CDN) från Microsoft 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 använda 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 begärans ursprungsvärdrubrik så att den 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 Firewalli Azure Front Door ger ett centraliserat skydd för webbprogram. Azure Web Application Firewall kan hjälpa dig 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 Private Link-. 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 att SNAT-porten (source network address translation) överbelastas. SNAT-portar generera unika identifierare som används för att underhålla distinkta flöden som program som körs på samma uppsättning beräkningsresurser initierar. Genom att köra flera klientprogram i ett delat AKS-kluster 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 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 extra hopp krävs för utgående trafik. Som standard skapas den offentliga lastbalanseraren med en offentlig STANDARD-IP-adress som utgående regler använda. Med regler för utgående trafik kan du uttryckligen definiera SNAT 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 fler 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 offentliga IP-adressprefixet till gatewayen. Mer information finns i Azure NAT Gateway-överväganden 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 routningkonfigurerar AKS inte utgående sökvägar automatiskt. Du måste slutföra utgående konfiguration. Du kan till exempel dirigera utgående trafik via en Azure Firewall-. Du måste distribuera AKS-klustret till ett befintligt virtuellt nätverk med ett undernät som du tidigare konfigurerade. När du inte använder en standardarkitektur för lastbalanserare 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 containerinsikter för att övervaka klientprogram som körs på ett delat AKS-kluster och för att beräkna kostnadsuppdelningar på enskilda namnområden. Använd Azure Monitor för att övervaka hälsotillståndet och prestandan för 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 som proaktivt meddelar 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 ofta för Kubernetes-övervakning. Eller så kan du använda andra verktyg som inte kommer från Microsoft 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 metoder som organisationer kan använda för att styra och optimera kostnader. Dessa metoder omfattar användning av inbyggda Kubernetes-verktyg för att hantera och styra resursanvändning och förbrukning samt 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 ett klientprogram använder. Vilken metod du använder för att ta ut avgifter tillbaka till klientorganisationen beror på vilken innehavarmodell som din lösning använder. I följande lista beskrivs innehavarmodeller mer detaljerat:

  • 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 varje klientorganisation genererar. 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 kostnaderna för Azure-resurser tillbaka till kunden. Den totala ägandekostnaden beror på många faktorer, inklusive antalet och storleken på virtuella datorer, nätverkskostnaderna för nätverkstrafik, offentliga IP-adresser, lastbalanserare och lagringstjänster, till exempel hanterade diskar eller Azure-filer som klientlösningen använder. Du kan tagga ett AKS-kluster och dess resurser i nodresursgruppen för att underlätta kostnadsladdningsåtgärder. Mer information finns i Lägg 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 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 Kubernetes-uppsättningar bort. Taggar på resurser som Kubernetes inte spårar påverkas inte. Mer information finns i Lägg till taggar med hjälp av Kubernetes.

Du kan använda verktyg med öppen källkod, till exempel KubeCost, för att övervaka och styra kostnaden för ett AKS-kluster. Du kan omfångsbegränsa kostnadsallokering till en distribution, tjänst, etikett, podd och namnrymd, vilket ger dig flexibilitet i hur du debiterar tillbaka 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 Overview of the Cost Optimization pillar.

Styrelseskick

När flera klienter delar samma infrastruktur kan det bli komplicerat att hantera datasekretess, efterlevnad och regelkrav. Du måste implementera starka säkerhetsåtgärder och principer för datastyrning. Delade AKS-kluster utgör en högre risk för dataintrång, obehörig åtkomst och inkompatibilitet med dataskyddsbestämmelser. Varje klientorganisation kan ha unika krav för datastyrning och efterlevnadsprinciper, vilket gör det svårt att säkerställa säkerheten och sekretessen för data.

Microsoft Defender för containrar är en molnbaserad containersäkerhetslösning som tillhandahåller funktioner för hotidentifiering och skydd för Kubernetes-miljöer. Genom att använda Defender för containrar kan du förbättra din datastyrning och efterlevnadsstatus när du är värd för flera klienter i ett Kubernetes-kluster. Använd Defender för containrar för att skydda känsliga data, identifiera och svara på hot genom att analysera containerbeteende och nätverkstrafik och uppfylla regelkrav. Den tillhandahåller granskningsfunktioner, logghantering och rapportgenerering för att demonstrera efterlevnad för tillsynsmyndigheter och granskare.

Bidragsgivare

Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

Andra deltagare: