Upravit

Sdílet prostřednictvím

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. Vzhledem k tomu, že AKS je hostovaná služba Kubernetes, Azure zpracovává důležité úlohy, jako je monitorování stavu a údržba a řídicí rovina.

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. Termín víceklientské často popisuje všechny tyto typy sdílení. 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.

Tento článek popisuje některé funkce AKS, které můžete použít při vytváření víceklientských systémů. Obecné pokyny a osvědčené postupy pro víceklientské prostředí Kubernetes najdete v víceklientských v dokumentaci Kubernetes.

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é jsou k dispozici pro použití. Obecně platí, že víceklientská architektura vclusterch Dokumentace ke službě 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é jsou hostované ve stejném clusteru nebo běží jako služby paaS (platforma jako služba) 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 jsou kubectl. Nebo mají členové nepřímý přístup prostřednictvím kontrolerů GitOps, jako jsou 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ů.

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 více zákazníků.

Modely izolace

Podle dokumentace Kubernetesje 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, které instance jednotlivých zákazníků sdílené složky aplikací SaaS.

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ů, může jeden tým použít více než spravedlivý podíl prostředků. Správci můžou k vyřešení tohoto problému použít kvóty prostředků.

Na základě úrovně zabezpečení, kterou izolace poskytuje, můžete rozlišovat mezi soft a hard multitenancy.

  • 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 je cílem izolace zaručit integritu úloh, orchestrovat prostředky clusteru napříč různými interními skupinami uživatelů a bránit před možnými útoky na zabezpečení.
  • Tvrdá víceklientská architektura popisuje scénáře, kdy heterogenní tenanti vzájemně nedůvěřují, často z hlediska zabezpečení a sdílení prostředků.

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

  • Shluk
  • Namespace
  • Fond uzlů nebo uzel
  • Lusk
  • Kontejner

Kromě toho byste měli zvážit vliv na zabezpečení sdílení různých prostředků mezi více tenanty. Můžete například snížit počet počítačů potřebných v clusteru naplánováním podů z různých tenantů na stejném uzlu. 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 (RBAC) Kubernetes a zásady sítě . Následující diagram například znázorňuje 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í 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 Kubernetesje obor názvů abstrakce, kterou používáte k podpoře izolace skupin prostředků v jednom clusteru. Obory názvů můžete 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 organizaci 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 oborů názvů. Týmy je můžou použít k zajištění, aby úlohy, které sdílejí 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é můžou ovlivnit jiné aplikace tenanta, které sdílejí stejný cluster.
  • zásady sítě jsou objekty oboru názvů, které týmy mohou přijmout k vynucení toho, 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 tenantů, které sdílejí stejný cluster.

AKS nabízí dva způsoby implementace zásad sítě:

  • Azure má svou implementaci pro zásady sítě, označované jako zásady sítě Azure.
  • zásady sítě Calico je opensourcové řešení zabezpečení sítě a sítě založené Tigera.

Obě implementace používají linuxové iptables 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 iptables. Zásady sítě Azure můžete používat jenom s clustery AKS nakonfigurovanými s azure CNI síťovým modulem plug-in. Zásady sítě Calico však 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, jako jsou azure SQL Database a Azure Cosmos DB, a další služby úložiště, které můžete použít jako trvalých svazků pro vaše úlohy. Klientské aplikace, které běží ve sdíleném clusteru AKS, mohou sdílet databázi nebo úložiště souborůnebo mohou používat vyhrazeného úložiště dat a prostředků úložiště. Další informace o různých strategiíchachch

Úlohy, které běží v AKS, můžou také k ukládání dat používat trvalé svazky. V Azure můžete vytvářet trvalých svazků jako prostředky Kubernetes, které Azure Storage podporuje. Datové svazky můžete vytvářet ručně a přiřazovat je přímo podům nebo je můžete automaticky vytvářet pomocí trvalých deklarací identity svazků. AKS poskytuje integrované třídy úložiště pro vytváření trvalých svazků, které disky Azure, azure Filesa podporu služby Azure NetApp Files. Další informace najdete v tématu Možnosti úložiště pro aplikace v 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é řeší požadavky různých 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 najdete v tématu Použití značek Azure v 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, aby nedocházelo k problémům 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.

