Overwegingen voor architectuur voor het kiezen van een Azure-containerservice

In dit artikel wordt beschreven hoe u een Azure-containerservice kiest. 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. We raden u ten zeerste aan om eerst deel één te lezen om context te krijgen voor deze architectuuroverwegingen.

Overzicht

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

Architectuur- en netwerkoverwegingen

  • Ondersteuning voor besturingssysteem
  • Netwerkadresruimte
  • Verkeersstroomanalyse
  • Planning van subnetten
  • Beschikbare IP-adressen voor inkomend verkeer
  • Door de gebruiker gedefinieerde routes (UDR's) en NAT-gatewayondersteuning
  • Integratie van privénetwerken
  • Protocoldekking
  • Taakverdeling
  • Serviceontdekking
  • Aangepaste domeinen en beheerde TLS (Transport Layer Security)
  • Wederzijdse TLS (mTLS)
  • Geavanceerde containernetwerken voor Azure Kubernetes Service (AKS)
  • Netwerkconcepten voor specifieke Azure-services

Beveiligingsoverwegingen

  • Netwerkbeleid voor de beveiliging van verkeer binnen het cluster
  • Netwerkbeveiligingsgroepen (NSG's)
  • Azure Key Vault-integratie
  • Ondersteuning voor beheerde identiteit
  • Evaluaties van bedreigingsbeveiliging en beveiligingsproblemen met Microsoft Defender for Containers
  • Beveiligingsbasislijnen
  • Azure Well-Architected Framework voor beveiliging

Operationele overwegingen

  • Updates en patches
  • Updates van containerafbeeldingen
  • Schaalbaarheid van verticale infrastructuur
  • Schaalbaarheid van horizontale infrastructuur
  • Schaalbaarheid van toepassingen
  • Observeerbaarheid
  • Well-Architected Framework voor operationele uitmuntendheid

overwegingen voor betrouwbaarheid

  • Service level agreements (SLA's)
  • Redundantie via beschikbaarheidszones
  • Gezondheidscontroles en zelfherstel
  • Implementaties van toepassingen zonder downtime
  • Resourcelimieten
  • Well-Architected Framework voor betrouwbaarheid

Dit artikel richt zich op een subset van Azure-containerservices die een volwassen functieset bieden voor webtoepassingen en API's, netwerken, waarneembaarheid, ontwikkelhulpprogramma's en bewerkingen. Deze services omvatten AKS, AKS Automatic, Azure Container Apps en Web App for Containers. Zie Container services voor een volledige lijst met Azure-containerservices.

Notitie

Sommige secties onderscheiden AKS Standard van AKS Automatic. Als er geen verschillen worden vermeld in een sectie, kunt u ervan uitgaan dat deze dezelfde functies heeft als de andere implementatiemodellen.

Overwegingen voor architectuur

In deze sectie worden beslissingen over architectuur besproken die moeilijk kunnen worden omgekeerd of gecorrigeerd zonder aanzienlijke downtime of herimplementatie. Het is vooral belangrijk om fundamentele onderdelen, zoals netwerken en beveiliging, zorgvuldig te evalueren voordat u ze voltooit.

Deze overwegingen zijn niet specifiek voor Well-Architected frameworkpijlers. Ze vereisen echter extra controle en evaluatie ten opzichte van bedrijfsvereisten wanneer u een Azure-containerservice kiest.

Notitie

AKS Automatic neemt een eigenzinniger benadering dan AKS Standard, dit betekent dat het bepaalde ingebouwde functies heeft die niet kunnen worden uitgeschakeld. In deze handleiding worden deze functies niet beschreven. Zie de functievergelijking van AKS Automatic en Standard voor meer informatie.

Besturingssysteemondersteuning

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

Eigenschap Container Toepassingen Azure Kubernetes Service (AKS) AKS Automatisch Webapplicatie voor Containers
Linux-ondersteuning ✅ ✅ ✅ ✅
Windows-ondersteuning ❌ ✅ ❌ ✅
Ondersteuning voor gemengde besturingssystemen ❌ ✅ ❌ ❌*

*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 uw voorkeur. Houd rekening met de volgende services:

  • Container Apps is een PaaS-aanbieding (Platform as a Service) die door Azure beheerde netwerkfuncties biedt, zoals servicedetectie, interne beheerde domeinen en besturingselementen voor virtuele netwerken.

  • AKS- is de meest configureerbare van de drie services en biedt de meeste controle over de netwerkstroom. AKS 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 van het Kubernetes-ecosysteem installeren en gebruiken.

  • Web App for Containers is een functie van App Service. Het netwerkmodel, met name voor integratie van privénetwerken, volgt de architectuur van App Service nauw. Deze architectuur is bekend bij workloadteams die App Service gebruiken. Voor teams zonder eerdere App Service-ervaring die de voorkeur geeft aan een conventionelere integratie van virtuele Azure-netwerken, raden we Container Apps aan.

Netwerken is een basisinfrastructuurlaag. 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, raadpleegt u deze sectie zorgvuldig voordat u de selectie van uw Azure-containerservice beperkt.

Netwerkadresruimten

Wanneer u toepassingen integreert in virtuele netwerken, moet u IP-adressen plannen om ervoor te zorgen dat containerinstanties voldoende zijn. Wijs tijdens dit proces extra IP-adressen toe voor updates, blauwgroene implementaties en vergelijkbare scenario's. Deze gebeurtenissen kunnen tijdelijk extra instanties inzetten die meer adressen gebruiken dan normaal.

Functionaliteit of vereiste Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Toegewezen subnetten - Verbruiksabonnement: optioneel

- Specifiek abonnement: vereist		 Vereist Facultatief
Vereisten voor IP-adressen - Consumptieplan. Zie alleen-verbruiksomgeving.

- Toegewijd plan. Zie de omgeving voor workloadprofielen.		 Zie Azure-virtuele netwerken voor AKS. Zie vereisten voor App Service-subnetten.

AKS-vereisten zijn afhankelijk van de door u gekozen netwerkinvoegtoepassing. Voor sommige netwerkinvoegtoepassingen voor AKS zijn bredere IP-adresreserveringen vereist. Deze informatie valt buiten het bereik van dit artikel. Zie Netwerkconcepten voor AKS-voor meer informatie.

Het begrijpen van verkeersstromen

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

In de volgende secties worden verschillende netwerkbeperkingen beschreven. Deze beperkingen zijn van invloed op het feit of u extra subnetten moet implementeren, afhankelijk van uw vereisten voor de volgende configuraties:

  • Meerdere samengevoegde werkbelastingen

  • Privé-toegang, openbare toegang of beide

  • Een toegangsbeheerde stroom van oost-west-verkeer in een cluster voor Container Apps en AKS, of binnen een virtueel netwerk voor alle Azure-containerservices

Planning van subnetten

Een subnet moet groot genoeg zijn om toepassingsexemplaren op te nemen, maar capaciteit is niet de enige factor die de netwerkvoetafdruk voor het implementeren van deze workloads bepaalt.

Vermogen Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Ondersteuning voor geco-lokaliseerde werkbelastingen binnen een subnet* ❌* ✅ Niet beschikbaar*

*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 implementeren voor toegangsbelastingverdeling als u zowel openbaar als particulier inkomend verkeer nodig hebt. Voorbeelden hiervan zijn Azure Application Gateway en Azure Front Door. Als voor meerdere workloads scheiding is vereist, moet u extra Container Apps-omgevingen inrichten en een afzonderlijk subnet toewijzen voor elke omgeving.

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

Voor Web App for Containers gelden geen beperkingen voor het aantal apps dat u met één subnet kunt integreren als het subnet voldoende capaciteit heeft. 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. Plan uw netwerk zorgvuldig om te voorkomen dat volledige workloadonderdelen opnieuw worden geïmplementeerd, wat kan leiden tot downtime.

Beschikbaarheid van Ingress IP-adres

De volgende tabel bevat de vorige sectie over subnetplanning om het aantal IP-adressen te definiëren dat beschikbaar kan worden gesteld. Het is van toepassing op een willekeurig aantal toepassingen dat wordt gehost binnen één implementatie van een Azure-containerservice.

Vermogen Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Het aantal IP-adressen voor inkomend verkeer Een Veel - App Service-omgeving: één

- Geen App Service-omgeving: veel

Container Apps ondersteunt één IP-adres voor elke omgeving, openbaar of privé. AKS ondersteunt een willekeurig aantal openbare of privé-IP-adressen. Web App for Containers, wanneer deze buiten een App Service-omgeving wordt gebruikt, staat één openbaar IP-adres toe voor elk App Service-plan en meerdere afzonderlijke privé-IP-adressen via privé-eindpunten van Azure.

Houd er rekening mee dat web-apps die zijn geïntegreerd in een App Service-omgeving alleen verkeer ontvangen via het ip-adres voor inkomend verkeer dat is gekoppeld aan de App Service-omgeving, ongeacht of deze openbaar of privé is.

UDRs en NAT-gateway-ondersteuning

Als voor een workload UDR's en NAT-gatewaymogelijkheden zijn vereist voor gedetailleerd netwerkbeheer, is voor Container Apps het gebruik van workloadprofielen vereist. UDR- en NAT-gatewaycompatibiliteit is niet beschikbaar in het abonnement voor alleen verbruik voor Container Apps.

AKS en Web App for Containers implementeren deze twee netwerkfuncties via respectievelijk de standaardfunctionaliteit voor virtuele netwerken of integratie van virtuele netwerken. AKS-knooppuntgroepen en Web App for Containers in een App Service-omgeving zijn al directe virtuele netwerkbronnen. Web App for Containers die zich niet in een App Service-omgeving bevinden, bieden ondersteuning voor UDR's en NAT-gateway via integratie van virtuele netwerken. Met integratie van virtuele netwerken bevindt de resource zich technisch gezien niet rechtstreeks in het virtuele netwerk. Alle uitgaande toegang stroomt echter via het virtuele netwerk en de bijbehorende regels van het netwerk zijn van invloed op het verkeer zoals verwacht.

Vermogen Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
UDR-ondersteuning - Abonnement met alleen verbruik: ❌

- Werkbelastingprofiel plan: ✅		 ✅ ✅
Ondersteuning voor NAT-gateway - Abonnement met alleen verbruik: ❌

- Werkbelastingprofiel plan: ✅		 ✅ ✅

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 van de App Service-omgeving met één tenant overwegen, waarbij workloads worden geïmplementeerd in een zelfbeheerd virtueel netwerk. Deze implementatie biedt aangepaste gedetailleerde besturingselementen voor privénetwerken.

Netwerkmogelijkheid Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Privé-inkomend verkeer in een virtueel netwerk ✅ ✅ Via privé-eindpunt
Privé-uitgang vanaf een virtueel netwerk ✅ ✅ Via integratie van virtueel netwerk
Volledig onderdrukt openbaar eindpunt ✅ ✅ Alleen een App Service-omgeving
Privénetwerken met Web App for Containers

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

Als u een PaaS-oplossing wilt en de voorkeur geeft aan netwerkconcepten die worden gedeeld in meerdere Azure-oplossingen, kunt 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 en biedt alleen ondersteuning voor HTTP en HTTPS. Container Apps staat ook binnenkomende TCP-verbindingen (Transmission Control Protocol) toe. AKS is het meest flexibel en ondersteunt niet-getraind gebruik van TCP en User Datagram Protocol (UDP) op zelf geselecteerde poorten.

Netwerk- en protocolondersteuning Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Protocol- en poortondersteuning - HTTP (poort 80)*

- HTTPS (poort 443)*

- TCP (poorten 1 tot en met 65535, behalve 80 en 443)		 - TCP (elke poort)

- UDP (elke poort)		 - HTTP (poort 80)

- HTTPS (poort 443)
Ondersteuning voor WebSocket ✅ ✅ ✅
HTTP/2-ondersteuning ✅ ✅ ✅

*In de Container Apps-omgeving kan HTTP of HTTPS worden weergegeven op elke poort voor communicatie tussen clusters. In dat scenario zijn ingebouwde HTTP-functies van Container Apps, zoals cross-origin resource delen en sessieaffiniteit, niet van toepassing.

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

Taakverdeling

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. In dit model beheert Azure de onderliggende Azure-infrastructuur die het workloadteam configureert door te communiceren met de Kubernetes-API. Voor taakverdeling op laag 7 in AKS kunt u een door Azure beheerde optie kiezen, zoals de door AKS beheerde invoegtoepassing voor routering van toepassingen, Application Gateway for Containers of een ingangscontroller van uw keuze implementeren en zelf beheren.

Verdelingsmechanisme Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor 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

Geavanceerde Container Networking Services voor AKS

Advanced Container Networking Services (ACNS) biedt AKS geavanceerde netwerkmogelijkheden die verder gaan dan wat beschikbaar is in Container Apps of Web App for Containers. Deze mogelijkheden bieden krachtige waarneembaarheid en verbeterde beveiliging die is ontworpen voor dynamische, containeromgevingen.

  • Waarneembaarheid van containernetwerk:

    ACNS maakt gebruik van het besturingsvlak van Hubble om intuïtieve, diepgaande inzichten te bieden in het netwerkgedrag. Met eenvoudig te gebruiken metrische gegevens op knooppunt- en podniveau en uitgebreide stroomlogboeken kunt u snel problemen vaststellen en prestaties optimaliseren. Deze ingebouwde waarneembaarheid vermindert de noodzaak van externe bewakingsinstellingen en verlaagt de leercurve die doorgaans is gekoppeld aan diagnostische gegevens van kubernetes-netwerken.

  • Containernetwerkbeveiliging:

    Voor clusters die gebruikmaken van de Azure Container Networking Interface mogelijk gemaakt door Cilium, biedt ACNS FQDN-filtering (Fully Qualified Domain Name). In plaats van statisch beveiligingsbeleid op basis van IP-adressen te beheren, kunt u beleidsregels definiëren op basis van domeinnamen. Deze dynamische benadering vereenvoudigt beleidsbeheer en is ook afgestemd op moderne, zero trust-beveiligingsmodellen. Met deze aanpak kunt u eenvoudiger robuuste beveiliging afdwingen zonder constante handmatige updates.

Zie de volgende bronnen voor meer informatie:

Serviceontdekking

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 voor betrouwbare en consistente communicatie.

Mechanisme voor servicedetectie Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Serviceontdekking Door Azure beheerde FQDN Kubernetes configureerbaar Door Azure beheerde FQDN

Web App 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 beschikbaar wordt gesteld en door het verkeer alleen binnen de omgeving te beperken. Deze functionaliteit maakt het eenvoudiger om oost-west-communicatie te beheren en onderdelen zoals Dapr in te schakelen.

Kubernetes-implementaties zijn niet inherent detecteerbaar vanuit of buiten het cluster. Als u toepassingen op een adresseerbare manier beschikbaar wilt maken voor het netwerk, moet u Kubernetes-services definiëren en maken zoals opgegeven door de Kubernetes-API.

Belangrijk

Alleen Container Apps en AKS bieden servicedetectie via interne DNS-schema's (Domain Name System) 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. Ze kunnen hetzelfde zijn in ontwikkel-/test- en productieomgevingen. 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 ingebouwde oplossingen voor aangepaste domeinen en certificaatbeheer.

Ondersteuning voor aangepast domein en TLS Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Aangepaste domeinen configureren Standaardfunctie Bring Your Own (BYO) Standaardfunctie
Beheerde TLS voor Azure FQDN's Standaardfunctie Niet beschikbaar Standaardfunctie
Beheerde TLS voor aangepaste domeinen Standaardfunctie BYO Standaardfunctie of BYO

AKS-gebruikers zijn verantwoordelijk voor het beheren van DNS-, clusterconfiguraties en TLS-certificaten voor hun aangepaste domeinen. AKS biedt geen beheerde TLS, maar klanten kunnen software van het Kubernetes-ecosysteem, zoals certificaatbeheer, gebruiken om TLS-certificaten te beheren.

mTLS

Een ander alternatief voor het beperken van binnenkomend verkeer is mTLS. Dit beveiligingsprotocol zorgt ervoor 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 dat 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 ook eenvoudig automatische mTLS inschakelen voor interne communicatie tussen apps in één omgeving.

U kunt mTLS in AKS implementeren via de service-mesh op basis van Istio als een beheerde invoegtoepassing. Deze invoegtoepassing bevat mTLS-mogelijkheden voor binnenkomende clientverbindingen en communicatie tussen services binnen het cluster. 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 om rekening te houden met het netwerkontwerp. Zie de volgende artikelen voor 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. Voor de hostingsystemen en onderliggende netwerkoverlays zijn echter extra kaders vereist. 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 met behulp van configuratieopties. U kunt bijvoorbeeld configuratieopties gebruiken om lokale accounts uit te schakelen naar de Kubernetes-API-server of automatische updates in te schakelen voor onderliggende knooppunten.

Automatische AKS-clusters worden geleverd met een beperkte standaardconfiguratie en hebben standaard veel cluster-, toepassings- en netwerkbeveiligingsinstellingen ingeschakeld. Deze initiële configuraties verminderen niet alleen de implementatietijd, maar bieden gebruikers ook een gestandaardiseerde configuratie die vooraf is gevalideerd. Deze configuratie biedt gebruikers een solide basis voor fase-2 operationele verantwoordelijkheden. Deze basis helpt bij het verkorten van de leercurve van langetermijnclusterbeheer voor teams die nieuw zijn voor de technologie.

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. Het 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 die u moet beveiligen.

Belangrijk

Deze sectie is niet relevant voor Web App for Containers, die de Resource Manager-API als besturingsvlak gebruikt.

Beveiliging op basis van identiteit

U bent verantwoordelijk voor het beveiligen van op identiteiten gebaseerde toegang tot de API. Kubernetes biedt een eigen verificatie- en autorisatiebeheersysteem. Dit systeem moet worden beveiligd met toegangsbeheer.

Als u wilt profiteren van één glaslaag 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 op rollen gebaseerd toegangsbeheer (Azure RBAC) voor Kubernetes. Als u deze best practice implementeert, hoeven beheerders geen identiteits- en toegangsbeheer uit te voeren op meerdere platforms.

Kubernetes-API-toegang Container Toepassingen Azure Kubernetes Service (AKS)
Toegangsbeheer voor Kubernetes-API Geen toegang Volledige toegang

U hebt geen toegang tot de Kubernetes-API als u Container Apps gebruikt. 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 integratie van het virtuele netwerk van de API-server waarbij de API-server is geïntegreerd in een gedelegeerd subnet.

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

Toegangsbeheer voor Kubernetes-API Container Toepassingen Azure Kubernetes Service (AKS)
Kubernetes API-netwerkbeveiliging Kan niet worden geconfigureerd in PaaS Configureerbaar met behulp van een openbaar of privé-IP-adres

ACNS verbetert de beveiliging van gegevensvlakken in AKS. Voor clusters die gebruikmaken van de Azure Container Networking Interface mogelijk gemaakt door Cilium, introduceert ACNS containernetwerkbeveiliging via FQDN-filtering. In plaats van statisch beveiligingsbeleid op basis van IP-adressen te beheren, kunt u dynamisch beleid definiëren op basis van FQDN's. Deze aanpak vereenvoudigt beleidsbeheer, vermindert administratieve overhead en ondersteunt een nulvertrouwensmodel door ervoor te zorgen dat alleen verkeer naar vertrouwde domeinen is toegestaan.

Notitie

ACNS-beveiligingsfuncties vereisen Kubernetes versie 1.29 of hoger en zijn alleen beschikbaar op clusters die gebruikmaken van het gegevensvlak Cilium.

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

Beveiliging van het gegevensvlakketwerk

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

Netwerkbeleid voor de beveiliging van verkeer binnen het cluster

Voor sommige beveiligingspostuuren is scheiding van netwerkverkeer in een omgeving vereist. Deze scheiding is bijvoorbeeld vaak nodig wanneer u multitenant-omgevingen gebruikt om toepassingen met meerdere of meerdere lagen te hosten. In deze scenario's selecteert u AKS en implementeert u netwerkbeleid, wat cloudeigen functies zijn die een gedetailleerde configuratie van Laag 4-netwerken in Kubernetes-clusters mogelijk maken.

Ondersteuning voor netwerkbeleid Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Netwerkbeleid Consumptieplan: ❌

Toegewezen abonnement: ❌		 ✅ ❌

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

NSGs

In alle scenario's kunt u netwerkcommunicatie binnen het bredere virtuele netwerk reguleren met behulp van NSG's. Met deze aanpak kunt u laag 4-verkeersregels gebruiken die zowel inkomend als uitgaand verkeer op het niveau van het virtuele netwerk reguleren.

NSG-ondersteuning Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
NSGs - Verbruiksplan: ✅

- Toegewezen abonnement: ✅		 ✅ ✅ Virtuele netwerk-geïntegreerde apps, alleen uitgaand verkeer

Ingebouwde IP-adresbeperkingen voor inkomend verkeer

Container Apps en Web App for Containers bieden ingebouwde IP-adresbeperkingen voor inkomend verkeer voor afzonderlijke toepassingen. AKS kan dezelfde functionaliteit bereiken, maar vereist kubernetes-systeemeigen functionaliteit via de Api-resource van de Kubernetes-service , waar u waarden voor loadBalancerSourceRanges kunt instellen.

Netwerktoegangsbeheer en impact op resources Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Ingebouwde IP-adresbeperkingen voor inkomend verkeer ✅ ❌ ✅
Resourceverbruik - Verbruikt clusterbronnen -

Notitie

AKS ondersteunt beperkingen voor inkomend IP-adres, maar u gebruikt Kubernetes-systeemeigen functies om deze mogelijkheid te implementeren in plaats van systeemeigen besturingselementen van Azure, in tegenstelling tot andere Azure-services.

Beveiliging op toepassingsniveau

U moet workloads niet alleen beveiligen op netwerk- en infrastructuurniveau, 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, om een verbeterde beveiliging voor deze onderdelen te bieden. 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.

Geheimenintegratie Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Key Vault-integratie ✅ ✅ ✅

Zie de volgende bronnen voor meer informatie:

Ondersteuning voor beheerde identiteit

Toepassingen kunnen beheerde identiteiten gebruiken om te verifiëren bij met Microsoft Entra ID beveiligde services zonder sleutels of geheimen te hoeven gebruiken. Container Apps en Web App for Container bieden ingebouwde, systeemeigen ondersteuning voor beheerde identiteit op toepassingsniveau. Ondersteuning voor beheerde identiteiten op toepassingsniveau voor AKS wordt bereikt via de Workload-id van Microsoft Entra. AKS vereist ook een infrastructuurgerelateerde beheerde identiteit om clusterbewerkingen toe te staan voor de Kubelet, het besturingsvlak en verschillende AKS-invoegtoepassingen.

Rapport beheerde identiteit Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Ondersteuning voor door infrastructuur beheerde identiteiten Niet beschikbaar ✅ Niet beschikbaar
Ondersteuning voor beheerde identiteiten bij het ophalen van containers ✅ ✅ ✅
Ondersteuning voor door toepassingen beheerde identiteiten ✅ ✅ ✅

Zie de volgende bronnen voor meer informatie:

Evaluaties van bedreigingsbeveiliging en beveiligingsproblemen met Defender for Containers

Bescherming tegen bedreigingen en kwetsbaarheden is ook belangrijk. Het is een best practice om Defender for Containerste gebruiken. Evaluaties van beveiligingsproblemen worden ondersteund in Azure-containerregisters. Als gevolg hiervan kan elke Azure-containerservice deze gebruiken, niet alleen de containers die in dit artikel worden beschreven. Defender for Containers Runtime-beveiliging 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 vanuit het Kubernetes-ecosysteem.

Beveiligingsfuncties Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Runtime-bedreigingsbeveiliging ❌ ✅ ❌

Zie De ondersteuningsmatrix voor containers in Microsoft Defender voor Cloud voor meer informatie.

Evaluaties van kwetsbaarheden in container-images zijn geen realtime scans. Het Azure-containerregister wordt regelmatig gescand.

Beveiligingsbasislijnen

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

Notitie

AKS-automatische clusters worden geconfigureerd met specifieke beveiligingsinstellingen. Zorg ervoor dat deze instellingen zijn afgestemd op uw workloadbehoeften.

Well-Architected Framework voor beveiliging

Dit artikel is gericht op belangrijke verschillen tussen functies van de containerservice.

Zie de best practices voor AKS voor meer volledige beveiligingsrichtlijnen over AKS.

Operationele overwegingen

Als u een workload in productie wilt uitvoeren, moet u procedures voor operationele uitmuntendheid implementeren, waaronder gecentraliseerde logboekregistratie, bewaking, schaalbaarheid, regelmatige updates en patching en beeldbeheer.

Updates en patches

Het is belangrijk dat het onderliggende besturingssysteem van een toepassing wordt bijgewerkt en regelmatig wordt gepatcht. Elke update vormt echter een foutrisico. In deze sectie en in 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 afbeeldingen voor het knooppuntbesturingssysteem en de componenten van de beheerlaag. Maar workloadteams zijn verantwoordelijk voor het toepassen van updates op hun clusters. U kunt handmatig updates activeren of de functie voor het automatisch upgraden van clusters gebruiken om ervoor te zorgen dat uw clusters up-to-date zijn. Zie AKS-clusters patchen en upgraden voor meer informatie over de bewerkingshandleiding voor dag 2 van AKS.

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

Verantwoordelijkheid bijwerken Container Toepassingen Azure Kubernetes Service (AKS) AKS Automatisch Webapplicatie voor Containers
Updates van controlevlak Perron Klant Perron Perron
Updates en patches voor de host. Perron Klant Perron Perron
Updates en patches voor containerafbeeldingen Klant Klant Klant Klant

Updates van containerafbeeldingen

Ongeacht de Azure-containeroplossing bent u verantwoordelijk voor uw eigen containerbeelden. Als er beveiligingspatches voor basisafbeeldingen van containers zijn, bent u verantwoordelijk voor het opnieuw bouwen van uw afbeeldingen. Als u waarschuwingen wilt ontvangen over deze beveiligingsproblemen, gebruikt u Defender for Containers voor Azure Container Registry-containers.

Schaalbaarheid

Schaalvergroting wordt gebruikt om de resourcecapaciteit aan te passen aan de vraag. Er wordt meer capaciteit toegevoegd 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, zoals reken-CPU en geheugen. 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 specifieke Azure-service. Deze aanbiedingen variëren en kunnen extra beperkingen opleggen.

Raadpleeg voor AKS de grootten voor virtuele machines (VM's) in azure-documentatie en de AKS-beperkingen voor elke regio.

De volgende artikelen bevatten informatie over SKU-aanbiedingen voor Container Apps en App Service:

Schaalbaarheid van horizontale infrastructuur

Horizontaal schalen verwijst naar de mogelijkheid om de capaciteit te vergroten of te verlagen door infrastructuuronderdelen, zoals VM-knooppunten, toe te voegen of te verwijderen. Tijdens het vergroten of verkleinen van de schaal abstraheert de Consumptielaag van Container Apps de onderliggende VM's. Voor de resterende Azure-containerservices beheert u de strategie voor horizontaal schalen met behulp van de standaard Resource Manager-API.

Uitschalen en inschalen omvat het herverdelen van instanties, wat het risico op downtime verhoogt. Het risico is kleiner dan het bijbehorende risico met verticale schaalaanpassing. Ongeacht de omstandigheden bent u verantwoordelijk voor ervoor te zorgen dat uw toepassingen met fouten kunnen omgaan. U bent ook verantwoordelijk voor het implementeren van sierlijke start-ups en het afsluiten van uw toepassingen om downtime te voorkomen.

Flexibiliteit van infrastructuur Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
In- en uitschalen van infrastructuur - Verbruiksabonnement: Niet beschikbaar

- Toegewezen plan: Configureerbaar		 Configureerbaar Configureerbaar
Flexibele hardwaretoewijzing - Verbruiksabonnement: Niet beschikbaar

- Toegewijd plan: Geïntegreerd met workloadprofielen		 Elke VM-SKU Samengevat, zie 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

Het schalen van infrastructuur en toepassingen wordt doorgaans geactiveerd door resourceverbruik, zoals CPU en geheugen. Sommige containeroplossingen kunnen ook het aantal containerinstanties schalen op basis van toepassingsspecifieke metrische gegevens, zoals HTTP-aanvragen. AKS en Container Apps kunnen bijvoorbeeld containerinstanties schalen op basis van berichtenwachtrijen via Kubernetes gebeurtenisgestuurde automatische schaalaanpassing (KEDA) en vele 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 die Azure biedt. Web App for Containers biedt geen ondersteuning voor aangepaste schaalaanpassingsconfiguraties, zoals KEDA.

Schaalbaarheidsmodel Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Container uitschalen HTTP, TCP of op metrieken gebaseerde (CPU-gebaseerd, geheugen-gebaseerd of gebeurtenisgestuurd) Op basis van metrische gegevens (CPU, geheugen of aangepast) Handmatig, op basis van metrische gegevens of automatisch
Gebeurtenisgestuurde schaalbaarheid Ja. cloud-native Ja. cloud-native Extra configuratie vereist. Ja. Azure-resource-specifiek.

AKS Automatic schakelt standaard de horizontale podautoscaler, KEDA, en de verticale podautoscaler in.

Observeerbaarheid

Werkbelastinginstrumentatie

Het verzamelen van meetwaarden voor complexe of meerlagige applicaties kan lastig zijn. Als u metrische gegevens wilt ophalen, kunt u workloads in containers integreren met Azure Monitor op de volgende manieren:

  • Automatische instrumentatie: Er zijn geen codewijzigingen vereist

  • Handmatige instrumentatie: Minimale codewijzigingen die nodig zijn voor het integreren en configureren van de SDK en client

    Instrumentatiemethode Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
    Automatische instrumentatie via het platform ❌ ❌ Gedeeltelijke ondersteuning*
    Automatische instrumentatie via softwareagent ❌ Gedeeltelijke ondersteuning* Niet beschikbaar
    Handmatige instrumentatie Via SDK ofwel OpenTelemetry Via SDK ofwel OpenTelemetry Via SDK ofwel OpenTelemetry

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

Instrumentatie binnen toepassingscode is de verantwoordelijkheid van toepassingsontwikkelaars, dus het is onafhankelijk van elke Azure-containeroplossing. OpenTelemetry gebruiken met Application Insights.

Logboeken en metrische gegevens

Alle Azure-containerservices bieden functionaliteit voor toepassings- en platformlogboeken en metrische gegevens. Toepassingslogboeken zijn consolelogboeken die door uw workload worden gegenereerd. In platformlogboeken worden gebeurtenissen vastgelegd die plaatsvinden op platformniveau, buiten het bereik van uw toepassing, zoals schalen en implementaties. Metrische gegevens zijn numerieke waarden die een bepaald aspect van een systeem op een bepaald moment beschrijven. Metrische gegevens helpen u bij het bewaken en waarschuwen van systeemprestaties en -status.

Azure Monitor is de belangrijkste service voor logboekregistratie en metrische gegevens in Azure die kan worden geïntegreerd met deze services. Azure Monitor gebruikt resourcelogboeken om logboeken van verschillende bronnen te scheiden in categorieën en metrische gegevens te verzamelen om inzicht te krijgen in resourceprestaties. Een manier om te bepalen welke logboeken en metrische gegevens beschikbaar zijn vanuit elke Azure-service, is door de resourcelogboekcategorieën en beschikbare metrische gegevens voor elk van de services te controleren.

Waarneembaarheidsfuncties Container Toepassingen Azure Kubernetes Service (AKS) AKS Automatisch Webapplicatie voor Containers
Ondersteuning voor logboekstreaming ✅ ✅ ✅ ✅
Ondersteuning voor Azure Monitor ✅ ✅ ✅ ✅
Logboeken van Azure Monitor-resources - Console

- Systeem		 Kubernetes API-server, controle, scheduler en automatische schaalaanpassing van clusters Hetzelfde als AKS ConsoleLogs, HTTPLogs en EnvironmentPlatformLogs
Metrische verzameling en bewaking Metrische gegevens via Azure Monitor. Aangepaste metrische gegevens via Dapr metrics. Metrische gegevens via Azure Monitor. Aangepaste metrische gegevens via Prometheus (hiervoor is handmatige installatie vereist). Vooraf geconfigureerde beheerde Prometheus voor verzameling metrische gegevens en Managed Grafana voor visualisatie. Metrische gegevens via Azure Monitor. Metrische gegevens via Azure Monitor
Vooraf geconfigureerde Prometheus en Grafana ❌ Hiervoor is handmatige installatie vereist. Beheerde Prometheus en Managed Grafana zijn standaard vooraf geconfigureerd. ❌

Overweeg metrische gegevens en logboeken voor de volgende services:

  • Container Apps abstraheert alle interne Kubernetes-logboeken in twee categorieën: consolelogboeken, die workloadcontainerlogboeken en systeemlogboeken bevatten, die alle platformgerelateerde logboeken bevatten. Voor metrische gegevens kan Container Apps worden geïntegreerd met Azure Monitor om metrische standaardgegevens te verzamelen en ondersteuning te bieden voor aangepaste metrische gegevens via Dapr-integratie voor geavanceerde scenario's.

  • AKS- biedt Kubernetes-gerelateerde logboeken en gedetailleerde controle over wat wordt geregistreerd. AKS behoudt volledige compatibiliteit met Kubernetes-clienthulpprogramma's voor logboekstreaming, zoals kubectl. Voor metrische gegevens kan AKS worden geïntegreerd met Azure Monitor om metrische gegevens van clusters en knooppunten te verzamelen. U kunt aangepaste metrische gegevens verzamelen met Prometheus en deze visualiseren met Grafana, maar voor deze actie is handmatige installatie en configuratie vereist.

  • AKS Automatic wordt vooraf geconfigureerd met specifieke bewakingshulpprogramma's. Het maakt gebruik van Managed Prometheus voor het verzamelen van metrische gegevens en Managed Grafana voor visualisatie. Metrische gegevens van clusters en toepassingen worden automatisch verzameld en kunnen worden gevisualiseerd. AKS Automatic kan ook worden geïntegreerd met Azure Monitor om logboeken en metrische gegevens te verzamelen.

  • Web App voor Containers biedt verschillende categorieën van logboeken voor resources, omdat het platform (App Service) niet exclusief bedoeld 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. Metrische gegevens worden verzameld via Azure Monitor, waarmee u de prestaties en het resourcegebruik van toepassingen kunt bewaken.

Well-Architected Framework voor operationele uitmuntendheid

Dit artikel is gericht op de belangrijkste verschillen tussen de functies van containerservices. Bekijk de volledige richtlijnen voor operationele uitmuntendheid voor de volgende services:

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, nieuwe pogingen, 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 SLA's en beschikbaarheidszones werken.

SLA's

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

Azure biedt veel SLA's voor specifieke services. Er is geen sprake van totale beschikbaarheid van services, omdat er fouten kunnen optreden in software, hardware of zelfs natuurlijke gebeurtenissen, zoals stormen en aardbevingen. Een SLA is geen garantie, maar een financiële ondersteuning voor een gedefinieerd beschikbaarheidsniveau.

Download voor SLA's en details de meest recente SLA voor onlineservices van Microsoft. Zie Een serviceovereenkomst lezen voor meer informatie over het interpreteren van SLA's en deze gebruiken als technische invoer.

Gratis lagen versus betaalde lagen

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

Extra factoren voor AKS

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

  • Besturingsvlak: De Kubernetes-API-server heeft een afzonderlijke SLA.

  • Gegevensvlak: Knooppuntgroepen gebruiken de onderliggende SLA's voor VM-SKU's.

  • Beschikbaarheidszones: Er zijn verschillende SLA's voor de twee vliegtuigen, afhankelijk van of het AKS-cluster beschikbaarheidszones heeft ingeschakeld en of meerdere exemplaren worden uitgevoerd in beschikbaarheidszones.

Wanneer u meerdere Azure-services gebruikt, kunnen samengestelde serviceniveaudoelstellingen verschillen van en lager zijn dan afzonderlijke SLA's.

Redundantie met beschikbaarheidszones

Beschikbaarheidszones zijn afzonderlijke datacenters met onafhankelijke elektrische voeding en koeling 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 of elke regio waar een datacenterregio aanwezig is. 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.

Eigenschap Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Ondersteuning voor beschikbaarheidszones Vol Vol Vol

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 optimaal gebruik wilt maken van ondersteuning voor beschikbaarheidszones, implementeert u workloads met ten minste drie containerinstanties die zijn verdeeld 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 controleert hoe het hostingplatform reageert wanneer er fouten optreden.

Als u meer inzicht wilt krijgen in typen Kubernetes-statustests, kunt u de volgende ingebouwde opties overwegen:

  • Opstarten: Controleert of de toepassing is gestart

  • Gereedheid: Controleert of de toepassing gereed is voor het afhandelen van binnenkomende aanvragen

  • Liveness: Controleert of de toepassing wordt uitgevoerd en reageert

Een andere belangrijke overweging is hoe vaak deze statuscontroles worden aangevraagd bij de toepassing of de interne granulariteit ervan. Als u een lang interval tussen deze verzoeken hebt, kunt u verkeer blijven bedienen totdat de instantie als ongezond wordt beschouwd.

De meeste toepassingen ondersteunen statuscontroles via het HTTP- of HTTPS-protocol. Sommige toepassingen hebben echter mogelijk andere protocollen nodig, zoals TCP of gRPC, om deze controles uit te voeren. Houd rekening met deze overweging wanneer u uw statuscontrolesysteem ontwerpt.

Mogelijkheden voor statuscontrole Container Apps- Azure Kubernetes Service (AKS) Webapp voor containers
Opstartprobes ✅ ✅ Gedeeltelijke ondersteuning
Gereedheidstests ✅ ✅ ❌
Liveness-tests ✅ ✅ ✅
Intervalgranulariteit Seconden Seconden 1 minuut
Protocolondersteuning - HTTP en HTTPS

-TCP		 - HTTP en HTTPS

-TCP

- gRPC		 HTTP en HTTPS

Gezondheidscontroles zijn het eenvoudigst te implementeren in Web App for Containers. Houd rekening met de volgende factoren:

  • De opstartprobes zijn ingebouwd en kunnen niet worden gewijzigd. Er wordt een HTTP-aanvraag verzonden naar de beginpoort van uw container. Elk antwoord van uw applicatie wordt beschouwd als een geslaagde start.

  • Het biedt geen ondersteuning voor gereedheidstests. Als de opstartprobe is geslaagd, wordt de containerinstantie toegevoegd aan de groep met gezonde instanties.

  • De statuscontrole wordt met intervallen van één minuut verzonden. U kunt het interval niet wijzigen.

  • De minimale drempelwaarde die u kunt instellen voor een ongezonde instantie die moet worden verwijderd uit het interne loadbalanceringsmechanisme, is twee minuten. Het ongezonde exemplaar ontvangt gedurende ten minste twee minuten verkeer nadat het een statuscontrole heeft gefaald. De standaardwaarde voor deze instelling is 10 minuten.

Container Apps en AKS zijn ook 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:

Automatische genezing

Het identificeren van een slecht containerexemplaar en daarna het stoppen van verkeer naar de container is alleen het begin. De volgende stap is het implementeren van automatische genezing. Automatische herstelbewerking is het proces van het opnieuw opstarten van de toepassing om te proberen te herstellen van een beschadigde status. Overweeg hoe de volgende containerservices zich verhouden:

  • In Web App for Containers is er geen optie om een containerinstantie onmiddellijk opnieuw op te starten nadat een statuscontrole is mislukt. Als de instantie één uur blijft falen, wordt deze vervangen door een nieuwe instantie. Automatisch herstel bewaakt en herstart instanties. Het is niet rechtstreeks gerelateerd aan statuscontroles. Automatische herstel maakt gebruik van verschillende metrische gegevens van toepassingen, 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, ondersteunen implementaties zonder downtime, maar op verschillende manieren.

Implementatiestrategie Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Strategie voor ononderbroken beschikbaarheid Rollende update Rolling update plus alle andere Kubernetes-strategieën implementatiesites

De toepassingsarchitecturen moeten ook ondersteuning bieden voor implementatie zonder downtime.

Resourcelimieten

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 gebruikmaakt van alle resources en andere toepassingen in een slechte status laat.

Afbakening van bronnen Container Toepassingen Azure Kubernetes Service (AKS) Webapplicatie voor Containers
Hulpbronnenlimieten (CPU of geheugen) Voor elke app en container Voor elke app, container en naamruimte Voor elk 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 gibibyte (GiB) ram-geheugen waarin u meerdere web-apps in containers kunt uitvoeren. U kunt een van de apps echter niet beperken tot een specifieke 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 voor elke 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.

Well-Architected Framework voor betrouwbaarheid

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

Conclusie

Goed ontworpen oplossingen maken de basis voor succesvolle workloads. Architectuurbeslissingen kunnen zich ontwikkelen naarmate workloads groeien en teams vooruitgang boeken in hun cloudtrajecten. Sommige keuzes, met name die met betrekking tot netwerken, zijn moeilijk om te keren zonder aanzienlijke downtime of herimplementatie.

Wanneer u Azure Container Services vergelijkt, ontstaat er een duidelijk thema. AKS maakt de meest onderliggende infrastructuur beschikbaar, die maximale controle en configureerbaarheid biedt. AKS Automatic vindt de balans tussen controle en eenvoud door veel operationele taken te automatiseren.

De hoeveelheid operationele overhead en complexiteit varieert sterk voor AKS-workloads. Sommige teams verminderen de overhead aanzienlijk met behulp van door Microsoft beheerde invoegtoepassingen, extensies en functies voor automatische upgrades. Andere teams geven de voorkeur aan volledig clusterbeheer om te profiteren van de volledige uitbreidbaarheid van Kubernetes en het CNCF-ecosysteem. Zo biedt Microsoft Flux bijvoorbeeld als een beheerde GitOps-extensie, kiezen veel teams ervoor om ArgoCD zelf in te stellen en te gebruiken.

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

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

Generalisaties kunnen helpen bij het beperken van de lijst met Azure-containerservices voor overweging. U moet uw keuze echter ook controleren door afzonderlijke vereisten in detail te bekijken en deze te koppelen aan servicespecifieke functies.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteurs:

Andere inzenders:

Meld u aan bij LinkedIn als u niet-openbare LinkedIn-profielen wilt zien.

Volgende stappen

  • Last updated on