Dela via

Allmänna arkitekturöverväganden för att välja en Azure-containertjänst

  • Artikel

Den här artikeln vägleder dig genom processen att välja en Azure-containertjänst. Den ger en översikt över överväganden på funktionsnivå som är vanliga och viktiga för vissa arbetsbelastningar. Det kan hjälpa dig att fatta beslut för att säkerställa att din arbetsbelastning uppfyller kraven för tillförlitlighet, säkerhet, kostnadsoptimering, driftseffektivitet och prestandaeffektivitet.

Kommentar

Den här artikeln är del två i en serie som börjar med Välj en Azure-containertjänst. Vi rekommenderar starkt att du läser den översiktsartikeln först för att få en kontext för dessa arkitekturöverväganden.

Översikt

Övervägandena i den här artikeln är indelade i fyra kategorier:

Överväganden för arkitektur och nätverk

  • Stöd för operativsystem
  • Nätverksadressutrymmen
  • Förstå trafikflödet
  • Planera undernät
  • Antal inkommande IP-adresser som är tillgängliga
  • Användardefinierade vägar och stöd för NAT-gateway
  • Integrering av privata nätverk
  • Protokolltäckning
  • Belastningsutjämning
  • Tjänsteidentifiering
  • Anpassade domäner och hanterad TLS
  • Ömsesidig TLS
  • Nätverksbegrepp för specifika Azure-tjänster

Säkerhetsöverväganden

  • Tillhandahålla säkerhet för trafik inom kluster med hjälp av nätverksprinciper
  • Nätverkssäkerhetsgrupper
  • Azure Key Vault-integrering
  • Stöd för hanterad identitet
  • Hotskydd och sårbarhetsbedömningar med Defender för containrar
  • Säkerhetsbaslinjer
  • Azure Well-Architected Framework for Security

Operativa överväganden

  • Uppdateringar och korrigeringar
  • Uppdateringar av containeravbildningar
  • Skalbarhet för lodrät infrastruktur
  • Skalbarhet för horisontell infrastruktur
  • Skalbarhet för program
  • Överskådlighet
  • Välkonstruerat ramverk för driftskvalitet

Tillförlitlighetsöverväganden

  • Serviceavtal
  • Redundans via tillgänglighetszoner
  • Hälsokontroller och självåterställning
  • Distributioner av program med noll driftstopp
  • Resursgränser
  • Välkonstruerat ramverk för tillförlitlighet

Observera att den här artikeln fokuserar på en delmängd av Azure-containertjänster som erbjuder en mogen funktionsuppsättning för webbprogram och API:er, nätverk, observerbarhet, utvecklarverktyg och åtgärder: Azure Kubernetes Service (AKS), Azure Container Apps och Web App for Containers. En fullständig lista över alla Azure-containertjänster finns på produktkategorisidan för containertjänster.

Kommentar

I den här guiden refererar termen arbetsbelastning till en samling programresurser som stöder ett affärsmål eller körning av en affärsprocess. En arbetsbelastning använder flera komponenter, till exempel API:er och datalager, som fungerar tillsammans för att leverera specifika funktioner från slutpunkt till slutpunkt.

Arkitekturöverväganden

Det här avsnittet beskriver arkitektoniska beslut som är svåra att vända eller korrigera utan att kräva betydande driftstopp eller omdistribution. Det är särskilt nödvändigt att tänka på detta för grundläggande komponenter som nätverk och säkerhet.

Dessa överväganden är inte specifika för väldefinierade ramverkspelare. De förtjänar dock extra granskning och utvärdering mot företagens krav när du väljer en Azure-containertjänst.

Stöd för operativsystem

De flesta containerbaserade program körs i Linux-containrar, som stöds av alla Azure-containertjänster. Alternativen är mer begränsade för arbetsbelastningskomponenter som kräver Windows-containrar.

Container Apps AKS Web App for Containers
Linux-stöd ✅ ✅ ✅
Windows-stöd ❌ ✅ ✅
Stöd för blandat operativsystem ❌ ✅ ❌*

*Stöd för blandat operativsystem för Web App for Containers kräver separata Azure App Service-planer för Windows och Linux.

Nätverksöverväganden

Det är viktigt att förstå nätverksdesign tidigt i dina planeringsprocesser på grund av säkerhets- och efterlevnadsbegränsningar och införda riktlinjer. I allmänhet beror de stora skillnaderna mellan de Azure-tjänster som beskrivs i den här guiden på inställningar:

  • Container Apps är ett PaaS-erbjudande som tillhandahåller många Azure-hanterade nätverksfunktioner, till exempel tjänstidentifiering och interna hanterade domäner. Arbetsbelastningsteam som behöver lite mer konfigurerbarhet kan använda arbetsbelastningar/dedikerade profiler innan de överväger alternativ för att maximera sina nätverksalternativ.
  • AKS är den mest konfigurerbara av de tre tjänsterna och ger mest kontroll över nätverksflödet. Den tillhandahåller till exempel anpassade ingresskontrollanter och kontroll av intraklustertrafik via Kubernetes-nätverksprinciper. Arbetsbelastningsteam kan dra nytta av olika Azure-hanterade nätverkstillägg, samt installera och använda tillägg från det bredare Kubernetes-ekosystemet.
  • Web App for Containers är en funktion i App Service. Därför är nätverksbegreppen, särskilt integrering av privata nätverk, mycket specifika för App Service. Den här tjänsten är bekant för arbetsbelastningsteam som redan använder App Service. Team som inte har erfarenhet av App Service och som vill ha en mer välbekant integrering av virtuella Azure-nätverk uppmuntras att överväga Container Apps.

Tänk på att nätverk är ett grundläggande infrastrukturlager. Det är ofta svårt att göra ändringar i designen utan att distribuera arbetsbelastningen igen, vilket kan leda till stilleståndstid. Om din arbetsbelastning har specifika nätverkskrav bör du därför granska det här avsnittet noggrant innan du begränsar valet av Azure-containertjänst.

Nätverksadressutrymmen