Můžete použít tainty, tolerance, popisky uzlů , selektory uzlůa spřažení uzlů 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, včetně:

  • 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žitím Pod Sandboxingu na základě Kata Containers.
  • 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 v 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íFederal Information Process Standard (FIPS), důvěrné virtuální počítačenebo šifrování založené na hostiteli.

Izolace uzlů umožňuje snadno přidružit a vrátit náklady na sadu uzlů nebo fond uzlů k jednomu tenantovi. 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.

Modely tenantů

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, který zobrazuje tři tenanty, každý s samostatnými nasazeními

Každá úloha tenanta běží ve vyhrazeném clusteru AKS a přistupuje k samostatné sadě prostředků Azure. Víceklientských řešení, která vytváříte pomocí tohoto modelu, obvykle využívajíinfrastruktury jako kódu (IaC). Například bicep, Azure Resource Manageru, Terraformunebo rozhraní REST API Azure Resource Manageru pomoct zahájit 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, má přístup pouze ke kontejnerům a připojeným svazkům, které patří do jednoho tenanta. 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, takže se vyhnete hlučným problémům sousedů. 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. Pomocí funkce sla dostupnosti sla můžete škálovat řídicí rovinu clusteru AKS tak, aby splňovala poptávku po provozu. Zřizování vyhrazeného clusteru by přesto mohlo být lepším řešením pro zákazníky se silnými požadavky z hlediska izolace úloh.
  • Aktualizace a změny můžete 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 potřebujete opakovat aktivity údržby 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. Můžou být užitečné i jiné operace mezi nasazeními, jako jsou vytváření sestav a analýzy v celém vašem majetku. Ujistěte se, ž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 infrastrukturu pro nasazení, monitorování a údržbu. Prostředek používají všichni tenanti, jak je znázorněno v následujícím diagramu:

diagram znázorňující tři tenanty, kteří 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. Pokud používáte tento model 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. Tyto změny pomáhají udržet provoz, který generují všechny 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í můžou 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 použít počet nevyřízených požadavků nebo metriky externího systému zasílání zpráv, který používáautomatického škálování založeného na 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 Na Azure k jednotlivým tenantům na základě jejich skutečného využití. Řešení jiných společností než Microsoft, 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. Může to ale být také rizikové, protože jakékoli změny infrastruktury nebo komponent aplikace můžou ovlivnit celou zákaznickou základnu.
  • Měli byste také zvážit omezení škálování. S větší pravděpodobností dosáhnete limitů škálování prostředků Azure, pokud máte sdílenou sadu prostředků. Abyste se vyhnuli dosažení limitu kvóty prostředků, můžete své tenanty distribuovat 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 sdílí některé komponenty řešení napříč všemi tenanty a nasazuje vyhrazené prostředky 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 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 hlučné problémy se sousedy. Tento přístup zvažte, pokud zjistíte, že většina zatížení provozu v aplikaci 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í dotazů 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 a sdílené komponenty jiných tenantů, 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, které používá jeden tenant.
  • Tento model nemusí poskytovat požadovanou úroveň izolace pro zákazníky, kteří nemůžou 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. Můžete také nasadit infrastrukturu s jedním tenantem pro 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. Cenový model může poskytovat více cenových úrovní, které každý z nich 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ílejí všichni tenanti úrovně Basic.
  • Úroveň Standard: Požadavky tenanta obsluhují vyhrazená aplikace Kubernetes, která běží v samostatném oboru názvů, který poskytuje hranice izolace z hlediska zabezpečení, sítí a 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 SLA, 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é hostují aplikaci tenanta. Sandbox ing podů můžete použít jako alternativní řešení vyhrazených clusterů nebo fondů uzlů k izolaci jedinečných úloh tenantů.

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, který zobrazuje tři tenanty Tenanti A a B sdílejí cluster AKS. Tenant C má vyhrazený cluster AKS.

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, který zobrazuje 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 SLA pro různé úrovně. Úroveň Basic může například nabízet 99,9% dobu provozu, úroveň Standard může nabízet 99,95% dobu provozu a úroveň Premium může nabízet 99,99% dobu provozu. Vyšší smlouvu SLA můžete 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é používají méně nákladnou velikost virtuálního počítače pro uzly agenta. 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 jeCoreDNS, konnectivitynebo kontroleru příchozího přenosu dat služby Azure Application Gatewayve vyhrazeném fondu uzlů v systémovém režimu. Pomocí taintů, tolerance, popisků uzlů , selektorů uzlů a spřažení uzlů ke spuštění aplikace tenanta v jednom nebo více fondech uzlů v uživatelském režimu.
  • 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ů, který má konkrétní velikost virtuálního počítače, nastavení automatického škálování a podporu 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 nebo jedno zobrazení.

