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.

Notera

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.

Överblick

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

arkitektur- och nätverksöverväganden

  • 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änsteupptäckt
  • 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 Ramverk för Säkerhet

operativa överväganden

  • Uppdateringar och korrigeringar
  • Uppdateringar av containeravbildningar
  • Skalbarhet för lodrät infrastruktur
  • Skalbarhet för horisontell infrastruktur
  • Skalbarhet för program
  • Observerbarhet
  • Well-Architected Ramverk för operativ förträfflighet

Tillförlitlighetsöverväganden

  • Serviceavtal
  • Redundans via tillgänglighetszoner
  • Hälsokontroller och självåterställning
  • Distributioner av program med noll driftstopp
  • Resursbegränsningar
  • Well-Architected 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), AKS Automatic, Azure Container Apps och Web App for Containers. En fullständig lista över alla Azure-containertjänster finns i produktkategorisidan för containertjänster.

Notera

Vissa avsnitt skiljer AKS Standard från AKS Automatic. Om ett avsnitt inte skiljer mellan de två antas funktionsparitet.

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 Well-Architected Framework-pelare. De förtjänar dock extra granskning och utvärdering mot företagens krav när du väljer en Azure-containertjänst.

Notera

AKS Automatic är en mer uttalad lösning än AKS Standard. Vissa färdiga funktioner kan inte inaktiveras. Den här guiden framhäver inte dessa funktioner. Uppdaterad information om dessa begränsningar och standard- och automatisk funktionsjämförelse finns i: AKS Automatisk och Standard-funktionsjämförelse.

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.

Containerapplikationer AKS AUTOMATISK AKS Webbapp för containrar
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, interna hanterade domäner och kontroller för virtuella nätverk.
  • 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äggsamt 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.

Containerapplikationer AKS Webbapp för containrar
dedikerade undernät Förbrukningsplan: valfritt
Dedikerad plan: krävs		 Krävs Valfri
IP-adresskrav Förbrukningsplan: Se Endast förbrukningsmiljö.
Dedikerad plan: Se miljö för arbetsbelastningsprofiler.		 Se virtuella Azure-nätverk för AKS. Se App Service-undernätskrav.

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 åtkomst.
  • 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.

Containerapplikationer AKS Webbapp för containrar
Stöd för samallokerade arbetsbelastningar i ett undernät* ❌* ✅ Ej tillämpligt*

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

Notera

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.

Containerapplikationer AKS Webbapp för containrar
Antal inkommande IP-adresser Ett 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 utanför en App Service-miljö stöder UDR:er och NAT-gateway via virtuell nätverksintegration. 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.

Containerapplikationer AKS Webbapp för containrar
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.

Containerapplikationer AKS Webbapp för containrar
Privat ingress till ett virtuellt nätverk ✅ ✅ Via privat slutpunkt
Privat utträde från ett virtuellt nätverk ✅ ✅ Via integrering av virtuella nätverk
Fullständigt undertryckt offentlig slutpunkt ✅ ✅ apptjänstmiljö endast
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 Containers
Protokoll och portstöd 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öder ✅ ✅ ✅
HTTP/2-stöd ✅ ✅ ✅

*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 det AKS-hanterade tillägget för programdirigering eller Application Gateway för containrar, eller distribuera och själv hantera en ingress-kontroller efter eget val.

Containerapplikationer AKS Webbapp för containrar
Layer 4-lastbalanserare Azure-hanterad Delat ansvar Azure-hanterad
Belastningsutjämnare för lager 7 Azure-hanterad Delad eller självstyrd Azure-hanterad

Tjänsteupptäckt

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.

Containerapplikationer AKS Webbapp för containrar
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 trafik 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.

Viktig

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.

Containerapplikationer AKS Webbapp för containrar
Konfigurera anpassade domäner Ur lådan BYO Ur lådan
Hanterad TLS för Azure FQDN:er 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-manager- 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 komma åt X-ARR-ClientCert 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 en annan service mesh-lösning 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äkerhetshänsyn

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.

AKS Automatiska kluster har en härdad standardkonfiguration, där många säkerhetsinställningar för kluster, program och nätverk är aktiverade som standard. Dessa inledande konfigurationer minskar inte bara distributionstiden, utan ger också användarna en standardiserad konfiguration som är förvald och därmed ger användarna en solid grund för driftsansvar dag 2. Den här grunden hjälper till att förkorta inlärningskurvan för långsiktig klusterhantering för team som är nya inom tekniken.

För en detaljerad jämförelse, granska noggrant följande överväganden för att säkerställa att dina arbetsbelastningens sä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.

Viktig

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.

Containerapplikationer AKS
Åtkomstkontroller för Kubernetes API Ingen åtkomst 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.

Containerapplikationer 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 dataplanet

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

Containerapplikationer AKS Webbapp för containrar
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.

Containerapplikationer AKS Webbapp för containrar
Nätverkssäkerhetsgrupper Förbrukningsplan: ✅
Dedikerad plan: ✅		 ✅ ✅ VNet-integrerade appar: endast utgående

Inbyggda IP-begränsningar för ingress

Container Apps och Web App for Containers tillhandahåller inbyggda käll-IP-begränsningar för inkommande trafik för enskilda program. AKS kan uppnå samma funktioner, men kräver kubernetes interna funktioner via Kubernetes Service api-resurs där du kan ange värden för loadBalancerSourceRanges.

Containerapplikationer AKS Webbapp för containrar
Inbyggda ingress-IP-begränsningar ✅ ❌* ✅
Resursförbrukning - Använder klusterresurser -

Notera

AKS erbjuder ingress-IP-begränsningar, men det är en inbyggd Kubernetes-funktion och inte Azure Native som de andra tjänsterna.

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-integreringen

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.

Containerapplikationer AKS Webbapp för containrar
Key Vault-integreringen ✅ ✅ ✅

Mer information finns i:

Stöd för hanterad identitet

Hanterad identitet kan användas av program för att autentisera till Microsoft Entra ID-skyddade tjänster utan att behöva använda nycklar eller hemligheter. Container Apps och Web App for Container erbjuder inbyggt Azure-stöd för hanterad identitet på programnivå. Stöd för hanterad identitet på programnivå för AKS uppnås via Entra Workload ID. AKS kräver också infrastrukturrelaterad hanterad identitet för att tillåta klusteråtgärder för Kubelet, kontrollplanet och olika AKS-tillägg.

Containerapplikationer AKS Webbapp för containrar
Stöd för hanterad identitetsinfrastruktur Ej tillämpligt ✅ Ej tillämpligt
Stöd för hanterad identitet för containerhämtning ✅ ✅ ✅
Stöd för programhanterad identitet ✅ ✅ ✅

Mer information finns i:

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

Skydd mot hot och sårbarheter är också viktigt. Det är en bra praxis 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.

Containerapplikationer AKS Webbapp för containrar
Skydd mot hot i körtid ❌ ✅ ❌

Mer information finns i Containers support matrix in Defender for Cloud.

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:

Notera

Automatiska AKS-kluster konfigureras med specifika säkerhetsinställningar. Se till att de är i linje med dina arbetsbelastningsbehov.

Well-Architected Framework for Security

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 framgångsrikt kunna köra en arbetslast i produktion måste teamen implementera praxis för driftseffektivitet, inklusive centraliserad loggning, övervakning, skalbarhet, regelbundna uppdateringar och korrigeringar samt hantering av systemavbildningar.

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 använda kanaler för automatisk uppgradering av kluster funktion för att säkerställa att dina kluster är uppdaterade. Mer information om korrigering och uppgradering av AKS-klusterfinns i AKS dag-2-driftsguide.

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.

Containerapplikationer AKS AUTOMATISK AKS Webbapp för containrar
Kontrollplansuppdateringar Plattform Kund Plattform Plattform
Värduppdateringar och patchar Plattform Kund Plattform Plattform
Uppdateringar och korrigeringar av containeravbildningar Kund Kund Kund Kund

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

vertikal skalning refererar till 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, granska dokumentationen om storlekar för virtuella datorer i Azure och AKS-begränsningar 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örbrukningstier för Container Apps bort 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 är dock alltid ansvariga för att se till att deras program kan hantera fel och för att genomföra smidiga starter och nedstängningar av sina program för att undvika driftstopp.

Containerapplikationer AKS Webbapp för containrar
Infrastruktur skalar in och ut Förbrukningsplan: Ej tillämpligt
Dedikerad plan: kan konfigureras		 Konfigurerbara Konfigurerbara
Flexibel maskinvaruetablering Förbrukningsplan: Ej tillämpligt
Dedikerad plan: abstrakt med arbetsbelastningsprofiler		 Valfri VM-SKU Abstrakt. Se App Service-plan.

Viktig

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.

Containerapplikationer AKS Webbapp för containrar
Container skala ut HTTP, TCP eller mätvärdesbaserad (CPU; minne; händelsedriven). Metrikbaserad (CPU, minne eller anpassad). Manuell, måttbaseradeller automatisk (förhandsvisning).
händelsedriven skalbarhet Ja. Molnbaserat. Ja. Molnbaserat. Ytterligare konfiguration krävs. Ja. Azure resursspecifik.

AKS Automatic aktiverar horizontal pod autoscaler, Kubernetes Event Driven Autoscaling (KEDA) och Vertical Pod Autoscaler (VPA) som standard.

Observerbarhet

Instrumentering av arbetsbelastning

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.
Containerapplikationer AKS Webbapp för containrar
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. Mer information finns i följande artiklar:

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

Loggar och mått

Alla Azure-containertjänster tillhandahåller funktioner för program- och plattformsloggar och mått. 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. Mått är numeriska värden som beskriver någon aspekt av ett system vid en tidpunkt, så att du kan övervaka och avisera om systemets prestanda och hälsa.

Azure Monitor är den huvudsakliga loggnings- och måtttjänsten i Azure som integreras med dessa tjänster. Azure Monitor använder resursloggar för att separera loggar från olika källor i kategorier och samlar in mått för att ge insikter om resursprestanda. Ett sätt att avgöra vilka loggar och mått som är tillgängliga från varje Azure-tjänst är att titta på resursloggkategorierna och tillgängliga mått för var och en av tjänsterna.

Containerapplikationer AKS AUTOMATISK AKS Webbapp för containrar
Stöd för loggströmning ✅ ✅ ✅ ✅
Stöd för Azure Monitor ✅ ✅ ✅ ✅
Azure Monitor-resursloggar Console och System Kubernetes API-server, Granskning, Scheduler, Autoskalning av kluster med mera Samma som AKS ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs och mer
Insamling och övervakning av mått Mått via Azure Monitor; anpassade mått via Dapr-metrik Mått via Azure Monitor; anpassade mått via Prometheus (kräver manuell konfiguration) Förkonfigurerad hanterad Prometheus för metrikinsamling och hanterad Grafana för visualisering. Metrier via Azure Monitor. Mått via Azure Monitor
Förkonfigurerade Prometheus och Grafana ❌ Kräver manuell installation ✅ Managed Prometheus och Managed Grafana är förkonfigurerade som standard. ❌

Container Apps abstraherar alla sina interna Kubernetes-loggar i två kategorier: Konsolloggar, som innehåller containerloggar för arbetsbelastningar och systemloggar, som innehåller alla plattformsrelaterade loggar. För mått integreras Container Apps med Azure Monitor för att samla in standardmått och stöder anpassade mått via Dapr-integrering för avancerade scenarier.

AKS- ger Kubernetes-relaterade loggar och detaljerad kontroll över vad som loggas. AKS behåller fullständig kompatibilitet med Kubernetes-klientverktyg för loggströmning, till exempel kubectl. För mått integreras AKS med Azure Monitor för att samla in kluster- och nodmått. Anpassad måttsamling med Prometheus och visualisering med Grafana är möjliga, men kräver manuell installation och konfiguration.

AKS Automatisk är förkonfigurerad med specifika övervakningsverktyg. Den använder Managed Prometheus för måttinsamling och Managed Grafana för visualisering. Kluster- och programmått samlas in automatiskt och kan visualiseras. AKS Automatic integreras också med Azure Monitor för logg- och måttinsamling.

Web App for Containers innehåller flera kategorier av resursloggar eftersom dess plattform (App Service) inte enbart är avsedd 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. Mått samlas in via Azure Monitor, så att du kan övervaka programmets prestanda och resursanvändning.

Well-Architected Ramverk för operativ förträfflighet

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

Reliability syftar på systemets förmåga att reagera på fel och förbli fullt fungerande. På applikationsprogramvarunivå bör arbetsbelastningar implementera bästa praxis, som cachelagring, återförsök, kretsbrytarmönster 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. Team för arbetsbelastning bör välja lämplig Azure-tjänstnivå och tillämpa nödvändiga minimikonfigurationer för instanser för att implementera automatiska omkopplingar 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 med 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 i naturen, till exempel stormar och jordbävningar. Ett serviceavtal är inte en garanti, utan snarare ett ekonomiskt uppbackat avtal om tjänsttillgänglighet.

För de senaste serviceavtalen och informationen 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 för att köra flera instanser över 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 i 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 Containerapplikationer AKS Webbapp för containrar
Stöd för tillgänglighetszoner Fullständigt Fullständigt Fullständigt

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 handlar om att kontrollera vad värdplattformen gör och hur den hanterar fel när de uppstår.

För att bättre skilja mellan olika typer av hälsosonder, ta en titt på de inbyggda typerna av sonder från Kubernetes:

  • Starta. Kontrollerar om programmet har startats framgångsrikt.
  • Beredskap. Kontrollerar om programmet är redo att hantera inkommande begäranden.
  • Livslängd. 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 förfrågningar kan du fortsätta att hantera trafik tills instansen bedöms vara ohälsosam.

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 Containers
Uppstartsprober ✅ ✅ Partiellt stöd
Beredskapsprober ✅ ✅ ❌
Liveness-kontroller ✅ ✅ ✅
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 din ansökan betraktas som en lyckad start.
  • Den stöder inte beredskapskontroller. Om startproben lyckas läggs containerinstansen till i poolen av hälsosamma 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 ohälsosamma instansen får 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:

Automatisk självläkning

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 återhämtning är processen att starta om programmet i ett försök att återhämta sig från ett ohälsosamt tillstå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 självläkning, som övervakar och startar om instanser. Det är inte direkt relaterat till hälsokontroller. Den använder olika applikationsmå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.

Containerapplikationer AKS Webbapp för containrar
nollavbrottsstrategi 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.

Resursbegränsningar

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.

Containerapplikationer AKS Webbapp för containrar
Resursbegränsningar (CPU eller minne) Per app/behållare Per app/behållare
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.
  • Container Apps: Du kan ange processor- 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.

Well-Architected 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 framträder i allmänhet ett tema: AKS visar den mest underliggande infrastrukturen och erbjuder därmed den största kontrollen och konfigurerbarheten, medan AKS Automatic erbjuder en balans mellan kontroll och enkelhet genom att automatisera många operativa uppgifter.

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.

Bidragsgivare

Den här artikeln underhålls av Microsoft. Texten skrevs ursprungligen av följande deltagare.

Huvudförfattare:

Andra deltagare:

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

Nästa steg