När du integrerar program i virtuella nätverk måste du göra en viss IP-adressplanering för att säkerställa att tillräckligt många IP-adresser är tillgängliga för containerinstanser. Under den här processen planerar du ytterligare adresser för uppdateringar, blå/gröna distributioner och liknande situationer där extra instanser distribueras, vilket förbrukar ytterligare IP-adresser.

Container Apps AKS Web App for Containers
Dedikerade undernät Förbrukningsplan: valfritt
Dedikerad plan: krävs		 Obligatoriskt Valfritt
KRAV för IP-adress Förbrukningsplan: Se Förbrukningsmiljö.
Dedikerad plan: Se Miljö för arbetsbelastningsprofiler.		 Se Virtuella Azure-nätverk för AKS. Se Krav för App Service-undernät.

Observera att AKS-kraven är beroende av det valda nätverks-plugin-programmet. Vissa nätverks-plugin-program för AKS kräver bredare IP-reservationer. Information ligger utanför omfånget för den här artikeln. Mer information finns i Nätverksbegrepp för AKS.

Förstå trafikflödet

De typer av trafikflöden som krävs för en lösning kan påverka nätverksdesignen.

Följande avsnitt innehåller information om olika nätverksbegränsningar. Dessa begränsningar påverkar ditt behov av att distribuera ytterligare undernät, beroende på om du behöver:

  • Flera samlokaliserade arbetsbelastningar.
  • Privat och/eller offentlig ingress.
  • Ett åtkomststyrt flöde av trafik mellan öst och väst i ett kluster (för Container Apps och AKS) eller i ett virtuellt nätverk (för alla Azure-containertjänster).

Planering av undernät

Att se till att du har ett undernät som är tillräckligt stort för att inkludera instanser av ditt program för din arbetsbelastning är inte den enda faktorn som avgör nätverkets fotavtryck där dessa program distribueras.

Container Apps AKS Web App for Containers
Stöd för samlokaliserade arbetsbelastningar i ett undernät* ❌* ✅ GÄLLER INTE*

*Detta beskriver bästa praxis, inte en teknisk begränsning.

För Container Apps gäller undernätsintegrering endast för en enda Container Apps-miljö. Varje Container Apps-miljö är begränsad till en enda inkommande IP-adress, offentlig eller privat.

Varje Container Apps-miljö är endast avsedd för en enda arbetsbelastning där beroende program samallokeras. Därför måste du introducera ytterligare Azure-nätverksinstallationer för ingressbelastningsutjämning om du behöver både offentliga och privata ingresser. Exempel är Azure Application Gateway och Azure Front Door. Om du har flera arbetsbelastningar som måste separeras krävs ytterligare Container Apps-miljöer, så ytterligare ett undernät måste allokeras för varje miljö.

AKS tillhandahåller detaljerad flödeskontroll mellan öst och väst i klustret i form av Kubernetes-nätverksprincip. Med den här flödeskontrollen kan du segmentera flera arbetsbelastningar med olika nätverkssäkerhetsgränser inom samma kluster.

För Web App for Containers finns det inga begränsningar för hur många appar du kan integrera med ett enda undernät, så länge undernätet är tillräckligt stort. Det finns inga metodtips för åtkomstkontroll mellan webbappar i samma virtuella nätverk. Varje webbapp hanterar oberoende åtkomstkontroll för trafik i öst-väst eller nord-syd från det virtuella nätverket eller Internet.

Kommentar

Du kan inte ändra storlek på undernät som har resurser distribuerade i dem. Var extra försiktig när du planerar ditt nätverk för att undvika att behöva distribuera om hela arbetsbelastningskomponenter, vilket kan leda till driftstopp.

Antal inkommande IP-adresser som är tillgängliga

I följande tabell tar vi hänsyn till föregående undernätsplaneringsavsnitt för att definiera hur många IP-adresser som kan exponeras för ett godtyckligt antal program som finns i en enda distribution av en Azure-containertjänst.

Container Apps AKS Web App for Containers
Antal inkommande IP-adresser En Många App Service-miljö: En
Ingen App Service-miljö: Många

Container Apps tillåter en IP-adress per miljö, offentlig eller privat. AKS tillåter valfritt antal IP-adresser, offentliga eller privata. Web App for Containers, utanför en App Service-miljö, tillåter en offentlig IP-adress för alla appar i en App Service-plan och flera, olika privata IP-adresser som använder privata Azure-slutpunkter.

Det är viktigt att observera att webbappar som är integrerade i en App Service-miljö endast tar emot trafik via den enda inkommande IP-adressen som är associerad med App Service Environment, oavsett om de är offentliga eller privata.

Användardefinierade vägar och stöd för NAT-gateway

Om en arbetsbelastning kräver användardefinierade vägar (UDR) och NAT-gatewayfunktioner för detaljerad nätverkskontroll, kräver Container Apps användning av arbetsbelastningsprofiler. UDR- och NAT-gatewaykompatibilitet är inte tillgängligt i förbrukningsplanen för ACA.

AKS och Web App for Containers implementerar dessa två nätverksfunktioner via standardfunktioner för virtuella nätverk respektive integrering av virtuella nätverk. För att utveckla är AKS-nodpooler och Web App for Containers i en App Service-miljö redan direkta virtuella nätverksresurser. Web App for Containers som inte finns i en App Service Environment har stöd för UDR och NAT-gateway via integrering av virtuella nätverk. Med integrering av virtuella nätverk finns resursen tekniskt sett inte direkt i det virtuella nätverket, utan alla dess utgående åtkomstflöden via det virtuella nätverket och nätverkets associerade regler påverkar trafiken som förväntat.

Container Apps AKS Web App for Containers
UDR-stöd Endast förbrukningsplan: ❌
Arbetsbelastningsprofilplan: ✅		 ✅ ✅
STÖD för NAT-gateway Endast förbrukningsplan: ❌
Arbetsbelastningsprofilplan: ✅		 ✅ ✅

Integrering av privata nätverk

För arbetsbelastningar som kräver strikt privat Layer 4-nätverk för både inkommande och utgående bör du överväga Container Apps, AKS och App Service Environment SKU för en enda klientorganisation, där arbetsbelastningar distribueras till ett självhanterat virtuellt nätverk, vilket ger de vanliga detaljerade privata nätverkskontrollerna.