Automatické škálování

Pokud chcete udržet krok s poptávkou po provozu, který aplikace tenanta generují, můžete povolit automatického škálování clusteru škálovat uzly agenta 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 agentů přestanou být dostupné kvůli výpadkům zóny dostupnosti.

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 zabránilo přechodu podů do čekajícího stavu kvůli nedostatku prostředků, jako je procesor a paměť.

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. HorizontalPodAutoscaler automaticky škáluje počet replik podů na základě využití procesoru nebo paměti nebo vlastních metrik. Pomocí KEDA můžete řídit škálování libovolného kontejneru v Kubernetes na základě počtu událostí z externích systémů, jako je azure Event Hubs nebo azure Service Bus, které používají aplikace tenanta.

vertikálního automatického škálování podů (VPA) umožňuje efektivní správu prostředků pro pody. Úpravou procesoru a paměti přidělené podům pomáhá VPA snížit počet uzlů potřebných ke spouštění aplikací tenanta. Menší počet uzlů snižuje celkové náklady na vlastnictví a pomáhá vyhnout se hlučným problémům sousedů.

Přiřaďte skupiny rezervací kapacity fondům uzlů, abyste zajistili lepší přidělování a izolaci prostředků pro různé tenanty.

Údržba

Pokud chcete snížit riziko výpadků, které můžou mít vliv na aplikace tenantů během upgradu fondu clusterů nebo uzlů, naplánujte AKS plánovanou údržbu mimo špičku. Naplánujte týdenní časové intervaly údržby a aktualizujte řídicí rovinu clusterů AKS, které spouštějí aplikace tenanta a fondy uzlů, aby se minimalizoval 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 probíhají během plánovaných časových období.

Bezpečnost

Následující části popisují osvědčené postupy zabezpečení pro víceklientských řešení pomocí AKS.

Přístup ke clusteru

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

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á aplikace je v samostatném oboru názvů, měla by každá úloha používat jiný účet služby Kubernetes a přihlašovací údaje pro přístup ke službám Azure pro podřízené služby Azure. Úč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, takže je autorizované pody můžou používat ke komunikaci se serverem rozhraní API. Většina požadavků rozhraní API poskytuje ověřovací token pro účet služby nebo běžný uživatelský účet.

Úlohy tenanta, které nasadíte 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 úlohy Microsoft Entra pro Kubernetes integruje s nativními funkcemi Kubernetes pro federaci se všemi externími zprostředkovateli identit.

Sandboxing podů

AKS obsahuje mechanismus označovaný jako Sandboxing 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ím aplikací do samostatných clusterů nebo fondů uzlů můžete silně izolovat úlohy tenantů různých týmů nebo zákazníků. Použití více 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ší. Můžete například použít jeden cluster, když spustíte nedůvěryhodné a důvěryhodné pody na stejném uzlu nebo seskupíte daemonSets a privilegované kontejnery na stejném uzlu pro rychlejší místní komunikaci a funkční seskupení. sandboxing podů vám může pomoct silně 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 kata containers, které běží na hostiteli kontejneru Azure Linux pro AKS zásobníku pro zajištění izolace vynucené hardwarem. Kata Containers v AKS jsou postavené na hypervisoru Azure posíleného zabezpečením. Izoluje jednotlivé pody 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 slouží k umístění mnoha kontejnerů Kata na jeden hostovaný virtuální počítač a současně nadále spouštět kontejnery na nadřazený virtuální počítač. Tento model poskytuje silnou hranici izolace ve sdíleném clusteru AKS.

