Sdílet prostřednictvím

Obecné aspekty architektury pro výběr služby kontejneru Azure

  • Článek

Tento článek vás provede procesem výběru služby kontejneru Azure. Poskytuje přehled aspektů na úrovni funkcí, které jsou pro některé úlohy běžné a kritické. Může vám pomoct při rozhodování, aby vaše úlohy splňovaly požadavky na spolehlivost, zabezpečení, optimalizaci nákladů, efektivitu provozu a efektivitu výkonu.

Poznámka

Tento článek je druhou částí série, která začíná Vybrat kontejnerovou službu Azure. Důrazně doporučujeme, abyste si nejprve přečetli tento článek s přehledem, abyste získali kontext pro tyto aspekty architektury.

Přehled

Aspekty v tomto článku jsou rozdělené do čtyř kategorií:

aspekty architektury a sítě

  • Podpora operačního systému
  • Adresní prostory sítě
  • Principy toku provozu
  • Plánování podsítí
  • Počet dostupných příchozích IP adres
  • Uživatelsky definované trasy a podpora služby NAT Gateway
  • Integrace privátních sítí
  • Pokrytí protokolu
  • Vyrovnávání zatížení
  • Zjišťování služeb
  • Vlastní domény a spravovaný protokol TLS
  • Vzájemné TLS
  • Koncepty sítí pro konkrétní služby Azure

aspekty zabezpečení

  • Zajištění zabezpečení provozu uvnitř clusteru pomocí zásad sítě
  • Skupiny zabezpečení sítě
  • Integrace služby Azure Key Vault
  • Podpora spravované identity
  • Ochrana před hrozbami a posouzení zranitelností pomocí Defender pro kontejnery
  • Standardní hodnoty zabezpečení
  • Azure Well-Architected Framework pro zabezpečení

Provozní úvahy

  • Aktualizace a opravy
  • Aktualizace imagí kontejneru
  • Škálovatelnost vertikální infrastruktury
  • Horizontální škálovatelnost infrastruktury
  • Škálovatelnost aplikací
  • Pozorovatelnost
  • rámec Well-Architected pro efektivitu provozu

aspekty spolehlivosti

  • Smlouvy o úrovni služeb
  • Redundance prostřednictvím zón dostupnosti
  • Kontroly stavu a samoopravení
  • Nasazení aplikací s nulovým výpadkem
  • Omezení prostředků
  • Well-Architected Framework pro spolehlivost

Tento článek se zaměřuje na podmnožinu služeb kontejnerů Azure, které nabízejí vyspělou sadu funkcí pro webové aplikace a rozhraní API, sítě, pozorovatelnost, vývojářské nástroje a operace: Azure Kubernetes Service (AKS), AKS Automatic, Azure Container Apps a Web App for Containers. Úplný seznam všech služeb kontejneru Azure najdete na stránce kategorie produktů container services.

Poznámka

Některé oddíly rozlišují AKS Standard od AKS Automatic. Pokud oddíl nerozlišuje mezi těmito dvěma, předpokládá se parita funkcí.

Aspekty architektury

Tato část popisuje rozhodnutí o architektuře, která se obtížně převrácejí nebo opravují bez nutnosti významného výpadku nebo opětovného nasazení. Zejména je potřeba mít na paměti tyto aspekty základních komponent, jako jsou sítě a zabezpečení.

Tyto aspekty nejsou specifické pro pilíře architektury Well-Architected. Při výběru služby kontejneru Azure si ale zaslouží další kontrolu a hodnocení ve vztahu k požadavkům podniku.

Poznámka

AKS Automatic je více názorné řešení než AKS Standard. Některé zastaralé funkce nelze zakázat. Tato příručka tyto funkce nezmiňuje. Aktuální informace o těchto omezeních a porovnání funkcí Standard vs Automatické najdete viz: Porovnání funkcí AKS Automatické a Standard.

Podpora operačního systému

Většina kontejnerizovaných aplikací běží v kontejnerech Linuxu, které podporují všechny služby kontejnerů Azure. Vaše možnosti jsou omezenější pro komponenty úloh, které vyžadují kontejnery Windows.

Kontejnerové aplikace AKS Automatické AKS Webová aplikace pro kontejnery
podpora Linuxu ✅ ✅ ✅ ✅
podpora Windows ❌ ✅ ❌ ✅
podpora smíšených operačních systémů ❌ ✅ ❌ ❌*

*Podpora smíšeného operačního systému pro Web App for Containers vyžaduje samostatné plány služby Azure App Service pro Windows a Linux.

Důležité informace o sítích

Je důležité porozumět návrhu sítí v rané fázi procesů plánování kvůli omezením zabezpečení a dodržování předpisů a uloženým pokynům. Hlavní rozdíly mezi službami Azure, které jsou popsané v této příručce, jsou obecně závislé na předvolbách:

  • Container Apps je nabídka PaaS, která poskytuje mnoho síťových funkcí spravovaných v Azure, jako je zjišťování služeb, interní spravované domény a řízení virtuálních sítí.
  • AKS je nejkonfigurovanější ze tří služeb a poskytuje největší kontrolu nad tokem sítě. Poskytuje například vlastní kontrolery příchozího přenosu dat a řízení provozu uvnitř clusteru prostřednictvím zásad sítě Kubernetes. Týmy úloh můžou využívat různé síťové doplňky spravované v Azurea také instalovat a provozovat doplňky z širšího ekosystému Kubernetes.
  • Web App for Containers je funkcí služby App Service. Proto jsou koncepty sítí, zejména integrace privátních sítí, velmi specifické pro Službu App Service. Tato služba bude známá týmům pracovního zatížení, které už používají App Service. Doporučujeme, aby týmy, které nemají zkušenosti se službou App Service a které chtějí lépe znát integraci s virtuální sítí Azure, zvážily použití služby Container Apps.

Mějte na paměti, že sítě jsou základní vrstvou infrastruktury. Často je obtížné provádět změny v návrhu bez opětovného nasazení úlohy, což může vést k výpadkům. Proto pokud vaše úloha má specifické požadavky na síť, pečlivě si přečtěte tuto část, než zúžíte výběr služby kontejneru Azure.

Adresní prostory sítě

Když integrujete aplikace do virtuálních sítí, je potřeba provést určité plánování IP adres, abyste zajistili, že pro instance kontejnerů bude k dispozici dostatek IP adres. Během tohoto procesu naplánujte další adresy pro aktualizace, modro-zelená nasazení a podobné situace, kdy se zavádějí další instance, což spotřebovává více IP adres.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
Vyhrazené podsítě Plán spotřeby: volitelné
Vyhrazený plán: povinné		 Povinný Volitelný
požadavky IP adres Plán spotřeby: Viz prostředí pouze pro spotřebu.
Vyhrazený plán: Viz prostředí profilů úloh.		 Viz virtuální sítě Azure pro AKS. Viz požadavky na podsíť služby App Service.

Upozorňujeme, že požadavky AKS závisí na zvoleném síťovém doplňku. Některé síťové pluginy pro AKS vyžadují širší rezervace IP adres. Podrobnosti jsou mimo rozsah tohoto článku. Další informace najdete v tématu Koncepty sítí proAKS .

Principy toku provozu

Typy toku provozu vyžadovaného pro řešení můžou ovlivnit návrh sítě.

Následující části obsahují informace o různých omezeních sítě. Tato omezení ovlivňují vaši potřebu nasadit další podsítě v závislosti na tom, jestli potřebujete:

  • Několik společně přidělených úloh.
  • Soukromý a/nebo veřejný přístup.
  • Tok řízený přístupem pro východo-západní provoz v clusteru (pro Container Apps a AKS) nebo ve virtuální síti (pro všechny služby kontejnmentu Azure).

Plánování podsítě

Zajištění, že máte podsíť, která je dostatečně velká, aby zahrnovala instance vaší aplikace pro vaši úlohu, není jediným faktorem, který určuje síťové nároky, ve kterých jsou tyto aplikace nasazené.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
Podpora pro spoluumístěné úlohy v rámci podsítě* ❌* ✅ Není k dispozici*

*Popisuje osvědčený postup, nikoli technické omezení.

V případě Container Apps se integrace podsítě vztahuje jenom na jedno prostředí Container Apps. Každé prostředí Container Apps je omezené na jednu IP adresu příchozího přenosu dat, veřejnou nebo privátní.

Každé prostředí Container Apps je určeno pouze pro jednu úlohu, ve které jsou závislé aplikace umístěny společně. Proto je potřeba zavést další síťová zařízení Azure pro vyrovnávání zatížení příchozího přenosu dat, pokud potřebujete veřejný i privátní příchozí přenos dat. Mezi příklady patří Azure Application Gateway a Azure Front Door. Pokud máte také více úloh, které je potřeba oddělit, vyžadují se další prostředí Container Apps, takže pro každé prostředí musí být přidělena další podsíť.

AKS poskytuje podrobné řízení toku sítě východ-západ v rámci clusteru ve formě zásad sítě Kubernetes. Toto řízení toku umožňuje segmentovat více úloh s různými hranicemi zabezpečení sítě v rámci stejného clusteru.

U služby Web App for Containers neexistují žádná omezení počtu aplikací, které můžete integrovat s jednou podsítí, pokud je podsíť dostatečně velká. Neexistují žádné osvědčené postupy pro řízení přístupu mezi webovými aplikacemi ve stejné virtuální síti. Každá webová aplikace nezávisle spravuje řízení přístupu pro provoz z virtuální sítě nebo internetu – východ – západ nebo sever – jih.

Poznámka

Nemůžete změnit velikost podsítí, ve kterých jsou nasazené prostředky. Při plánování sítě se dejte pozor, abyste se vyhnuli opětovnému nasazení celých komponent úloh, což může vést k výpadkům.

Počet dostupných příchozích IP adres

Následující tabulka bere v úvahu předchozí část plánování podsítě a definuje, kolik IP adres je možné zpřístupnit pro libovolný počet aplikací hostovaných v jediném nasazení služby kontejneru Azure.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
počet příchozích IP adres Jedna Mnoho App Service Environment: Jedna
Žádné prostředí služby aplikace: mnoho

Container Apps umožňuje jednu IP adresu pro každé prostředí, veřejné nebo soukromé. AKS umožňuje libovolný počet IP adres, veřejné nebo soukromé. Služba Web App for Containers mimo službu App Service Environment umožňuje jednu veřejnou IP adresu pro všechny aplikace v rámci plánu služby App Service a několik různých privátních IP adres, které používají privátní koncové body Azure.

Je důležité si uvědomit, že webové aplikace integrované do služby App Service Environment přijímají provoz pouze prostřednictvím jedné IP adresy příchozího přenosu dat, která je přidružená ke službě App Service Environment bez ohledu na to, jestli je veřejná nebo soukromá.

Uživatelsky definované trasy a podpora služby NAT Gateway

Pokud úloha vyžaduje uživatelem definované trasy (trasy definované uživatelem) a možnosti služby NAT Gateway pro podrobné řízení sítě, služba Container Apps vyžaduje použití profilů úloh . Kompatibilita tras definovaných uživatelem a služby NAT Gateway není k dispozici v plánu ACA určeném pouze ke spotřebě.

AKS a Web App for Containers implementují tyto dvě síťové funkce prostřednictvím standardních funkcí virtuální sítě nebo integrace virtuální sítě. Uzlové fondy AKS a Web App for Containers v prostředí App Service Environment jsou už přímé virtuální síťové prostředky. Webová aplikace pro kontejnery, které nejsou ve službě App Service Environment, podporují trasy definované uživatelem a bránu NAT prostřednictvím integrace virtuální sítě. S integrací virtuální sítě se prostředek technicky nenachází přímo ve virtuální síti, ale veškerý odchozí přístup prochází přes virtuální síť a související pravidla sítě ovlivňují provoz podle očekávání.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
podpora UDR Plán jen pro spotřebu: ❌
Plán profilu zatížení: ✅		 ✅ ✅
podpora NAT Gateway Plán jen pro spotřebu: ❌
Plán profilu zatížení: ✅		 ✅ ✅

Integrace privátních sítí

U úloh, které vyžadují striktní privátní sítě vrstvy 4 pro příchozí i výchozí přenos dat, byste měli zvážit kontejnerové aplikace, AKS a skladovou položku Služby App Service Environment s jedním tenantem, kde jsou úlohy nasazené do virtuální sítě s vlastním zabezpečením a poskytují vlastní podrobné ovládací prvky privátních sítí.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
Privátní přístup do virtuální sítě ✅ ✅ Prostřednictvím privátního koncového bodu
Privátní výstup z virtuální sítě ✅ ✅ Integrace virtuální sítě prostřednictvím
Plně blokovaný veřejný koncový bod ✅ ✅ App Service Environment pouze
Privátní sítě s využitím služby Web App for Containers

Služba Web App for Containers poskytuje další síťové funkce, které nejsou uvedeny stejným způsobem jinými službami Azure popsanými v tomto článku. Aby bylo potřeba implementovat přísné požadavky na privátní sítě, musí se týmy úloh seznámit s těmito koncepty sítí. Pečlivě si projděte tyto síťové funkce:

Pokud chcete řešení PaaS a dáváte přednost konceptům sítí sdíleným napříč několika řešeními Azure, měli byste zvážit službu Container Apps.

Pokrytí protokolu

Důležitým aspektem hostitelské platformy jsou síťové protokoly, které jsou podporované pro příchozí aplikační požadavky (ingres). Web App for Containers je nejtužší možností, která podporuje pouze PROTOKOL HTTP a HTTPS. Container Apps navíc umožňuje příchozí připojení TCP. AKS je nejflexibilnější a podporuje neomezené použití TCP a UDP na vlastnoručně vybraných portech.

Container Apps AKS Webová aplikace pro kontejnery
podpora protokolu a portu HTTP (port 80)*
HTTPS (port 443)*
TCP (porty 1–65535 s výjimkou 80 a 443)		 TCP (jakýkoli port)
UDP (jakýkoli port)		 HTTP (port 80)
HTTPS (port 443)
podpora protokolu WebSocket ✅ ✅ ✅
podpora HTTP/2 ✅ ✅ ✅

*V prostředí Container Apps je možné HTTP/S zpřístupnit na libovolném portu pro komunikaci uvnitř clusteru. V tomto scénáři se nepoužívají integrované funkce HTTP služby Container Apps, jako je CORS a spřažení relací.

Container Apps i Web App for Containers podporují protokol TLS 1.2 pro jejich integrované příchozí přenosy dat HTTPS.

Vyrovnávání zatížení

Díky container Apps a Web App for Containers Azure plně abstrahuje nástroje pro vyrovnávání zatížení vrstvy 4 a vrstvy 7.

Naproti tomu AKS používá model sdílené odpovědnosti, ve kterém Azure spravuje základní infrastrukturu Azure, kterou tým úloh konfiguruje prostřednictvím propojení s rozhraním API Kubernetes. Pro vyrovnávání zatížení vrstvy 7 v AKS můžete zvolit možnosti spravované Azure, například doplněk směrování aplikací spravovaných službou AKS nebo Application Gateway pro kontejnery, nebo nasadit a samoobslužně spravovat kontroler příchozího přenosu dat podle vašeho výběru.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
Vyrovnávač zatížení vrstvy 4 Spravováno Azure Sdílená odpovědnost Spravováno Azure
nástroje pro vyrovnávání zatížení vrstvy vrstvy 7 Spravováno Azure Sdílené nebo samospravované Spravováno Azure

Zjišťování služeb

V cloudových architekturách je možné běhová prostředí kdykoli odebrat a znovu vytvořit, aby se znovu vyvážily prostředky, takže IP adresy instancí se pravidelně mění. Tyto architektury používají plně kvalifikované názvy domén (FQDN) pro spolehlivou a konzistentní komunikaci.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
zjišťování služby Plně kvalifikovaný název domény spravované v Azure Konfigurovatelná služba Kubernetes Plně kvalifikovaný název domény spravované v Azure

Web Apps for Containers poskytuje automaticky veřejné plně kvalifikované názvy domén pro příchozí komunikaci (sever–jih). Nevyžaduje se žádná další konfigurace DNS. Neexistuje ale žádný integrovaný mechanismus pro usnadnění nebo omezení provozu mezi jinými aplikacemi (komunikace mezi východem a západem).

Container Apps také poskytuje veřejné přístupové plně kvalifikované názvy domén. Služba Container Apps ale dále umožňuje zveřejnění plně kvalifikovaného názvu domény aplikace a omezení provozu pouze v rámci prostředí. Tato funkce usnadňuje správu komunikace mezi východem a západem a povolení komponent, jako je Dapr.

Nasazení Kubernetes nejsou zpočátku zjistitelná v rámci clusteru ani mimo cluster. Musíte vytvořit služby Kubernetes definované rozhraním API Kubernetes, které pak zpřístupňuje aplikace do sítě adresovatelným způsobem.

Důležitý

Pouze Container Apps a AKS poskytují zjišťování služeb prostřednictvím interních schémat DNS v příslušných prostředích. Tato funkce může zjednodušit konfigurace DNS napříč vývojovými/testovacími a produkčními prostředími. Můžete například vytvořit tato prostředí s libovolnými názvy služeb, které musí být jedinečné pouze v rámci prostředí nebo clusteru, aby mohly být stejné v rámci vývoje/testování a produkce. U služby Web App for Containers musí být názvy služeb jedinečné v různých prostředích, aby nedocházelo ke konfliktům s Azure DNS.

Vlastní domény a spravovaný protokol TLS

Služba Container Apps i Web App for Containers poskytují připravená řešení pro vlastní domény a správu certifikátů.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
Konfigurace vlastních domén Připravený k použití BYO Připravený k použití
spravovaný protokol TLS pro plně kvalifikované názvy domén Azure Připravený k použití Není k dispozici Připravený k použití
spravovaný protokol TLS pro vlastní domény v režimu Preview BYO Out of the box or BYO

Uživatelé AKS zodpovídají za správu DNS, konfigurací clusteru a certifikátů TLS pro vlastní domény. I když AKS nenabízí spravovaný protokol TLS, můžou zákazníci využívat software z ekosystému Kubernetes, například oblíbený cert-manager ke správě certifikátů TLS.

Vzájemné TLS

Další alternativou pro omezení příchozího provozu je vzájemné TLS (mTLS). Vzájemné TLS je protokol zabezpečení, který zajišťuje, že jsou při komunikaci ověřeni jak klient, tak server. K ověření si obě strany vyměňují a ověřují certifikáty před přenosem jakýchkoli dat.

Služba Web App for Containers má integrovanou podporu mTLS pro příchozí připojení klientů. Aplikace ale musí certifikát ověřit přístupem k hlavičce http X-ARR-ClientCert, kterou platforma App Service předává.

Container Apps má také integrovanou podporu mTLS. Předává klientský certifikát aplikaci v hlavičce HTTP X-Forwarded-Client-Cert. Můžete také snadno povolit automatické mTLS pro interní komunikaci mezi aplikacemi v rámci jednoho prostředí.

Vzájemné TLS v AKS je možné implementovat pomocí služby mesh založené na Istio jako spravovaným doplňkem, který zahrnuje možnosti mTLS pro příchozí připojení klientů a vnitroklastrovou komunikaci mezi službami. Týmy úloh se také můžou rozhodnout nainstalovat a spravovat další nabídku sítě služeb z ekosystému Kubernetes. Díky těmto možnostem je implementace mTLS v Kubernetes nejflexibilnější.

Koncepty sítí specifických pro služby

Předchozí části popisují některé z nejběžnějších aspektů, které je potřeba vzít v úvahu. Další podrobnosti a další informace o síťových funkcích specifických pro jednotlivé služby kontejnerů Azure najdete v těchto článcích:

Předchozí části se zaměřují na návrh sítě. Další informace o zabezpečení sítě a zabezpečení síťového provozu najdete v další části.

Důležité informace o zabezpečení

Selhání řešení bezpečnostních rizik může vést k neoprávněnému přístupu, porušením zabezpečení nebo únikům citlivých informací. Kontejnery nabízejí zapouzdřené prostředí pro vaši aplikaci. Hostitelské systémy a podkladové překryvy sítě však vyžadují další mantinely. Vaše volba služby Azure Container Service musí podporovat vaše konkrétní požadavky na zabezpečení jednotlivých aplikací a poskytovat správná bezpečnostní opatření, která brání neoprávněnému přístupu a snižují riziko útoků.

Přehled porovnání zabezpečení

Většina služeb Azure, včetně Container Apps, AKS a Web App for Containers, se integruje s nabídkami zabezpečení klíčů, včetně služby Key Vault a spravovaných identit.

Ze služeb v této příručce nabízí AKS částečně největší konfigurovatelnost a rozšiřitelnost díky zpřístupnění podkladových komponent, které se často dají zabezpečit prostřednictvím možností konfigurace. Zákazníci můžou například zakázat místní účty na serveru rozhraní API Kubernetes nebo zapnout automatické aktualizace základních uzlů prostřednictvím možností konfigurace.

Automatické clustery AKS mají ve výchozím nastavení posílenou výchozí konfiguraci s mnoha nastaveními zabezpečení clusteru, aplikací a sítí. Tyto počáteční konfigurace nejen zkracují dobu nasazení, ale také poskytují uživatelům standardizovanou konfiguraci, která je předem ověřená, a tím uživatelům poskytuje solidní základ pro každodenní 2 provozní povinnosti. Tato platforma pomáhá zkrátit křivku učení při řízení dlouhodobé správy clusterů pro týmy, které jsou v této technologii nováčky.

Pro podrobné porovnání pečlivě zvažte následující úvahy, abyste měli jistotu, že vaše požadavky na zabezpečení úloh budou splněny.

Zabezpečení řídicí roviny Kubernetes

AKS nabízí největší flexibilitu tří možností, které jsou v tomto článku považovány za předpokladu, že poskytuje úplný přístup k rozhraní API Kubernetes, abyste mohli přizpůsobit orchestraci kontejnerů. Tento přístup k rozhraní Kubernetes API ale představuje také významný prostor pro útoky a potřebujete ho zabezpečit.

Důležitý

Všimněte si, že tato část není relevantní pro službu Web App for Containers, která jako řídicí rovinu používá rozhraní API Azure Resource Manageru.

Zabezpečení na základě identit

Zákazníci zodpovídají za zabezpečení přístupu na základě identity k rozhraní API. Kubernetes nabízí vlastní systém pro správu ověřování a autorizace, který je také potřeba zabezpečit pomocí řízení přístupu.

Pokud chcete využít jednu rovinu skla pro správu identit a přístupu v Azure, je osvědčeným postupem zakázat místní účty specifické pro Kubernetes a místo toho implementovat integraci Microsoft Entra spravovanou AKS společně s Azure RBAC pro Kubernetes. Pokud implementujete tento osvědčený postup, správci nemusí provádět správu identit a přístupu na více platformách.

Kontejnerové aplikace AKS
řízení přístupu k rozhraní API Kubernetes Žádný přístup Úplný přístup

Zákazníci, kteří používají Container Apps, nemají přístup k rozhraní API Kubernetes. Microsoft poskytuje zabezpečení pro toto rozhraní API.

Zabezpečení na základě sítě

Pokud chcete omezit síťový přístup k řídicí rovině Kubernetes, musíte použít AKS, který nabízí dvě možnosti. První možností je použít privátní clustery AKS, které používají službu Azure Private Link mezi privátní sítí serveru API a privátní sítí clusteru AKS. Druhou možností je integrace API serveru do virtuální sítě (v předběžné verzi), kde je API server integrován do delegované podsítě. Další informace najdete v dokumentaci.

Implementace síťového přístupu k rozhraní API Kubernetes má důsledky. Především je možné správu provádět pouze v rámci privátní sítě. Obvykle to znamená, že potřebujete nasadit agenty v místním prostředí pro Azure DevOps nebo GitHub Actions. Další informace o dalších omezeních najdete v dokumentaci specifické pro jednotlivé produkty.

Kontejnerové aplikace AKS
zabezpečení sítě rozhraní API Kubernetes V PaaS nejde konfigurovat Konfigurovatelná: veřejná IP adresa nebo privátní IP adresa

Tyto aspekty se nevztahují na kontejnerové aplikace. Vzhledem k tomu, že se jedná o PaaS, Microsoft abstrahuje základní infrastrukturu.

Zabezpečení datové roviny sítě

Následující síťové funkce se dají použít k řízení přístupu k úlohě a v rámci této úlohy.

Použití zásad sítě k zajištění zabezpečení provozu uvnitř clusteru

Některé stavy zabezpečení vyžadují oddělení síťového provozu v rámci prostředí, například při použití víceklientských prostředí k hostování vícevrstvých aplikací. V těchto scénářích byste měli zvolit AKS a implementovat zásady sítě, technologii nativní pro cloud, která umožňuje podrobnou konfiguraci sítí vrstvy 4 v clusterech Kubernetes.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
zásady sítě Plán spotřeby: ❌
Vyhrazený plán: ❌		 ✅ ❌

Ze tří služeb Azure popsaných v tomto článku je AKS jediný, který podporuje další izolaci úloh v rámci clusteru. Zásady sítě nejsou podporovány v Container Apps ani v Web App for Containers.

Skupiny zabezpečení sítě

Ve všech scénářích můžete regulovat síťovou komunikaci v rámci širší virtuální sítě pomocí skupin zabezpečení sítě, která umožňují používat pravidla provozu vrstvy 4, která regulují příchozí a výchozí přenos dat na úrovni virtuální sítě.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
skupiny zabezpečení sítě Plán spotřeby: ✅
Vyhrazený plán: ✅		 ✅ ✅ aplikace integrované do virtuální sítě: pouze výchozí přenos dat

Integrovaná omezení IP pro příchozí přenos dat

Container Apps a Web App for Containers poskytují integrovaná omezení zdrojových IP adres pro příchozí přenos dat pro jednotlivé aplikace. AKS může dosáhnout stejné funkčnosti, ale vyžaduje nativní funkčnost Kubernetes prostřednictvím API prostředku služby Kubernetes , kde můžete nastavit hodnoty pro loadBalancerSourceRanges.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
Vestavěné omezení přístupu IP ✅ ❌* ✅
spotřeba prostředků - Využívá prostředky clusteru. -

Poznámka

AKS nabízí omezení příchozích IP adres, ale jedná se o nativní funkci Kubernetes, nikoli nativní pro Azure, jako jsou ostatní služby.

Zabezpečení na úrovni aplikace

Úlohy potřebujete zabezpečit nejen na úrovni sítě a infrastruktury, ale také na úrovni úloh a aplikací. Řešení kontejnerů Azure se integrují s nabídkami zabezpečení Azure, které vám pomůžou standardizovat implementaci zabezpečení a ovládací prvky pro vaše aplikace.

Integrace služby Key Vault

Osvědčeným postupem je ukládat a spravovat tajné kódy, klíče a certifikáty v řešení pro správu klíčů, jako je Key Vault, což poskytuje lepší zabezpečení pro tyto komponenty. Místo ukládání a konfigurace tajných kódů v kódu nebo ve výpočetní službě Azure by se všechny aplikace měly integrovat se službou Key Vault.

Integrace služby Key Vault umožňuje vývojářům aplikací zaměřit se na kód aplikace. Všechny tři služby kontejneru Azure popsané v tomto článku můžou automaticky synchronizovat tajné kódy ze služby Key Vault a poskytnout je aplikaci, obvykle jako proměnné prostředí nebo připojené soubory.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
integrace služby Key Vault ✅ ✅ ✅

Další informace najdete tady:

Podpora spravované identity

Spravovanou identitu můžou používat aplikace k ověřování v chráněných službách Microsoft Entra ID, aniž by musely používat klíče nebo tajné kódy. Container Apps a Web App for Container nabízejí integrovanou nativní podporu Azure pro spravovanou identitu na úrovni aplikace. Podpora řízené identity na úrovni aplikace pro AKS je poskytována prostřednictvím Entra Workload ID. AKS také vyžaduje spravovanou identitu související s infrastrukturou, která umožňuje provoz clusteru s Kubeletem, řídicí plochou a různými doplňky AKS.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
podpora spravované identity infrastruktury Není k dispozici ✅ Není k dispozici
Podpora spravovaných identit pro operace kontejnerů ✅ ✅ ✅
podpora identity spravované aplikací ✅ ✅ ✅

Další informace najdete tady:

Ochrana před hrozbami a posouzení zranitelností pomocí Defender pro kontejnery

Ochrana před zranitelnostmi je také důležitá. Osvědčeným postupem je použít Defender for Containers. Posouzení ohrožení zabezpečení jsou podporována v registrech kontejnerů Azure, takže je může používat libovolná služba kontejneru Azure, nejen ta popsaná v tomto článku. Ochrana runtime služby Defender for Containers je dostupná jenom pro AKS.

Vzhledem k tomu, že AKS zpřístupňuje nativní rozhraní Kubernetes API, je možné zabezpečení clusteru vyhodnotit také pomocí nástrojů pro zabezpečení specifické pro Kubernetes z ekosystému Kubernetes.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
ochrana proti hrozbám za běhu ❌ ✅ ❌

Další informace naleznete v tématu Containers support matrix in Defender for Cloud.

Upozorňujeme, že posouzení zranitelností obrazů kontejnerů nejsou skenování v reálném čase. Registr kontejneru Azure se kontroluje v pravidelných intervalech.

Standardní hodnoty zabezpečení

Obecně platí, že většina kontejnerových služeb Azure integruje nabídky zabezpečení Azure. Celkově mějte na paměti, že sada funkcí zabezpečení je jen malou součástí implementace zabezpečení cloudu. Další informace o implementaci zabezpečení pro kontejnerové služby najdete v následujících standardních hodnotách zabezpečení specifických pro službu:

Poznámka

Automatické clustery AKS jsou nakonfigurované s konkrétním nastavením zabezpečení . Ujistěte se, že jsou v souladu s vašimi potřebami úloh.

Well-Architected Framework pro zabezpečení

Tento článek se zaměřuje na hlavní rozdíly mezi funkcemi služeb kontejnerů popsanými zde.

Podrobnější pokyny k zabezpečení AKS najdete v tématu Well-Architected Framework – AKS.

Důležité informace o provozu

Aby týmy úspěšně spustily úlohu v produkčním prostředí, musí implementovat postupy efektivity provozu, včetně centralizovaného protokolování, monitorování, škálovatelnosti, pravidelných aktualizací a oprav a správy imagí.

Aktualizace a opravy

Je důležité, aby se základní operační systém aplikace aktualizoval a pravidelně opravoval. Mějte ale na paměti, že při každé aktualizaci hrozí riziko selhání. Tato část a další popisují hlavní aspekty tří služeb kontejneru, pokud jde o sdílenou odpovědnost mezi zákazníkem a platformou.

Jako spravovaná služba Kubernetes poskytne AKS aktualizované image pro operační systém uzlu a komponenty řídicí roviny. Týmy úloh ale zodpovídají za aplikování aktualizací na své clustery. Můžete ručně aktivovat aktualizace nebo využít funkci kanálů pro automatický upgrade clusteru , abyste měli jistotu, že jsou vaše clustery aktuální. Informace o opravách a upgradu clusterů AKSnajdete v příručce pro operace AKS fáze 2.

Container Apps a Web App for Containers jsou řešení PaaS. Azure zodpovídá za správu aktualizací a oprav, takže zákazníci se můžou vyhnout složitosti správy upgradu AKS.

Kontejnerové aplikace AKS Automatické AKS Webová aplikace pro kontejnery
Aktualizace řídicí roviny Platforma Zákazník Platforma Platforma
Aktualizace a opravy hostitele Platforma Zákazník Platforma Platforma
aktualizace a opravy imagí kontejneru Zákazník Zákazník Zákazník Zákazník

Aktualizace imagí kontejneru

Bez ohledu na řešení kontejnerů Azure zodpovídají zákazníci vždy za vlastní image kontejnerů. Pokud existují opravy zabezpečení pro základní obrazy kontejnerů, je vaší odpovědností znovu sestavit své obrazy. Pokud chcete získat upozornění na tato ohrožení zabezpečení, použijte Defender for Containers pro kontejnery hostované ve službě Container Registry.

Škálovatelnost

Škálování se používá k úpravě kapacity prostředků tak, aby splňovala požadavky, a přidává další kapacitu k zajištění výkonu a odebrání nevyužité kapacity, aby se ušetřily peníze. Při výběru řešení kontejneru je potřeba zvážit omezení infrastruktury a strategie škálování.

Škálovatelnost vertikální infrastruktury

vertikálního škálování odkazuje na schopnost zvýšit nebo snížit stávající infrastrukturu, tj. výpočetní procesor a paměť. Různé úlohy vyžadují různé množství výpočetních prostředků. Když zvolíte řešení kontejneru Azure, musíte mít přehled o nabídkách hardwarových skladových položek, které jsou dostupné pro konkrétní službu Azure. Liší se a mohou uplatňovat další omezení.

V případě AKS zkontrolujte v dokumentaci k Azure velikosti virtuálních počítačů a omezení AKS pro jednotlivé oblasti .

Tyto články obsahují podrobnosti o nabídkách skladových položek pro ostatní dvě služby:

Horizontální škálovatelnost infrastruktury

horizontálního škálování odkazuje na schopnost zvýšit nebo snížit kapacitu prostřednictvím nové infrastruktury, jako jsou uzly virtuálních počítačů. Během nárůstu nebo snížení škálování abstrahuje spotřební úroveň Container Apps základní virtuální počítače. U zbývajících služeb kontejneru Azure spravujete strategii horizontálního škálování pomocí standardního rozhraní API Azure Resource Manageru.

Mějte na paměti, že škálování nahoru a dolů zahrnuje také opětovné vyvážení instancí, což vytváří riziko výpadku. Riziko je menší než odpovídající riziko se vertikálním škálováním. Týmy úloh však vždy zodpovídají za zajištění toho, aby jejich aplikace mohly zvládnout selhání a implementaci elegantních spuštění a vypnutí aplikací, aby nedocházelo k výpadkům.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
Škálování infrastruktury dovnitř a ven Plán spotřeby: Není k dispozici
Vyhrazený plán: konfigurovatelný		 Konfigurovatelný Konfigurovatelný
flexibilní zřizování hardwaru Plán spotřeby: Není k dispozici
Vyhrazený plán: abstrahovaný pomocí profilů zatížení		 Libovolná specifikace virtuálního počítače Abstrahovaný. Podívejte se na plán služby App Service .

Důležitý

Možnosti zřizování hardwaru dostupné prostřednictvím vyhrazeného plánu Container Apps (profily úloh) a Služby Web App for Containers (plány služby App Service) nejsou tak flexibilní jako AKS. Musíte se seznámit se skladovými jednotkami dostupnými v jednotlivých službách, abyste měli jistotu, že jsou splněné vaše potřeby.

Škálovatelnost aplikací

Typická míra, pro kterou se má aktivovat škálování infrastruktury a aplikací, je spotřeba prostředků: procesor a paměť. Některá řešení kontejnerů můžou škálovat počet instancí kontejneru na metriky s kontextem specifickým pro aplikaci, jako jsou požadavky HTTP. Například AKS a Container Apps můžou škálovat instance kontejnerů na základě front zpráv prostřednictvím KEDA a mnoha dalších metrik prostřednictvím škálovačů. Tyto funkce poskytují flexibilitu při volbě strategie škálovatelnosti pro vaši aplikaci. Služba Web App for Containers spoléhá na možnosti škálovatelnosti, které poskytuje Azure. (Viz následující tabulka.) Služba Web App for Containers nepodporuje vlastní konfigurace škálovače, jako je KEDA.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
Rozšíření kontejneru HTTP, TCP nebo založené na metrikách (CPU, paměť, řízené událostmi). založené na metrikách (procesor, paměť nebo vlastní). ručnízaložené na metrikách nebo automatické(Preview).
Škálovatelnost řízená událostmi Ano. Nativní pro cloud Ano. Nativní pro cloud Vyžaduje se další konfigurace. Ano. Specifické pro prostředky Azure.

AKS Automatic ve výchozím nastavení umožňuje horizontální automatické škálování podů, automatické škálování řízené událostmi Kubernetes (KEDA) a vertikální automatické škálování podů (VPA).

Pozorovatelnost

Instrumentace pracovní zátěže

Shromažďování metrik pro složité nebo vícevrstvé aplikace může být náročné. Pokud chcete získat metriky, můžete kontejnerizované úlohy integrovat se službou Azure Monitor dvěma způsoby:

  • Automatické instrumentování. Nevyžaduje se žádné změny kódu.
  • ruční nástroje. Minimální změny kódu potřebné k integraci a konfiguraci sady SDK nebo klienta.
Kontejnerové aplikace AKS Webová aplikace pro kontejnery
Automatické instrumentování prostřednictvím platformy ❌ ❌ Částečná podpora*
Automatická instrumentace prostřednictvím agenta ❌ Částečná podpora* Není k dispozici
ruční instrumentace Prostřednictvím sady SDK nebo OpenTelemetry Prostřednictvím sady SDK nebo OpenTelemetry Prostřednictvím sady SDK nebo OpenTelemetry

*AKS a Web App for Containers podporují automatickou instrumentaci pro určité konfigurace úloh Linuxu a Windows v závislosti na jazyce aplikace. Další informace najdete v těchto článcích:

Instrumentace v kódu aplikace je zodpovědností vývojářů aplikací, takže je nezávislá na jakémkoli řešení kontejneru Azure. Vaše úloha může používat řešení, jako jsou:

Protokoly a metriky

Všechny služby kontejneru Azure poskytují funkce protokolů aplikací a platforem a metrik. Protokoly aplikací jsou protokoly konzoly generované vaší úlohou. Protokoly platformy zaznamenávají události, ke kterým dochází na úrovni platformy, mimo rozsah vaší aplikace, jako je škálování a nasazení. Metriky jsou číselné hodnoty, které popisují určité aspekty systému v určitém okamžiku a umožňují vám monitorovat a upozorňovat na výkon a stav systému.

Azure Monitor je hlavní služba protokolování a metrik v Azure, která se integruje s těmito službami. Azure Monitor používá záznamy prostředků k oddělení záznamů do kategorií podle různých zdrojů a shromažďuje metriky, aby poskytl přehled o výkonu prostředků. Jedním ze způsobů, jak určit, které protokoly a metriky jsou dostupné z každé služby Azure, je podívat se na kategorie protokolů prostředků a dostupné metriky pro každou službu.

Kontejnerové aplikace AKS AKS Automatické Webová aplikace pro kontejnery
Podpora streamování protokolů ✅ ✅ ✅ ✅
podpora pro službu Azure Monitor ✅ ✅ ✅ ✅
protokoly prostředků služby Azure Monitor Konzole a Systém server API Kubernetes, auditní služby, plánovač, automatická škálovací služba, a další komponenty Stejné jako AKS ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs a mnohem více
Sběr a sledování metrik Metriky prostřednictvím služby Azure Monitor; vlastní metriky prostřednictvím Dapr metrics Metriky prostřednictvím služby Azure Monitor; vlastní metriky přes Prometheus (vyžaduje ruční nastavení) Předkonfigurovaný Spravovaný Prometheus pro shromažďování metrik a předkonfigurovaná Spravovaná Grafana pro vizualizaci, metriky prostřednictvím služby Azure Monitor. Metriky přes Azure Monitor
Předkonfigurované Prometheus a Grafana ❌ Vyžaduje ruční nastavení. ✅ Managed Prometheus a Managed Grafana jsou standardně předkonfigurované. ❌

Container Apps abstrahuje všechny její interní protokoly Kubernetes do dvou kategorií: protokoly konzoly, které obsahují protokoly kontejnerů úloh, a systémové protokoly, které obsahují všechny protokoly související s platformou. Pro metriky se Služba Container Apps integruje se službou Azure Monitor, aby shromažďuje standardní metriky a podporuje vlastní metriky prostřednictvím integrace Dapr pro pokročilé scénáře.

AKS poskytuje protokoly související s Kubernetes a podrobnou kontrolu nad tím, co se protokoluje. AKS zachovává úplnou kompatibilitu s klientskými nástroji Kubernetes pro streamování protokolů, jako je kubectl. Pro metriky se AKS integruje se službou Azure Monitor za účelem shromažďování metrik clusteru a uzlů. Vlastní shromažďování metrik s využitím Prometheus a vizualizace s Grafana je možné, ale vyžaduje ruční nastavení a konfiguraci.

AKS Automatic je předem nakonfigurované s konkrétními monitorovacími nástroji. Používá spravovaný Prometheus pro shromažďování metrik a spravovanou Grafana pro vizualizaci. Metriky clusteru a aplikací se shromažďují automaticky a dají se vizualizovat. AKS Automatic se také integruje se službou Azure Monitor pro shromažďování protokolů a metrik.

Web App for Containers poskytuje několik kategorií protokolů prostředků, protože jeho platforma (App Service) není výhradně určená pro kontejnerové úlohy. Pro operace specifické pro kontejnery, které spravují svou interní platformu Dockeru, poskytuje kategorii protokolu AppServicePlatformLogs. Další důležitou kategorií je AppServiceEnvironmentPlatformLogs, která protokoluje události, jako je škálování a změny konfigurace. Metriky se shromažďují prostřednictvím služby Azure Monitor a umožňují monitorovat výkon aplikací a využití prostředků.

rámec Well-Architected pro efektivitu provozu

Tento článek se zaměřuje na hlavní rozdíly mezi funkcemi služeb kontejnerů popsanými zde. Projděte si tyto články a projděte si kompletní pokyny pro efektivitu provozu pro následující služby:

Spolehlivost

spolehlivost označuje schopnost systému reagovat na selhání a zůstat plně funkční. Na úrovni aplikačního softwaru by úlohy měly implementovat osvědčené postupy, jako je ukládání do mezipaměti, opakování, vzory jističe a kontroly stavu. Na úrovni infrastruktury zodpovídá Azure za zpracování fyzických selhání, jako jsou selhání hardwaru a výpadky napájení, v datacentrech. K selháním může dojít i nadále. Týmy zpracovávající zátěž by měly vybrat odpovídající úroveň služby Azure a použít konfigurace s minimálním počtem instancí pro implementaci automatického přepínání služeb při selhání mezi zónami dostupnosti.

Pokud chcete zvolit odpovídající úroveň služby, musíte pochopit, jak fungují smlouvy o úrovni služeb (SLA) a zóny dostupnosti.

Smlouvy o úrovni služeb

Spolehlivost se běžně měří metrikami řízenými obchodními, jako jsou smlouvy SLA nebo metriky obnovení, jako jsou cíle doby obnovení (RTO).

Azure má mnoho smluv SLA pro konkrétní služby. Neexistuje něco jako 100% úroveň služby, protože k selhání může vždy dojít v softwaru, hardwaru a v přírodě, například při bouřích a zemětřeseních. Smlouva SLA není zárukou, ale spíše finančně zajištěnou smlouvou o dostupnosti služeb.

Pro nejnovější SLA a podrobnosti si stáhněte nejnovější dokument SLA pro Microsoft Online Services z licenčního webu společnosti Microsoft.

Free vs. placené úrovně

Obecně platí, že úrovně Free služeb Azure nenabízejí smlouvu SLA, což z nich činí nákladově efektivní volby pro neprodukční prostředí. V produkčních prostředích je ale osvědčeným postupem zvolit placenou úroveň, která má smlouvu SLA.

Další faktory pro AKS

AKS má různé smlouvy SLA pro různé komponenty a konfigurace:

  • řídicí rovina. Server rozhraní API Kubernetes má samostatnou smlouvu SLA.
  • Datová rovina. Pooly uzlů používají základní SLA pro SKU virtuálních počítačů.
  • zóny dostupnosti. Pro tyto dvě roviny existují různé úrovně služeb (SLA) v závislosti na tom, zda má cluster AKS povoleny zóny dostupnosti a pro spuštění více instancí napříč těmito zónami.

Mějte na paměti, že když používáte více služeb Azure, složené SLO se můžou lišit od SLA jednotlivých služeb a mohou být nižší než SLA těchto služeb.

Redundance se zónami dostupnosti

zón dostupnosti jsou různá datová centra, která mají nezávislou elektrickou energii, chlazení atd. v rámci jedné oblasti. Výsledná redundance zvyšuje odolnost proti chybám, aniž byste museli implementovat architektury s více oblastmi.

Azure má zóny dostupnosti ve všech zemích nebo oblastech, ve kterých Azure provozuje oblast datacentra. Pokud chcete povolit více instancí kontejnerů napříč zónami dostupnosti, nezapomeňte vybrat skladové položky, úrovně služeb a oblasti, které poskytují podporu zóny dostupnosti.

Funkce Kontejnerové aplikace AKS Webová aplikace pro kontejnery
podpora zóny dostupnosti Plný Plný Plný

Například aplikace nebo infrastruktura nakonfigurovaná tak, aby spouštěla jednu instanci, se stane nedostupnou, pokud dojde k problému v zóně dostupnosti, kde je hardware hostovaný. Pokud chcete plně používat podporu zón dostupnosti, měli byste nasadit úlohy s minimální konfigurací tří instancí kontejneru, které jsou rozložené mezi zóny.

Kontroly stavu a samoopravení

Koncové body kontroly stavu jsou pro spolehlivou pracovní zátěž zásadní. Vytváření těchto koncových bodů je ale pouze polovina řešení. Druhá polovina řídí, co a jak hostitelská platforma dělá, když dojde k selháním.

Pokud chcete lépe rozlišovat mezi typy zdravotních sond, podívejte se na vestavěné typy sond z Kubernetes:

  • spouštěcí. Zkontroluje, jestli se aplikace úspěšně spustila.
  • připravenosti Zkontroluje, jestli je aplikace připravená na zpracování příchozích požadavků.
  • Živost. Zkontroluje, jestli aplikace stále běží a reaguje.

Dalším důležitým aspektem je, jak často se tyto kontroly stavu požadují z aplikace (interní členitost). Pokud máte mezi těmito požadavky dlouhý interval, můžete dál obsluhovat síťový provoz, dokud instance není považována za nefunkční.

Většina aplikací podporuje kontroly stavu prostřednictvím protokolu HTTP(S). Některé však můžou k provádění těchto kontrol potřebovat jiné protokoly, jako je TCP nebo gRPC. Mějte na paměti při návrhu systému kontroly stavu.

Container Apps AKS Webová aplikace pro kontejnery
spouštěcí sondy ✅ ✅ Částečná podpora
sondy připravenosti ✅ ✅ ❌
sondy životaschopnosti ✅ ✅ ✅
Granularita intervalu Sekundy Sekundy 1 minuta
podpora protokolu HTTP(S)
Protokol tcp		 HTTP(S)
Protokol tcp
gRPC		 HTTP(S)

Kontroly stavu se nejsnadněji implementují ve službě Web App for Containers. Je potřeba vzít v úvahu několik důležitých aspektů:

  • Jeho spouštěcí sondy jsou vestavěné a nelze je změnit. Odešle požadavek HTTP na počáteční port kontejneru. Jakákoli odpověď z vaší aplikace se považuje za úspěšné spuštění.
  • Nepodporuje testy připravenosti. Pokud je spouštěcí sonda úspěšná, přidá se instance kontejneru do fondu instancí, které jsou v pořádku.
  • Odesílá zdravotní kontrolu v minutových intervalech. Interval nemůžete změnit.
  • Minimální prahová hodnota, kterou můžete nastavit, aby se instance, která není v pořádku, odebrala z interního mechanismu vyrovnávání zatížení, je dvě minuty. Nezdravá instance přijímá provoz po dobu alespoň dvou minut po selhání kontroly stavu. Výchozí hodnota tohoto nastavení je 10 minut.

Container Apps a AKS jsou naopak mnohem flexibilnější a nabízejí podobné možnosti. Z hlediska konkrétních rozdílů poskytuje AKS následující možnosti pro provádění kontrol stavu, které nejsou dostupné v Container Apps:

Automatické obnovení

Identifikace špatné instance kontejneru a zastavení odesílání provozu do ní je začátek. Dalším krokem je implementace automatického opravy. Samoopravný proces je proces restartování aplikace s cílem obnovit ze stavu selhání. Zde je srovnání tří služeb kontejnerů:

  • Ve službě Web App for Containers není k dispozici žádná možnost restartovat instanci kontejneru okamžitě po selhání kontroly stavu . Pokud instance po dobu jedné hodiny selhává, nahradí se novou instancí. Existuje další funkce označovaná jako samoozdravná funkce, která monitoruje a restartuje instance. Nesouvisí přímo se zdravotními kontrolami. Používá různé metriky aplikací, jako jsou limity paměti, doba trvání požadavku HTTP a stavové kódy.
  • Container Apps a AKS se automaticky pokusí restartovat instanci kontejneru, pokud sonda aktivity dosáhne definované prahové hodnoty selhání.

Nasazení aplikací s nulovým výpadkem

Schopnost nasazovat a nahrazovat aplikace bez jakýchkoli výpadků pro uživatele je zásadní pro spolehlivou úlohu. Všechny tři služby kontejneru popsané v tomto článku podporují nasazení s nulovými výpadky, ale různými způsoby.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
strategie nulového výpadku průběžná aktualizace kumulativní aktualizace a všechny ostatní strategie Kubernetes Nasazovací sloty

Upozorňujeme, že architektury aplikací musí také podporovat nasazení bez výpadků. Pokyny najdete v Azure Well-Architected Framework.

Omezení prostředků

Další důležitou součástí spolehlivého sdíleného prostředí je vaše kontrola nad využitím prostředků (jako je procesor nebo paměť) kontejnerů. Musíte se vyhnout scénářům, ve kterých jedna aplikace zabírá všechny prostředky a nechá ostatní aplikace ve špatném stavu.

Kontejnerové aplikace AKS Webová aplikace pro kontejnery
limity prostředků (procesor nebo paměť) Na aplikaci/kontejner Na aplikaci/kontejner
Na jeden obor názvů		 Podle plánu služby App Service
  • Web App for Containers: V rámci jednoho plánu služby App Service můžete hostovat více aplikací (kontejnerů). Můžete například přidělit plán se dvěma jádry procesoru a 4 GiB paměti RAM, ve kterém můžete spustit více webových aplikací v kontejnerech. Nemůžete ale omezit jednu z aplikací na určitou část procesoru nebo paměti. Všichni soutěží o stejné prostředky plánu služby App Service. Pokud chcete izolovat prostředky aplikace, musíte vytvořit další plány služby App Service.
  • kontejnerové aplikace: Můžete nastavit omezení procesoru a paměti pro každou aplikaci ve vašem prostředí. Jste však omezeni na sadu povolených kombinací procesoru a paměti. Nemůžete například nakonfigurovat jeden virtuální procesor a 1 GiB paměti, ale můžete nakonfigurovat jeden virtuální procesor a 2 GiB paměti. Prostředí Container Apps je obdobné jako obor názvů v Kubernetes.
  • AKS: Můžete zvolit libovolnou kombinaci vCPU a paměti, pokud uzly mají hardware, který ji podporuje. Prostředky můžete také omezit na úrovni oboru názvů, pokud chcete cluster segmentovat tímto způsobem.

Well-Architected Framework pro spolehlivost

Tento článek se zaměřuje na hlavní rozdíly mezi funkcemi služeb kontejnerů v Azure. Pokud chcete zkontrolovat kompletní pokyny ke spolehlivosti pro konkrétní službu, projděte si tyto články:

Závěr

Dobře navržená řešení nastavují základy úspěšných úloh. I když se architektury dají upravit s tím, jak roste zatížení a týmy na svých cloudových cestách postupují, některá rozhodnutí, zejména ohledně sítí, se obtížně převrácejí bez významných výpadků nebo opětovného nasazení.

Obecně platí, že když porovnáváte služby kontejnerů Azure, objeví se motiv: AKS otevře nejzásadnější infrastrukturu, takže nabízí největší kontrolu a konfigurovatelnost, zatímco AKS Automatic nabízí rovnováhu mezi řízením a jednoduchostí díky automatizaci mnoha provozních úloh.

Velikost provozní režie a složitosti je pro úlohy AKS vysoce proměnlivá. Některé týmy můžou výrazně snížit provozní režii pomocí doplňků a rozšíření spravovaných Microsoftem a funkcí automatického upgradu. Jiní zákazníci můžou preferovat plnou kontrolu nad clusterem, aby mohli využívat plnou rozšiřitelnost Kubernetes a ekosystém CNCF. Microsoft například nabízí Flux jako spravované rozšíření GitOps, mnoho týmů si místo toho zvolí nastavení a provoz ArgoCD sami.

Týmy úloh, které například nevyžadují aplikace CNCF, mají méně provozního prostředí nebo preferují zaměření na funkce aplikací, mohou preferovat nabídku PaaS. Doporučujeme, aby nejprve zvážili kontejnerové aplikace.

I když container Apps i Web App for Containers představují nabídky PaaS, které poskytují podobné úrovně infrastruktury spravované Microsoftem, klíčovým rozdílem je, že služba Container Apps je blíže Kubernetes a poskytuje další nativní cloudové funkce pro zjišťování služeb, automatické škálování řízené událostmi, integraci Dapr atd. Týmy, které tyto funkce nepotřebují a jsou obeznámené se sítěmi a modely nasazení služby App Service, ale můžou preferovat službu Web App for Containers.

Generalizace vám můžou pomoct zúžit seznam služeb kontejnerů Azure, které je potřeba zvážit. Mějte ale na paměti, že potřebujete také ověřit svou volbu tak, že podrobně prozkoumáte jednotlivé požadavky a shodíte je se sadami funkcí specifických pro službu.

Přispěvatelé

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

Hlavní autoři:

Další přispěvatelé:

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se na LinkedIn.

Další kroky