Container Apps AKS Web App for Containers
Privat ingress till ett virtuellt nätverk ✅ ✅ Via privat slutpunkt
Privat utgående från ett virtuellt nätverk ✅ ✅ Via integrering av virtuella nätverk
Fullständigt undertryckt offentlig slutpunkt ✅ ✅ Endast App Service-miljö
Privat nätverk med Web App for Containers

Web App for Containers innehåller ytterligare nätverksfunktioner som inte visas på samma sätt av de andra Azure-tjänsterna som beskrivs i den här artikeln. För att implementera strikta krav för privata nätverk måste arbetsbelastningsteamen bekanta sig med dessa nätverksbegrepp. Granska dessa nätverksfunktioner noggrant:

Om du vill ha en PaaS-lösning och föredrar nätverksbegrepp som delas mellan flera Azure-lösningar bör du överväga Container Apps.

Protokolltäckning

Ett viktigt övervägande för värdplattformen är de nätverksprotokoll som stöds för inkommande programbegäranden (ingress). Web App for Containers är det strängaste alternativet och stöder endast HTTP och HTTPS. Container Apps tillåter dessutom inkommande TCP-anslutningar. AKS är den mest flexibla och stöder obegränsad användning av TCP och UDP på självvalda portar.

Container Apps AKS Webbapp för containrar
Stöd för protokoll och portar HTTP (port 80)*
HTTPS (port 443)*
TCP (portarna 1-65535, utom 80 och 443)		 TCP (valfri port)
UDP (valfri port)		 HTTP (port 80)
HTTPS (port 443)
WebSocket-stöd ✅ ✅ ✅
Stöd för HTTP/2 ✅ ✅ ✅

*I Container Apps-miljön kan HTTP/S exponeras på valfri port för kommunikation mellan kluster. I det scenariot gäller inte inbyggda HTTP-funktioner för Container Apps som CORS och sessionstillhörighet.

Både Container Apps och Web App for Containers stöder TLS 1.2 för deras inbyggda HTTPS-ingress.

Belastningsutjämning

Med Container Apps och Web App for Containers abstraherar Azure helt lastbalanserarna Layer 4 och Layer 7.

AKS använder däremot en modell för delat ansvar där Azure hanterar den underliggande Azure-infrastruktur som arbetsbelastningsteamet konfigurerar genom att samverka med Kubernetes-API:et. För Layer 7-belastningsutjämning i AKS kan du välja ett Azure-hanterat alternativ, till exempel tillägget FÖR AKS-hanterad programroutning eller Application Gateway för containrar, eller distribuera och självhantera valfri ingresskontrollant.

Container Apps AKS Web App for Containers
Layer 4-lastbalanserare Azure-hanterad Delat ansvar Azure-hanterad
Layer 7-lastbalanserare Azure-hanterad Delad eller självhanterad Azure-hanterad

Tjänsteidentifiering

I molnarkitekturer kan körningar tas bort och återskapas när som helst för att balansera om resurser, så instans-IP-adresser ändras regelbundet. Dessa arkitekturer använder fullständigt kvalificerade domännamn (FQDN) för tillförlitlig och konsekvent kommunikation.

Container Apps AKS Web App for Containers
Tjänstidentifiering Azure-hanterat FQDN Kubernetes kan konfigureras Azure-hanterat FQDN

Web Apps for Containers tillhandahåller offentliga inkommande (nord-syd-kommunikation) FQDN:er direkt. Ingen ytterligare DNS-konfiguration krävs. Det finns dock ingen inbyggd mekanism för att underlätta eller begränsa trafik mellan andra appar (kommunikation mellan öst och väst).

Container Apps tillhandahåller även offentliga inkommande FQDN:er. Container Apps går dock längre genom att tillåta att appens FQDN exponeras och begränsa trafiken endast i miljön. Den här funktionen gör det enklare att hantera kommunikation mellan öst och väst och aktivera komponenter som Dapr.

Kubernetes-distributioner kan inte identifieras från början inom eller utanför klustret. Du måste skapa Kubernetes-tjänster enligt kubernetes-API:et, som sedan exponerar program för nätverket på ett adresserbart sätt.

Viktigt!

Endast Container Apps och AKS tillhandahåller tjänstidentifiering via interna DNS-scheman i respektive miljö. Den här funktionen kan förenkla DNS-konfigurationer i utvecklings-/test- och produktionsmiljöer. Du kan till exempel skapa dessa miljöer med godtyckliga tjänstnamn som bara måste vara unika i miljön eller klustret, så att de kan vara desamma i utvecklings-/test- och produktionsmiljön. Med Web App for Containers måste tjänstnamn vara unika i olika miljöer för att undvika konflikter med Azure DNS.

Anpassade domäner och hanterad TLS

Både Container Apps och Web App for Containers tillhandahåller färdiga lösningar för anpassade domäner och certifikathantering.

Container Apps AKS Web App for Containers
Konfigurera anpassade domäner Ur lådan BYO Ur lådan
Hanterad TLS för Azure FQDN Ur lådan Ej tillämpligt Ur lådan
Hanterad TLS för anpassade domäner I förhandsversion BYO Ut ur lådan eller BYO

AKS-användare ansvarar för att hantera DNS-, klusterkonfigurationer och TLS-certifikat för sina anpassade domäner. Även om AKS inte erbjuder hanterad TLS kan kunderna utnyttja programvara från Kubernetes-ekosystemet, till exempel den populära cert-managern för att hantera TLS-certifikat.

Ömsesidig TLS

Ett annat alternativ för att begränsa inkommande trafik är ömsesidig TLS (mTLS). Ömsesidig TLS är ett säkerhetsprotokoll som säkerställer att både klienten och servern i kommunikationen autentiseras. För att utföra autentiseringen utbyter och verifierar båda parter certifikat innan några data överförs.

Web App for Containers har inbyggt mTLS-stöd för inkommande klientanslutningar. Programmet måste dock verifiera certifikatet genom att X-ARR-ClientCert komma åt HTTP-huvudet som App Service-plattformen vidarebefordrar.

Container Apps har också inbyggt stöd för mTLS. Klientcertifikatet vidarebefordras till programmet i HTTP-huvudet X-Forwarded-Client-Cert. Du kan också enkelt aktivera automatisk mTLS för intern kommunikation mellan appar i en enda miljö.

Ömsesidig TLS i AKS kan implementeras via det Istio-baserade tjänstnätet som ett hanterat tillägg, som innehåller mTLS-funktioner för inkommande klientanslutningar och kommunikation mellan tjänster inom klustret. Arbetsbelastningsteam kan också välja att installera och hantera ett annat service mesh-erbjudande från Kubernetes-ekosystemet. De här alternativen gör mTLS-implementeringen i Kubernetes till den mest flexibla.

Tjänstspecifika nätverksbegrepp

I föregående avsnitt beskrivs några av de vanligaste övervägandena att ta hänsyn till. Mer information och mer information om nätverksfunktioner som är specifika för enskilda Azure-containertjänster finns i följande artiklar:

Föregående avsnitt fokuserar på nätverksdesign. Fortsätt till nästa avsnitt om du vill veta mer om nätverkssäkerhet och skydd av nätverkstrafik.

Säkerhetsfrågor

Om säkerhetsriskerna inte åtgärdas kan det leda till obehörig åtkomst, dataintrång eller läckage av känslig information. Containrar erbjuder en inkapslad miljö för ditt program. Värdsystemen och underliggande nätverksöverlägg kräver dock ytterligare skyddsräcken. Ditt val av Azure-containertjänst måste stödja dina specifika krav för att skydda varje program individuellt och tillhandahålla lämpliga säkerhetsåtgärder för att förhindra obehörig åtkomst och minska risken för attacker.

Översikt över säkerhetsjämförelse

De flesta Azure-tjänster, inklusive Container Apps, AKS och Web App for Containers, integreras med viktiga säkerhetserbjudanden, inklusive Key Vault och hanterade identiteter.

Av tjänsterna i den här guiden erbjuder AKS den mest konfigurerbarhet och utökningsbarhet delvis genom att de underliggande komponenterna visas, som ofta kan skyddas via konfigurationsalternativ. Kunder kan till exempel inaktivera lokala konton till Kubernetes API-servern eller aktivera automatiska uppdateringar av underliggande noder via konfigurationsalternativ.

En detaljerad jämförelse finns i följande överväganden för att säkerställa att dina arbetsbelastningssäkerhetskrav kan uppfyllas.

Säkerhet för Kubernetes-kontrollplan

AKS erbjuder den största flexibiliteten för de tre alternativ som beskrivs i den här artikeln, vilket ger fullständig åtkomst till Kubernetes-API:et så att du kan anpassa containerorkestrering. Den här åtkomsten till Kubernetes API representerar dock också en betydande attackyta och du måste skydda den.

Viktigt!

Observera att det här avsnittet inte är relevant för Web App for Containers, som använder Azure Resource Manager-API:et som kontrollplan.

Identitetsbaserad säkerhet

Kunderna ansvarar för att skydda identitetsbaserad åtkomst till API:et. Kubernetes tillhandahåller ett eget autentiserings- och auktoriseringshanteringssystem, som också måste skyddas med åtkomstkontroller.

För att dra nytta av ett enda glasplan för identitets- och åtkomsthantering i Azure är det bästa praxis att inaktivera Kubernetes-specifika lokala konton och i stället implementera AKS-hanterad Microsoft Entra-integrering tillsammans med Azure RBAC för Kubernetes. Om du implementerar den här bästa metoden behöver administratörer inte utföra identitets- och åtkomsthantering på flera plattformar.

Container Apps AKS
Åtkomstkontroller för Kubernetes API Ingen behörighet Fullständig åtkomst

Kunder som använder Container Apps har inte åtkomst till Kubernetes API. Microsoft tillhandahåller säkerhet för det här API:et.

Nätverksbaserad säkerhet

Om du vill begränsa nätverksåtkomsten till Kubernetes-kontrollplanet måste du använda AKS, som innehåller två alternativ. Det första alternativet är att använda privata AKS-kluster, som använder Azure Private Link mellan API-serverns privata nätverk och AKS-klustrets privata nätverk. Det andra alternativet är API Server VNet-integrering (förhandsversion) där API-servern är integrerad i ett delegerat undernät. Mer information finns i dokumentationen.

Det finns konsekvenser för implementering av nätverksbegränsad åtkomst till Kubernetes-API:et. Framför allt kan hantering endast utföras inifrån det privata nätverket. Det innebär vanligtvis att du behöver distribuera lokalt installerade agenter för Azure DevOps eller GitHub Actions. Mer information om andra begränsningar finns i den produktspecifika dokumentationen.

Container Apps AKS
Kubernetes API-nätverkssäkerhet Kan inte konfigureras i PaaS Konfigurerbar: offentlig IP-adress eller privat IP-adress

Dessa överväganden gäller inte för Container Apps. Eftersom det är PaaS abstraherar Microsoft bort den underliggande infrastrukturen.

Nätverkssäkerhet för dataplan

Följande nätverksfunktioner kan användas för att styra åtkomsten till, från och inom en arbetsbelastning.

Använda nätverksprinciper för att ge säkerhet för trafik inom klustret

Vissa säkerhetsstatusar kräver nätverkstrafiksegregering i en miljö, till exempel när du använder miljöer med flera klienter för att vara värd för flera eller flernivåbaserade program. I dessa scenarier bör du välja AKS och implementera nätverksprinciper, en molnbaserad teknik som möjliggör detaljerad konfiguration av Layer 4-nätverk i Kubernetes-kluster.

Container Apps AKS Web App for Containers
Nätverksprinciper Förbrukningsplan: ❌
Dedikerad plan: ❌		 ✅ ❌

Av de tre Azure-tjänster som beskrivs i den här artikeln är AKS den enda som stöder ytterligare arbetsbelastningsisolering i klustret. Nätverksprinciper stöds inte i Container Apps eller Web App for Containers.

Nätverkssäkerhetsgrupper

I alla scenarier kan du reglera nätverkskommunikationen i det bredare virtuella nätverket med hjälp av nätverkssäkerhetsgrupper, vilket gör att du kan använda Layer 4-trafikregler som reglerar inkommande och utgående trafik på den virtuella nätverksnivån.

Container Apps AKS Web App for Containers
Nätverkssäkerhetsgrupper Förbrukningsplan: ✅
Dedikerad plan: ✅		 ✅ ✅ VNet-integrerade appar: endast utgående

IP-begränsningar för inkommande

Nätverkstrafikbegränsningar tillämpas vanligtvis via Layer 4-regler som beskrivs ovan. I PaaS-scenarier med program utan integrering av virtuella nätverk kan det dock vara användbart att begränsa trafiken på programnivån.

Container Apps och Web App for Containers tillhandahåller inbyggda käll-IP-begränsningar för inkommande trafik i enskilda program.

Container Apps AKS Web App for Containers
Ingress-IP-begränsningar på programnivå Ur lådan Självhanterat eller via hanterat tillägg Ur lådan
Resursförbrukning - Använder klusterresurser -

För AKS-arbetsbelastningar beror implementeringen på den valda ingresskontrollanten. Både självhanterade och Azure-hanterade programdirigeringstillägg förbrukar klusterresurser.

Säkerhet på programnivå

Du måste skydda arbetsbelastningar inte bara på nätverks- och infrastrukturnivå, utan även på arbetsbelastnings- och programnivå. Azure-containerlösningar integreras med Azure-säkerhetserbjudanden för att standardisera säkerhetsimplementering och kontroller för dina program.

Key Vault-integrering

Det är en bra idé att lagra och hantera hemligheter, nycklar och certifikat i en nyckelhanteringslösning som Key Vault, som ger förbättrad säkerhet för dessa komponenter. I stället för att lagra och konfigurera hemligheter i kod eller i en Azure-beräkningstjänst bör alla program integreras med Key Vault.

Med Key Vault-integrering kan programutvecklare fokusera på sin programkod. Alla tre Azure-containertjänster som beskrivs i den här artikeln kan automatiskt synkronisera hemligheter från Key Vault-tjänsten och tillhandahålla dem till programmet, vanligtvis som miljövariabler eller monterade filer.

Container Apps AKS Web App for Containers
Key Vault-integrering ✅ ✅ ✅

Mer information finns i:

Stöd för hanterad identitet

Program med tilldelade hanterade identiteter kan komma åt Azure-resurser utan lösenord. Alla containertjänster som nämns i den här guiden stöder hanterade identiteter.

Container Apps AKS Web App for Containers
Stöd för hanterad identitet ✅ ✅ ✅

Mer information finns i:

Hotskydd och sårbarhetsbedömningar med Defender för containrar

Skydd mot sårbarheter är också viktigt. Det är en bra idé att använda Defender för containrar. Sårbarhetsbedömningar stöds i Azure-containerregister, så de kan användas av alla Azure-containertjänster, inte bara de som beskrivs i den här artikeln. Körningsskydd för Defender för containrar är dock endast tillgängligt för AKS.

Eftersom AKS exponerar det inbyggda Kubernetes-API:et kan klustersäkerhet också utvärderas med Kubernetes-specifika säkerhetsverktyg från Kubernetes-ekosystemet.

Container Apps AKS Web App for Containers
Skydd mot körningshot ❌ ✅ ❌

Mer information finns i Stödmatris för containrar i Defender för molnet.

Observera att sårbarhetsbedömningar för containeravbildningar inte är realtidsgenomsökningar. Azure-containerregistret genomsöks med jämna mellanrum.

Säkerhetsbaslinjer

I allmänhet integrerar de flesta Azure-containertjänster Azure-säkerhetserbjudanden. Tänk på att en uppsättning säkerhetsfunktioner bara är en liten del av implementeringen av molnsäkerhet. Mer information om hur du implementerar säkerhet för containertjänster finns i följande tjänstspecifika säkerhetsbaslinjer:

Säkerhetsbaslinjerna omfattar andra Azure-integreringar, inklusive maskinvarukryptering och loggning, som ligger utanför omfånget för den här artikeln.

Välkonstruerat ramverk för säkerhet

Den här artikeln fokuserar på de största skillnaderna mellan funktionerna för containertjänster som beskrivs här.

Mer fullständig säkerhetsvägledning om AKS finns i Well-Architected Framework review – AKS.

Operativa överväganden

För att kunna köra en arbetsbelastning i produktion måste teamen implementera metodtips för driftseffektivitet, inklusive centraliserad loggning, övervakning, skalbarhet, regelbundna uppdateringar och korrigeringar samt avbildningshantering.

Uppdateringar och korrigeringar

Det är viktigt att ett programs underliggande operativsystem uppdateras och korrigeras regelbundet. Tänk dock på att det finns en risk för fel vid varje uppdatering. Det här avsnittet och nästa beskriver de viktigaste övervägandena för de tre containertjänsterna när det gäller det delade ansvaret mellan kunden och plattformen.

Som en hanterad Kubernetes-tjänst tillhandahåller AKS uppdaterade avbildningar för nodoperativsystemet och kontrollplanskomponenterna. Men arbetsbelastningsteamen ansvarar för att tillämpa uppdateringar på sina kluster. Du kan utlösa uppdateringar manuellt eller utnyttja funktionen för automatisk uppgradering av klusterkanaler för att säkerställa att dina kluster är uppdaterade. Mer information om hur du korrigerar och uppgraderar AKS-kluster finns i aks dag-2-driftguiden.

Container Apps och Web App for Containers är PaaS-lösningar. Azure ansvarar för att hantera uppdateringar och korrigeringar, så att kunderna kan undvika komplexiteten i AKS-uppgraderingshanteringen.

Container Apps AKS Web App for Containers
Kontrollplansuppdateringar Plattform Kund Plattform
Värduppdateringar och korrigeringar Plattform Kund Plattform
Uppdateringar och korrigeringar av containeravbildningar Kunder Kunder Kunder

Uppdateringar av containeravbildningar

Oavsett Azure-containerlösningen ansvarar kunderna alltid för sina egna containeravbildningar. Om det finns säkerhetskorrigeringar för containerbasavbildningar är det ditt ansvar att återskapa avbildningarna. Om du vill få aviseringar om dessa säkerhetsrisker använder du Defender för containrar för containrar som finns i Container Registry.

Skalbarhet

Skalning används för att justera resurskapaciteten för att uppfylla kraven, lägga till mer kapacitet för att säkerställa prestanda och ta bort outnyttjad kapacitet för att spara pengar. När du väljer en containerlösning måste du överväga infrastrukturbegränsningar och skalningsstrategier.

Skalbarhet för lodrät infrastruktur

Lodrät skalning syftar på möjligheten att öka eller minska befintlig infrastruktur, dvs. beräknings-CPU och minne. Olika arbetsbelastningar kräver olika mängder beräkningsresurser. När du väljer en Azure-containerlösning måste du vara medveten om de maskinvaru-SKU-erbjudanden som är tillgängliga för en viss Azure-tjänst. De varierar och kan medföra ytterligare begränsningar.

För AKS läser du storlekarna för virtuella datorer i Azure-dokumentationen och AKS-begränsningarna per region.

De här artiklarna innehåller information om SKU-erbjudanden för de andra två tjänsterna:

Skalbarhet för horisontell infrastruktur

Horisontell skalning syftar på möjligheten att öka eller minska kapaciteten via ny infrastruktur, till exempel VM-noder. När skalningen ökar eller minskar abstraherar förbrukningsnivån containerappar de underliggande virtuella datorerna. För de återstående Azure-containertjänsterna hanterar du den horisontella skalningsstrategin med hjälp av standard-API:et för Azure Resource Manager.

Observera att utskalning och inskalning omfattar ombalansering av instanser, så det skapar också en risk för stilleståndstid. Risken är mindre än motsvarande risk med vertikal skalning. Arbetsbelastningsteamen ansvarar dock alltid för att se till att deras program kan hantera fel och för att implementera ansenliga nystartade företag och avstängningar av sina program för att undvika driftstopp.

Container Apps AKS Web App for Containers
Infrastrukturskalning in och ut Förbrukningsplan: Ej tillämpligt
Dedikerad plan: kan konfigureras		 Konfigureringsbart Konfigureringsbart
Flexibel maskinvaruetablering Förbrukningsplan: Ej tillämpligt
Dedikerad plan: abstrakt med arbetsbelastningsprofiler		 Valfri VM-SKU Abstraherade. Se App Service-plan.

Viktigt!

Alternativen för maskinvaruetablering som är tillgängliga via containerappars dedikerade plan (arbetsbelastningsprofiler) och Web App for Containers (App Service-planer) är inte lika flexibla som AKS. Du måste bekanta dig med de SKU:er som är tillgängliga i varje tjänst för att säkerställa att dina behov uppfylls.

Skalbarhet för program

Det typiska måttet för att utlösa skalning av infrastruktur och program är resursförbrukning: CPU och minne. Vissa containerlösningar kan skala antalet containerinstanser med mått med programspecifik kontext, till exempel HTTP-begäranden. AKS och Container Apps kan till exempel skala containerinstanser baserat på meddelandeköer via KEDA och många andra mått via dess skalare. De här funktionerna ger flexibilitet när du väljer skalbarhetsstrategin för ditt program. Web App for Containers förlitar sig på skalbarhetsalternativen som tillhandahålls av Azure. (Se följande tabell.) Web App for Containers stöder inte anpassade skalningskonfigurationer som KEDA.

Container Apps AKS Web App for Containers
Utskalning av container HTTP, TCP eller måttbaserad (CPU, minne, händelsedriven). Måttbaserad (CPU, minne eller anpassad). Manuell, måttbaserad eller automatisk (förhandsversion).
Händelsedriven skalbarhet Ja. Molnbaserat. Ja. Molnbaserat. Ytterligare konfiguration krävs. Ja. Azure-resursspecifik.

Överskådlighet

Arbetsbelastningsinstrumentation

Det kan vara svårt att samla in mått för komplexa eller flernivåbaserade program. För att få mått kan du integrera containerbaserade arbetsbelastningar med Azure Monitor på två sätt:

  • Automatisk instrumentering. Inga kodändringar krävs.
  • Manuell instrumentering. Minimala kodändringar som krävs för att integrera och konfigurera SDK och/eller klienten.
Container Apps AKS Web App for Containers
Automatisk instrumentering via plattform ❌ ❌ Partiellt stöd*
Automatisk instrumentering via agent ❌ Partiellt stöd* Ej tillämpligt
Manuell instrumentering Via SDK eller OpenTelemetry Via SDK eller OpenTelemetry Via SDK eller OpenTelemetry

*AKS och Web App for Containers stöder automatisk instrumentering för vissa konfigurationer av Linux- och Windows-arbetsbelastningar, beroende på programspråket. För mer information, se dessa artiklar:

Instrumentering i programkod är programutvecklares ansvar, så det är oberoende av vilken Azure-containerlösning som helst. Din arbetsbelastning kan använda lösningar som:

Loggar

Alla Azure-containertjänster tillhandahåller funktioner för program- och plattformsloggar. Programloggar är konsolloggar som genereras av din arbetsbelastning. Plattformsloggar samlar in händelser som inträffar på plattformsnivå, utanför programmets omfång, till exempel skalning och distributioner.

De största skillnaderna mellan loggningsfunktionerna för containertjänster gäller plattformsloggning: vad som loggas och hur loggar organiseras internt. Azure Monitor är den huvudsakliga loggningstjänsten i Azure som integreras med dessa tjänster. Monitor använder resursloggar för att separera loggar som kommer från olika källor i kategorier. Ett sätt att avgöra vilka loggar som är tillgängliga från varje Azure-tjänst är att titta på de resursloggkategorier som är tillgängliga för var och en av tjänsterna.

Container Apps AKS Web App for Containers
Stöd för loggströmning (realtidsströmning) ✅ ✅ ✅
Stöd för Azure Monitor ✅ ✅ ✅
Azure Monitor-resursloggar Konsol och system Kubernetes API-server, Granskning, Scheduler, Autoskalning av kluster med mera ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs med mera

Om du vill ha en detaljerad beskrivning av var och en av resursloggarna i tabellen väljer du länkarna i tabellen.

Här är en kort sammanfattning av loggningsfunktionerna för containertjänsterna:

  • Container Apps abstraherar alla sina interna Kubernetes-loggar i två kategorier. En, som kallas Konsolloggar , innehåller containerloggarna för arbetsbelastningar. En andra systemkategori innehåller alla plattformsrelaterade loggar.
  • AKS ger alla Kubernetes-relaterade loggar och detaljerad kontroll över vad som kan loggas. Den behåller också fullständig kompatibilitet med Kubernetes-klientverktyg för loggströmning, till exempel kubectl.
  • Web App for Containers innehåller många kategorier av resursloggar eftersom dess plattform (App Service) inte enbart gäller för containerarbetsbelastningar. För containerspecifika åtgärder som hanterar sin interna Docker-plattform tillhandahåller den loggkategorin AppServicePlatformLogs. En annan viktig kategori är AppServiceEnvironmentPlatformLogs, som loggar händelser som skalning och konfigurationsändringar.

Välkonstruerat ramverk för driftskvalitet

Den här artikeln fokuserar på de största skillnaderna mellan funktionerna för containertjänster som beskrivs här. Se de här artiklarna om du vill läsa den fullständiga vägledningen för operational excellence för följande tjänster:

Tillförlitlighet

Tillförlitlighet avser möjligheten för ett system att reagera på fel och förbli fullt fungerande. På program-programvarunivå bör arbetsbelastningar implementera metodtips som cachelagring, återförsök, mönster för kretsbrytare och hälsokontroller. På infrastrukturnivå ansvarar Azure för att hantera fysiska fel, till exempel maskinvarufel och strömavbrott, i datacenter. Fel kan fortfarande inträffa. Arbetsbelastningsteam bör välja lämplig Azure-tjänstnivå och tillämpa nödvändiga konfigurationer för minsta instans för att implementera automatiska redundans mellan tillgänglighetszoner.

Om du vill välja lämplig tjänstnivå måste du förstå hur serviceavtal (SLA) och tillgänglighetszoner fungerar.

Serviceavtal

Tillförlitlighet mäts ofta av affärsdrivna mått som serviceavtal eller återställningsmått som mål för återställningstid (RTO).

Azure har många serviceavtal för specifika tjänster. Det finns inget sådant som en tjänstnivå på 100 %, eftersom fel alltid kan inträffa i programvara och maskinvara, och till sin natur, till exempel stormar och jordbävningar. Ett serviceavtal är inte en garanti, utan snarare ett ekonomiskt uppbackat avtal om tjänsttillgänglighet.

Om du vill ha de senaste serviceavtalen och informationen kan du ladda ned det senaste SLA för Microsoft Online Services-dokumentet från Microsofts licensieringswebbplats.

Kostnadsfria eller betalda nivåer

I allmänhet erbjuder kostnadsfria nivåer av Azure-tjänster inte något serviceavtal, vilket gör dem till kostnadseffektiva val för icke-produktionsmiljöer. För produktionsmiljöer är det dock bästa praxis att välja en betald nivå som har ett serviceavtal.

Ytterligare faktorer för AKS

AKS har olika serviceavtal för olika komponenter och konfigurationer:

  • Kontrollplan. Kubernetes API-servern har ett separat serviceavtal.
  • Dataplan. Nodpooler använder de underliggande SKU-serviceavtalen för virtuella datorer.
  • Tillgänglighetszoner. Det finns olika serviceavtal för de två planen, beroende på om AKS-klustret har tillgänglighetszoner aktiverade och kör flera instanser i tillgänglighetszoner.

Observera att när du använder flera Azure-tjänster kan sammansatta serviceavtal skilja sig från och vara lägre än enskilda serviceavtal.

Redundans med tillgänglighetszoner

Tillgänglighetszoner är distinkta datacenter som har oberoende elkraft, kylning och så vidare inom en enda region. Den resulterande redundansen ökar toleransen för fel utan att du behöver implementera arkitekturer i flera regioner.

Azure har tillgänglighetszoner i varje land/region där Azure driver en datacenterregion. Om du vill tillåta flera instanser av containrar att korsa tillgänglighetszoner måste du välja SKU:er, tjänstnivåer och regioner som tillhandahåller stöd för tillgänglighetszoner.

Funktion Container Apps AKS Web App for Containers
Stöd för tillgänglighetszon Fullständig Fullständig Fullständig

Till exempel blir ett program eller en infrastruktur som är konfigurerad för att köra en enskild instans otillgänglig om ett problem uppstår i tillgänglighetszonen där maskinvaran finns. Om du vill använda stöd för tillgänglighetszoner fullt ut bör du distribuera arbetsbelastningar med minst tre instanser av containern, spridda över zoner.

Hälsokontroller och självåterställning

Slutpunkter för hälsokontroll är avgörande för en tillförlitlig arbetsbelastning. Men att bygga dessa slutpunkter är bara hälften av lösningen. Den andra hälften styr vad värdplattformen gör och hur det uppstår fel.

För att bättre skilja mellan olika typer av hälsoavsökningar kan du ta en titt på de inbyggda typerna av avsökningar från Kubernetes:

  • Start. Kontrollerar om programmet har startats.
  • Beredskap. Kontrollerar om programmet är redo att hantera inkommande begäranden.
  • Livskraft. Kontrollerar om programmet fortfarande körs och svarar.

En annan viktig faktor är hur ofta dessa hälsokontroller begärs från programmet (intern kornighet). Om du har ett långt intervall mellan dessa begäranden kan du fortsätta att hantera trafik tills instansen bedöms vara felaktig.

De flesta program stöder hälsokontroller via HTTP(S)-protokollet. Vissa kan dock behöva andra protokoll, till exempel TCP eller gRPC, för att utföra dessa kontroller. Tänk på detta när du utformar ditt hälsokontrollsystem.

Container Apps AKS Webbapp för containrar
Startavsökningar ✅ ✅ Partiellt stöd
Beredskapsavsökningar ✅ ✅ ❌
Liveness-avsökningar ✅ ✅ ✅
Intervallkornighet Sekunder Sekunder 1 minut
Protokollstöd HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