Další informace najdete tady:

Azure Dedicated Host

azure Dedicated Host je služba, která poskytuje fyzické servery vyhrazené pro jedno předplatné Azure a poskytují izolaci hardwaru na úrovni fyzického serveru. Tyto vyhrazené hostitele můžete 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ů.

Používání služby Azure Dedicated Host s AKS má několik výhod, mezi které patří:

  • 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, které platforma Azure iniciuje. 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 AKS.

Karpenter

Karpenter je opensourcový projekt správy životního cyklu uzlů vytvořený pro Kubernetes. Přidání Karpenteru do clusteru Kubernetes může zlepšit efektivitu a náklady na spouštění úloh v daném clusteru. Karpenter sleduje pody, které plánovač Kubernetes označí jako nenaplánovatelné. Také dynamicky zřizuje a spravuje uzly, které můžou splňovat požadavky na pody.

Karpenter poskytuje jemně odstupňovanou kontrolu nad zřizováním uzlů a umístěním úloh ve spravovaném clusteru. Toto řízení zlepšuje víceklientskou architekturu optimalizací přidělování prostředků, zajištěním izolace mezi aplikacemi jednotlivých tenantů a snížením provozních nákladů. Při vytváření víceklientských řešení v AKS poskytuje Karpenter užitečné funkce, které vám pomůžou se správou různorodých požadavků na aplikace pro podporu různých tenantů. Můžete například potřebovat, aby některé aplikace tenantů běžely na fondech uzlů optimalizovaných pro GPU a jiné pro spouštění na fondech uzlů optimalizovaných pro paměť. Pokud vaše aplikace vyžaduje nízkou latenci úložiště, můžete pomocí Karpenteru označit, že pod vyžaduje uzel, který běží v konkrétní zóně dostupnosti, abyste mohli úložiště a aplikační vrstvu společně přidělit.

AKS umožňuje automatické zřizování uzlů v clusterech AKS prostřednictvím Karpenteru. Většina uživatelů by k povolení Karpenteru jako spravovaného doplňku měla použít režim automatického zřizování uzlu. Další informace najdete v tématu Automatické zřizování node. Pokud potřebujete pokročilejší přizpůsobení, můžete se rozhodnout pro vlastní hostitele Karpenter. Další informace naleznete v poskytovatele AKS Karpenter.

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

Pomocí důvěrných virtuálních počítačů přidat do clusteru AKS jeden nebo více fondů uzlů, abyste vyřešili striktní izolaci, ochranu osobních údajů a požadavky na zabezpečení tenantů. důvěrné virtuální počítače používají hardwarově důvěryhodné spouštěcí prostředí. AMD Secure Encrypted Virtualization – zabezpečené vnořené stránkování (SEV-SNP) důvěrných virtuálních počítačů zamítají hypervisor a další kód pro správu hostitele přístup k paměti a stavu virtuálního počítače, který přidává vrstvu ochrany a hloubkové ochrany před přístupem operátora. Další informace najdete v tématu Použití důvěrných virtuálních počítačů 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ů AKSmůž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, což vám umožňuje posílit stav zabezpečení víceklientských prostředí AKS. Další informace najdete 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 najdete tady:

Šifrování na základě hostitele

šifrování založené na hostiteli 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í o tenantovi 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 k šifrování klíče ochrany dat pomocí šifrování obálky, označovaného také jako obtékání. Mezipaměť pro disky s operačním systémem a datovými disky se také šifruje prostřednictvím BYOK, které 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 najdete tady:

Síťování

Následující části popisují osvědčené postupy sítí pro víceklientských řešení pomocí AKS.

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ů. Když sdílíte cluster AKS napříč několika týmy v organizaci, chraňte 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 AKS.

Autorizované rozsahy IP adres

Druhou možností, jak zlepšit zabezpečení clusteru a minimalizovat útoky, je použití autorizovaných rozsahů IP adres. Tento přístup omezuje přístup k řídicí rovině veřejného clusteru AKS na dobře známý seznam IP adres a rozsahů 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ů. Další informace najdete v tématu Zabezpečení přístupu k serveru rozhraní API pomocí autorizovaných rozsahů IP adres v AKS.

služba Azure Private Link 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, která je definovaná ve virtuální síti a připojená ke konfiguraci front-endOVÉ IP adresy azure Load Balanceru instanci. Se službou Private Linkmůžou poskytovatelé služeb 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 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 veřejný koncový bod na veřejném internetu.

Další informace o tom, jak nakonfigurovat Službu Private Link pro víceklientské řešení hostované v Azure, najdete v tématu víceklientské a privátní propojení.

Reverzní proxy servery

reverzního proxy 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:

Pokud používáte reverzní proxy server hostovaný v AKS, který pomáhá zabezpečit a zpracovávat příchozí požadavky na 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 akcelerované síťové povolené.
  • 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í.

Pokud používátekontroleru příchozího přenosu dat služby Azure Application Gateway (AGIC), zvažte implementaci následujících osvědčených postupů:

  • Nakonfigurujte aplikační bránu, kterou kontroler příchozího přenosu dat používá pro automatické škálování. Když je povolené automatické škálování, služba Application Gateway a firewall webových aplikací (WAF) v2 se škálují na více nebo více instancí na základě požadavků na provoz aplikací. Tento režim poskytuje vaší aplikaci lepší elasticitu a eliminuje potřebu odhadnout velikost nebo počet instancí služby Application Gateway. Tento režim také pomáhá ušetřit náklady tím, že nevyžaduje, aby brána běžela ve špičce zřízené kapacitě pro očekávané maximální zatížení provozu. Musíte zadat minimální (a volitelně maximální) počet instancí.
  • Zvažte nasazení více instancí AGIC , každý přidružený k samostatné aplikační brány, pokud počet aplikací tenantů překračuje maximální množství lokalit. Za předpokladu, že každá aplikace tenanta běží ve vyhrazeném oboru názvů, použijte více oborů názvů podporují k rozložení aplikací tenantů do více instancí AGIC.

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 použít při zveřejnění víceklientských aplikací hostovaných službou AKS pro veřejný internet.

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, který ukazuje, jak se Azure Front Door a AKS připojují.

Službu Azure Front Door můžete nakonfigurovat tak, aby upravila hlavičku hostitele zdroje požadavku tak, aby odpovídala názvu domény back-endové aplikace. Původní hlavička Host odeslaná klientem se rozšíří prostřednictvím hlavičky X-Forwarded-Host a kód víceklientská aplikace může tyto informace použít k mapování příchozího požadavku na správnýtenanta .

azure Web Application Firewall, ve službě Azure Front Door, poskytuje centralizovanou ochranu webových aplikací. Azure Web Application Firewall vám může pomoct bránit aplikace tenanta hostované 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í private linku. Další informace najdete v tématu Připojení služby Azure Front Door Premium k internímu zdroji nástroje pro vyrovnávání zatížení pomocíprivate Linku .

Odchozí připojení

Když se aplikace hostované 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ů překladu zdrojových síťových adres (SNAT). porty SNAT generovat jedinečné identifikátory, které slouží k udržování jedinečných toků, které aplikace spouštěné na stejné sadě výpočetních prostředků iniciují. Spuštěním několika klientských aplikací ve sdíleném clusteru AKS můžete provést 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:

  • azure Load Balancer: 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í ale nemusí splňovat požadavky všech scénářů, pokud jsou veřejné IP adresy zakázané 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ý nástroj pro vyrovnávání zatížení vytvoří s výchozí veřejnou IP adresou, kterou pravidla odchozích přenosů použít. Odchozí pravidla umožňují explicitně definovat 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 více veřejných IP adres. 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 aplikací tenanta. 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 aspekty služby Azure NAT Gateway pro víceklientské.
  • trasy definované uživatelem (UDR): Můžete přizpůsobit trasu výchozího přenosu dat clusteru AKS tak, aby podporovala vlastní síťové scénáře, jako jsou ty, které nepovolují veřejné IP adresy a vyžadují, aby se cluster nacházel za síťovým virtuálním zařízením (NVA). Když nakonfigurujete cluster pro uživatelsky definované směrování, AKS automaticky nenakonfiguruje cesty výchozího přenosu dat. Musíte dokončit nastavení výchozího přenosu dat. Například směrujete výchozí provoz přes azure firewall. Cluster AKS musíte nasadit do existující virtuální sítě s podsítí, kterou jste dříve nakonfigurovali. Pokud nepoužíváte standardní architekturu nástroje pro vyrovnávání zatížení, 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.

Monitorování

Pomocí Azure Monitoru a přehledů kontejnerů můžete monitorovat aplikace tenantů, které běží ve sdíleném clusteru AKS, a vypočítat rozpis nákladů na jednotlivé obory názvů. Pomocí služby Azure Monitor můžete monitorovat stav a výkon AKS. Zahrnuje kolekci protokolů a metrik, analýzy telemetrie a vizualizací shromážděných dat za účelem identifikace trendů a konfigurace výstrah, které proaktivně upozorní na kritické problémy. Můžete povolit přehledy kontejnerů rozšířit o toto monitorování.

Můžete také přijmout opensourcové nástroje, jako jsou Prometheus a Grafana, které se běžně používají pro monitorování Kubernetes. Nebo můžete pro monitorování a pozorovatelnost přijmout další nástroje od jiných společností než Microsoft.

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 metod, které mohou organizace použít k řízení a optimalizaci nákladů. Mezi tyto metody patří použití nativních nástrojů Kubernetes ke správě 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, který aplikace tenanta používá. Postup, který budete postupovat při účtování poplatků zpět tenantům, závisí na modelu tenantů, který vaše řešení přijme. Následující seznam podrobněji popisuje modely tenantů:

  • Plně víceklientská aplikace: Když jedna víceklientská aplikace obsluhuje všechny požadavky tenanta, je vaší zodpovědností sledovat spotřebu prostředků a počet požadavků, které každý tenant generuje. 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, včetně počtu a velikosti virtuálních počítačů, síťových nákladů na síťový provoz, veřejných IP adres, nástrojů pro vyrovnávání zatížení a služeb úložiště, jako jsou spravované disky nebo soubory Azure, které řešení tenanta používá. 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 doclusteru .
  • Vyhrazený fond uzlů: Značku Azure můžete použít na nový nebo existující fond uzlů vyhrazený pro jednoho tenanta. Značky 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 najdete 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 udržují 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, které sady Kubernetes používají. Značky prostředků, které Kubernetes nesleduje, 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ů můžete nastavit na nasazení, službu, popisek, pod a obor názvů, což vám dává flexibilitu v tom, jak zaúčtujete nebo zobrazujete zpět uživatele clusteru. Další informace najdete v tématu Zásady správného řízení nákladů sKubecost .

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 rozhraní Azure Well-Architected Framework Přehled pilíře optimalizace nákladů.

Vládnutí

Když více tenantů sdílí stejnou infrastrukturu, může být správa ochrany osobních údajů dat, dodržování předpisů a zákonných požadavků složitá. Potřebujete implementovat silná bezpečnostní opatření a zásady správného řízení dat. Sdílené clustery AKS představují vyšší riziko porušení zabezpečení dat, neoprávněného přístupu a nedodržení předpisů ochrany dat. Každý tenant může mít jedinečné požadavky na zásady správného řízení dat a zásady dodržování předpisů, které ztěžují zabezpečení a ochranu osobních údajů dat.

Microsoft Defender for Containers je řešení zabezpečení kontejnerů nativní pro cloud, které poskytuje možnosti detekce hrozeb a ochrany pro prostředí Kubernetes. Pomocí defenderu pro kontejnery můžete vylepšit stav zásad správného řízení a dodržování předpisů při hostování více tenantů v clusteru Kubernetes. Pomocí Defenderu for Containers můžete chránit citlivá data, zjišťovat hrozby a reagovat na ně pomocí analýzy chování kontejnerů a síťového provozu a splnění zákonných požadavků. Poskytuje možnosti auditování, správu protokolů a generování sestav, které demonstrují dodržování předpisů regulačním orgánům a auditorům.

Přispěvatelů

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

Hlavní autor:

Další přispěvatelé: