Koncepty: Víceklientská architektura v Azure Kubernetes Service (AKS)

Při odpovídání na otázku "Jak nakonfigurovat Kubernetes pro víceklientské architektury?", architekti musí nejprve porozumět koncepčním hranicím a dostupným modelům izolace. Víceklientská architektura v AKS je praxe spouštění více izolovaných úloh, které patří různým týmům, aplikacím nebo zákazníkům, ve sdíleném clusteru Kubernetes. Tento článek podrobně popisuje základní koncepty a modely architektury pro víceklientské architektury na Azure Kubernetes Service (AKS).

Tip

Jaké jsou tři modely s více tenanty v AKS? Víceklientské prostředí AKS využívá spektrum možností izolace se třemi běžnými modely: izolace oboru názvů, izolace fondu uzlů a samostatný cluster pro každého tenanta. Izolace jmenného prostoru je nejvhodnější pro důvěryhodné interní týmy a maximální nákladovou efektivitu, izolace na úrovni fondu uzlů poskytuje silnější oddělení pracovních zátěží při středních režijních nákladech a samostatný cluster pro každého tenanta poskytuje nejsilnější izolaci pro nedůvěryhodné nebo vysoce regulované scénáře.

Podrobné pokyny k implementaci a manifesty YAML najdete v doprovodné příručce: Osvědčené postupy pro víceklientské architektury v AKS.

Proč multitenance v AKS?

Víceklientská architektura umožňuje více týmům, aplikacím nebo zákazníkům sdílet jeden cluster Kubernetes. Primárním důvodem víceklientské architektury v AKS je nákladová efektivita a provozní škálování.

Provozování vyhrazeného clusteru pro každou aplikaci či tým vede ke značné fragmentaci prostředků, nevyužité výpočetní kapacitě a násobení režie řídicí roviny. Sloučením úloh do clusterů s více tenanty maximalizují organizace využití prostředků a snižují útratu v cloudu. Provozně víceklientská architektura zmenšuje velikost vozového parku, což znamená, že týmy platforem mají méně clusterů pro opravy, upgrade, monitorování a zabezpečení, a tím zjednodušují správu životního cyklu.

Jaký je rozdíl mezi měkkou a tvrdou víceklientskou architekturou?

Kubernetes není ze své podstaty systém s více tenanty. Chcete-li dosáhnout modelu více tenantů, musíte navrhnout řešení podle buď „měkkého“, nebo „tvrdého“ modelu izolace v závislosti na úrovni důvěry mezi tenanty.

Rozdíl mezi měkkým a tvrdým multitenantním modelem v Kubernetes spočívá především v modelu důvěry a z něj vyplývajících požadavcích na izolaci. Měkký multitenantní model předpokládá důvěryhodné interní tenanty a zaměřuje se na předcházení nechtěnému vzájemnému ovlivňování prostřednictvím logických mechanismů, jako jsou jmenné prostory, RBAC a kvóty. Striktní model více tenantů předpokládá nízkou nebo nulovou důvěru mezi tenanty a vyžaduje silnější mechanismy izolace, aby se snížilo riziko neoprávněného přístupu, laterálního pohybu a úniku dat.

Model	Úroveň důvěryhodnosti	Goal	Případ použití	Ukázkové scénáře
Měkká víceklientská architektura	Vysoká míra důvěry mezi interními tenanty	Zabraňte neúmyslnému narušení, hladovění prostředků a kolizím konfigurace	Interní prostředí platformy, kde týmy sdílejí infrastrukturu	Několik produktových týmů v jedné organizaci sdílejí cluster AKS pro vývoj/testování a interní služby
Striktní víceklientský model	Nízký nebo nulový vztah důvěryhodnosti mezi tenanty	Prevence škodlivých útoků, laterálního pohybu a exfiltrace dat	Hostování externích zákazníků a regulovaných úloh	Poskytovatel SaaS hostující úlohy specifické pro zákazníky, u kterých je izolace tenanta požadavkem na zabezpečení a dodržování předpisů

Spektrum izolace

Multitenance v AKS není binární volba; pohybuje se na škále. Při procházení napříč spektrem se zvyšuje izolace, ale stejně tak se zvyšuje provozní složitost a náklady. Toto spektrum tvoří základní rámec pro návrh víceklientského clusteru:

• Izolace jmenného prostoru (logická): Nájemci sdílejí stejné fondy uzlů a řídicí rovinu, ale jsou logicky odděleni pomocí jmenných prostorů Kubernetes. Toto je základ měkké multiklientské architektury.
• Izolace fondu uzlů (fyzický výpočetní výkon): Klienti sdílejí řídicí rovinu, ale jsou jim přiřazeny vyhrazené pracovní uzly. To zlepšuje oddělení úloh a zmírnění efektu hlučného souseda, ale nejde o úplnou izolaci tenanta, protože řídicí rovina a komponenty na úrovni clusteru jsou stále sdílené.
• Jeden cluster na tenanta (zcela fyzický): Tenanti jsou zcela izolováni a mají vlastní řídicí rovinu AKS i datovou rovinu. Jedná se o konečnou formu tvrdé víceklientské architektury, která efektivně obchází sdílení na úrovni Kubernetes ve prospěch izolace na úrovni Azure.

Základní prvky AKS pro multitenanci

AKS poskytuje sadu nativních primitiv a primitiv integrovaných se službou Azure pro zajištění různých úrovní izolace.

• Microsoft Entra ID: Poskytuje centralizovanou správu identit a přístupu pro ověřování uživatelů a automatizovaných systémů v rozhraní Kubernetes API.
• Azure RBAC: Mapuje identity Microsoft Entra ID na oprávnění v Kubernetes a zajišťuje, aby tenanti měli přístup pouze k prostředkům, k nimž mají oprávnění.
• Spravované obory názvů: Poskytují logické hranice v rámci clusteru pro seskupování prostředků tenanta, uplatnění kvót a vymezení rozsahu přístupu.
• Azure Policy / Gatekeeper: Vynucuje centralizovaná pravidla dodržování předpisů a zásad správného řízení v clusteru, aby zabránili tenantům v nasazování nezabezpečených nebo neoprávněných konfigurací.
• Azure CNI: Poskytuje nativní integraci virtuální sítě pro sítě AKS a podporuje segmentaci provozu klientů pomocí řízení zásad sítě. Chování IP adresy podu závisí na zvoleném režimu CNI (například Overlay nebo podsíť podu).
• Azure Container Networking Services (ACNS) Cilium L7: Poskytuje vysoce výkonné síťové zásady založené na eBPF a filtrování provozu na 7. vrstvě pro striktní izolaci síťového provozu tenantů.
• Identita úloh: Umožňuje jednotlivým podům bezpečně ověřovat externí Azure služby pomocí federované identity a eliminovat sdílené tajné kódy mezi tenanty.

Mapování vrstev izolace napříč rovinami

Pokud chcete vytvořit zabezpečenou architekturu s více tenanty, musíte použít primitiva AKS napříč třemi různými rovinami prostředí clusteru.

Letadlo	Description	Použití primitiv AKS
Řídicí rovina	Zabezpečení přístupu k serveru a logickým hranicím rozhraní API Kubernetes	Microsoft Entra ID, Azure RBAC, spravované obory názvů
Datová rovina	Zabezpečení síťového provozu, spouštění výpočetních prostředků a hranic na úrovni uzlů	Azure CNI, ACNS Cilium L7, Fondy uzlů
Rovina prostředků	Řízení spotřeby výpočetních prostředků, externího přístupu a dodržování předpisů konfigurace	Azure Policy, identita úloh

Který model izolace byste měli zvolit?

Pomocí následující matice určete, který bod v izolovaném spektru nejlépe vyhovuje požadavkům vaší organizace.

Model izolace	Úroveň zabezpečení	Nákladová efektivita	Provozní složitost	Nejvhodnější pro
Jmenný prostor pro každého tenanta	Nízká až střední (logická)	Vysoká (maximální sdílení)	Nízká (správa jednoho clusteru)	Interní týmy, vývojová/testovací prostředí, měkké vícenájemnictví.
Fond uzlů na tenanta	Vysoký výkon (izolované výpočetní prostředky)	Střední (sdílená řídicí rovina)	Střední (Správa taintů a tolerancí)	Interní a externí úlohy, které potřebují silnější oddělení výpočetních prostředků při sdílení řídicí roviny; není ideální pro nehostinnou tenantskou architekturu nulové důvěry.
Cluster pro každého tenanta	Nejvyšší (fyzický)	Nízká (vysoké režijní náklady)	Vysoká (vyžaduje se správa vozového parku)	Nepřátelské víceklientské prostředí, externí podnikoví zákazníci, model nulové důvěry.

Kdy použít každý model

• Použijte jeden jmenný prostor na tenanta, pokud jsou tenanti interní nebo důvěryhodní, prioritou je nákladová efektivita a logické mechanismy izolace jsou dostačující.
• Použijte fond uzlů pro každého tenanta, když potřebujete silnější oddělení výpočetních prostředků a menší dopad vzájemného ovlivňování tenantů, a současně stále sdílet jednu řídicí vrstvu AKS.
• Použijte cluster pro každého tenanta, pokud jsou tenanti nedůvěryhodní, zákonné hranice jsou striktní nebo váš rizikový model vyžaduje minimální sdílenou infrastrukturu.

Další kroky

Teď, když rozumíte koncepčním modelům a primitivům pro víceklientské prostředí, pokračujte v průvodci implementací a použijte tyto koncepty ve vašem clusteru.

• Osvědčené postupy pro víceklientské prostředí v AKS

Sečteno a podtrženo

• Víceklientská architektura ve Azure Kubernetes Service (AKS) je postup spouštění více izolovaných úloh tenantů ve sdílené infrastruktuře Kubernetes, aby se snížily náklady a zjednodušily operace.
• Model jednoho jmenného prostoru na tenanta je pro důvěryhodné interní pracovní zátěže nákladově nejúspornější, protože maximalizuje sdílení infrastruktury při zachování logického oddělení.
• Node-pool-per-tenant zlepšuje izolaci výpočetních prostředků a omezení vlivu efektu noisy neighbor, ale stále sdílí řídicí rovinu AKS a další komponenty na úrovni clusteru.
• Samostatný cluster pro každého tenanta poskytuje nejsilnější izolaci jednotlivých tenantů pro scénáře s modelem zero trust a vysoce regulovaná prostředí, ale vyžaduje vyšší náklady a vyšší provozní režii.