Hälsokontroller är enklast att implementera i Web App for Containers. Det finns några viktiga överväganden:

  • Startavsökningarna är inbyggda och kan inte ändras. Den skickar en HTTP-begäran till startporten för containern. Alla svar från ditt program anses vara en lyckad start.
  • Den stöder inte beredskapsavsökningar. Om startavsökningen lyckas läggs containerinstansen till i poolen med felfria instanser.
  • Hälsokontrollen skickas med en minuts intervall. Du kan inte ändra intervallet.
  • Det minsta tröskelvärde som du kan ange för att en instans med fel ska tas bort från den interna belastningsutjämningsmekanismen är två minuter. Den felaktiga instansen hämtar trafik i minst två minuter efter att en hälsokontroll misslyckas. Standardvärdet för den här inställningen är 10 minuter.

Container Apps och AKS är å andra sidan mycket mer flexibla och erbjuder liknande alternativ. När det gäller specifika skillnader tillhandahåller AKS följande alternativ för att utföra hälsokontroller, som inte är tillgängliga i Container Apps:

Auto-healing

Att identifiera en felaktig containerinstans och sluta skicka trafik till den är en början. Nästa steg är att implementera automatisk återställning. Automatisk återställning är processen för att starta om programmet i ett försök att återställa från ett feltillstånd. Så här jämför de tre containertjänsterna:

  • I Web App for Containers finns det inget alternativ för att starta om en containerinstans omedelbart efter att en hälsokontroll misslyckas. Om instansen fortsätter att misslyckas i en timme ersätts den av en ny instans. Det finns en annan funktion, som kallas automatisk återställning, som övervakar och startar om instanser. Det är inte direkt relaterat till hälsokontroller. Den använder olika programmått, till exempel minnesgränser, VARAKTIGHET för HTTP-begäranden och statuskoder.
  • Container Apps och AKS försöker automatiskt starta om en containerinstans om liveness-avsökningen når det definierade tröskelvärdet för fel.

Distributioner av program med noll driftstopp

Möjligheten att distribuera och ersätta program utan att orsaka avbrott för användare är avgörande för en tillförlitlig arbetsbelastning. Alla tre containertjänster som beskrivs i den här artikeln stöder distributioner utan avbrott, men på olika sätt.

Container Apps AKS Web App for Containers
Strategi för noll stilleståndstid Löpande uppdatering Löpande uppdatering, plus alla andra Kubernetes-strategier Distributionsplatser

Observera att programarkitekturerna också måste ha stöd för distribution utan avbrott. Mer information finns i Azure Well-Architected Framework .

Resursgränser

En annan viktig komponent i en tillförlitlig delad miljö är din kontroll över resursanvändningen (till exempel CPU eller minne) för dina containrar. Du måste undvika scenarier där ett enda program tar upp alla resurser och lämnar andra program i ett felaktigt tillstånd.

Container Apps AKS Web App for Containers
Resursgränser (CPU eller minne) Per app/container Per app/container
Per namnområde		 Per App Service-plan
  • Web App for Containers: Du kan vara värd för flera program (containrar) i en enda App Service-plan. Du kan till exempel allokera en plan med två CPU-kärnor och 4 GiB RAM-minne där du kan köra flera webbappar i containrar. Du kan dock inte begränsa en av apparna till en viss mängd processor eller minne. De konkurrerar alla om samma App Service-planresurser. Om du vill isolera dina programresurser måste du skapa ytterligare App Service-planer.
  • Containerappar: Du kan ange cpu- och minnesgränser per program i din miljö. Du är dock begränsad till en uppsättning tillåtna kombinationer av CPU och minne. Du kan till exempel inte konfigurera en vCPU och 1 GiB minne, men du kan konfigurera en vCPU och 2 GiB minne. En Container Apps-miljö motsvarar ett Kubernetes-namnområde.
  • AKS: Du kan välja valfri kombination av vCPU och minne, så länge noderna har maskinvaran som stöd för den. Du kan också begränsa resurser på namnområdesnivå om du vill segmentera klustret på det sättet.

Välkonstruerat ramverk för tillförlitlighet

Den här artikeln fokuserar på de största skillnaderna mellan funktionerna för containertjänster i Azure. Om du vill granska den fullständiga tillförlitlighetsvägledningen för en viss tjänst kan du läsa följande artiklar:

Slutsats

Väldefinierade lösningar lägger grunden för lyckade arbetsbelastningar. Även om arkitekturer kan justeras när en arbetsbelastning växer och teamen fortsätter på sina molnresor, är vissa beslut, särskilt kring nätverk, svåra att vända utan betydande driftstopp eller omdistribution.

När du jämför Azure-containertjänster visas i allmänhet ett tema: AKS visar den mest underliggande infrastrukturen och erbjuder därmed den största konfigurerbarheten och utökningsbarheten. Mängden driftkostnader och komplexitet är mycket varierande för AKS-arbetsbelastningar. Vissa team kan avsevärt minska driftkostnaderna med hjälp av Microsofts hanterade tillägg och tillägg, samt funktioner för automatisk uppgradering. Andra kunder kanske föredrar fullständig kontroll över klustret för att utnyttja fullständig utökningsbarhet av Kubernetes och CNCF-ekosystemet. Även om Microsoft till exempel erbjuder Flux som ett hanterat GitOps-tillägg väljer många team i stället att konfigurera och använda ArgoCD på egen hand.

Arbetsbelastningsteam som till exempel inte kräver CNCF-program, har mindre driftserfarenhet eller föredrar att fokusera på programfunktioner kanske föredrar ett PaaS-erbjudande. Vi rekommenderar att de först överväger Container Apps.

Även om Container Apps och Web App for Containers båda är PaaS-erbjudanden som tillhandahåller liknande nivåer av Microsoft-hanterad infrastruktur, är en viktig skillnad att Container Apps ligger närmare Kubernetes och ger ytterligare molnbaserade funktioner för tjänstidentifiering, händelsedriven autoskalning, Dapr-integrering med mera. Team som inte behöver dessa funktioner och som är bekanta med App Service-nätverks- och distributionsmodeller kanske föredrar Web App for Containers.

Generaliseringar kan hjälpa dig att begränsa listan över Azure-containertjänster att överväga. Men kom ihåg att du också måste verifiera ditt val genom att undersöka enskilda krav i detalj och matcha dem med tjänstspecifika funktionsuppsättningar.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg