Arkitekturöverväganden för att välja en Azure-containertjänst

I den här artikeln beskrivs hur du väljer 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.

Överblick

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

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

• Stöd för operativsystem (OS)
• Nätverksadressutrymme
• Analys av trafikflöde
• Planering av undernät
• Tillgängliga inkommande IP-adresser
• Stöd för användardefinierade vägar (UDR) och NAT-gateway
• Integrering av privata nätverk
• Protokolltäckning
• Belastningsutjämning
• Tjänsteupptäckt
• Anpassade domäner och hanterad TLS (Transport Layer Security)
• Ömsesidig TLS (mTLS)
• Avancerat containernätverk för Azure Kubernetes Service (AKS)
• Nätverksbegrepp för specifika Azure-tjänster

Säkerhetshänsyn

• Nätverksprinciper för trafiksäkerhet inom kluster
• Nätverkssäkerhetsgrupper (NSG:er)
• Azure Key Vault-integrering
• Stöd för hanterad identitet
• Hotskydd och sårbarhetsbedömningar med Microsoft Defender för containrar
• Säkerhetsbaslinjer
• Azure Well-Architected Framework 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 Framework för driftskvalitet

Tillförlitlighetsöverväganden

• Serviceavtal (SLA)
• Redundans genom tillgänglighetszoner
• Hälsokontroller och självåterställning
• Distributioner av program med noll driftstopp
• Resursbegränsningar
• Well-Architected Framework för pålitlighet

Den här artikeln fokuserar på en delmängd av Azure-containertjänster som tillhandahåller en mogen funktionsuppsättning för webbprogram och API:er, nätverk, observerbarhet, utvecklarverktyg och åtgärder. Dessa tjänster omfattar AKS, AKS Automatic, Azure Container Apps och Web App for Containers. En fullständig lista över Azure-containertjänster finns i Containertjänster.

Arkitekturöverväganden

Det här avsnittet beskriver arkitekturbeslut som är svåra att ångra eller korrigera utan betydande driftstopp eller omdistribution. Det är särskilt viktigt att noggrant utvärdera grundläggande komponenter som nätverk och säkerhet innan du slutför dem.

Dessa överväganden är inte specifika för Well-Architected Framework-pelare. De kräver dock extra granskning och utvärdering mot affärskrav när du väljer en Azure-containertjänst.

Stöd för operativsystem

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

*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 planeringsprocesserna på grund av säkerhets- och efterlevnadsbegränsningar och införda riktlinjer. I allmänhet beror de viktigaste skillnaderna mellan de Azure-tjänster som beskrivs i den här guiden på dina önskemål. Överväg följande tjänster:

• Container Apps är ett PaaS-erbjudande (plattform som en tjänst) som tillhandahåller Azure-hanterade nätverksfunktioner som 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. AKS 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 och installera och använda tillägg från Kubernetes-ekosystemet.

• Web App for Containers är en funktion i App Service. Dess nätverksmodell, särskilt för integrering av privata nätverk, följer noga apptjänstens arkitektur. Den här arkitekturen är bekant för arbetsbelastningsteam som använder App Service. För team utan tidigare App Service-upplevelse som föredrar en mer konventionell integrering av virtuella Azure-nätverk rekommenderar vi Container Apps.

Nätverk är ett grundläggande infrastrukturlager. Det är ofta svårt att göra ändringar i designen utan att omdistribuera arbetsbelastningen, vilket kan leda till stilleståndstid. Om din arbetsbelastning har specifika nätverkskrav kan du 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 planera IP-adresser för att säkerställa att containerinstanserna har tillräckligt. Under den här processen allokerar du extra IP-adresser för att hantera uppdateringar, blågröna distributioner och liknande scenarier. Dessa händelser kan tillfälligt distribuera extra instanser som använder fler adresser än vanligt.

AKS-kraven beror på ditt valda nätverks-plugin-program. Vissa nätverks-plugin-program för AKS kräver bredare IP-adressreservationer. Den informationen ligger utanför den här artikelns omfång. 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.

I följande avsnitt beskrivs olika nätverksbegränsningar. Dessa begränsningar påverkar om du behöver distribuera extra undernät, beroende på dina krav för följande konfigurationer:

• Flera samlokaliserade arbetsbelastningar

• Privat åtkomst, offentlig åtkomst eller både och

• 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

Ett undernät måste vara tillräckligt stort för att inkludera programinstanser, men kapaciteten är inte den enda faktorn som avgör nätverkets fotavtryck för att distribuera dessa arbetsbelastningar.

*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, antingen 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 extra 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 flera arbetsbelastningar kräver uppdelning måste du etablera extra Container Apps-miljöer och allokera ett separat undernät för varje miljö.

AKS tillhandahåller detaljerad öst-västlig nätverksflödeskontroll i klustret via 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 antalet appar som du kan integrera med ett enda undernät om undernätet har tillräcklig kapacitet. 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.

Ingress IP-adress tillgänglighet

Följande tabell innehåller det föregående avsnittet för planering av undernät för att definiera antalet IP-adresser som kan exponeras. Den gäller för ett godtyckligt antal program som finns i en enda distribution av en Azure-containertjänst.

Container Apps stöder en IP-adress för varje miljö, antingen offentlig eller privat. AKS stöder valfritt antal offentliga eller privata IP-adresser. Web App for Containers, när det används utanför en App Service-miljö, tillåter en offentlig IP-adress för varje App Service-plan och flera distinkta privata IP-adresser via privata Azure-slutpunkter.

Tänk på 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-miljön, oavsett om den är offentlig eller privat.

Stöd för UDR och NAT-gateway

Om en arbetsbelastning kräver 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 Container Apps.

AKS och Web App for Containers implementerar dessa två nätverksfunktioner via standardfunktioner för virtuella nätverk respektive integrering av virtuella nätverk. AKS-nodpooler och Web App for Containers i en App Service-miljö är redan direkta virtuella nätverksresurser. Web App for Containers som inte finns i en App Service-miljö stöder UDR och NAT-gateway via virtuell nätverksintegrering. Med integrering av virtuella nätverk finns resursen tekniskt sett inte direkt i det virtuella nätverket. Alla dess utgående trafikflöden flödar dock genom det virtuella nätverket, och nätverkets associerade regler påverkar trafiken som förväntat.

Integrering av privata nätverk

För arbetsbelastningar som kräver strikt privat nätverk på Layer 4 för både ingående och utgående trafik bör du överväga Container Apps, AKS och App Service-miljöns single-tenant SKU, där arbetsbelastningar distribueras i ett självhanterat virtuellt nätverk. Den här distributionen tillhandahåller anpassade detaljerade privata nätverkskontroller.

Privat nätverk med Web App for Containers

Web App for Containers innehåller extra nätverksfunktioner som inte visas på samma sätt som andra Azure-tjänster som beskrivs i den här artikeln. För att implementera strikta krav för privata nätverk bör arbetsbelastningsteam bekanta sig med dessa nätverksbegrepp. Granska noggrant följande nätverksfunktioner:

• Privata slutpunkter
• Integrering av virtuellt nätverk

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 även inkommande TCP-anslutningar (Transmission Control Protocol). AKS är den mest flexibla och stöder obegränsad användning av TCP och UDP (User Datagram Protocol) på självvalda portar.

*I Container Apps-miljön kan HTTP eller HTTPS exponeras på valfri port för kommunikation mellan kluster. I det scenariot gäller inte inbyggda HTTP-funktioner för Container Apps som resursdelning mellan ursprung 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 fullständigt lastbalanserarna Layer 4 och Layer 7.

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

Avancerade containernätverkstjänster för AKS

Advanced Container Networking Services (ACNS) ger AKS avancerade nätverksfunktioner som går utöver vad som är tillgängligt i Container Apps eller Web App for Containers. Dessa funktioner ger kraftfull observerbarhet och förbättrad säkerhet som utformats för dynamiska, containerbaserade miljöer.

• Observerbarhet för containernätverk:

  ACNS använder Hubbles kontrollplan för att ge intuitiva och djupgående insikter om nätverksbeteende. Med mått på nodnivå och poddnivå som är lätta att använda och omfattande flödesloggar kan du snabbt hitta problem och optimera prestanda. Den här inbyggda observerbarheten minskar behovet av externa övervakningsinställningar och sänker inlärningskurvan som vanligtvis associeras med Kubernetes-nätverksdiagnostik.

• Säkerhet för containernätverk:

  För kluster som använder Azure Container Networking Interface som drivs av Cilium tillhandahåller ACNS filtrering av fullständigt kvalificerade domännamn (FQDN). I stället för att hantera statiska IP-adressbaserade säkerhetsprinciper kan du definiera principer baserat på domännamn. Den här dynamiska metoden förenklar principhanteringen och överensstämmer även med moderna nollförtroendesäkerhetsmodeller. Den här metoden gör det enklare för dig att framtvinga robust säkerhet utan ständiga manuella uppdateringar.

Mer information finns i följande resurser:

• Vad är containernätverksobservabilitet?
• Vad är containernätverkssäkerhet?

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 FQDN för tillförlitlig och konsekvent kommunikation.

Web App for Containers tillhandahåller offentliga inkommande (nord-syd-kommunikation) FQDN som standard. Ingen extra 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 inifrån eller utanför klustret. Om du vill exponera program för nätverket på ett adresserbart sätt måste du definiera och skapa Kubernetes-tjänster enligt kubernetes-API:et.

Anpassade domäner och hanterad TLS

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

AKS-användare ansvarar för att hantera DNS-, klusterkonfigurationer och TLS-certifikat för sina anpassade domäner. AKS tillhandahåller inte hanterad TLS, men kunder kan använda programvara från Kubernetes-ekosystemet, till exempel cert-manager, för att hantera TLS-certifikat.

mTLS

Ett annat alternativ för att begränsa inkommande trafik är mTLS. Det här säkerhetsprotokollet 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ö.

Du kan implementera mTLS i AKS via det Istio-baserade tjänstnätet som ett hanterat tillägg. Det här tillägget innehåller mTLS-funktioner för inkommande klientanslutningar och kommunikation mellan tjänster inom klustret. Team som hanterar arbetsbelastningar 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 för nätverksdesign. Mer information om nätverksfunktioner som är specifika för enskilda Azure-containertjänster finns i följande artiklar:

• Nätverk i Container Apps
• App Service-nätverksfunktioner

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 tillhandahåller en inkapslad miljö för ditt program. Värdsystemen och underliggande nätverksöverlägg kräver dock extra 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 ger AKS den största konfigurerbarheten och utökningsbarheten, delvis genom att exponera underliggande komponenter, som ofta kan skyddas med hjälp av konfigurationsalternativ. Du kan till exempel använda konfigurationsalternativ för att inaktivera lokala konton till Kubernetes API-servern eller aktivera automatiska uppdateringar av underliggande noder.

AKS Automatiska kluster har en härdad standardkonfiguration och har många säkerhetsinställningar för kluster, program och nätverk aktiverade som standard. Dessa inledande konfigurationer minskar inte bara distributionstiden utan ger också användarna en standardiserad konfiguration som är förvaliderad. Den här konfigurationen ger användarna en gedigen grund för driftsansvaret 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 ger den största flexibiliteten av de tre alternativ som beskrivs i den här artikeln. Det ger fullständig åtkomst till Kubernetes API så att du kan anpassa containerorkestrering. Den här åtkomsten till Kubernetes API representerar dock också en betydande attackyta som du behöver skydda.

Identitetsbaserad säkerhet

Du ansvarar för att skydda identitetsbaserad åtkomst till API:et. Kubernetes tillhandahåller ett eget autentiserings- och auktoriseringshanteringssystem. Det här systemet 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 rollbaserad åtkomstkontroll i Azure (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.

Du har inte åtkomst till Kubernetes API om du använder Container Apps. 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 integrering av virtuella API-servrar där API-servern är integrerad i ett delegerat undernät.

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. Vanligtvis behöver du distribuera lokalt installerade agenter för Azure DevOps eller GitHub Actions. Mer information om andra begränsningar finns i den produktspecifika dokumentationen.

ACNS förbättrar säkerheten för dataplanet i AKS. För kluster som använder Azure Container Networking Interface som drivs av Cilium introducerar ACNS containernätverkssäkerhet via FQDN-filtrering. I stället för att hantera statiska IP-adressbaserade säkerhetsprinciper kan du definiera dynamiska principer baserat på FQDN. Den här metoden förenklar principhanteringen, minskar administrativa kostnader och stöder en Zero Trust-modell genom att se till att endast trafik till betrodda domäner tillåts.

Dessa överväganden gäller inte för Container Apps. Eftersom det är PaaS abstraherar Microsoft 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.

Nätverksprinciper för trafiksäkerhet inom kluster

Vissa säkerhetsstatusar kräver nätverkstrafiksegregering i en miljö. Den här segregationen är till exempel ofta nödvändig när du använder miljöer för flera klienter för att vara värd för flera eller flernivåapplikationer. I dessa scenarier väljer du AKS och implementerar nätverksprinciper, som är molnbaserade funktioner som möjliggör detaljerad konfiguration av Layer 4-nätverk i Kubernetes-kluster.

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

NSG:er

I alla scenarier kan du reglera nätverkskommunikationen i det bredare virtuella nätverket med hjälp av NSG:er. Med den här metoden kan du använda Layer 4-trafikregler som reglerar både inkommande och utgående trafik på den virtuella nätverksnivån.

Inbyggda IP-adressbegränsningar för ingress

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

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 för att ge 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.

Mer information finns i följande resurser:

• Hantera hemligheter i Container Apps
• Integrera Key Vault med AKS
• Använda Key Vault-referenser som appinställningar i App Service

Stöd för hanterad identitet

Program kan använda hanterade identiteter 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 tillhandahåller inbyggt Azure-stöd för hanterad identitet på programnivå. Stöd för hanterad identitet på programnivå för AKS uppnås via Microsoft Entra-arbetsbelastnings-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.

Mer information finns i följande resurser:

• Använda en hanterad identitet i AKS
• Arbetsbelastnings-ID med AKS
• Hanterade identiteter i Container Apps
• Hanterade identiteter för App Service

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

Skydd mot hot och sårbarheter är också viktigt. Det är en bästa praxis att använda Defender för containrar. Sårbarhetsbedömningar stöds i Azure-containerregister. Därför kan alla Azure-containertjänster använda dem, inte bara de som beskrivs i den här artikeln. Defender for Containers-körningsskydd är dock endast tillgängligt för AKS.

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

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

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

Säkerhetsbaslinjer

De flesta Azure-containertjänster integrerar vanligtvis Azure-säkerhetserbjudanden. Tänk på att en säkerhetsfunktionsuppsättning 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:

• Azure-säkerhetsbaslinje för Container Apps
• Azure-säkerhetsbaslinje för AKS
• Azure-säkerhetsbaslinje för App Service

Well-Architected Framework för säkerhet

Den här artikeln fokuserar på viktiga skillnader mellan containertjänstfunktioner.

Mer fullständig säkerhetsvägledning om AKS finns i AKS-metodtips.

Operativa överväganden

För att framgångsrikt köra ett arbetsflöde i produktion måste du implementera praxis för operativ excellens, inklusive centraliserad loggning, övervakning, skalbarhet, regelbundna uppdateringar och patchning samt hantering av avbildningar.

Uppdateringar och korrigeringar

Det är viktigt att ett programs underliggande operativsystem uppdateras och korrigeras regelbundet. Varje uppdatering utgör dock en felrisk. Det här avsnittet och nästa avsnitt 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 funktionen automatiska uppgraderingskanaler i klustret för att säkerställa att klustren är up-to-date. Mer information om AKS day-2-driftguiden finns i Korrigera och uppgradera AKS-kluster.

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

Uppdateringar av containeravbildningar

Oavsett Azure-containerlösningen ansvarar du för dina 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 Azure Container Registry-containrar.

Skalbarhet

Skalning används för att justera resurskapaciteten för att uppfylla kraven. Den lägger till mer kapacitet för att säkerställa prestanda och tar 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 syftar på möjligheten att öka eller minska befintlig infrastruktur, till exempel 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 specifik Azure-tjänst. Dessa erbjudanden varierar och kan medföra extra begränsningar.

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

Följande artiklar innehåller information om SKU-erbjudanden för Container Apps och App Service:

• Arbetsbelastningsprofiler i Container Apps
• Priser för App Service

Skalbarhet för horisontell infrastruktur

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

Skalning upp och ner inkluderar ombalansering av instanser, vilket skapar en risk för stilleståndstid. Risken är mindre än motsvarande risk med vertikal skalning. Oavsett är du ansvarig för att säkerställa att dina program kan hantera fel. Du ansvarar också för att implementera smidiga uppstarter och avstängningar av dina applikationer för att undvika avbrott.

Skalbarhet för program

Skalning av infrastruktur och program utlöses vanligtvis av resursförbrukning, till exempel CPU och minne. Vissa containerlösningar kan också skala antalet containerinstanser baserat på programspecifika mått, till exempel HTTP-begäranden. AKS och Container Apps kan till exempel skala containerinstanser baserat på meddelandeköer via Kubernetes händelsedriven autoskalning (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å de skalbarhetsalternativ som Azure tillhandahåller. Web App for Containers stöder inte anpassade skalningskonfigurationer som KEDA.

AKS Automatic aktiverar horisontell podd autoskalare, KEDA och vertikal podd autoskalare som standard.

Observerbarhet

Instrumentering av arbetsbelastning

Det kan vara svårt att samla in mått för komplexa program eller program med flera nivåer. För att hämta mått kan du integrera containerbaserade arbetsbelastningar med Azure Monitor på följande 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 klienten

  Instrumenteringsmetod	Containerapplikationer	AKS	Webbapp för containrar
  Automatisk instrumentering genom plattform	❌	❌	Partiellt stöd*
  Automatisk instrumentering via agent	❌	Partiellt stöd*	Ej tillgänglig
  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 specifika konfigurationer av Linux- och Windows-arbetsbelastningar, beroende på programspråket. Mer information finns i följande artiklar:

• Miljöer, språk och resursprovidrar som stöds för automatisk instrumentering
• Automatisk övervakning av instrumenteringsprogram för Kubernetes

Instrumentering i programkod är programutvecklares ansvar, så det är oberoende av vilken Azure-containerlösning som helst. Använd följande lösningar för din arbetsbelastning:

• SDK:er för Application Insights
• OpenTelemetry-distributioner

Loggar och mätvärden

Alla Azure-containertjänster tillhandahåller funktioner för program- och plattformsloggar och mått. Programloggar är konsolloggar som din arbetsbelastning genererar. 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. Med mått kan du övervaka och avisera om systemets prestanda och hälsa.

Azure Monitor är den nyckelloggnings- och måtttjänst 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 granska resursloggkategorierna och tillgängliga mått för var och en av tjänsterna.

Överväg mått och loggar för följande tjänster:

• 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 tillhandahåller 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 både kluster- och nodmått. Du kan samla in anpassade mått med hjälp av Prometheus och visualisera dem med Grafana, men den här åtgärden kräver manuell konfiguration.

• AKS Automatic är förkonfigurerat 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 att samla in loggar och mått.

• 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 den interna Docker-plattformen 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, vilket gör att du kan övervaka programprestanda och resursanvändning.

Well-Architected Framework för driftskvalitet

Den här artikeln fokuserar på de viktigaste skillnaderna mellan funktionerna i containertjänster. Granska den fullständiga vägledningen för driftskvalitet för följande tjänster:

• AKS
• Webbapp för containrar

Tillförlitlighet

Tillförlitlighet avser möjligheten för ett system att reagera på fel och förbli fullt fungerande. På programvarunivå 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 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.

Azure tillhandahåller många serviceavtal för specifika tjänster. Det finns inget sådant som total tjänsttillgänglighet eftersom fel kan inträffa i programvara, maskinvara eller till och med naturliga händelser som stormar och jordbävningar. Ett serviceavtal är inte en garanti utan ett ekonomiskt stödda åtagande för en definierad tillgänglighetsnivå.

Om du vill ha serviceavtal och information laddar du ned det senaste dokumentet om serviceavtal för Microsoft Online Services.

Kostnadsfria nivåer jämfört med betalda nivåer

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

Extra 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 serviceavtalen för VM-SKU:er.

• Tillgänglighetszoner: Det finns olika serviceavtal för de två planen, beroende på om AKS-klustret har tillgänglighetszoner aktiverade och om flera instanser körs över tillgänglighetszoner.

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

Redundans med tillgänglighetszoner

Tillgänglighetszoner är distinkta datacenter som har oberoende elkraft och kylning 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 eller region där den 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.

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 som har 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 hur värdplattformen svarar när fel inträffar.

För att bättre förstå typer av Kubernetes-hälsoavsökningar bör du överväga följande inbyggda alternativ:

• Start: Kontrollerar om programmet startar

• Beredskap: Kontrollerar om programmet är redo att hantera inkommande begäranden

• Livskraft: Kontrollerar om programmet körs och svarar

En annan viktig faktor är hur ofta dessa hälsokontroller begärs från programmet eller dess interna 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- eller HTTPS-protokollet. Vissa program 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 hälsokontrollsystemet.

Hälsokontroller är enklast att implementera i Web App for Containers. Överväg följande faktorer:

• Uppstartssonderna ä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.

Alternativt är Container Apps och AKS mycket mer flexibla och ger 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:

• gRPC-stöd
• Namngivna portar
• Exec-kommandon

Automatisk läkning

Att identifiera en felaktig containerinstans och stoppa trafik till den är bara början. Nästa steg är att implementera automatisk återställning. Automatisk återställning är processen att starta om programmet för att försöka återställa från ett feltillstånd. Tänk på hur följande containertjänster jämförs:

• 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ätter en ny instans den. Automatisk självläkning startar om instanser och övervakar dem. Det är inte direkt relaterat till hälsokontroller. Automatisk återställning använder olika programmått, till exempel minnesgränser, varaktighetsbegränsning 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 med noll driftstopp men på olika sätt.

Programarkitekturerna måste också ha stöd för distribution utan avbrott.

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 använder alla resurser och lämnar andra program i ett felaktigt tillstånd.

• Webbapp för containrar: 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 gibibyte (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 extra App Service-planer.

• ContainerAppar: Du kan ange cpu- och minnesgränser för varje 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ö har ett liknande syfte som 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 Framework för pålitlighet

Den här artikeln fokuserar på de viktigaste 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:

• Well-Architected Framework-översikt för AKS
• Tillförlitlighet i Container Apps
• App Service och tillförlitlighet

Slutsats

Väldefinierade lösningar skapar grunden för lyckade arbetsbelastningar. Arkitekturbeslut kan utvecklas i takt med att arbetsbelastningarna växer och teamen fortsätter sina molnresor. Vissa alternativ, särskilt de som rör nätverk, är svåra att ångra utan betydande stilleståndstid eller omdistribution.

När du jämför Azure-containertjänster visas ett tydligt tema. AKS exponerar den mest underliggande infrastrukturen, vilket ger maximal kontroll och konfigurerbarhet. AKS Automatiskt balanserar kontroll och enkelhet genom att automatisera många operativa uppgifter.

Mängden driftkostnader och komplexitet varierar kraftigt för AKS-arbetsbelastningar. Vissa team minskar kostnaderna avsevärt genom att använda Microsoft-hanterade tillägg, tillägg och funktioner för automatisk uppgradering. Andra team föredrar fullständig klusterkontroll för att dra nytta av Kubernetes fullständiga utökningsbarhet och CNCF-ekosystemet. Även om Microsoft till exempel tillhandahåller Flux som ett hanterat GitOps-tillägg väljer många team att konfigurera och använda ArgoCD på egen hand.

Arbetsbelastningsteam som 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.

Container Apps och Web App for Containers är båda PaaS-erbjudanden som tillhandahåller liknande nivåer av Microsoft-hanterad infrastruktur. Container Apps ligger dock närmare Kubernetes och tillhandahåller extra molnbaserade funktioner för tjänstidentifiering, händelsedriven autoskalning och Dapr-integrering . Team som inte behöver de här funktionerna 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 för övervägande. Du bör dock även kontrollera ditt val genom att granska enskilda krav i detalj och matcha dem med tjänstspecifika funktioner.

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

• Andre Dewes | Senior kundtekniker
• Xuhong Liu | Senior Serviceingenjör
• Marcos Martinez | Senior Serviceingenjör
• Julie Ng | Senior ingenjör

Andra deltagare:

• Martin Gjoshevski | Senior kundtekniker
• Don High | Huvudkundtekniker
• Nelly Kiboi | Tjänsttekniker
• Faisal Mustafa | Senior kundtekniker
• Walter Myers - Sverige | Huvudsaklig chef för kundteknik
• Sonalika Roy | Senior kundtekniker
• Paolo Salvatori | Huvudkundtekniker
• Victor Santana | Huvudkundtekniker

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

Nästa steg

• AKS-dokumentation
• Dokumentation om App Service
• Dokumentation om Container Apps

Relaterade resurser

• Distribuera mikrotjänster med Container Apps
• Planera din design och dina åtgärder