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á výběrem služby kontejneru 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 IP adres příchozího přenosu dat
  • 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 se službou Azure Key Vault
  • Podpora spravované identity
  • Posouzení ohrožení zabezpečení a ochrany před hrozbami pomocí defenderu for Containers
  • Standardní hodnoty zabezpečení
  • Dobře navržená architektura Azure pro zabezpečení

Důležité informace o provozu

  • Aktualizace a opravy
  • Aktualizace imagí kontejneru
  • Škálovatelnost vertikální infrastruktury
  • Horizontální škálovatelnost infrastruktury
  • Škálovatelnost aplikací
  • Pozorovatelnost
  • Dobře navržená architektura pro efektivitu provozu

Důležité informace o spolehlivosti

  • Smlouvy o rozsahu služeb
  • Redundance prostřednictvím zón dostupnosti
  • Kontroly stavu a samoopravení
  • Nasazení aplikací s nulovým výpadkem
  • Omezení prostředků
  • Dobře navržená architektura pro spolehlivost

Tento článek se zaměřuje na podmnožinu služeb kontejneru 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), Azure Container Apps a Web App for Containers. Úplný seznam všech služeb kontejneru Azure najdete na stránce kategorie produktů kontejnerových služeb.

Poznámka:

V této příručce termín úloha odkazuje na kolekci prostředků aplikace, které podporují obchodní cíl nebo provádění obchodního procesu. Úloha používá několik komponent, jako jsou rozhraní API a úložiště dat, která spolupracují na poskytování konkrétních komplexních 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 dobře navržená architektura. Při výběru služby kontejneru Azure si ale zaslouží další kontrolu a hodnocení požadavků na firmy.

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.

Container Apps AKS Web App for Containers
Podpora Linuxu ✅ ✅ ✅
Podpora pro Windows ❌ ✅ ✅
Podpora smíšeného operačního systému ❌ ✅ ❌*

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

Aspekty sítí

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 a interní spravované domény. Týmy úloh, které potřebují trochu větší konfigurovatelnost, můžou před zvážením alternativ použít profily úloh nebo vyhrazených profilů, aby maximalizovaly možnosti sítě.
  • AKS je nejkonfigurovatelný 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 Azure a instalovat a provozovat všechny doplňky z širšího ekosystému Kubernetes.
  • Web App for Containers je funkce 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át týmy úloh, které už službu App Service používají. Týmy, které nemají zkušenosti se službou App Service a které chtějí znáte integraci virtuální sítě Azure, doporučujeme zvážit službu 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, modrá/zelená nasazení a podobné situace, ve kterých se nasazují další instance, které spotřebovávají další IP adresy.

Container Apps AKS Web App for Containers
Vyhrazené podsítě Plán Consumption: volitelné
Vyhrazený plán: povinné		 Požadováno Volitelné
Požadavky na IP adresu Plán Consumption: Viz prostředí jen 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.

Všimněte si, že požadavky AKS závisí na zvoleném síťovém modulu plug-in. Některé síťové moduly plug-in pro AKS vyžadují širší rezervace IP adres. Podrobnosti jsou mimo rozsah tohoto článku. Další informace najdete v tématu Koncepty sítí pro AKS.

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.
  • Privátní nebo veřejné příchozí přenosy dat.
  • Tok řízeného přístupem pro provoz východ-západ v clusteru (pro Container Apps a AKS) nebo ve virtuální síti (pro všechny služby kontejnerů 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é.

Container Apps AKS Web App for Containers
Podpora společně přidělených úloh v rámci podsítě* ❌* ✅ –*

*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čené pouze pro jednu úlohu, ve které jsou závislé aplikace společně přiděleny. 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ří Aplikace Azure lication 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 IP adres příchozího přenosu dat

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.

Container Apps AKS Web App for Containers
Počet IP adres příchozího přenosu dat Jeden Mnoho App Service Environment: Jedna
Žádná služba App Service Environment: 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živatelsky 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 S trasou definovanou uživatelem a službou NAT Gateway není v plánu ACA určená jen pro spotřebu.

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ě. Propracované fondy uzlů AKS a Web App for Containers ve službě App Service Environment už jsou přímé prostředky virtuální sítě. Webová aplikace pro kontejnery, které nejsou ve službě App Service Environment, podporují trasy definované uživatelem a bránu PŘEKLADU adres (NAT Gateway) 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í.

Container Apps AKS Web App for Containers
Podpora definovaná uživatelem Plán jen pro spotřebu: ❌
Plán profilu úlohy: ✅		 ✅ ✅
Podpora služby NAT Gateway Plán jen pro spotřebu: ❌
Plán profilu úlohy: ✅		 ✅ ✅

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í.

Container Apps AKS Web App for Containers
Privátní příchozí přenos dat do virtuální sítě ✅ ✅ Prostřednictvím privátního koncového bodu
Privátní výchozí přenos dat z virtuální sítě ✅ ✅ Integrace virtuální sítě
Plně potlačené veřejné koncové body ✅ ✅ Pouze služba App Service Environment
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 je síťové protokoly, které jsou podporovány pro příchozí požadavky aplikací (příchozí přenos dat). 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 unconstrained use of TCP and UDP on self-selected ports.

Container Apps AKS Web App for Containers
Podpora protokolů a portů 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é protokol HTTP/S zpřístupnit na jakémkoli 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é v Azure, například doplněk směrování spravované aplikace AKS nebo Application Gateway for Containers nebo nasadit a sami spravovat kontroler příchozího přenosu dat podle vašeho výběru.

Container Apps AKS Web App for Containers
Nástroj pro vyrovnávání zatížení vrstvy 4 Spravovaná Azure Společná odpovědnost Spravovaná Azure
Nástroj pro vyrovnávání zatížení vrstvy 7 Spravovaná Azure Sdílené nebo samospravované Spravovaná Azure

Zjišťování služeb

V cloudových architekturách je možné moduly runtime kdykoli odebrat a znovu vytvořit, aby se prostředky znovu vyrovnaly, 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.

Container Apps AKS Web App for Containers
Zjišťování služeb 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 veřejné plně kvalifikované názvy domén příchozího přenosu dat (komunikace na 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é plně kvalifikované názvy domén příchozího přenosu dat. Služba Container Apps ale dále pokračuje tím, že umožní 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ů.

Container Apps AKS Web App for Containers
Konfigurace vlastních domén Out of the box BYO Out of the box
Spravovaný protokol TLS pro plně kvalifikované názvy domén Azure Out of the box – Out of the box
Spravovaný protokol TLS pro vlastní domény Ve verzi 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, zákazníci můžou využívat software z ekosystému Kubernetes, například oblíbeného správce certifikátů 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 ověření klienta i serveru při komunikaci. 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 potřebuje ověřit certifikát tak , že přistupuje k X-ARR-ClientCert hlavičce HTTP, 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. Automatické mTLS můžete také snadno povolit pro interní komunikaci mezi aplikacemi v jednom prostředí.

Vzájemné tls v AKS je možné implementovat prostřednictvím sítě služeb založené na Istio jako spravovaný doplněk, který zahrnuje funkce mTLS pro příchozí klientská připojení a komunikaci uvnitř clusteru 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.

Bezpečnostní aspekty

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.

Podrobné porovnání pečlivě zkontrolujte následující aspekty, 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 spravované pomocí 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.

Container Apps 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 virtuální sítě serveru API (Preview), kde je server API integrovaný do delegovaných 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.

Container Apps 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í sítě roviny dat

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 nebo 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.

Container Apps AKS Web App for Containers
Zásady sítě Plán Consumption: ❌
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ě se nepodporují v Container Apps ani Ve službě 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ě.

Container Apps AKS Web App for Containers
Skupiny zabezpečení sítě Plán Consumption: ✅
Vyhrazený plán: ✅		 ✅ ✅ Integrované aplikace virtuální sítě: pouze výchozí přenos dat

Omezení IP pro příchozí přenos dat

Omezení síťového provozu se obvykle používají prostřednictvím výše popsaných pravidel vrstvy 4. Ve scénářích PaaS aplikací bez integrace virtuální sítě ale může být užitečné omezit provoz na aplikační vrstvě.

Container Apps a Web App for Containers poskytují integrovaná omezení zdrojových IP adres pro příchozí přenos dat v jednotlivých aplikacích.

Container Apps AKS Web App for Containers
Omezení ip adres příchozího přenosu dat na aplikační vrstvě Out of the box Samoobslužná správa nebo spravovaný doplněk Out of the box
Spotřeba prostředků - Využívá prostředky clusteru. -

U úloh AKS závisí implementace na zvoleném kontroleru příchozího přenosu dat. Doplněk směrování spravovaných aplikací Azure i samoobslužný modul spotřebovávají prostředky clusteru.

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.

Container Apps AKS Web App for Containers
Integrace služby Key Vault ✅ ✅ ✅

Další informace naleznete v tématu:

Podpora spravované identity

Aplikace s přiřazenými spravovanými identitami mají přístup k prostředkům Azure bez hesel. Všechny služby kontejnerů uvedené v této příručce podporují spravované identity.

Container Apps AKS Web App for Containers
Podpora spravované identity ✅ ✅ ✅

Další informace naleznete v tématu:

Posouzení ohrožení zabezpečení a ochrany před hrozbami pomocí defenderu for Containers

Ochrana před ohroženími zabezpečení před hrozbami 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 modulu runtime Defender for Containers je ale 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.

Container Apps AKS Web App for Containers
Ochrana před internetovými útoky za běhu ❌ ✅ ❌

Další informace najdete v matici podpory kontejnerů v programu Defender for Cloud.

Upozorňujeme, že posouzení ohrožení zabezpečení imagí kontejnerů nejsou kontroly 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:

Standardní hodnoty zabezpečení pokrývají další integrace Azure, včetně šifrování hardwaru a protokolování, které jsou mimo rozsah pro tento článek.

Dobře navržená architektura 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í pro AKS najdete v tématu Přehledné architektury architektury – 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. Aktualizace můžete aktivovat ručně nebo můžete využít funkci kanálů automatického upgradu clusteru, abyste měli jistotu, že jsou clustery aktuální. Informace o opravách a upgradu clusterů AKS najdete v provozním průvodci AKS 2.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.

Container Apps AKS Web App for Containers
Aktualizace řídicí roviny Platforma Zákazník Platforma
Aktualizace a opravy hostitele Platforma Zákazník Platforma
Aktualizace a opravy imagí kontejneru 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í image kontejnerů, je vaší zodpovědností znovu sestavit image. 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í škálování označuje 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 si projděte velikosti virtuálních počítačů v dokumentaci k Azure 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í škálování označuje 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 úroveň consumption 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 horizontální navýšení kapacity a zahrnutí opětovného vyrovnávání instancí, takže také 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.

Container Apps AKS Web App for Containers
Horizontální navýšení a snížení kapacity infrastruktury Plán Consumption: Není k dispozici
Vyhrazený plán: konfigurovatelný		 Konfigurovatelné Konfigurovatelné
Flexibilní zřizování hardwaru Plán Consumption: Není k dispozici
Vyhrazený plán: abstrakce s profily úloh		 Libovolná skladová položka virtuálního počítače Roztržitý. Viz 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álovacích služeb. 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.

Container Apps AKS Web App for Containers
Horizontální navýšení kapacity kontejneru HTTP, TCP nebo metriky (procesor, paměť, řízené událostmi) Na základě metrik (procesor, paměť nebo vlastní) Ruční, na základě metrik 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.

Pozorovatelnost

Instrumentace úloh

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á instrumentace. Nevyžaduje se žádné změny kódu.
  • Ruční instrumentace. Minimální změny kódu potřebné k integraci a konfiguraci sady SDK nebo klienta.
Container Apps AKS Web App for Containers
Automatická instrumentace prostřednictvím platformy ❌ ❌ Částečná podpora*
Automatická instrumentace prostřednictvím agenta ❌ Částečná podpora* –
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 naleznete 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

Všechny služby kontejneru Azure poskytují funkce protokolu aplikací a platforem. Protokoly aplikací jsou protokoly konzoly, které jsou generovány 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í.

Hlavní rozdíly mezi funkcemi protokolování pro služby kontejneru se týkají protokolování platformy: co se protokoluje a jak se protokoly organizují interně. Azure Monitor je hlavní služba protokolování v Azure, která se integruje s těmito službami. Monitorování používá protokoly prostředků k oddělení protokolů , které pocházejí z různých zdrojů do kategorií. Jedním ze způsobů, jak určit, které protokoly jsou dostupné z každé služby Azure, je podívat se na kategorie protokolů prostředků, které jsou dostupné pro jednotlivé služby.

Container Apps AKS Web App for Containers
Podpora streamování protokolů (streamování v reálném čase) ✅ ✅ ✅
Podpora služby Azure Monitor ✅ ✅ ✅
Protokoly prostředků služby Azure Monitor Konzola a systém Server rozhraní API Kubernetes, audit, plánovač, automatické škálování clusteru a další ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs a další

Podrobný popis jednotlivých protokolů prostředků v tabulce zobrazíte tak, že vyberete odkazy v tabulce.

Tady je krátký přehled možností protokolování služeb kontejneru:

  • Container Apps abstrahuje všechny své interní protokoly Kubernetes do dvou kategorií. Jeden z protokolů konzoly obsahuje protokoly kontejneru úloh. Druhá kategorie systému obsahuje všechny protokoly související s platformou.
  • AKS poskytuje všechny protokoly související s Kubernetes a podrobnou kontrolu nad tím, co se dá protokolovat. Zachovává také úplnou kompatibilitu s klientskými nástroji Kubernetes pro streamování protokolů, jako je kubectl.
  • Web App for Containers poskytuje mnoho kategorií protokolů prostředků, protože její platforma (App Service) není výhradně určená pro úlohy kontejnerů. 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.

Dobře navržená architektura 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 úloh by měly vybrat odpovídající úroveň služby Azure a použít nezbytné konfigurace minimální instance pro implementaci automatického převzetí 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 rozsahu služeb

Spolehlivost se běžně měří metrikami řízenými firmami, 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 nic takového jako 100% úroveň služeb, protože selhání se vždy můžou vyskytovat v softwaru a hardwaru a v přírodě, například bouře a zemětřesení. Smlouva SLA není zárukou, ale spíše finančně zajištěnou smlouvou o dostupnosti služeb.

Nejnovější smlouvy SLA a podrobnosti najdete v dokumentu SLA pro služby 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.
  • Rovina dat. Fondy uzlů používají základní smlouvy SLA skladové položky virtuálního počítače.
  • Zóny dostupnosti. Pro tyto dvě roviny existují různé smlouvy SLA v závislosti na tom, jestli má cluster AKS povolené zóny dostupnosti a spouští více instancí napříč zónami dostupnosti.

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

Redundance se zónami dostupnosti

Zóny dostupnosti jsou samostatná 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 Container Apps AKS Web App for Containers
Podpora zón 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 úlohu zásadní. Vytváření těchto koncových bodů je ale pouze polovina řešení. Druhá polovina řídí, co hostitelské platformy dělá a jak, když dojde k selháním.

Pokud chcete lépe rozlišovat mezi typy sond stavu, podívejte se na předdefinované typy testů z Kubernetes:

  • Spuštění. Zkontroluje, jestli se aplikace úspěšně spustila.
  • Připravenost. Zkontroluje, jestli je aplikace připravená na zpracování příchozích požadavků.
  • Liveness. 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 provoz, dokud se instance nepovažuje za poškozenou.

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 Web App for Containers
Spouštěcí sondy ✅ ✅ Částečná podpora
Testy připravenosti ✅ ✅ ❌
Sondy živé aktivity ✅ ✅ ✅
Intervalová členitost Sekundy Sekundy 1 min.
Podpora protokolu HTTP(S)
TCP		 HTTP(S)
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 integrované 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.
  • Odešle kontrolu stavu 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. Instance, která není v pořádku, získá provoz po dobu nejméně 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é opravení

Identifikace chybné instance kontejneru a zastavení odesílání provozu do ní je spuštění. Dalším krokem je implementace automatického opravy. Automatické opravy je proces restartování aplikace při pokusu o zotavení ze stavu, který není v pořádku. Tady je postup porovnání tří služeb kontejneru:

  • 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 automatické opravy, která monitoruje a restartuje instance. Nesouvisí přímo s kontrolami stavu. 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.

Container Apps AKS Web App for Containers
Strategie nulového výpadku Kumulativní aktualizace Kumulativní aktualizace a všechny ostatní strategie Kubernetes Sloty nasazení

Upozorňujeme, že architektury aplikací musí také podporovat nasazení nulového výpadku. Pokyny najdete v architektuře Azure.

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.

Container Apps AKS Web App for Containers
Limity prostředků (procesor nebo paměť) Na aplikaci nebo kontejner Na aplikaci nebo kontejner
Na obor názvů		 Podle plánu služby App Service
  • Web App for Containers: V jednom 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: Omezení procesoru a paměti můžete nastavit pro každou aplikaci ve vašem prostředí. Jste ale 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 podobné oboru názvů Kubernetes.
  • AKS: Můžete zvolit libovolnou kombinaci vCPU a paměti, pokud uzly mají hardware, který ho podporuje. Pokud chcete segmentovat cluster tímto způsobem, můžete také omezit prostředky na úrovni oboru názvů.

Dobře navržená architektura 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ší konfigurovatelnost a rozšiřitelnost. 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 a další. 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