Upravit

Share via

Důležité informace o službě Azure Kubernetes Service (AKS) pro víceklientské prostředí

Azure
Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) zjednodušuje nasazení spravovaného clusteru Kubernetes v Azure tím, že přesměruje provozní režii na cloudovou platformu Azure. Azure jako hostovaná služba Kubernetes zpracovává důležité úlohy, jako je monitorování stavu a údržba. Platforma Azure spravuje řídicí rovinu AKS a platíte jenom za uzly AKS, které spouští vaše aplikace.

Clustery AKS je možné sdílet napříč několika tenanty v různých scénářích a způsobech. V některých případech můžou různé aplikace běžet ve stejném clusteru. V jiných případech může ve stejném sdíleném clusteru běžet více instancí stejné aplikace, jedna pro každého tenanta. Všechny tyto typy sdílení se často popisují pomocí zastřešujícího termínu víceklientské architektury. Kubernetes nemá prvotřídní koncept koncových uživatelů ani tenantů. Přesto nabízí několik funkcí, které vám pomůžou se správou různých požadavků na tenanty.

V tomto článku popisujeme některé funkce AKS, které jsou užitečné při vytváření víceklientských systémů. Obecné pokyny a osvědčené postupy pro víceklientské prostředí Kubernetes najdete v dokumentaci ke službě Kubernetes s více tenanty .

Víceklientské typy

Prvním krokem k určení způsobu sdílení clusteru AKS mezi více tenanty je vyhodnocení vzorů a nástrojů, které máte k dispozici. Obecně platí, že víceklientská architektura v clusterech Kubernetes spadá do dvou hlavních kategorií, i když je stále možné mnoho variant. Dokumentace Kubernetes popisuje dva běžné případy použití víceklientské architektury: více týmů a více zákazníků.

Více týmů

Běžnou formou víceklientské architektury je sdílení clusteru mezi několika týmy v rámci organizace. Každý tým může nasadit, monitorovat a provozovat jedno nebo více řešení. Tyto úlohy často potřebují vzájemně komunikovat a s jinými interními nebo externími aplikacemi umístěnými ve stejném clusteru nebo na jiných hostitelských platformách.

Kromě toho tyto úlohy potřebují komunikovat se službami, jako je relační databáze, úložiště NoSQL nebo systém zasílání zpráv, který je hostovaný ve stejném clusteru nebo běží jako služby PaaS v Azure.

V tomto scénáři mají členové týmů často přímý přístup k prostředkům Kubernetes prostřednictvím nástrojů, jako je kubectl. Nebo mají členové nepřímý přístup prostřednictvím kontrolerů GitOps, jako je Flux a Argo CD, nebo prostřednictvím jiných typů nástrojů pro automatizaci verzí.

Další informace o tomto scénáři najdete v dokumentaci k Kubernetes více týmům .

Více zákazníků

Další běžnou formou víceklientské architektury často zahrnuje dodavatele softwaru jako služby (SaaS). Poskytovatel služeb také pro své zákazníky spouští více instancí úlohy, které jsou považovány za samostatné tenanty. V tomto scénáři nemají zákazníci přímý přístup ke clusteru AKS, ale mají přístup pouze ke své aplikaci. Navíc ani neví, že jejich aplikace běží na Kubernetes. Optimalizace nákladů je často zásadním problémem. Poskytovatelé služeb používají zásady Kubernetes, jako jsou kvóty prostředků a zásady sítě, k zajištění silné izolace úloh mezi sebou.

Další informace o tomto scénáři najdete v dokumentaci k Kubernetes několika zákazníkům .

Modely izolace

Podle dokumentace Kubernetes je cluster Kubernetes s více tenanty sdílený více uživateli a úlohami, které se běžně označují jako tenanti. Tato definice zahrnuje clustery Kubernetes, které sdílejí různé týmy nebo divize v rámci organizace. Obsahuje také clustery sdílené instancemi softwaru jako služby (SaaS) pro jednotlivé zákazníky.

Víceklientská architektura clusteru je alternativou ke správě mnoha vyhrazených clusterů s jedním tenantem. Operátory clusteru Kubernetes s více tenanty musí navzájem izolovat tenanty. Tato izolace minimalizuje poškození, které může napadený nebo škodlivý tenant provádět s clusterem a s jinými tenanty.

Když několik uživatelů nebo týmů sdílí stejný cluster s pevným počtem uzlů, existuje obava, že jeden tým může použít více než spravedlivé sdílení prostředků. Kvóty prostředků jsou nástroj, který správcům umožní tento problém vyřešit.

Na základě úrovně zabezpečení poskytované izolací můžeme rozlišovat mezi měkkou a tvrdou víceklientské architekturou.

  • Měkká víceklientská architektura je vhodná v rámci jednoho podniku, kde jsou tenanti různými týmy nebo odděleními, které vzájemně důvěřují. V tomto scénáři se izolace zaměřuje na záruku integrity úloh, orchestraci prostředků clusteru napříč různými interními skupinami uživatelů a ochranu před možnými útoky na zabezpečení.
  • Tvrdá víceklientská architektura se používá k popisu scénářů, kdy heterogenní tenanti vzájemně nedůvěřují, často z hlediska zabezpečení a sdílení prostředků.

Pokud plánujete vytvořit cluster Azure Kubernetes Service (AKS) s více tenanty, měli byste zvážit vrstvy izolace prostředků a víceklientské architektury, které poskytuje Kubernetes:

  • Cluster
  • Obor názvů
  • Fond uzlů nebo uzel
  • Pod
  • Kontejner

Kromě toho byste měli zvážit vliv na zabezpečení sdílení různých prostředků mezi více tenanty. Například plánování podů z různých tenantů na stejném uzlu může snížit počet počítačů potřebných v clusteru. Na druhou stranu může být potřeba zabránit kolaci konkrétních úloh. Můžete například nepovolit, aby nedůvěryhodný kód mimo vaši organizaci běžel na stejném uzlu jako kontejnery, které zpracovávají citlivé informace.

I když Kubernetes nemůže zaručit dokonale zabezpečenou izolaci mezi tenanty, nabízí funkce, které můžou stačit pro konkrétní případy použití. Osvědčeným postupem je oddělit jednotlivé tenanty a prostředky Kubernetes do jejich oborů názvů. K vynucení izolace tenanta pak můžete použít řízení přístupu na základě role Kubernetes (RBAC) a zásady sítě. Následující obrázek například ukazuje typický model poskytovatele SaaS, který hostuje více instancí stejné aplikace ve stejném clusteru, jeden pro každého tenanta. Každá aplikace se nachází v samostatném oboru názvů.

Diagram znázorňující model poskytovatele SaaS, který hostuje více instancí stejné aplikace ve stejném clusteru

Existuje několik způsobů, jak navrhovat a vytvářet víceklientová řešení pomocí služby Azure Kubernetes Service (AKS). Každá z těchto metod se dodává s vlastní sadou kompromisů z hlediska nasazení infrastruktury, topologie sítě a zabezpečení. Tyto metody ovlivňují úroveň izolace, úsilí implementace, provozní složitost a náklady. Izolaci tenanta můžete použít v řídicích rovinách a rovinách dat na základě vašich požadavků.

Izolace řídicí roviny

Pokud máte izolaci na úrovni řídicí roviny, zaručujete, že různí tenanti nemají přístup k prostředkům ostatních, jako jsou pody a služby. Nemůžou také ovlivnit výkon aplikací jiných tenantů. Další informace najdete v tématu Izolace roviny řízení v dokumentaci Kubernetes. Nejlepším způsobem, jak implementovat izolaci na úrovni řídicí roviny, je oddělit úlohy každého tenanta a jeho prostředky Kubernetes do samostatného oboru názvů.

Podle dokumentace Kubernetes je obor názvů abstrakcí, která se používá k podpoře izolace skupin prostředků v rámci jednoho clusteru. Obory názvů se dají použít k izolaci úloh tenantů, které sdílejí cluster Kubernetes:

  • Obory názvů umožňují, aby různé úlohy tenantů existovaly ve svém vlastním virtuálním pracovním prostoru bez rizika, že by to mělo vliv na práci ostatních. Samostatné týmy v rámci organizace můžou pomocí oborů názvů izolovat své projekty od sebe, protože můžou používat stejné názvy prostředků v různých oborech názvů bez rizika překrývání názvů.
  • Role RBAC a vazby rolí jsou prostředky v oboru názvů, které týmy můžou použít k omezení uživatelů a procesů tenanta pro přístup k prostředkům a službám pouze v jejich oborech názvů. Různé týmy mohou definovat role pro seskupení seznamů oprávnění nebo schopností pod jedním názvem. Tyto role pak přiřadí uživatelským účtům a účtům služeb, aby se zajistilo, že k prostředkům v daném oboru názvů mají přístup jenom autorizované identity.
  • Kvóty prostředků pro procesor a paměť jsou objekty oboru názvů. Týmy je můžou použít k zajištění, aby úlohy sdílející stejný cluster byly silně izolované od spotřeby systémových prostředků. Tato metoda může zajistit, aby každá aplikace tenanta, která běží v samostatném oboru názvů, má prostředky, které potřebuje ke spuštění, a vyhnula se problémům s hlučným sousedem, které by mohly ovlivnit jiné aplikace tenanta, které sdílejí stejný cluster.
  • Zásady sítě jsou objekty oboru názvů, které můžou týmy přijmout, aby vynucovaly, který síťový provoz je pro danou aplikaci tenanta povolený. Pomocí zásad sítě můžete oddělit různé úlohy, které sdílejí stejný cluster z hlediska sítí.
  • Týmové aplikace, které běží v různých oborech názvů, můžou používat různé účty služeb pro přístup k prostředkům ve stejném clusteru, externích aplikacích nebo spravovaných službách.
  • Použití oborů názvů ke zlepšení výkonu na úrovni řídicí roviny. Pokud jsou úlohy ve sdíleném clusteru uspořádané do více oborů názvů, má rozhraní API Kubernetes méně položek pro vyhledávání při spouštění operací. Tato organizace může snížit latenci volání vůči serveru rozhraní API a zvýšit propustnost řídicí roviny.

Další informace o izolaci na úrovni oboru názvů najdete v následujících zdrojích informací v dokumentaci Kubernetes:

Izolace roviny dat

Izolace roviny dat zaručuje, že pody a úlohy různých tenantů jsou dostatečně izolované od sebe. Další informace najdete v tématu Izolace roviny dat v dokumentaci Kubernetes.

Izolace sítě

Při spouštění moderních aplikací založených na mikroslužbách v Kubernetes často chcete řídit, které komponenty spolu můžou vzájemně komunikovat. Ve výchozím nastavení můžou všechny pody v clusteru AKS odesílat a přijímat provoz bez omezení, včetně dalších aplikací, které sdílejí stejný cluster. Pokud chcete zlepšit zabezpečení, můžete definovat pravidla sítě pro řízení toku provozu. Zásady sítě jsou specifikace Kubernetes, která definuje zásady přístupu pro komunikaci mezi pody. Zásady sítě můžete použít k oddělení komunikace mezi aplikacemi tenanta, které sdílejí stejný cluster.

Azure Kubernetes Service (AKS) nabízí dva způsoby implementace zásad sítě:

  1. Azure má svou implementaci pro zásady sítě, označované jako zásady sítě Azure.
  2. Zásady sítě Calico jsou opensourcové řešení zabezpečení sítě a sítě, které založil Tigera.

Obě implementace používají tabulky IPTable pro Linux k vynucení zadaných zásad. Zásady sítě se překládají do sad povolených a nepovolovaných párů IP adres. Tyto páry se pak naprogramují jako pravidla filtru IPTable. Zásady sítě Azure můžete používat jenom s clustery AKS, které jsou nakonfigurované pomocí síťového plug-inu Azure CNI . Zásady sítě Calico ale podporují Azure CNI i kubenet. Další informace najdete v tématu Zabezpečení provozu mezi pody pomocí zásad sítě ve službě Azure Kubernetes Service.

Další informace najdete v tématu Izolace sítě v dokumentaci Kubernetes.

Izolace úložiště

Azure poskytuje bohatou sadu spravovaných úložišť dat PaaS (platforma jako služba), jako je Azure SQL Database a Azure Cosmos DB, a další služby úložiště, které můžete pro své úlohy používat jako trvalé svazky . Klientské aplikace spuštěné ve sdíleném clusteru AKS můžou sdílet databázi nebo úložiště souborů nebo můžou používat vyhrazené úložiště dat a prostředek úložiště. Další informace o různýchstrategiích

Úlohy spuštěné ve službě Azure Kubernetes Service (AKS) můžou také k ukládání dat používat trvalé svazky. V Azure můžete vytvořit trvalé svazky jako prostředky Kubernetes, které jsou podporovány službou Azure Storage. Datové svazky můžete vytvářet ručně a přiřazovat je přímo k podům nebo je můžete automaticky vytvářet pomocí deklarací trvalých svazků. AKS poskytuje integrované třídy úložiště pro vytváření trvalých svazků, které jsou podporovány disky Azure, soubory Azure a Azure NetApp Files. Další informace najdete v tématu Možnosti úložiště pro aplikace ve službě Azure Kubernetes Service (AKS). Z důvodů zabezpečení a odolnosti byste se měli vyhnout použití místního úložiště na uzlech agenta prostřednictvím emptyDir a hostPath.

Pokud předdefinované třídy úložiště AKS nejsou vhodné pro jednoho nebo více tenantů, můžete vytvořit vlastní třídy úložiště, které budou řešit různé požadavky tenantů. Mezi tyto požadavky patří velikost svazku, skladová položka úložiště, smlouva o úrovni služeb (SLA), zásady zálohování a cenová úroveň.

Můžete například nakonfigurovat vlastní třídu úložiště pro každého tenanta. Pak ho můžete použít k aplikování značek na libovolný trvalý svazek vytvořený v jejich oboru názvů, abyste jim mohli účtovat náklady. Další informace o tomto scénáři najdete v tématu Použití značek Azure ve službě Azure Kubernetes Service (AKS).

Další informace najdete v tématu Izolace úložiště v dokumentaci Kubernetes.

Izolace uzlu

Úlohy tenanta můžete nakonfigurovat tak, aby běžely na samostatných uzlech agenta, abyste se vyhnuli problému s hlučným sousedem a snížili riziko zpřístupnění informací. V AKS můžete vytvořit samostatný cluster nebo jenom vyhrazený fond uzlů pro tenanty, kteří mají přísné požadavky na izolaci, zabezpečení, dodržování právních předpisů a výkon.

Pomocí taintů, tolerací, popisků uzlů, selektorů uzlů a spřažení uzlů můžete omezit pody tenantů tak, aby běžely jenom na konkrétní sadě uzlů nebo fondů uzlů.

AKS obecně poskytuje izolaci úloh na různých úrovních:

  • Na úrovni jádra spuštěním úloh tenantů v jednoduchých virtuálních počítačích na sdílených uzlech agenta a používáním sandboxu podů založených na kontejnerech Kata.
  • Na fyzické úrovni hostováním aplikací tenanta ve vyhrazených clusterech nebo fondech uzlů.
  • Na úrovni hardwaru spuštěním úloh tenantů na vyhrazených hostitelích Azure, které zaručují, že virtuální počítače uzlů agenta spouštějí vyhrazené fyzické počítače. Izolace hardwaru zajišťuje, že na vyhrazených hostitelích nejsou umístěné žádné jiné virtuální počítače, což poskytuje další vrstvu izolace pro úlohy tenanta.

Tyto techniky můžete kombinovat. Můžete například spouštět clustery a fondy uzlů pro jednotlivé tenanty ve skupině vyhrazených hostitelů Azure, abyste dosáhli oddělení úloh a fyzické izolace na úrovni hardwaru. Můžete také vytvořit sdílené fondy uzlů nebo uzlů pro jednotlivé tenanty, které podporují standard FIPS (Federal Information Process Standard), důvěrné virtuální počítače (CVM) nebo šifrování založené na hostitelích.

Izolace uzlu umožňuje snadno přidružit a zaúčtovat náklady na sadu uzlů nebo fond uzlů do jednoho tenanta. Souvisí výhradně s modelem tenantů, který vaše řešení přijímá.

Další informace najdete v tématu Izolace uzlu v dokumentaci Kubernetes.

Model architektury tenantů

Azure Kubernetes Service (AKS) poskytuje více typů izolace uzlů a modelů tenantů.

Automatizovaná nasazení s jedním tenantem

V automatizovaném modelu nasazení s jedním tenantem nasadíte pro každého tenanta vyhrazenou sadu prostředků, jak je znázorněno v tomto příkladu:

Diagram znázorňující tři tenanty, z nichž každý má samostatná nasazení

Každá úloha tenanta běží ve vyhrazeném clusteru AKS a přistupuje k samostatné sadě prostředků Azure. Víceklientských řešení vytvořených pomocí tohoto modelu obvykle využívá infrastrukturu jako kód (IaC). Například rozhraní REST API Bicep, Azure Resource Manageru (ARM), Terraformu nebo rozhraní REST API Azure Resource Manageru pomáhají inicializovat a koordinovat nasazení vyhrazených prostředků na vyžádání. Tento přístup můžete použít v případě, že potřebujete zřídit zcela samostatnou infrastrukturu pro každého zákazníka. Při plánování nasazení zvažte použití vzoru Razítka nasazení.

Výhody:

  • Klíčovou výhodou tohoto přístupu je, že server ROZHRANÍ API každého clusteru AKS tenanta je oddělený. Tento přístup zaručuje úplnou izolaci mezi tenanty od úrovně zabezpečení, sítě a spotřeby prostředků. Útočník, který se stará o získání kontroly nad kontejnerem, bude mít přístup pouze ke kontejnerům a svazkům připojeným k jednomu tenantovi. Model tenantů tenantů s plnou izolací je pro některé zákazníky zásadní s vysokou režií na dodržování právních předpisů.
  • Tenanti si pravděpodobně nebudou moct vzájemně ovlivnit výkon systému, což vám umožní vyhnout se problému s hlučným sousedem. Mezi tyto aspekty patří přenosy proti serveru rozhraní API. Server rozhraní API je sdílená kritická komponenta v jakémkoli clusteru Kubernetes. Vlastní kontrolery, které generují neregulovaný velký objem provozu na serveru rozhraní API, můžou způsobit nestabilitu clusteru. Tato nestabilita vede k selháním požadavků, vypršení časových limitů a opakovaným pokusům rozhraní API. Funkce SLA (smlouva o úrovni služeb) umožňuje škálovat řídicí rovinu clusteru AKS tak, aby splňovala poptávku po provozu. Zřizování vyhrazeného clusteru však může být lepším řešením pro zákazníky se silnými požadavky z hlediska izolace úloh.
  • Aktualizace a změny je možné postupně zavádět napříč tenanty, což snižuje pravděpodobnost výpadku celého systému. Náklady na Azure se dají snadno účtovat zpět tenantům, protože každý prostředek používá jeden tenant.

Rizika:

  • Nákladová efektivita je nízká, protože každý tenant používá vyhrazenou sadu prostředků.
  • Průběžná údržba bude pravděpodobně časově náročná, protože je potřeba ji replikovat napříč několika clustery AKS, jednou pro každého tenanta. Zvažte automatizaci provozních procesů a postupné aplikování změn v prostředích. Pomůže vám to, kdybyste také zvážili další operace mezi nasazeními, jako jsou vytváření sestav a analýzy v rámci celého majetku. Stejně tak se ujistěte, že plánujete dotazování a manipulaci s daty napříč několika nasazeními.

Plně víceklientských nasazení

V plně víceklientských nasazeních obsluhuje jedna aplikace požadavky všech tenantů a všechny prostředky Azure se sdílejí, včetně clusteru AKS. V tomto kontextu máte pouze jednu sadu infrastruktury pro nasazení, monitorování a údržbu. Všichni tenanti používají prostředek, jak je znázorněno v následujícím diagramu:

Diagram znázorňující tři tenanty, všichni používají jedno sdílené nasazení

Výhody:

  • Tento model je atraktivní kvůli nižším nákladům na provoz řešení se sdílenými komponentami. Při použití tohoto modelu tenantů možná budete muset nasadit větší cluster AKS a přijmout vyšší skladovou položku pro jakékoli sdílené úložiště dat, aby bylo možné udržovat provoz vygenerovaný všemi prostředky tenantů, jako jsou úložiště dat.

Rizika:

  • V tomto kontextu jedna aplikace zpracovává všechny požadavky tenantů. Měli byste navrhnout a implementovat bezpečnostní opatření, která zabrání tenantům v zahlcení aplikace voláními. Tato volání by mohla zpomalit celý systém a ovlivnit všechny tenanty.
  • Pokud je profil provozu vysoce proměnný, měli byste nakonfigurovat automatické škálování clusteru AKS tak, aby se měnil počet podů a uzlů agenta. Založte konfiguraci na využití systémových prostředků, jako je procesor a paměť. Alternativně můžete škálovat a škálovat v počtu podů a uzlů clusteru na základě vlastních metrik. Můžete například prozkoumat počet čekajících požadavků nebo metriky externího systému zasílání zpráv, který používá automatické škálování řízené událostmi Kubernetes (KEDA).
  • Ujistěte se, že data pro každého tenanta oddělíte a implementujete bezpečnostní opatření, abyste se vyhnuli úniku dat mezi různými tenanty.
  • Nezapomeňte sledovat a přidružit náklady Azure k jednotlivým tenantům na základě jejich skutečného využití. Řešení třetích stran, jako je kubecost, vám můžou pomoct s výpočtem a rozdělením nákladů napříč různými týmy a tenanty.
  • Údržba může být jednodušší s jedním nasazením, protože stačí aktualizovat jenom jednu sadu prostředků Azure a udržovat jednu aplikaci. Je ale také často riskantní, protože jakékoli změny infrastruktury nebo komponent aplikací můžou ovlivnit celou zákaznickou základnu.
  • Měli byste také zvážit omezení škálování. Pokud máte sdílenou sadu prostředků, pravděpodobně dosáhnete limitů škálování prostředků Azure. Abyste se vyhnuli dosažení limitu kvóty prostředků, můžete zvážit distribuci tenantů napříč několika předplatnými Azure.

Horizontálně dělené nasazení

Alternativně můžete zvážit horizontální dělení víceklientských aplikací Kubernetes. Tento přístup se skládá ze sdílení některých komponent řešení napříč všemi tenanty a nasazení vyhrazených prostředků pro jednotlivé tenanty. Můžete například vytvořit jednu aplikaci Kubernetes s více tenanty a pak vytvořit jednotlivé databáze, jednu pro každého tenanta, jak je znázorněno na tomto obrázku:

Diagram znázorňující tři tenanty, z nichž každý používá vyhrazenou databázi a jednu sdílenou aplikaci Kubernetes

Výhody:

  • Horizontálně dělená nasazení vám můžou pomoct zmírnit problém s hlučným sousedem. Tento přístup zvažte, pokud jste zjistili, že většina zatížení provozu vaší aplikace Kubernetes je způsobená konkrétními komponentami, které můžete nasadit samostatně pro každého tenanta. Například vaše databáze můžou absorbovat většinu zatížení systému, protože zatížení dotazu je vysoké. Pokud jeden tenant odešle do vašeho řešení velký počet požadavků, může to mít negativní vliv na výkon databáze, ale databáze ostatních tenantů (a sdílené komponenty, jako je aplikační vrstva), zůstanou nedotčené.

Rizika:

  • S horizontálně děleným nasazením stále potřebujete zvážit automatizované nasazení a správu komponent, zejména komponenty používané jedním tenantem.
  • Tento model nemusí poskytovat požadovanou úroveň izolace pro zákazníky, kteří si nemůžou dovolit sdílet prostředky s jinými tenanty, z důvodů interních zásad nebo dodržování předpisů.

Vertikálně dělené nasazení

Výhody jednoklientských a plně víceklientských modelů můžete využít pomocí hybridního modelu, který vertikálně rozděluje tenanty napříč několika clustery AKS nebo fondy uzlů. Tento přístup nabízí následující výhody oproti předchozím dvěma modelům tenantů:

  • Můžete použít kombinaci nasazení s jedním tenantem a více tenanty. Můžete mít například většinu zákazníků, kteří sdílejí cluster a databázi AKS v infrastruktuře s více tenanty. Přesto můžete také nasadit infrastruktury s jedním tenantem pro ty zákazníky, kteří vyžadují vyšší výkon a izolaci.
  • Tenanty můžete nasadit do několika regionálních clusterů AKS, potenciálně s různými konfiguracemi. Tato technika je nejúčinnější, pokud máte tenanty rozložené mezi různé geografické oblasti.

Můžete implementovat různé varianty tohoto modelu tenantů. Můžete se například rozhodnout nabídnout víceklientové řešení s různými úrovněmi funkcí za jiné náklady. Váš cenový model může poskytovat více cenových úrovní, z nichž každá poskytuje přírůstkovou úroveň výkonu a izolace z hlediska sdílení prostředků, výkonu, sítě a oddělení dat. Zvažte následující úrovně:

  • Úroveň Basic: Žádosti o tenanta obsluhují jedna víceklientská aplikace Kubernetes, která je sdílená s jinými tenanty. Data jsou uložená v jedné nebo více databázích, které sdílí všechny tenanty úrovně Basic.
  • Úroveň Standard: Požadavky tenantů obsluhují vyhrazená aplikace Kubernetes, která běží v samostatném oboru názvů, která poskytuje hranice izolace z hlediska zabezpečení, sítě, spotřeby prostředků. Všechny aplikace tenantů, jedna pro každého tenanta, sdílejí stejný cluster AKS a fond uzlů s ostatními zákazníky úrovně Standard.
  • Úroveň Premium: Aplikace tenanta běží ve vyhrazeném fondu uzlů nebo v clusteru AKS, která zaručuje vyšší smlouvu o úrovni služeb, lepší výkon a vyšší stupeň izolace. Tato úroveň může poskytovat flexibilní nákladový model na základě počtu a skladové položky uzlů agenta, které se používají k hostování aplikace tenanta. Sandboxing podů můžete použít jako alternativní řešení k izolaci jedinečných úloh tenantů pomocí vyhrazených clusterů nebo fondů uzlů.

Následující diagram znázorňuje scénář, ve kterém tenanti A a B běží ve sdíleném clusteru AKS, zatímco tenant C běží na samostatném clusteru AKS.

Diagram znázorňující tři tenanty Tenanti A a B sdílejí cluster AKS. Tenant C má vyhrazený cluster AKS.

Podobně následující diagram znázorňuje scénář, ve kterém tenanti A a B běží ve stejném fondu uzlů, zatímco tenant C běží ve vyhrazeném fondu uzlů.

Diagram znázorňující tři tenanty Tenanti A a B sdílejí fond uzlů. Tenant C má vyhrazený fond uzlů.

Tento model může také nabízet různé smlouvy o úrovni služeb pro různé úrovně. Úroveň Basic může například nabízet 99,9% dostupnost, úroveň Standard může nabízet 99,95% dostupnost a úroveň Premium může nabízet 99,99 %. Vyšší smlouvu o úrovni služeb (SLA) je možné implementovat pomocí služeb a funkcí, které umožňují vyšší cíle dostupnosti.

Výhody:

  • Vzhledem k tomu, že stále sdílíte infrastrukturu, můžete stále získat některé z výhod nákladů při sdílení víceklientských nasazení. Můžete nasadit clustery a fondy uzlů, které jsou sdílené napříč několika aplikacemi tenantů úrovně Basic a Standard, které pro uzly agentů používají levnější velikost virtuálního počítače. Tento přístup zaručuje lepší hustotu a úsporu nákladů. Pro zákazníky úrovně Premium můžete nasadit clustery a fondy uzlů AKS s vyšší velikostí virtuálního počítače a maximálním počtem replik podů a uzlů za vyšší cenu.
  • Systémové služby, jako je CoreDNS, Konnectivity nebo kontroler příchozího přenosu dat brány Aplikace Azure, můžete spouštět ve vyhrazeném fondu uzlů v režimu systému. Ke spuštění aplikace tenanta v jednom nebo několika fondech uzlů v uživatelském režimu můžete použít tainty, tolerance, popisky uzlů, selektory uzlů a spřažení uzlů.
  • Ke spouštění sdílených prostředků můžete použít tainty, tolerance, popisky uzlů, selektory uzlů a spřažení uzlů. Můžete mít například kontroler příchozího přenosu dat nebo systém zasílání zpráv ve vyhrazeném fondu uzlů s konkrétní velikostí virtuálního počítače, nastavením automatického škálování a podporou zón dostupnosti.

Rizika:

  • Potřebujete navrhnout aplikaci Kubernetes tak, aby podporovala nasazení s více tenanty i jednoklienty.
  • Pokud plánujete povolit migraci mezi infrastrukturami, musíte zvážit, jak migrovat zákazníky z víceklientského nasazení do vlastního nasazení s jedním tenantem.
  • Ke sledování a správě více clusterů AKS potřebujete konzistentní strategii a jedno podokno skla (jedno zobrazení).

Automatické škálování

Pokud chcete udržet krok s poptávkou po provozu, kterou generují aplikace tenantů, můžete povolit automatické škálování clusteru, aby škáloval uzly agentů služby Azure Kubernetes Service (AKS). Automatické škálování pomáhá systémům reagovat za následujících okolností:

  • Zatížení provozu se zvyšuje během konkrétních pracovních hodin nebo období v roce.
  • Tenant nebo sdílené velké zatížení se nasadí do clusteru.
  • Uzly agenta přestanou být dostupné kvůli zónovým výpadkům.

Když povolíte automatické škálování pro fond uzlů, zadáte minimální a maximální počet uzlů na základě očekávaných velikostí úloh. Konfigurací maximálního počtu uzlů můžete zajistit dostatek místa pro všechny pody tenantů v clusteru bez ohledu na obor názvů, ve kterých běží.

Když se provoz zvýší, automatické škálování clusteru přidá nové uzly agentů, aby pody nepřestály do čekajícího stavu, a to kvůli nedostatku prostředků z hlediska procesoru a paměti.

Podobně když se zatížení sníží, automatické škálování clusteru sníží počet uzlů agentů ve fondu uzlů na základě zadaných hranic, což pomáhá snížit provozní náklady.

Automatické škálování podů můžete použít k automatickému škálování podů na základě požadavků na prostředky. Horizontální automatické škálování podů (HPA) automaticky škáluje počet replik podů na základě využití procesoru nebo paměti nebo vlastních metrik. Díky automatickému škálování řízenému událostmi Kubernetes (KEDA) můžete řídit škálování libovolného kontejneru v Kubernetes na základě počtu událostí externích systémů, jako jsou Azure Event Hubs nebo Azure Service Bus, které používají aplikace tenantů.

Údržba

Pokud chcete snížit riziko výpadků, které můžou mít vliv na aplikace tenantů během upgradů clusteru nebo fondu uzlů, naplánujte plánovanou údržbu AKS během mimo špičku. Plánovaná údržba umožňuje naplánovat týdenní časové intervaly údržby, které aktualizují řídicí rovinu clusterů AKS, které spouštějí klientské aplikace a fondy uzlů, což minimalizuje dopad úloh. V clusteru můžete naplánovat jedno nebo více týdenních časových intervalů údržby zadáním dne nebo časového rozsahu v konkrétním dni. Všechny operace údržby budou probíhat během plánovaných časových období.

Zabezpečení

Přístup ke clusteru

Když sdílíte cluster AKS mezi několika týmy v rámci organizace, musíte implementovat princip nejnižších oprávnění k izolaci různých tenantů od sebe. Konkrétně je potřeba zajistit, aby uživatelé měli přístup pouze ke svým oborům názvů a prostředkům Kubernetes při používání nástrojů, jako jsou kubectl, Helm, Flux, Argo CD nebo jiné typy nástrojů.

Další informace o ověřování a autorizaci v AKS najdete v následujících článcích:

Identita úloh

Pokud hostujete více klientských aplikací v jednom clusteru AKS a každý je v samostatném oboru názvů, každá úloha by měla pro přístup ke podřízeným službám Azure použít jiný účet služby Kubernetes a přihlašovací údaje. Účty služeb jsou jedním z primárních typů uživatelů v Kubernetes. Rozhraní API Kubernetes uchovává a spravuje účty služeb. Přihlašovací údaje účtu služby se ukládají jako tajné kódy Kubernetes, které umožňují jejich použití autorizovanými pody ke komunikaci se serverem API. Většina požadavků rozhraní API poskytuje ověřovací token pro účet služby nebo běžný uživatelský účet.

Úlohy tenantů nasazené do clusterů AKS můžou používat přihlašovací údaje aplikace Microsoft Entra pro přístup k prostředkům chráněným ID Microsoftu, jako je Azure Key Vault a Microsoft Graph. ID úloh Microsoft Entra pro Kubernetes se integruje s nativními možnostmi Kubernetes pro federaci se všemi externími zprostředkovateli identit.

Sandboxing podů

AKS obsahuje mechanismus označovaný jako sandbox podů , který poskytuje hranici izolace mezi aplikací kontejneru a sdíleným jádrem a výpočetními prostředky hostitele kontejneru, jako jsou procesor, paměť a sítě. Sandboxing podů doplňuje další bezpečnostní opatření nebo kontroly ochrany dat, které pomáhají úlohám tenantů zabezpečit citlivé informace a splnit zákonné, oborové nebo zásady správného řízení, jako jsou standard PCI DSS (Payment Card Industry Data Security Standard), Mezinárodní organizace pro standardizaci (ISO) 27001 a zákon o přenositelnosti a odpovědnosti za zdravotní pojištění (HIPAA).

Nasazení aplikací do samostatných clusterů nebo fondů uzlů umožňuje silně izolovat úlohy tenantů různých týmů nebo zákazníků. Použití několika clusterů a fondů uzlů může být vhodné pro požadavky na izolaci mnoha organizací a řešení SaaS, ale existují scénáře, ve kterých je jeden cluster se sdílenými fondy uzlů virtuálních počítačů efektivnější, například při spouštění nedůvěryhodných a důvěryhodných podů na stejném uzlu nebo společné umístění démonů a privilegovaných kontejnerů na stejném uzlu pro rychlejší místní komunikaci a funkční seskupení. Sandboxing podů vám může pomoct výrazně izolovat aplikace tenantů na stejných uzlech clusteru, aniž byste je museli spouštět v samostatných clusterech nebo fondech uzlů. Jiné metody vyžadují, abyste kód znovu zkompilovali nebo způsobili jiné problémy s kompatibilitou, ale sandboxování podů v AKS může spustit jakýkoli kontejner beze změny uvnitř hranice rozšířeného zabezpečení virtuálního počítače.

Sandboxing podů v AKS je založený na kontejnerech Kata, které běží na hostiteli kontejnerů Azure s Linuxem pro zásobník AKS , aby se zajistila izolace vynucená hardwarem. Kata Containers v AKS jsou postavené na hypervisoru Azure posíleného zabezpečením. Izolace na pod se dosahuje prostřednictvím vnořeného zjednodušeného virtuálního počítače Kata, který využívá prostředky z nadřazeného uzlu virtuálního počítače. V tomto modelu získá každý pod Kata vlastní jádro ve vnořeném virtuálním počítači hosta Kata. Tento model umožňuje umístit mnoho kontejnerů Kata do jednoho hostovaného virtuálního počítače a zároveň dál spouštět kontejnery v nadřazené virtuálním počítači. Model poskytuje silnou hranici izolace ve sdíleném clusteru AKS.

Další informace naleznete v tématu:

Azure Dedicated Host

Azure Dedicated Host je služba, která poskytuje fyzické servery vyhrazené pro jedno předplatné Azure a poskytuje izolaci hardwaru na úrovni fyzického serveru. Tyto vyhrazené hostitele je možné zřídit v rámci oblasti, zóny dostupnosti a domény selhání a virtuální počítače můžete umístit přímo do zřízených hostitelů.

Pomocí služby Azure Dedicated Host s AKS můžete dosáhnout několika výhod, včetně následujících:

  • Izolace hardwaru zajišťuje, že na vyhrazených hostitelích nejsou umístěné žádné jiné virtuální počítače, což poskytuje další vrstvu izolace pro úlohy tenanta. Vyhrazené hostitele se nasazují ve stejných datacentrech a sdílejí stejnou síťovou a základní infrastrukturu úložiště jako ostatní neizolované hostitele.

  • Azure Dedicated Host poskytuje kontrolu nad událostmi údržby iniciované platformou Azure. Můžete zvolit časové období údržby, abyste snížili dopad na služby a pomohli zajistit dostupnost a ochranu osobních údajů úloh tenanta.

Azure Dedicated Host může poskytovatelům SaaS pomoct zajistit, aby aplikace tenantů splňovaly zákonné, oborové a zásady správného řízení požadavky na dodržování předpisů pro zabezpečení citlivých informací. Další informace najdete v tématu Přidání vyhrazeného hostitele Azure do clusteru Azure Kubernetes Service (AKS).

Důvěrné virtuální počítače

Pomocí důvěrných virtuálních počítačů (CVM) můžete do clusteru AKS přidat jeden nebo více fondů uzlů, abyste vyřešili striktní izolaci, ochranu osobních údajů a požadavky na zabezpečení tenantů. CvM používají hardwarové důvěryhodné spouštěcí prostředí (TEE). Amd Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) důvěrné virtuální počítače zakazují hypervisor a další kód pro správu hostitele přístup k paměti a stavu virtuálního počítače a přidává vrstvu hloubkové ochrany před přístupem operátora. Další informace najdete v tématu Použití CVMs v clusteru AKS.

Federal Information Process Standards (FIPS)

FIPS 140-3 je standard státní správy USA, který definuje minimální požadavky na zabezpečení kryptografických modulů v produktech a systémech informačních technologií. Povolením dodržování předpisů FIPS pro fondy uzlů AKS můžete vylepšit izolaci, ochranu osobních údajů a zabezpečení úloh tenanta. Dodržování předpisů FIPS zajišťuje použití ověřených kryptografických modulů pro šifrování, hashování a další operace související se zabezpečením. S fondy uzlů AKS s podporou FIPS můžete splňovat zákonné a oborové požadavky na dodržování předpisů pomocí robustních kryptografických algoritmů a mechanismů. Azure poskytuje dokumentaci k povolení FIPS pro fondy uzlů AKS a umožňuje posílit stav zabezpečení víceklientských prostředí AKS. Další informace naleznete v tématu Povolení FIPS pro fondy uzlů AKS.

Používání vlastních klíčů (BYOK) s disky Azure

Azure Storage šifruje všechna neaktivní uložená data v účtu úložiště, včetně disků s operačním systémem a datových disků clusteru AKS. Ve výchozím nastavení se data šifrují pomocí klíčů spravovaných Microsoftem. Pokud chcete mít větší kontrolu nad šifrovacími klíči, můžete zadat klíče spravované zákazníkem, které se použijí pro šifrování ve zbytku operačního systému a datových disků clusterů AKS. Další informace naleznete v tématu:

Šifrování na základě hostitele

Šifrování na základě hostitele v AKS dále posiluje izolaci úloh tenanta, ochranu osobních údajů a zabezpečení. Když povolíte šifrování založené na hostiteli, AKS šifruje neaktivní uložená data na podkladových hostitelských počítačích, což pomáhá zajistit ochranu citlivých informací tenanta před neoprávněným přístupem. Dočasné disky a dočasné disky s operačním systémem se při povolování kompletního šifrování šifrují pomocí klíčů spravovaných platformou.

V AKS používají operační disky a datové disky ve výchozím nastavení šifrování na straně serveru s klíči spravovanými platformou. Mezipaměti pro tyto disky se šifrují v klidovém stavu pomocí klíčů spravovaných platformou. Můžete zadat vlastní šifrovací klíč klíče (KEK) k šifrování klíče ochrany dat (DEK) pomocí šifrování obálky, označovaného také jako zabalení. Mezipaměť pro disky s operačním systémem a datovými disky se také šifruje prostřednictvím funkce BYOK , kterou zadáte.

Šifrování na základě hostitele přidává vrstvu zabezpečení pro víceklientská prostředí. Data každého tenanta v mezipaměti operačního systému a datových disků se šifrují v klidovém stavu pomocí klíčů spravovaných zákazníkem nebo spravovaných platformou v závislosti na vybraném typu šifrování disku. Další informace naleznete v tématu:

Sítě

Omezení síťového přístupu k serveru rozhraní API

V Kubernetes server rozhraní API přijímá požadavky na provádění akcí v clusteru, jako je vytváření prostředků nebo škálování počtu uzlů. Při sdílení clusteru AKS napříč několika týmy v organizaci můžete chránit přístup k řídicí rovině pomocí jednoho z následujících řešení.

Privátní clustery AKS

Pomocí privátního clusteru AKS můžete zajistit, aby síťový provoz mezi vaším serverem rozhraní API a fondy uzlů zůstal ve vaší virtuální síti. V privátním clusteru AKS má řídicí rovina nebo server rozhraní API interní IP adresu, která je přístupná pouze prostřednictvím privátního koncového bodu Azure, který se nachází ve stejné virtuální síti clusteru AKS. Podobně může každý virtuální počítač ve stejné virtuální síti soukromě komunikovat s řídicí rovinou prostřednictvím privátního koncového bodu. Další informace najdete v tématu Vytvoření privátního clusteru Azure Kubernetes Service.

Autorizované IP adresy

Druhou možností, jak zlepšit zabezpečení clusteru a minimalizovat útoky, je použití autorizovaných IP adres. Tento přístup omezuje přístup k řídicí rovině veřejného clusteru AKS na dobře známý seznam IP adres (Internet Protocol) a ciDR (Classless Inter-Domain Routing). Když používáte autorizované IP adresy, jsou stále veřejně přístupné, ale přístup je omezený na sadu rozsahů IP adres. Další informace najdete v tématu Zabezpečení přístupu k serveru rozhraní API pomocí autorizovaných rozsahů IP adres ve službě Azure Kubernetes Service (AKS).

Azure Private Link Service (PLS) je komponenta infrastruktury, která umožňuje aplikacím privátní připojení ke službě prostřednictvím privátního koncového bodu Azure (PE), který je definovaný ve virtuální síti a připojený ke konfiguraci front-endové IP adresy instance Azure Load Balanceru (ALB). Poskytovatelé služeb Azure Private Link můžou bezpečně poskytovat své služby svým tenantům, kteří se můžou připojit z Azure nebo z místního prostředí bez rizik exfiltrace dat.

Integraci služby Azure Private Link můžete použít k zajištění privátního připojení tenantů k úlohám hostovaným v AKS zabezpečeným způsobem, aniž byste museli zveřejnit jakýkoli veřejný koncový bod na veřejném internetu.

Obecné pokyny ke konfiguraci služby Private Link pro víceklientské řešení hostované v Azure najdete v tématu Víceklientská architektura a Azure Private Link.

Reverzní proxy servery

Reverzní proxy server je nástroj pro vyrovnávání zatížení a brána rozhraní API, která se obvykle používá před aplikacemi tenanta k zabezpečení, filtrování a odesílání příchozích požadavků. Oblíbené reverzní proxy servery podporují funkce, jako je vyrovnávání zatížení, ukončení protokolu SSL a směrování vrstvy 7. Reverzní proxy servery se obvykle implementují, aby pomohly zvýšit zabezpečení, výkon a spolehlivost. Mezi oblíbené reverzní proxy servery pro Kubernetes patří následující implementace:

  • Kontroler příchozího přenosu dat NGINX je oblíbený reverzní proxy server, který podporuje pokročilé funkce, jako je vyrovnávání zatížení, ukončení protokolu SSL a směrování vrstvy 7.
  • Traefik Poskytovatel příchozího přenosu dat Kubernetes je kontroler příchozího přenosu dat Kubernetes, který lze použít ke správě přístupu ke službám clusteru pomocí specifikace příchozího přenosu dat.
  • Kontroler příchozího přenosu dat HAProxy Kubernetes je ještě dalším reverzním proxy serverem pro Kubernetes, který podporuje standardní funkce, jako je ukončení protokolu TLS, směrování založené na cestě URL a další.
  • Aplikace Azure kontroleru příchozího přenosu dat brány (AGIC) je aplikace Kubernetes, která zákazníkům Azure Kubernetes Service (AKS) umožňuje využívat nativní nástroj pro vyrovnávání zatížení služby Application Gateway L7 azure k zveřejnění klientských aplikací veřejnému internetu nebo interně jiným systémům, které běží ve virtuální síti.

Při použití reverzního proxy serveru hostovaného v AKS k zabezpečení a zpracování příchozích požadavků do více aplikací tenantů zvažte následující doporučení:

  • Hostujte reverzní proxy server ve vyhrazeném fondu uzlů, který je nakonfigurovaný tak, aby používal velikost virtuálního počítače s velkou šířkou pásma sítě a povolenými akcelerovanými síťovými službami .
  • Nakonfigurujte fond uzlů, který je hostitelem reverzního proxy serveru pro automatické škálování.
  • Pokud se chcete vyhnout zvýšené latenci a vypršení časových limitů pro aplikace tenanta, definujte zásadu automatického škálování, aby počet podů kontroleru příchozího přenosu dat mohl okamžitě rozšířit a uzavřít kontrakt tak, aby odpovídal kolísání provozu.
  • Zvažte horizontální dělení příchozího provozu do aplikací tenanta napříč několika instancemi kontroleru příchozího přenosu dat, abyste zvýšili úroveň škálovatelnosti a oddělení.

Při použití kontroleru příchozího přenosu dat brány Aplikace Azure (AGIC) zvažte implementaci následujících osvědčených postupů:

Integrace se službou Azure Front Door

Azure Front Door je globální nástroj pro vyrovnávání zatížení vrstvy 7 a moderní cloudová síť pro doručování obsahu (CDN) Od Microsoftu, která poskytuje rychlý, spolehlivý a zabezpečený přístup mezi uživateli a webovými aplikacemi po celém světě. Azure Front Door podporuje funkce, jako je akcelerace požadavků, ukončení protokolu SSL, ukládání odpovědí do mezipaměti, WAF na hraničních zařízeních, směrování založené na adrese URL, přepsání a přesměrování, které můžete využít při zveřejnění víceklientských aplikací hostovaných ve službě AKS na veřejném internetu.

Můžete například chtít použít víceklientovou aplikaci hostované službou AKS k poskytování všech požadavků zákazníků. V tomto kontextu můžete pomocí služby Azure Front Door spravovat více vlastních domén, jednu pro každého tenanta. Připojení SSL můžete ukončit na hraničním zařízení a směrovat veškerý provoz do víceklientské aplikace AKS, která je nakonfigurovaná s jedním názvem hostitele.

Diagram znázorňuje, jak se Azure Front Door a AKS připojují.

Azure Front Door můžete nakonfigurovat tak, aby upravil hlavičku hostitele původu požadavku tak, aby odpovídala názvu domény back-endové aplikace. Původní Host hlavička odeslaná klientem se rozšíří prostřednictvím X-Forwarded-Host hlavičky a kód víceklientská aplikace může pomocí těchto informací namapovat příchozí požadavek na správného tenanta.

Azure Web Application Firewall (WAF) ve službě Azure Front Door poskytuje centralizovanou ochranu webových aplikací. Azure WAF můžete použít k ochraně aplikací tenanta hostovaných službou AKS, které zpřístupňují veřejný koncový bod na internetu před škodlivými útoky.

Službu Azure Front Door Premium můžete nakonfigurovat tak, aby se soukromě připojila k jedné nebo více aplikacím tenantů, které běží v clusteru AKS prostřednictvím interního zdroje nástroje pro vyrovnávání zatížení, pomocí služby Azure Private Link. Další informace najdete v tématu Připojení Azure Front Door Premium k internímu zdroji nástroje pro vyrovnávání zatížení pomocí služby Private Link.

Odchozí připojení

Když se aplikace hostované službou AKS připojují k velkému počtu databází nebo externích služeb, může být cluster ohrožen vyčerpáním portů SNAT. Porty SNAT generují jedinečné identifikátory, které se používají k udržování jedinečných toků inicializovány aplikacemi, které běží na stejné sadě výpočetních prostředků. Spuštěním několika aplikací tenanta ve sdíleném clusteru Azure Kubernetes Service můžete provádět velký počet odchozích volání, což může vést k vyčerpání portů SNAT. Cluster AKS dokáže zpracovat odchozí připojení třemi různými způsoby:

  • Veřejný nástroj pro vyrovnávání zatížení Azure: Ve výchozím nastavení AKS zřídí Load Balancer úrovně Standard, který se má nastavit a používat pro odchozí připojení. Výchozí nastavení však nemusí splňovat požadavky všech scénářů, pokud jsou veřejné IP adresy zakázány nebo pokud jsou pro výchozí přenos dat vyžadovány další segmenty směrování. Ve výchozím nastavení se veřejný Load Balancer vytvoří s výchozí veřejnou IP adresou, kterou používají pravidla odchozích přenosů. Odchozí pravidla umožňují explicitně definovat překlad zdrojových síťových adres (SNAT) pro veřejný load balancer úrovně Standard. Tato konfigurace umožňuje používat veřejné IP adresy vašeho nástroje pro vyrovnávání zatížení k poskytování odchozího připojení k internetu pro vaše back-endové instance. Pokud je to potřeba, abyste se vyhnuli vyčerpání portů SNAT, můžete nakonfigurovat pravidla odchozích přenosů veřejného nástroje pro vyrovnávání zatížení tak, aby používala další veřejné IP adresy. Další informace najdete v tématu Použití front-endové IP adresy nástroje pro vyrovnávání zatížení pro odchozí komunikaci prostřednictvím odchozích pravidel.
  • Azure NAT Gateway: Cluster AKS můžete nakonfigurovat tak, aby pomocí služby Azure NAT Gateway směrovali odchozí provoz z klientských aplikací. NAT Gateway umožňuje až 64 512 odchozích toků UDP a TCP na veřejnou IP adresu s maximálně 16 IP adresami. Abyste se vyhnuli riziku vyčerpání portů SNAT při použití služby NAT Gateway ke zpracování odchozích připojení z clusteru AKS, můžete k bráně přidružit více veřejných IP adres nebo předponu veřejné IP adresy. Další informace najdete v tématu Důležité informace o službě Azure NAT Gateway pro víceklientské prostředí.
  • Trasa definovaná uživatelem: Výchozí trasu clusteru AKS můžete přizpůsobit tak, aby podporovala vlastní síťové scénáře, například ty, které nepovolují veřejné IP adresy a vyžadují, aby cluster zůstal za síťovým virtuálním zařízením. Když nakonfigurujete cluster pro směrování definované uživatelem, AKS automaticky nenakonfiguruje cesty výchozího přenosu dat. Nastavení výchozího přenosu dat musíte provést vy. Směrujete například odchozí provoz přes bránu Azure Firewall. Cluster AKS musí být nasazený do existující virtuální sítě s podsítí, která byla dříve nakonfigurovaná. Pokud nepoužíváte architekturu SLB (Standard Load Balancer), musíte vytvořit explicitní výchozí přenos dat. Tato architektura proto vyžaduje explicitní odesílání odchozího provozu do zařízení, jako je brána firewall, brána nebo proxy server. Nebo architektura umožňuje překlad síťových adres (NAT) veřejnou IP adresou, která je přiřazená standardnímu nástroji pro vyrovnávání zatížení nebo zařízením.

Sledování

Azure Monitor a kontejnerové Přehledy můžete použít k monitorování aplikací tenantů spuštěných ve sdíleném clusteru AKS a k výpočtu rozpisu nákladů v jednotlivých oborech názvů. Azure Monitor umožňuje monitorovat stav a výkon služby Azure Kubernetes Service (AKS). Zahrnuje shromažďování protokolů a metrik, analýzy telemetrie a vizualizací shromážděných dat za účelem identifikace trendů a konfigurace výstrah pro proaktivně upozorňování na kritické problémy. Službu Container Insights můžete povolit k rozšíření tohoto monitorování.

Můžete také přijmout opensourcové nástroje, jako jsou Prometheus a Grafana, které komunita běžně používá pro monitorování Kubernetes. Nebo můžete přijmout další nástroje třetích stran pro monitorování a pozorovatelnost.

Náklady

Zásady správného řízení nákladů jsou průběžným procesem implementace zásad pro řízení nákladů. V kontextu Kubernetes existuje několik způsobů, jak můžou organizace řídit a optimalizovat náklady. Patří sem nativní nástroje Kubernetes pro správu a řízení využití a spotřeby prostředků a k proaktivnímu monitorování a optimalizaci základní infrastruktury. Při výpočtu nákladů na tenanta byste měli zvážit náklady spojené s jakýmkoli prostředkem používaným aplikací tenanta. Postup, který budete postupovat při účtování poplatků zpět tenantům, závisí na modelu tenantů, který vaše řešení přijalo. Další podrobnosti jsou vysvětleny pomocí následujících modelů tenantů:

  • Plně víceklientská aplikace: Pokud jedna, víceklientská aplikace obsluhuje všechny požadavky tenanta, je vaší zodpovědností sledovat spotřebu prostředků a počet požadavků vygenerovaných jednotlivými tenanty. Zákazníky pak naúčtujete odpovídajícím způsobem.
  • Vyhrazený cluster: Pokud je cluster vyhrazený pro jednoho tenanta, je snadné účtovat náklady na prostředky Azure zpět zákazníkovi. Celkové náklady na vlastnictví závisí na mnoha faktorech, mezi které patří počet a velikost virtuálních počítačů, náklady na síť kvůli síťovému provozu, veřejným IP adresám, nástrojům pro vyrovnávání zatížení, službám úložiště, jako jsou spravované disky nebo soubory Azure používané řešením tenanta atd. Cluster AKS a jeho prostředky můžete označit ve skupině prostředků uzlu, abyste usnadnili operace účtování nákladů. Další informace najdete v tématu Přidání značek do clusteru.
  • Vyhrazený fond uzlů: Značku Azure můžete použít na nový nebo existující fond uzlů vyhrazený pro jednoho tenanta. Značky použité u fondu uzlů se použijí na každý uzel ve fondu uzlů a jsou trvalé prostřednictvím upgradů. Značky se také použijí na nové uzly přidané do fondu uzlů během operací horizontálního navýšení kapacity. Přidání značky může pomoct s úkoly, jako je sledování zásad nebo účtování nákladů. Další informace naleznete v tématu Přidání značek do fondů uzlů.
  • Další prostředky: Značky můžete použít k přidružení nákladů na vyhrazené prostředky k danému tenantovi. Konkrétně můžete označit veřejné IP adresy, soubory a disky pomocí manifestu Kubernetes. Značky nastavené tímto způsobem budou udržovat hodnoty Kubernetes, i když je později aktualizujete pomocí jiné metody. Když se prostřednictvím Kubernetes odeberou veřejné IP adresy, soubory nebo disky, odeberou se všechny značky nastavené Kubernetes. Značky na těchto prostředcích, které Kubernetes nesledují, zůstávají nedotčené. Další informace najdete v tématu Přidání značek pomocí Kubernetes.

K monitorování a řízení nákladů na cluster AKS můžete použít opensourcové nástroje, jako je KubeCost. Přidělení nákladů se dá vymezit na nasazení, službu, popisek, pod a obor názvů, což vám poskytne flexibilitu v tom, jak vyúčtujete nebo zobrazíte uživatele clusteru. Další informace najdete v tématu Zásady správného řízení nákladů pomocí Kubecost.

Další informace o měření, přidělování a optimalizaci nákladů pro víceklientské aplikace najdete v tématu Přístupy architektury pro správu nákladů a přidělování ve víceklientských řešeních. Obecné pokyny k optimalizaci nákladů najdete v článku o architektuře Azure, přehled pilíře optimalizace nákladů.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

  • Paul Salvatori | Hlavní zákaznický inženýr, FastTrack pro Azure

Další přispěvatelé:

Další kroky

Projděte si materiály pro architekty a vývojáře víceklientských řešení.