Delen via

Algemene overwegingen voor architectuur voor het kiezen van een Azure-containerservice

  • Artikel

In dit artikel wordt u begeleid bij het kiezen van een Azure-containerservice. Het biedt een overzicht van overwegingen op functieniveau die algemeen en essentieel zijn voor sommige workloads. Het kan u helpen beslissingen te nemen om ervoor te zorgen dat uw workload voldoet aan de vereisten voor betrouwbaarheid, beveiliging, kostenoptimalisatie, operationele uitmuntendheid en prestatie-efficiëntie.

Notitie

Dit artikel is deel twee in een reeks die begint met Een Azure-containerservice kiezen. We raden u ten zeerste aan dat u dat overzichtsartikel eerst leest om een context te krijgen voor deze architectuuroverwegingen.

Overzicht

De overwegingen in dit artikel zijn onderverdeeld in vier categorieën:

Overwegingen voor architectuur en netwerk

  • Ondersteuning van het besturingssysteem
  • Netwerkadresruimten
  • Inzicht in verkeersstroom
  • Subnetten plannen
  • Aantal beschikbare ip-adressen voor inkomend verkeer
  • Door de gebruiker gedefinieerde routes en NAT-gatewayondersteuning
  • Integratie van privénetwerken
  • Protocoldekking
  • Load balancing
  • Servicedetectie
  • Aangepaste domeinen en beheerde TLS
  • Wederzijdse TLS
  • Netwerkconcepten voor specifieke Azure-services

Beveiligingsoverwegingen

  • Beveiliging bieden voor verkeer binnen clusters met behulp van netwerkbeleid
  • Netwerkbeveiligingsgroepen
  • Integratie van Azure Sleutelkluis
  • Ondersteuning voor beheerde identiteit
  • Evaluaties van bedreigingsbeveiliging en beveiligingsproblemen met Defender for Containers
  • Beveiligingsbasislijnen
  • Azure Well-Architected Framework for Security

Operationele overwegingen

  • Updates en patches
  • Updates van containerinstallatiekopieën
  • Schaalbaarheid van verticale infrastructuur
  • Schaalbaarheid van horizontale infrastructuur
  • Schaalbaarheid van toepassingen
  • Waarneembaarheid
  • Goed ontworpen framework voor operationele uitmuntendheid

Overwegingen voor betrouwbaarheid

  • Dienstverleningsovereenkomsten
  • Redundantie via beschikbaarheidszones
  • Gezondheidscontroles en zelfherstel
  • Implementaties van toepassingen zonder downtime
  • Bronlimieten
  • Goed ontworpen framework voor betrouwbaarheid

Houd er rekening mee dat dit artikel is gericht op een subset van Azure-containerservices die een volwassen functieset bieden voor webtoepassingen en API's, netwerken, waarneembaarheid, ontwikkelhulpprogramma's en bewerkingen: Azure Kubernetes Service (AKS), Azure Container Apps en Web App for Containers. Zie de pagina productcategorie containerservices voor containerservices voor een volledige lijst met alle Azure-containerservices.

Notitie

In deze handleiding verwijst de term workload naar een verzameling toepassingsresources die ondersteuning bieden voor een bedrijfsdoel of de uitvoering van een bedrijfsproces. Een workload maakt gebruik van meerdere onderdelen, zoals API's en gegevensarchieven, die samenwerken om specifieke end-to-end-functionaliteit te leveren.

Overwegingen voor architectuur

In deze sectie worden beslissingen over de architectuur beschreven die moeilijk om te keren of te corrigeren zijn zonder dat er aanzienlijke downtime of herimplementatie nodig is. Het is met name nodig om rekening te houden met fundamentele onderdelen, zoals netwerken en beveiliging.

Deze overwegingen zijn niet specifiek voor goed ontworpen frameworkpijlers. Ze verdienen echter extra controle en evaluatie ten opzichte van de vereisten van bedrijven wanneer u een Azure-containerservice kiest.

Ondersteuning van het besturingssysteem

De meeste containertoepassingen worden uitgevoerd in Linux-containers, die worden ondersteund door alle Azure-containerservices. Uw opties zijn beperkter voor workloadonderdelen waarvoor Windows-containers zijn vereist.

Container Apps AKS Web App for Containers
Linux-ondersteuning ✅ ✅ ✅
Windows-ondersteuning ❌ ✅ ✅
Ondersteuning voor gemengde besturingssystemen ❌ ✅ ❌*

*Ondersteuning voor gemengde besturingssystemen voor Web App for Containers vereist afzonderlijke Azure-app Service-abonnementen voor Windows en Linux.

Aandachtspunten voor netwerken

Het is belangrijk dat u het netwerkontwerp vroeg in uw planningsprocessen begrijpt vanwege beveiligings- en nalevingsbeperkingen en opgelegde richtlijnen. Over het algemeen zijn de belangrijkste verschillen tussen de Azure-services die in deze handleiding worden behandeld, afhankelijk van de voorkeur:

  • Container Apps is een PaaS-aanbieding die veel door Azure beheerde netwerkfuncties biedt, zoals servicedetectie en interne beheerde domeinen. Workloadteams die iets meer configureerbaarheid nodig hebben, kunnen workload-/toegewezen profielen gebruiken voordat ze alternatieven overwegen om hun netwerkopties te maximaliseren.
  • AKS is het meest configureerbaar van de drie services en biedt de meeste controle over de netwerkstroom. Het biedt bijvoorbeeld aangepaste ingangscontrollers en het beheer van verkeer tussen clusters via Kubernetes-netwerkbeleid. Workloadteams kunnen profiteren van verschillende door Azure beheerde netwerkinvoegtoepassingen en eventuele invoegtoepassingen installeren en gebruiken vanuit het bredere Kubernetes-ecosysteem.
  • Web App for Containers is een functie van App Service. De netwerkconcepten, met name de integratie van privénetwerken, zijn dus zeer specifiek voor App Service. Deze service is bekend met workloadteams die al gebruikmaken van App Service. Teams die geen ervaring hebben met App Service en die een vertrouwdere integratie van virtuele Azure-netwerken willen, worden aangemoedigd om Container Apps te overwegen.

Houd er rekening mee dat netwerken een basisinfrastructuurlaag is. Het is vaak moeilijk om wijzigingen aan te brengen in het ontwerp zonder de workload opnieuw te implementeren, wat kan leiden tot downtime. Als uw workload specifieke netwerkvereisten heeft, bekijkt u deze sectie zorgvuldig voordat u de selectie van uw Azure-containerservice beperkt.

Netwerkadresruimten

Wanneer u toepassingen integreert in virtuele netwerken, moet u een aantal IP-adressen plannen om ervoor te zorgen dat er voldoende IP-adressen beschikbaar zijn voor containerinstanties. Plan tijdens dit proces aanvullende adressen voor updates, blauw/groene implementaties en vergelijkbare situaties waarin extra exemplaren worden geïmplementeerd, die extra IP-adressen verbruiken.

Container Apps AKS Web App for Containers
Toegewezen subnetten Verbruiksabonnement: optioneel
Toegewezen abonnement: vereist		 Vereist Optioneel
Vereisten voor IP-adressen Verbruiksabonnement: Zie alleen-verbruiksomgeving.
Toegewezen plan: Zie de omgeving voor workloadprofielen.		 Zie virtuele Azure-netwerken voor AKS. Zie de vereisten voor het App Service-subnet.

Houd er rekening mee dat de AKS-vereisten afhankelijk zijn van de gekozen netwerkinvoegtoepassing. Voor sommige netwerkinvoegtoepassingen voor AKS zijn bredere IP-reserveringen vereist. Details vallen buiten het bereik van dit artikel. Zie Netwerkconcepten voor AKS voor meer informatie.

Inzicht in verkeersstroom

De typen verkeersstroom die vereist zijn voor een oplossing, kunnen van invloed zijn op het netwerkontwerp.

De volgende secties bevatten informatie over verschillende netwerkbeperkingen. Deze beperkingen zijn van invloed op de noodzaak om extra subnetten te implementeren, afhankelijk van of u het volgende nodig hebt:

  • Meerdere workloads met een puntkomma.
  • Privé- en/of openbare toegangsbeheerobjecten.
  • Een toegangsbeheerde stroom van oost-west-verkeer in een cluster (voor Container Apps en AKS) of binnen een virtueel netwerk (voor alle Azure-containerservices).

Subnetplanning

Zorg ervoor dat u een subnet hebt dat groot genoeg is om instanties van uw toepassing voor uw workload op te nemen, is niet de enige factor die de netwerkvoetafdruk bepaalt waar deze toepassingen worden geïmplementeerd.

Container Apps AKS Web App for Containers
Ondersteuning voor werkbelastingen in een subnet* ❌* ✅ N.v.t.*

*Dit beschrijft een best practice, geen technische beperking.

Voor Container Apps is subnetintegratie alleen van toepassing op één Container Apps-omgeving. Elke Container Apps-omgeving is beperkt tot één inkomend IP-adres, openbaar of privé.

Elke Container Apps-omgeving is alleen bedoeld voor één workload waarin afhankelijke toepassingen zijn geplaatst. Daarom moet u extra Azure-netwerkapparaten introduceren voor inkomend verkeer als u zowel openbaar als privé-inkomend verkeer nodig hebt. Voorbeelden hiervan zijn Azure-toepassing Gateway en Azure Front Door. Als u meerdere workloads hebt die moeten worden gescheiden, zijn er extra Container Apps-omgevingen vereist, zodat er een extra subnet moet worden toegewezen voor elke omgeving.

AKS biedt gedetailleerd beheer van de netwerkstroom oost-west binnen het cluster in de vorm van Kubernetes-netwerkbeleid. Met dit stroombeheer kunt u meerdere workloads segmenteren met verschillende netwerkbeveiligingsgrenzen binnen hetzelfde cluster.

Voor Web App for Containers gelden er geen beperkingen voor het aantal apps dat u met één subnet kunt integreren, zolang het subnet groot genoeg is. Er zijn geen aanbevolen procedures voor toegangsbeheer tussen web-apps in hetzelfde virtuele netwerk. Elke web-app beheert onafhankelijk toegangsbeheer voor respectievelijk oost-west- of noord-zuidverkeer van het virtuele netwerk of internet.

Notitie

U kunt het formaat van subnetten waarop resources zijn geïmplementeerd, niet wijzigen. Zorg er extra voor wanneer u uw netwerk plant om te voorkomen dat u hele workloadonderdelen opnieuw moet implementeren, wat kan leiden tot downtime.

Aantal beschikbare ip-adressen voor inkomend verkeer

In de volgende tabel wordt rekening gehouden met de vorige sectie voor subnetplanning om te definiëren hoeveel IP-adressen beschikbaar kunnen worden gemaakt voor een willekeurig aantal toepassingen dat wordt gehost in één implementatie van een Azure-containerservice.

Container Apps AKS Web App for Containers
Aantal ip-adressen voor inkomend verkeer Eén Veel App Service-omgeving: één
Geen App Service-omgeving: veel

Container Apps staat één IP per omgeving, openbaar of privé toe. AKS staat een willekeurig aantal IP-adressen, openbaar of privé toe. Web App for Containers, buiten een App Service-omgeving, staat één openbaar IP-adres toe voor alle apps binnen een App Service-plan en meerdere privé-IP's die gebruikmaken van privé-eindpunten van Azure.

Het is belangrijk te weten dat web-apps die zijn geïntegreerd in een App Service Environment alleen verkeer ontvangen via het ip-adres voor inkomend verkeer dat is gekoppeld aan de App Service Environment, ongeacht of deze openbaar of privé is.

Door de gebruiker gedefinieerde routes en NAT-gatewayondersteuning

Als voor een workload door de gebruiker gedefinieerde routes (UDR's) en NAT-gatewaymogelijkheden zijn vereist voor gedetailleerd netwerkbeheer, vereist Container Apps het gebruik van workloadprofielen. UDR- en NAT-gatewaycompatibiliteit is niet beschikbaar in het abonnement voor alleen verbruik voor ACA.

AKS en Web App for Containers implementeren deze twee netwerkfuncties via respectievelijk de standaardfunctionaliteit voor virtuele netwerken of integratie van virtuele netwerken. Om uit te werken, zijn AKS-knooppuntgroepen en Web App for Containers in een App Service Environment al directe virtuele netwerkresources. Web App for Containers die zich niet in een App Service Environment bevinden, bieden ondersteuning voor UDR's en NAT-gateway via integratie van virtuele netwerken. Met integratie van virtuele netwerken bevindt de resource zich technisch gesproken niet rechtstreeks in het virtuele netwerk, maar alle uitgaande toegangsstromen via het virtuele netwerk en de bijbehorende regels van het netwerk zijn van invloed op verkeer zoals verwacht.

Container Apps AKS Web App for Containers
UDR-ondersteuning Abonnement met alleen verbruik: ❌
Plan van workloadprofiel: ✅		 ✅ ✅
Ondersteuning voor NAT-gateway Abonnement met alleen verbruik: ❌
Plan van workloadprofiel: ✅		 ✅ ✅

Integratie van privénetwerken

Voor workloads waarvoor strikte laag 4-privénetwerken zijn vereist voor zowel inkomend als uitgaand verkeer, moet u Container Apps, AKS en de SKU voor app-omgeving met één tenant overwegen, waarbij workloads worden geïmplementeerd in een zelfbeheerd virtueel netwerk, met de aangepaste gedetailleerde besturingselementen voor privénetwerken.

Container Apps AKS Web App for Containers
Privé-inkomend verkeer in een virtueel netwerk ✅ ✅ Via privé-eindpunt
Privé-uitgaand verkeer van een virtueel netwerk ✅ ✅ Via integratie van virtueel netwerk
Volledig onderdrukt openbaar eindpunt ✅ ✅ Alleen App Service Environment
Privénetwerken met Web App for Containers

Web App for Containers biedt extra netwerkfuncties die niet op dezelfde manier worden weergegeven door de andere Azure-services die in dit artikel worden beschreven. Om strikte vereisten voor privénetwerken te implementeren, moeten workloadteams zich vertrouwd maken met deze netwerkconcepten. Bekijk de volgende netwerkfuncties zorgvuldig:

Als u een PaaS-oplossing wilt en de voorkeur geeft aan netwerkconcepten die worden gedeeld in meerdere Azure-oplossingen, moet u Container Apps overwegen.

Protocoldekking

Een belangrijke overweging voor het hostingplatform zijn de netwerkprotocollen die worden ondersteund voor binnenkomende toepassingsaanvragen (inkomend verkeer). Web App for Containers is de strengste optie die alleen HTTP en HTTPS ondersteunt. Container Apps maakt bovendien binnenkomende TCP-verbindingen mogelijk. AKS is het meest flexibele, ondersteunend niet-getraind gebruik van TCP en UDP op zelf-geselecteerde poorten.

Container Apps AKS Web App for Containers
Protocol- en poortondersteuning HTTP (poort 80)*
HTTPS (poort 443)*
TCP (poorten 1-65535, behalve 80 en 443)		 TCP (elke poort)
UDP (elke poort)		 HTTP (poort 80)
HTTPS (poort 443)
Ondersteuning voor WebSocket ✅ ✅ ✅
Ondersteuning voor HTTP/2 ✅ ✅ ✅

*In de Container Apps-omgeving kan HTTP/S worden weergegeven op elke poort voor communicatie tussen clusters. In dat scenario zijn ingebouwde HTTP-functies van Container Apps, zoals CORS en sessieaffiniteit, niet van toepassing.

Zowel Container Apps als Web App for Containers ondersteunen TLS 1.2 voor hun ingebouwde HTTPS-inkomend verkeer.

Load balancing

Met Container Apps en Web App for Containers abstraheert Azure de load balancers van Laag 4 en Laag 7 volledig.

AKS maakt daarentegen gebruik van een model voor gedeelde verantwoordelijkheid waarin Azure de onderliggende Azure-infrastructuur beheert die het workloadteam configureert door te communiceren met de Kubernetes-API. Voor taakverdeling op laag 7 in AKS kunt u een door Azure beheerde opties kiezen, bijvoorbeeld de invoegtoepassing voor routering van door AKS beheerde toepassingen of de Application Gateway for Containers, of een controller voor inkomend verkeer van uw keuze implementeren en zelf beheren.

Container Apps AKS Web App for Containers
Laag 4 load balancer Door Azure beheerd Gedeelde verantwoordelijkheid Door Azure beheerd
Load balancer van laag 7 Door Azure beheerd Gedeeld of zelfbeheerd Door Azure beheerd

Servicedetectie

In cloudarchitecturen kunnen runtimes op elk gewenst moment worden verwijderd en opnieuw worden gemaakt om resources opnieuw te verdelen, zodat exemplaar-IP-adressen regelmatig veranderen. Deze architecturen gebruiken FQDN's (Fully Qualified Domain Names) voor betrouwbare en consistente communicatie.

Container Apps AKS Web App for Containers
Servicedetectie Door Azure beheerde FQDN Kubernetes configureerbaar Door Azure beheerde FQDN

Web Apps for Containers biedt standaard openbare FQDN's voor inkomend verkeer (noord-zuid). Er is geen extra DNS-configuratie vereist. Er is echter geen ingebouwd mechanisme om verkeer tussen andere apps (oost-west-communicatie) te vergemakkelijken of te beperken.

Container Apps biedt ook openbare FQDN's voor inkomend verkeer. Container Apps gaat echter verder door toe te staan dat de FQDN van de app alleen in de omgeving beschikbaar wordt gesteld en het verkeer beperkt. Deze functionaliteit maakt het eenvoudiger om oost-west-communicatie te beheren en onderdelen zoals Dapr in te schakelen.

Kubernetes-implementaties zijn in eerste instantie niet detecteerbaar binnen of buiten het cluster. U moet Kubernetes-services maken zoals gedefinieerd door de Kubernetes-API, waarmee toepassingen vervolgens op een adresseerbare manier aan het netwerk worden blootgesteld.

Belangrijk

Alleen Container Apps en AKS bieden servicedetectie via interne DNS-schema's binnen hun respectieve omgevingen. Deze functionaliteit kan DNS-configuraties vereenvoudigen in ontwikkel-/test- en productieomgevingen. U kunt deze omgevingen bijvoorbeeld maken met willekeurige servicenamen die alleen uniek moeten zijn binnen de omgeving of het cluster, zodat ze hetzelfde kunnen zijn in dev/test en productie. Met Web App for Containers moeten servicenamen uniek zijn in verschillende omgevingen om conflicten met Azure DNS te voorkomen.

Aangepaste domeinen en beheerde TLS

Zowel Container Apps als Web App for Containers bieden out-of-the-box-oplossingen voor aangepaste domeinen en certificaatbeheer.

Container Apps AKS Web App for Containers
Aangepaste domeinen configureren Out-of-the-box BYO Out-of-the-box
Beheerde TLS voor Azure FQDN's Out-of-the-box N.v.t. Out-of-the-box
Beheerde TLS voor aangepaste domeinen In preview BYO Out of the box or BYO

AKS-gebruikers zijn verantwoordelijk voor het beheren van DNS-, clusterconfiguraties en TLS-certificaten voor hun aangepaste domeinen. Hoewel AKS geen beheerde TLS biedt, kunnen klanten gebruikmaken van software uit het Kubernetes-ecosysteem, bijvoorbeeld de populaire certificaatbeheerder voor het beheren van TLS-certificaten.

Wederzijdse TLS

Een ander alternatief voor het beperken van binnenkomend verkeer is wederzijdse TLS (mTLS). Wederzijdse TLS is een beveiligingsprotocol dat ervoor zorgt dat zowel de client als de server in communicatie worden geverifieerd. Voor verificatie wisselen beide partijen certificaten uit en verifiëren ze certificaten voordat gegevens worden verzonden.

Web App for Containers heeft ingebouwde mTLS-ondersteuning voor binnenkomende clientverbindingen. De toepassing moet het certificaat echter valideren door toegang te krijgen tot de X-ARR-ClientCert HTTP-header die het App Service-platform doorstuurt.

Container Apps biedt ook ingebouwde ondersteuning voor mTLS. Het clientcertificaat wordt doorgestuurd naar de toepassing in de HTTP-header X-Forwarded-Client-Cert. U kunt automatische mTLS ook eenvoudig inschakelen voor interne communicatie tussen apps in één omgeving.

Wederzijdse TLS in AKS kan worden geïmplementeerd via de service-mesh op basis van Istio als een beheerde invoegtoepassing, waaronder mTLS-mogelijkheden voor binnenkomende clientverbindingen en intraclustercommunicatie tussen services. Workloadteams kunnen er ook voor kiezen om een ander service-mesh-aanbod te installeren en te beheren vanuit het Kubernetes-ecosysteem. Deze opties maken mTLS-implementatie in Kubernetes het meest flexibel.

Servicespecifieke netwerkconcepten

In de voorgaande secties worden enkele van de meest voorkomende overwegingen beschreven waarmee u rekening moet houden. Zie de volgende artikelen voor meer informatie en meer informatie over netwerkfuncties die specifiek zijn voor afzonderlijke Azure-containerservices:

De voorgaande secties richten zich op het netwerkontwerp. Ga door naar de volgende sectie voor meer informatie over netwerkbeveiliging en het beveiligen van netwerkverkeer.

Beveiligingsoverwegingen

Als er geen beveiligingsrisico's worden aangepakt, kan dit leiden tot onbevoegde toegang, gegevensschendingen of lekken van gevoelige informatie. Containers bieden een ingekapselde omgeving voor uw toepassing. De hostingsystemen en onderliggende netwerkoverlays vereisen echter extra kaders. Uw keuze voor Azure Container Service moet uw specifieke vereisten ondersteunen voor het afzonderlijk beveiligen van elke toepassing en de juiste beveiligingsmaatregelen bieden om onbevoegde toegang te voorkomen en het risico op aanvallen te beperken.

Overzicht van beveiligingsvergelijking

De meeste Azure-services, waaronder Container Apps, AKS en Web App for Containers, kunnen worden geïntegreerd met belangrijke beveiligingsaanbiedingen, waaronder Key Vault en beheerde identiteiten.

Van de services in deze handleiding biedt AKS gedeeltelijk de meest configureerbaarheid en uitbreidbaarheid door onderliggende onderdelen weer te geven, die vaak kunnen worden beveiligd via configuratieopties. Klanten kunnen bijvoorbeeld lokale accounts uitschakelen op de Kubernetes API-server of automatische updates voor onderliggende knooppunten inschakelen via configuratieopties.

Bekijk voor een gedetailleerde vergelijking de volgende overwegingen om ervoor te zorgen dat aan de beveiligingsvereisten van uw workload kan worden voldaan.

Beveiliging van kubernetes-besturingsvlak

AKS biedt de meeste flexibiliteit van de drie opties die in dit artikel worden overwogen en biedt volledige toegang tot de Kubernetes-API, zodat u containerindeling kunt aanpassen. Deze toegang tot de Kubernetes-API vertegenwoordigt echter ook een aanzienlijk kwetsbaarheid voor aanvallen en u moet deze beveiligen.

Belangrijk

Houd er rekening mee dat deze sectie niet relevant is voor Web App for Containers, die de Azure Resource Manager-API als besturingsvlak gebruikt.

Beveiliging op basis van identiteit

Klanten zijn verantwoordelijk voor het beveiligen van op identiteiten gebaseerde toegang tot de API. Standaard biedt Kubernetes een eigen verificatie- en autorisatiebeheersysteem, dat ook moet worden beveiligd met toegangsbeheer.

Als u wilt profiteren van één glasvlak voor identiteits- en toegangsbeheer in Azure, is het een best practice om Kubernetes-specifieke lokale accounts uit te schakelen en in plaats daarvan AKS-beheerde Microsoft Entra-integratie te implementeren in combinatie met Azure RBAC voor Kubernetes. Als u deze best practice implementeert, hoeven beheerders geen identiteits- en toegangsbeheer uit te voeren op meerdere platforms.

Container Apps AKS
Toegangsbeheer voor Kubernetes-API Geen toegang Volledige toegang

Klanten die Container Apps gebruiken, hebben geen toegang tot de Kubernetes-API. Microsoft biedt beveiliging voor deze API.

Netwerkbeveiliging

Als u de netwerktoegang tot het Kubernetes-besturingsvlak wilt beperken, moet u AKS gebruiken. Dit biedt twee opties. De eerste optie is het gebruik van privé-AKS-clusters, die gebruikmaken van Azure Private Link tussen het privénetwerk van de API-server en het privénetwerk van het AKS-cluster. De tweede optie is VNet-integratie van API Server (preview) waarbij de API-server is geïntegreerd in een gedelegeerd subnet. Zie de documentatie voor meer informatie.

Er zijn gevolgen voor het implementeren van netwerktoegang tot de Kubernetes-API. Met name kan beheer alleen worden uitgevoerd vanuit het particuliere netwerk. Dit betekent meestal dat u zelf-hostende agents moet implementeren voor Azure DevOps of GitHub Actions. Zie de productspecifieke documentatie voor meer informatie over andere beperkingen.

Container Apps AKS
Kubernetes API-netwerkbeveiliging Kan niet worden geconfigureerd in PaaS Configureerbaar: openbaar IP- of privé-IP-adres

Deze overwegingen zijn niet van toepassing op Container Apps. Omdat het PaaS is, abstraheert Microsoft de onderliggende infrastructuur.

Netwerkbeveiliging van gegevensvlak

De volgende netwerkfuncties kunnen worden gebruikt om de toegang tot, van en binnen een workload te beheren.

Netwerkbeleid gebruiken om beveiliging te bieden voor verkeer tussen clusters

Voor sommige beveiligingspostuuren is scheiding van netwerkverkeer in een omgeving vereist, bijvoorbeeld wanneer u omgevingen met meerdere tenants gebruikt voor het hosten van meerdere of toepassingen met meerdere lagen. In deze scenario's moet u AKS kiezen en netwerkbeleid implementeren, een cloudeigen technologie die een gedetailleerde configuratie van Laag 4-netwerken binnen Kubernetes-clusters mogelijk maakt.

Container Apps AKS Web App for Containers
Netwerkbeleid Verbruiksabonnement: ❌
Toegewezen abonnement: ❌		 ✅ ❌

Van de drie Azure-services die in dit artikel worden beschreven, is AKS de enige die ondersteuning biedt voor verdere isolatie van werkbelastingen binnen het cluster. Netwerkbeleid wordt niet ondersteund in Container Apps of Web App for Containers.

Netwerkbeveiligingsgroepen

In alle scenario's kunt u netwerkcommunicatie binnen het bredere virtuele netwerk reguleren met behulp van netwerkbeveiligingsgroepen, waarmee u laag 4-verkeersregels kunt gebruiken die inkomend en uitgaand verkeer op het niveau van het virtuele netwerk reguleren.

Container Apps AKS Web App for Containers
Netwerkbeveiligingsgroepen Verbruiksabonnement: ✅
Toegewezen abonnement: ✅		 ✅ ✅ Met VNet geïntegreerde apps: alleen uitgaand verkeer

IP-beperkingen voor inkomend verkeer

Normaal gesproken worden netwerkverkeersbeperkingen toegepast via laag 4-regels die hierboven worden beschreven. In PaaS-scenario's van toepassingen zonder integratie van virtuele netwerken kan het echter handig zijn om verkeer op de toepassingslaag te beperken.

Container Apps en Web App for Containers bieden ingebouwde IP-beperkingen voor inkomend verkeer voor afzonderlijke toepassingen.

Container Apps AKS Web App for Containers
IP-beperkingen voor inkomend verkeer op de toepassingslaag Out-of-the-box Zelfbeheerd of via beheerde invoegtoepassing Out-of-the-box
Resourceverbruik - Clusterbronnen verbruikt -

Voor AKS-workloads is de implementatie afhankelijk van de gekozen ingangscontroller. Zowel zelfbeheerde als de door Azure beheerde invoegtoepassing voor routering van toepassingen verbruiken clusterbronnen.

Beveiliging op toepassingsniveau

U moet workloads niet alleen op netwerk- en infrastructuurniveau beveiligen, maar ook op workload- en toepassingsniveau. Azure-containeroplossingen kunnen worden geïntegreerd met Azure-beveiligingsaanbiedingen om de implementatie en controles van beveiliging voor uw toepassingen te standaardiseren.

Key Vault-integratie

Het is een best practice om geheimen, sleutels en certificaten op te slaan en te beheren in een oplossing voor sleutelbeheer, zoals Key Vault, die een verbeterde beveiliging biedt voor deze onderdelen. In plaats van geheimen op te slaan en te configureren in code of in een Azure-rekenservice, moeten alle toepassingen worden geïntegreerd met Key Vault.

Met Key Vault-integratie kunnen ontwikkelaars van toepassingen zich richten op hun toepassingscode. Alle drie de Azure-containerservices die in dit artikel worden beschreven, kunnen geheimen van de Key Vault-service automatisch synchroniseren en aan de toepassing leveren, meestal als omgevingsvariabelen of gekoppelde bestanden.

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

Zie voor meer informatie:

Ondersteuning voor beheerde identiteit

Toepassingen met toegewezen beheerde identiteiten hebben toegang tot Azure-resources zonder wachtwoorden. Alle containerservices die in deze handleiding worden genoemd, ondersteunen beheerde identiteiten.

Container Apps AKS Web App for Containers
Ondersteuning voor beheerde identiteit ✅ ✅ ✅

Zie voor meer informatie:

Evaluaties van bedreigingsbeveiliging en beveiligingsproblemen met Defender for Containers

Bedreigingsbeveiliging tegen beveiligingsproblemen is ook belangrijk. Het is een best practice om Defender for Containers te gebruiken. Evaluaties van beveiligingsproblemen worden ondersteund in Azure-containerregisters, zodat ze kunnen worden gebruikt door elke Azure-containerservice, niet alleen de azure-containerregisters die in dit artikel worden beschreven. Defender for Containers Runtime Protection is echter alleen beschikbaar voor AKS.

Omdat AKS de systeemeigen Kubernetes-API beschikbaar maakt, kan clusterbeveiliging ook worden geëvalueerd met Kubernetes-specifieke beveiligingshulpprogramma's van het Kubernetes-ecosysteem.

Container Apps AKS Web App for Containers
Runtime-bedreigingsbeveiliging ❌ ✅ ❌

Zie Containers-ondersteuningsmatrix in Defender voor Cloud voor meer informatie.

Houd er rekening mee dat evaluaties van beveiligingsproblemen in containerinstallatiekopieën geen realtime scans zijn. Het Azure-containerregister wordt regelmatig gescand.

Beveiligingsbasislijnen

Over het algemeen integreren de meeste Azure-containerservices Azure-beveiligingsaanbiedingen. Houd er in het algemeen rekening mee dat een beveiligingsfunctiesset slechts een klein deel is van het implementeren van cloudbeveiliging. Zie de volgende servicespecifieke beveiligingsbasislijnen voor meer informatie over het implementeren van beveiliging voor containerservices:

De beveiligingsbasislijnen hebben betrekking op andere Azure-integraties, waaronder hardwareversleuteling en logboekregistratie, die buiten het bereik van dit artikel vallen.

Goed ontworpen framework voor beveiliging

Dit artikel is gericht op de belangrijkste verschillen tussen de functies van containerservices die hier worden beschreven.

Zie Voor meer volledige beveiligingsrichtlijnen over AKS, zie Well-Architected Framework review - AKS.

Operationele overwegingen

Als u een workload in productie wilt uitvoeren, moeten teams procedures voor operationele uitmuntendheid implementeren, waaronder gecentraliseerde logboekregistratie, bewaking, schaalbaarheid, regelmatige updates en patching en beheer van installatiekopieën.

Updates en patches

Het is belangrijk dat het onderliggende besturingssysteem van een toepassing wordt bijgewerkt en regelmatig wordt gepatcht. Houd er echter rekening mee dat er bij elke update een fout kan optreden. In deze sectie en de volgende sectie worden de belangrijkste overwegingen beschreven voor de drie containerservices met betrekking tot de gedeelde verantwoordelijkheid tussen de klant en het platform.

Als beheerde Kubernetes-service biedt AKS de bijgewerkte installatiekopieën voor het knooppuntbesturingssysteem en onderdelen van het besturingsvlak. Maar workloadteams zijn verantwoordelijk voor het toepassen van updates op hun clusters. U kunt handmatig updates activeren of gebruikmaken van de functie voor het automatisch upgraden van clusters om ervoor te zorgen dat uw clusters up-to-date zijn. Zie de handleiding voor AKS day-2-bewerkingen voor meer informatie over het patchen en upgraden van AKS-clusters.

Container Apps en Web App for Containers zijn PaaS-oplossingen. Azure is verantwoordelijk voor het beheren van updates en patches, zodat klanten de complexiteit van AKS-upgradebeheer kunnen vermijden.

Container Apps AKS Web App for Containers
Updates van besturingsvlak Platform Klant Platform
Updates en patches hosten Platform Klant Platform
Updates en patches voor containerinstallatiekopieën Customer Customer Customer

Updates van containerinstallatiekopieën

Ongeacht de Azure-containeroplossing zijn klanten altijd verantwoordelijk voor hun eigen containerinstallatiekopieën. Als er beveiligingspatches voor containerbasisinstallatiekopieën zijn, is het uw verantwoordelijkheid om uw installatiekopieën opnieuw te bouwen. Als u waarschuwingen wilt ontvangen over deze beveiligingsproblemen, gebruikt u Defender for Containers voor containers die worden gehost in Container Registry.

Schaalbaarheid

Schalen wordt gebruikt om de resourcecapaciteit aan te passen aan de eisen, meer capaciteit toe te voegen om prestaties te garanderen en ongebruikte capaciteit te verwijderen om geld te besparen. Wanneer u een containeroplossing kiest, moet u rekening houden met infrastructuurbeperkingen en schaalstrategieën.

Schaalbaarheid van verticale infrastructuur

Verticaal schalen verwijst naar de mogelijkheid om de bestaande infrastructuur te vergroten of verkleinen, dat wil gezegd, CPU en geheugen berekenen. Voor verschillende workloads zijn verschillende hoeveelheden rekenresources vereist. Wanneer u een Azure-containeroplossing kiest, moet u rekening houden met de hardware-SKU-aanbiedingen die beschikbaar zijn voor een bepaalde Azure-service. Ze variëren en kunnen extra beperkingen opleggen.

Raadpleeg voor AKS de grootten voor virtuele machines in de Azure-documentatie en de AKS-beperkingen per regio.

Deze artikelen bevatten informatie over SKU-aanbiedingen voor de andere twee services:

Schaalbaarheid van horizontale infrastructuur

Horizontaal schalen verwijst naar de mogelijkheid om de capaciteit te vergroten of te verlagen via een nieuwe infrastructuur, zoals VM-knooppunten. Tijdens het vergroten of verkleinen van de Container Apps-verbruikslaag worden de onderliggende virtuele machines geabstraheerd. Voor de resterende Azure-containerservices beheert u de strategie voor horizontaal schalen met behulp van de standaard Azure Resource Manager-API.

Houd er rekening mee dat uitschalen en inschalen het opnieuw verdelen van exemplaren omvat, waardoor er ook een risico op downtime ontstaat. Het risico is kleiner dan het bijbehorende risico met verticale schaalaanpassing. Toch zijn workloadteams altijd verantwoordelijk voor het afhandelen van fouten in hun toepassingen en voor het implementeren van probleemloze start-ups en het afsluiten van hun toepassingen om downtime te voorkomen.

Container Apps AKS Web App for Containers
Infrastructuur in- en uitschalen Verbruiksabonnement: N/B
Toegewezen plan: configureerbaar		 Configureerbaar Configureerbaar
Flexibele hardwareinrichting Verbruiksabonnement: N/B
Toegewezen plan: geabstraheerd met workloadprofielen		 Elke VM-SKU Verstrooid. Zie Het App Service-plan.

Belangrijk

De hardwareinrichtingsopties die beschikbaar zijn via het Container Apps Dedicated-plan (workloadprofielen) en Web App for Containers (App Service-plannen) zijn niet zo flexibel als AKS. U moet vertrouwd raken met de SKU's die beschikbaar zijn in elke service om ervoor te zorgen dat aan uw behoeften wordt voldaan.

Schaalbaarheid van toepassingen

De gebruikelijke meting voor het activeren van het schalen van infrastructuur en toepassingen is resourceverbruik: CPU en geheugen. Sommige containeroplossingen kunnen het aantal containerinstanties schalen op metrische gegevens met toepassingsspecifieke context, zoals HTTP-aanvragen. AKS en Container Apps kunnen bijvoorbeeld containerinstanties schalen op basis van berichtenwachtrijen via KEDA en veel andere metrische gegevens via de schaalders. Deze mogelijkheden bieden flexibiliteit wanneer u de schaalbaarheidsstrategie voor uw toepassing kiest. Web App for Containers is afhankelijk van de schaalbaarheidsopties van Azure. (Zie de volgende tabel.) Web App for Containers biedt geen ondersteuning voor aangepaste schaalaanpassingsconfiguraties, zoals KEDA.

Container Apps AKS Web App for Containers
Container uitschalen HTTP, TCP of op metrische gegevens gebaseerd (CPU, geheugen, gebeurtenisgestuurd). Op basis van metrische gegevens (CPU, geheugen of aangepast). Handmatig, op metrische gegevens gebaseerd of automatisch (preview).
Gebeurtenisgestuurde schaalbaarheid Ja. Cloudeigen. Ja. Cloudeigen. Aanvullende configuratie vereist. Ja. Azure-resourcespecifiek.

Waarneembaarheid

Instrumentatie van werkbelasting

Het verzamelen van metrische gegevens voor complexe of toepassingen met meerdere lagen kan lastig zijn. Als u metrische gegevens wilt ophalen, kunt u workloads in containers integreren met Azure Monitor op twee manieren:

  • Automatische instrumentatie. Er zijn geen codewijzigingen vereist.
  • Handmatige instrumentatie. Minimale codewijzigingen die nodig zijn voor het integreren en configureren van de SDK en/of client.
Container Apps AKS Web App for Containers
Automatische instrumentatie via platform ❌ ❌ Gedeeltelijke ondersteuning*
Automatische instrumentatie via agent ❌ Gedeeltelijke ondersteuning* N.v.t.
Handmatige instrumentatie Via SDK of OpenTelemetry Via SDK of OpenTelemetry Via SDK of OpenTelemetry

*AKS en Web App for Containers ondersteunen automatische instrumentatie voor bepaalde configuraties van Linux- en Windows-workloads, afhankelijk van de toepassingstaal. Lees deze artikelen voor meer informatie:

Instrumentatie binnen toepassingscode is de verantwoordelijkheid van toepassingsontwikkelaars, dus het is onafhankelijk van elke Azure-containeroplossing. Uw workload kan oplossingen gebruiken zoals:

Logboeken

Alle Azure-containerservices bieden functionaliteit voor toepassings- en platformlogboeken. Toepassingslogboeken zijn consolelogboeken die worden gegenereerd door uw workload. In platformlogboeken worden gebeurtenissen vastgelegd die plaatsvinden op platformniveau, buiten het bereik van uw toepassing, zoals schalen en implementaties.

De belangrijkste verschillen tussen de functionaliteit voor logboekregistratie voor containerservices hebben betrekking op platformregistratie: wat wordt geregistreerd en hoe logboeken intern worden georganiseerd. Azure Monitor is de belangrijkste logboekregistratieservice in Azure die kan worden geïntegreerd met deze services. Monitor maakt gebruik van resourcelogboeken om logboeken te scheiden die afkomstig zijn van verschillende bronnen in categorieën. Een manier om te bepalen welke logboeken beschikbaar zijn in elke Azure-service, is door te kijken naar de resourcelogboekcategorieën die beschikbaar zijn voor elk van de services.

Container Apps AKS Web App for Containers
Ondersteuning voor logboekstreaming (realtime streaming) ✅ ✅ ✅
Ondersteuning voor Azure Monitor ✅ ✅ ✅
Azure Monitor-resourcelogboeken Console en systeem Kubernetes API-server, controle, scheduler, automatische schaalaanpassing van clusters en meer ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs en meer

Selecteer de koppelingen in de tabel voor een gedetailleerde beschrijving van elk van de resourcelogboeken in de tabel.

Hier volgt een kort overzicht van de mogelijkheden voor logboekregistratie van de containerservices:

  • Container Apps abstraheert alle interne Kubernetes-logboeken in twee categorieën. Een, genaamd Console-logboeken , bevat de logboeken van de workloadcontainer. Een tweede systeemcategorie bevat alle platformgerelateerde logboeken.
  • AKS biedt alle Kubernetes-gerelateerde logboeken en gedetailleerde controle over wat kan worden vastgelegd. Het behoudt ook volledige compatibiliteit met Kubernetes-clienthulpprogramma's voor logboekstreaming, zoals kubectl.
  • Web App for Containers biedt veel categorieën resourcelogboeken omdat het platform (App Service) niet exclusief is voor containerworkloads. Voor containerspecifieke bewerkingen die het interne Docker-platform beheren, biedt het de appServicePlatformLogs-logboekcategorie. Een andere belangrijke categorie is AppServiceEnvironmentPlatformLogs, waarmee gebeurtenissen zoals schalen en configuratiewijzigingen worden geregistreerd.

Goed ontworpen framework voor operationele uitmuntendheid

Dit artikel is gericht op de belangrijkste verschillen tussen de functies van containerservices die hier worden beschreven. Raadpleeg deze artikelen om de volledige Operational Excellence-richtlijnen voor de volgende services te bekijken:

Betrouwbaarheid

Betrouwbaarheid verwijst naar de mogelijkheid van een systeem om te reageren op storingen en volledig functioneel te blijven. Op toepassingssoftwareniveau moeten workloads best practices implementeren, zoals caching, opnieuw proberen, circuitonderbrekerpatronen en statuscontroles. Op infrastructuurniveau is Azure verantwoordelijk voor het afhandelen van fysieke storingen, zoals hardwarefouten en stroomstoringen, in datacenters. Er kunnen nog steeds fouten optreden. Workloadteams moeten de juiste Azure-servicelaag selecteren en de benodigde configuraties voor minimale exemplaren toepassen om automatische failovers tussen beschikbaarheidszones te implementeren.

Als u de juiste servicelaag wilt kiezen, moet u begrijpen hoe serviceovereenkomsten (SLA's) en beschikbaarheidszones werken.

Dienstverleningsovereenkomsten

Betrouwbaarheid wordt meestal gemeten door bedrijfsgestuurde metrische gegevens , zoals SLA's of metrische herstelgegevens, zoals beoogde hersteltijd (RTO's).

Azure heeft veel SLA's voor specifieke services. Er bestaat geen serviceniveau van 100%, omdat er altijd fouten kunnen optreden in software en hardware, en in de natuur, bijvoorbeeld stormen en aardbevingen. Een SLA is geen garantie, maar eerder een financieel ondersteunde overeenkomst voor de beschikbaarheid van services.

Voor de meest recente SLA's en details downloadt u het meest recente SLA voor Microsoft Online Services-document van de microsoft-licentiewebsite.

Gratis versus betaalde lagen

Over het algemeen bieden gratis lagen van Azure-services geen SLA, waardoor ze rendabele keuzes maken voor niet-productieomgevingen. Voor productieomgevingen is het echter een best practice om een betaalde laag met een SLA te kiezen.

Aanvullende factoren voor AKS

AKS heeft verschillende SLA's voor verschillende onderdelen en configuraties:

  • Besturingsvlak. De Kubernetes-API-server heeft een afzonderlijke SLA.
  • Gegevensvlak. Knooppuntgroepen maken gebruik van de onderliggende SKU-SLA's voor VM's.
  • Beschikbaarheidszones. Er zijn verschillende SLA's voor de twee vliegtuigen, afhankelijk van of het AKS-cluster beschikbaarheidszones heeft ingeschakeld en meerdere exemplaren in beschikbaarheidszones uitvoert.

Houd er rekening mee dat wanneer u meerdere Azure-services gebruikt, samengestelde SLO's mogelijk verschillen van en lager zijn dan afzonderlijke service-SLA's.

Redundantie met beschikbaarheidszones

Beschikbaarheidszones zijn afzonderlijke datacenters met onafhankelijke elektrische voeding, koeling, enzovoort, binnen één regio. De resulterende redundantie verhoogt de tolerantie van fouten zonder dat u architecturen met meerdere regio's hoeft te implementeren.

Azure heeft beschikbaarheidszones in elk land/elke regio waarin Azure een datacenterregio beheert. Als u meerdere exemplaren van containers wilt toestaan om meerdere beschikbaarheidszones te kruisen, moet u SKU's, servicelagen en regio's selecteren die ondersteuning bieden voor beschikbaarheidszones.

Functie Container Apps AKS Web App for Containers
Ondersteuning voor beschikbaarheidszone Volledig Volledig Volledig

Een toepassing of infrastructuur die is geconfigureerd voor het uitvoeren van één exemplaar, is bijvoorbeeld niet meer beschikbaar als er een probleem optreedt in de beschikbaarheidszone waar de hardware wordt gehost. Als u volledig gebruik wilt maken van ondersteuning voor beschikbaarheidszones, moet u workloads implementeren met een minimale configuratie van drie exemplaren van de container, verspreid over zones.

Gezondheidscontroles en zelfherstel

Statuscontrole-eindpunten zijn van cruciaal belang voor een betrouwbare workload. Maar het bouwen van deze eindpunten is slechts de helft van de oplossing. De andere helft beheert wat het hostingplatform doet en hoe, wanneer er fouten optreden.

Bekijk de ingebouwde typen tests van Kubernetes om beter onderscheid te maken tussen typen statustests:

  • Opstarten. Controleert of de toepassing is gestart.
  • Gereedheid. Controleert of de toepassing gereed is voor het afhandelen van binnenkomende aanvragen.
  • Leven. Controleert of de toepassing nog steeds wordt uitgevoerd en reageert.

Een andere belangrijke overweging is hoe vaak deze statuscontroles worden aangevraagd bij de toepassing (interne granulariteit). Als u een lang interval tussen deze aanvragen hebt, kunt u verkeer blijven verwerken totdat het exemplaar als beschadigd wordt beschouwd.

De meeste toepassingen ondersteunen statuscontroles via het HTTP(S)-protocol. Sommigen hebben echter mogelijk andere protocollen nodig, zoals TCP of gRPC, om deze controles uit te voeren. Houd dit in gedachten wanneer u uw statuscontrolesysteem ontwerpt.

Container Apps AKS Web App for Containers
Opstarttests ✅ ✅ Gedeeltelijke ondersteuning
Gereedheidstests ✅ ✅ ❌
Liveness-tests ✅ ✅ ✅
Intervalgranulariteit Seconden Seconden 1 minuut
Protocolondersteuning HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

Statuscontroles zijn het eenvoudigst te implementeren in Web App for Containers. Er zijn enkele belangrijke overwegingen:

  • De opstarttests zijn ingebouwd en kunnen niet worden gewijzigd. Er wordt een HTTP-aanvraag verzonden naar de beginpoort van uw container. Elk antwoord van uw toepassing wordt beschouwd als een geslaagde start.
  • Het biedt geen ondersteuning voor gereedheidstests. Als de opstarttest is geslaagd, wordt de containerinstantie toegevoegd aan de groep met gezonde exemplaren.
  • De statuscontrole wordt met intervallen van één minuut verzonden. U kunt het interval niet wijzigen.
  • De minimale drempelwaarde die u kunt instellen voor een beschadigde instantie die moet worden verwijderd uit het interne taakverdelingsmechanisme, is twee minuten. Het beschadigde exemplaar krijgt ten minste twee minuten nadat er een statuscontrole is mislukt. De standaardwaarde voor deze instelling is 10 minuten.

Container Apps en AKS zijn daarentegen veel flexibeler en bieden vergelijkbare opties. Wat specifieke verschillen betreft, biedt AKS de volgende opties voor het uitvoeren van statuscontroles, die niet beschikbaar zijn in Container Apps:

Automatisch herstellen

Een ongeldig containerexemplaren identificeren en stoppen met het verzenden van verkeer naar het exemplaar is een begin. De volgende stap is het implementeren van automatisch herstel. Automatisch herstellen is het proces van het opnieuw opstarten van de toepassing in een poging om te herstellen van een beschadigde status. De drie containerservices vergelijken als volgt:

  • In Web App for Containers is er geen optie om een containerinstantie onmiddellijk opnieuw op te starten nadat een statuscontrole is mislukt. Als het exemplaar één uur blijft mislukken, wordt deze vervangen door een nieuw exemplaar. Er is een andere functie, ook wel automatisch herstellen genoemd, die exemplaren bewaakt en opnieuw start. Het is niet rechtstreeks gerelateerd aan statuscontroles. Er worden verschillende metrische gegevens van toepassingen gebruikt, zoals geheugenlimieten, duur van HTTP-aanvragen en statuscodes.
  • Container Apps en AKS proberen automatisch een containerinstantie opnieuw op te starten als de livenesstest de gedefinieerde drempelwaarde voor fouten bereikt.

Implementaties van toepassingen zonder downtime

De mogelijkheid om toepassingen te implementeren en vervangen zonder downtime voor gebruikers te veroorzaken, is van cruciaal belang voor een betrouwbare workload. Alle drie de containerservices die in dit artikel worden beschreven, bieden ondersteuning voor implementaties zonder downtime, maar op verschillende manieren.

Container Apps AKS Web App for Containers
Strategie voor zero-downtime Rolling update Rolling update, plus alle andere Kubernetes-strategieën Implementatiesites

Houd er rekening mee dat de toepassingsarchitecturen ook ondersteuning moeten bieden voor implementatie zonder downtime. Zie Azure Well-Architected Framework voor hulp.

Bronlimieten

Een ander belangrijk onderdeel van een betrouwbare gedeelde omgeving is uw controle over het resourcegebruik (zoals CPU of geheugen) van uw containers. U moet scenario's voorkomen waarin één toepassing alle resources in beslag neemt en andere toepassingen in een slechte status laat.

Container Apps AKS Web App for Containers
Resourcelimieten (CPU of geheugen) Per app/container Per app/container
Per naamruimte		 Per App Service-plan
  • Web App for Containers: u kunt meerdere toepassingen (containers) hosten in één App Service-plan. U kunt bijvoorbeeld een plan toewijzen met twee CPU-kernen en 4 GiB ram-geheugen waarin u meerdere web-apps in containers kunt uitvoeren. U kunt een van de apps echter niet beperken tot een bepaalde hoeveelheid CPU of geheugen. Ze concurreren allemaal voor dezelfde App Service-planbronnen. Als u uw toepassingsbronnen wilt isoleren, moet u extra App Service-abonnementen maken.
  • Container Apps: U kunt CPU- en geheugenlimieten instellen per toepassing in uw omgeving. U bent echter beperkt tot een set toegestane combinaties van CPU en geheugen. U kunt bijvoorbeeld niet één vCPU en 1 GiB geheugen configureren, maar u kunt één vCPU en 2 GiB aan geheugen configureren. Een Container Apps-omgeving is vergelijkbaar met een Kubernetes-naamruimte.
  • AKS: U kunt elke combinatie van vCPU en geheugen kiezen, zolang uw knooppunten de hardware hebben om deze te ondersteunen. U kunt ook resources beperken op naamruimteniveau als u uw cluster op die manier wilt segmenteren.

Goed ontworpen framework voor betrouwbaarheid

Dit artikel is gericht op de belangrijkste verschillen tussen de functies van containerservices in Azure. Als u de volledige richtlijnen voor betrouwbaarheid voor een specifieke service wilt bekijken, raadpleegt u de volgende artikelen:

Conclusie

Goed ontworpen oplossingen stellen de basis voor succesvolle workloads. Hoewel architecturen kunnen worden aangepast naarmate een workload groeit en teams hun cloudtrajecten voortzetten, zijn sommige beslissingen, met name rond netwerken, moeilijk om te keren zonder aanzienlijke downtime of herimplementatie.

Wanneer u Azure-containerservices vergelijkt, ontstaat er een thema: AKS geeft de meest onderliggende infrastructuur weer, wat de grootste configureerbaarheid en uitbreidbaarheid biedt. De hoeveelheid operationele overhead en complexiteit is zeer variabel voor AKS-workloads. Sommige teams kunnen de operationele overhead aanzienlijk verminderen met behulp van door Microsoft beheerde invoegtoepassingen en extensies, evenals functies voor automatisch upgraden. Andere klanten geven mogelijk de voorkeur aan volledige controle over het cluster om volledige uitbreidbaarheid van Kubernetes en het CNCF-ecosysteem te benutten. Hoewel Microsoft Flux bijvoorbeeld aanbiedt als een beheerde GitOps-extensie, kiezen veel teams ervoor om ArgoCD zelf in te stellen en te gebruiken.

Workloadteams die bijvoorbeeld geen CNCF-toepassingen nodig hebben, minder bewerkingservaring hebben of zich liever richten op toepassingsfuncties, geven mogelijk de voorkeur aan een PaaS-aanbieding. We raden ze aan om container-apps eerst te overwegen.

Hoewel Container Apps en Web App for Containers beide PaaS-aanbiedingen zijn die vergelijkbare niveaus van door Microsoft beheerde infrastructuur bieden, is een belangrijk verschil dat Container Apps zich dichter bij Kubernetes bevindt en aanvullende cloudeigen mogelijkheden biedt voor servicedetectie, gebeurtenisgestuurde automatische schaalaanpassing, Dapr-integratie en meer. Teams die deze mogelijkheden echter niet nodig hebben en bekend zijn met App Service-netwerk- en implementatiemodellen, geven mogelijk de voorkeur aan Web App for Containers.

Met generalisaties kunt u de lijst met Azure-containerservices beperken die u kunt overwegen. Houd er echter rekening mee dat u uw keuze ook moet controleren door afzonderlijke vereisten in detail te onderzoeken en deze te koppelen aan servicespecifieke functiesets.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen