Geavanceerde AKS-microservicesarchitectuur (Azure Kubernetes Service)

Azure Application Gateway

Azure Container Registry

Azure Kubernetes Service (AKS)

Azure Virtual Network

In deze referentiearchitectuur worden verschillende configuraties beschreven die u moet overwegen wanneer u microservices uitvoert in Azure Kubernetes Service (AKS). In dit artikel worden de configuratie van netwerkbeleid, automatische schaalaanpassing van pods en gedistribueerde tracering in een microservicetoepassing besproken.

Deze architectuur bouwt voort op de AKS-basislijnarchitectuur, die Microsoft aanbeveelt als uitgangspunt voor de AKS-infrastructuur. De AKS-basislijn beschrijft infrastructuurfuncties zoals De workload-id van Microsoft Entra, beperkingen voor inkomend en uitgaand verkeer, resourcelimieten en andere beveiligde AKS-infrastructuurconfiguraties. Deze functies worden niet behandeld in dit artikel. U wordt aangeraden vertrouwd te raken met de AKS-basislijnarchitectuur voordat u verdergaat met de inhoud van de microservices.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Als u liever begint met een meer eenvoudig voorbeeld van microservices in AKS, raadpleegt u de Microservices-architectuur op AKS.

Werkproces

Met deze aanvraagstroom worden de ontwerppatronen uitgever-abonnee, concurrerende consumenten en gatewayroutering in de cloud geïmplementeerd. De volgende werkstroom komt overeen met het vorige diagram:

Er wordt een HTTPS-aanvraag ingediend om een drone af te halen. De aanvraag wordt via Azure Application Gateway doorgegeven aan de opnamewebtoepassing, die wordt uitgevoerd als een microservice in het cluster in AKS.
De opnamewebtoepassing produceert een bericht en verzendt het naar de Azure Service Bus-berichtenwachtrij.
Het back-endsysteem wijst een drone toe en brengt de gebruiker op de hoogte. De microservice van de werkstroom voert de volgende taken uit:
- Verbruikt berichtgegevens uit de Service Bus-berichtenwachtrij
- Verzendt een HTTPS-aanvraag naar de leveringsmicroservice, die gegevens doorgeeft aan externe gegevensopslag van Azure Cache voor Redis
- Verzendt een HTTPS-aanvraag naar de microservice van de droneplanner
- Verzendt een HTTPS-aanvraag naar de pakketmicroservice, die gegevens doorgeeft aan externe MongoDB-gegevensopslag
De architectuur maakt gebruik van een HTTPS GET-aanvraag om de leveringsstatus te retourneren. Deze aanvraag wordt via Application Gateway doorgegeven aan de leveringsmicroservice.
De leveringsmicroservice leest gegevens uit Azure Cache voor Redis.

Onderdelen

AKS biedt een beheerd Kubernetes-cluster. Wanneer u AKS gebruikt, beheert Azure de Kubernetes-API-server. De clusteroperator kan de Kubernetes-knooppunten of -knooppuntgroepen openen en beheren. In deze architectuur worden de volgende AKS-infrastructuurfuncties gebruikt:
- Met AKS beheerde Microsoft Entra-id voor op rollen gebaseerd toegangsbeheer (RBAC) wordt Microsoft Entra ID geïntegreerd met AKS om identiteitstoegangsbeheer af te dwingen. In deze architectuur zorgt het voor veilige, gecentraliseerde verificatie en autorisatie voor clustergebruikers en -workloads.
- Azure Container Networking Interface is een invoegtoepassing waarmee containers rechtstreeks verbinding kunnen maken met een virtueel Azure-netwerk, waarmee pods IP-adressen van virtuele Azure-netwerken kunnen ontvangen. In deze architectuur maakt het integratie met Azure-netwerkservices mogelijk en biedt het controle over de verkeersstroom.
- Azure Monitor-containerinzichten is een functie die inzicht biedt in de prestaties en status van AKS-clusters. In deze architectuur worden metrische gegevens, logboeken en telemetrie verzameld ter ondersteuning van bewaking en diagnose.
- Azure Policy-invoegtoepassing voor AKS is een ingebouwde extensie waarmee beheer- en nalevingsbeheer rechtstreeks in uw AKS-clusters worden geplaatst. Er worden governanceregels toegepast voor AKS-resources met behulp van Azure Policy. In deze architectuur wordt naleving afgedwongen door configuraties te valideren en niet-geautoriseerde implementaties te beperken.
- Beheerde NGINX-ingangen met de invoegtoepassing voor toepassingsroutering is een functie in AKS die de wijze waarop u uw toepassingen beschikbaar maakt voor internet vereenvoudigt met behulp van HTTP/HTTPS-verkeer. Het biedt een vooraf geconfigureerde NGINX-ingangscontroller voor AKS. In deze architectuur wordt verkeerroutering naar services verwerkt en wordt openbare blootstelling van workloads mogelijk.
- Scheiding van systeem- en gebruikersknooppuntgroepen is een architectuurpraktijk waarmee clusterknooppunten worden verdeeld in twee verschillende typen knooppuntgroepen en AKS-infrastructuuronderdelen worden geïsoleerd van toepassingsworkloads. In deze architectuur worden beveiliging en resource-efficiëntie verbeterd door knooppuntgroepen toe te wijzen aan specifieke operationele rollen.
- Workload-id is een veilige en schaalbare manier voor Kubernetes-workloads voor toegang tot Azure-resources met behulp van Microsoft Entra-id zonder dat geheimen of referenties in het cluster hoeven te worden opgeslagen. Met workload-id kunnen AKS-workloads veilig toegang krijgen tot Azure-resources met behulp van federatieve identiteit. In deze architectuur elimineert het de noodzaak van geheimen en verbetert het beveiligingspostuur via op identiteit gebaseerde toegang.
Application Gateway is een door Azure beheerde service die laag 7-taakverdelings- en WAF-mogelijkheden (Web Application Firewall) biedt. In deze architectuur wordt de opnamemicroservice als een openbaar eindpunt weergegeven en wordt binnenkomend webverkeer naar de toepassing in balans.
Azure Firewall is een door Azure beheerde service die intelligente, cloudeigen netwerkbeveiliging en bedreigingsbeveiliging biedt. In deze architectuur wordt uitgaande communicatie van microservices naar externe resources beheerd, waardoor alleen goedgekeurde FQDN's (Fully Qualified Domain Names) als uitgaand verkeer worden toegestaan.
Azure Private Link is een door Azure beheerde service waarmee privéconnectiviteit met PaaS-aanbiedingen (Platform-as-a-Service) van Azure via het Microsoft backbone-netwerk mogelijk is. In deze architectuur worden privé-IP-adressen toegewezen voor toegang tot Azure Container Registry en Azure Key Vault vanuit AKS-knooppuntgroepen via privé-eindpunten.
Azure Virtual Network is een door Azure beheerde service die geïsoleerde en zeer veilige omgevingen biedt voor het uitvoeren van toepassingen en virtuele machines. In deze architectuur wordt een peered hub-spoke-topologie gebruikt. Het hubnetwerk fungeert als host voor Azure Firewall en Azure Bastion, terwijl het spoke-netwerk subnetten voor AKS-systeem- en gebruikersknooppuntgroepen bevat, samen met het Application Gateway-subnet.

Externe opslag en andere onderdelen

Azure Cache voor Redis is een door Azure beheerde service waarmee een hoogwaardige cachelaag wordt toegevoegd aan toepassingen. In deze architectuur gebruikt de leveringsmicroservice Azure Cache voor Redis als de statusopslag en sidecache om de snelheid en reactiesnelheid onder intensief verkeer te verbeteren.
Azure Container Registry is een door Azure beheerde service waarin privécontainerinstallatiekopieën worden opgeslagen voor implementatie in AKS. In deze architectuur worden de containerinstallatiekopieën voor microservices opgeslagen en wordt AKS geverifieerd met behulp van de door Microsoft Entra beheerde identiteit. Andere registers, zoals Docker Hub, kunnen ook worden gebruikt.
Azure Cosmos DB is een door Azure beheerde, wereldwijd gedistribueerde NoSQL-, relationele en vectordatabaseservice. In deze architectuur fungeren Azure Cosmos DB en Azure Cosmos DB voor MongoDB als externe gegevensarchieven voor elke microservice.
Key Vault is een door Azure beheerde service waarmee geheimen, sleutels en certificaten veilig worden opgeslagen en beheerd. In deze architectuur slaat Key Vault referenties op die worden gebruikt door microservices voor toegang tot Azure Cosmos DB en Azure Cache voor Redis.
Azure Monitor is een door Azure beheerd waarneembaarheidsplatform dat metrische gegevens, logboeken en telemetrie over services verzamelt. In deze architectuur is het mogelijk om de toepassing, waarschuwingen, dashboarding en hoofdoorzaakanalyse voor fouten in AKS en geïntegreerde services te bewaken.
Azure Service Bus is een door Azure beheerde berichtenservice die betrouwbare en asynchrone communicatie tussen gedistribueerde toepassingen ondersteunt. In deze architectuur fungeert Service Bus als de wachtrijlaag tussen de opname- en werkstroommicroservices, waardoor ontkoppelde en schaalbare berichtuitwisseling mogelijk is.

Andere bewerkingen ondersteunen systeemonderdelen

Flux is een door Azure ondersteunde, open en uitbreidbare oplossing voor continue levering voor Kubernetes die GitOps in AKS mogelijk maakt. In deze architectuur automatiseert Flux implementaties door toepassingsmanifestbestanden vanuit een Git-opslagplaats te synchroniseren, wat zorgt voor consistente en declaratieve levering van microservices aan het AKS-cluster.
Helm is een systeemeigen Pakketbeheerder van Kubernetes die Kubernetes-objecten in één eenheid bundelt voor het publiceren, implementeren, versiebeheer en bijwerken. In deze architectuur wordt Helm gebruikt voor het verpakken en implementeren van microservices in het AKS-cluster.
Key Vault Secrets Store CSI-stuurprogrammaprovider is een met Azure geïntegreerd stuurprogramma waarmee AKS-clusters geheimen uit Key Vault kunnen koppelen met CSI-volumes. In deze architectuur worden geheimen rechtstreeks gekoppeld aan microservicecontainers, waardoor veilig referenties kunnen worden opgehaald voor Azure Cosmos DB en Azure Cache voor Redis.

Alternatieven

In plaats van een invoegtoepassing voor toepassingsroutering te gebruiken, kunt u alternatieven gebruiken, zoals Application Gateway for Containers en de invoegtoepassing Istio-gateway. Zie Inkomend verkeer in AKS voor een vergelijking van de opties voor inkomend verkeer in AKS. Application Gateway for Containers is een evolutie van de controller voor inkomend verkeer van Application Gateway en biedt extra functies zoals het splitsen van verkeer en gewogen round robin-taakverdeling.

U kunt ArgoCD gebruiken als het GitOps-hulpprogramma in plaats van Flux. Zowel Flux als ArgoCD zijn beschikbaar als clusterextensies.

In plaats van referenties op te slaan voor Azure Cosmos DB en Azure Cache voor Redis in sleutelkluizen, raden we u aan beheerde identiteiten te gebruiken om te verifiëren omdat verificatiemechanismen zonder wachtwoord veiliger zijn. Zie Beheerde identiteiten gebruiken om vanuit een Azure-VM verbinding te maken met Azure Cosmos DB en een beheerde identiteit te verifiëren met behulp van Microsoft Entra ID voor toegang tot Service Bus-resources. Azure Cache voor Redis biedt ook ondersteuning voor verificatie met behulp van beheerde identiteiten.

Scenariodetails

In dit voorbeeld beheert Fabrikam, Inc., een fictief bedrijf, een vloot van dronevliegtuigen. Bedrijven registreren zich bij de service en gebruikers kunnen dan een aanvraag indienen om pakketjes door een drone te laten ophalen. Wanneer een klant een ophaalbewerking plant, wijst het back-endsysteem een drone toe en geeft de gebruiker een melding met een geschatte levertijd. Terwijl de levering wordt uitgevoerd, kan de klant de locatie van de drone volgen en een continu bijgewerkte geschatte tijd van aankomst zien.

Aanbevelingen

U kunt de volgende aanbevelingen toepassen op de meeste scenario's. Volg deze aanbevelingen tenzij er een specifieke vereiste is die iets anders voorschrijft.

Beheerd NGINX-inkomend verkeer met invoegtoepassing voor toepassingsroutering

API Gateway-routering is een algemeen ontwerppatroon voor microservices. Een API-gateway fungeert als een omgekeerde proxy waarmee aanvragen van clients naar microservices worden gerouteerd. De Kubernetes-bron voor inkomend verkeer en de ingangscontroller verwerken de meeste API-gatewayfunctionaliteit door de volgende acties uit te voeren:

Clientaanvragen routeren naar de juiste back-endservices om één eindpunt voor clients te bieden en clients te helpen loskoppelen van services
Meerdere aanvragen samenvoegen tot één aanvraag om chatter tussen de client en de back-end te verminderen
Offloading-functionaliteit zoals SSL-beëindiging (Secure Sockets Layer), verificatie, IP-adresbeperkingen en clientsnelheidsbeperking of beperking van de back-endservices

Toegangsbeheerobjectcontrollers vereenvoudigen de opname van verkeer in AKS-clusters, verbeteren de veiligheid en prestaties en besparen van resources. Deze architectuur maakt gebruik van het beheerde NGINX-inkomend verkeer met de invoegtoepassing voor toepassingsroutering voor inkomend verkeer.

U wordt aangeraden de ingangscontroller te gebruiken met een intern (privé) IP-adres en een interne load balancer en te integreren in azure-zones voor privédomeinnaamsysteemzones voor hostnaamomzetting van microservices. Configureer het privé-IP-adres of de hostnaam van de ingangscontroller als het adres van de back-endpool in Application Gateway. Application Gateway ontvangt verkeer op het openbare eindpunt, voert WAF-inspecties uit en stuurt het verkeer naar het privé-IP-adres voor inkomend verkeer.

U moet de ingangscontroller configureren met een aangepaste domeinnaam en EEN SSL-certificaat , zodat het verkeer end-to-end versleuteld is. Application Gateway ontvangt verkeer op de HTTPS-listener. Na WAF-inspecties stuurt Application Gateway verkeer naar het HTTPS-eindpunt van de ingangscontroller. Alle microservices moeten worden geconfigureerd met aangepaste domeinnamen en SSL-certificaten, zodat communicatie tussen microservices in het AKS-cluster ook wordt beveiligd met SSL.

Voor multitenant-workloads of één cluster dat ontwikkel- en testomgevingen ondersteunt, zijn mogelijk meer toegangsbeheerobjectcontrollers vereist. De invoegtoepassing voor toepassingsroutering ondersteunt geavanceerde configuraties en aanpassingen, waaronder meerdere ingangscontrollers binnen hetzelfde AKS-cluster en het gebruik van aantekeningen voor het configureren van toegangsbeheerresources.

Zero Trust-netwerkbeleid

Netwerkbeleid geeft aan hoe AKS-pods met elkaar en met andere netwerkeindpunten mogen communiceren. Standaard is al het inkomend en uitgaand verkeer naar en van pods toegestaan. Wanneer u ontwerpt hoe uw microservices met elkaar en met andere eindpunten communiceren, kunt u overwegen om een Zero Trust-principe te volgen, waarbij toegang tot een service, apparaat, toepassing of gegevensopslagplaats expliciete configuratie vereist.

Een strategie voor het implementeren van een Zero Trust-beleid is het maken van een netwerkbeleid dat al het inkomend en uitgaand verkeer weigert naar alle pods binnen de doelnaamruimte. In het volgende voorbeeld ziet u een beleid weigeren dat van toepassing is op alle pods die zich in de backend-dev naamruimte bevinden.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Nadat er een beperkend beleid is ingesteld, begint u specifieke netwerkregels te definiëren om verkeer naar en van elke pod in de microservice toe te staan. In het volgende voorbeeld wordt het netwerkbeleid toegepast op een pod in de backend-dev naamruimte met een label dat overeenkomt app.kubernetes.io/component: backend. Het beleid weigert verkeer, tenzij het afkomstig is van een pod met een label dat overeenkomt app.kubernetes.io/part-of: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Zie de Kubernetes-documentatie voor meer informatie over Kubernetes-netwerkbeleid en meer voorbeelden van mogelijke standaardbeleidsregels.

Azure biedt drie netwerkbeleidsengines voor het afdwingen van netwerkbeleid:

Cilium voor AKS-clusters die gebruikmaken van Azure CNI Powered by Cilium
Azure-netwerkbeleidsmanager
Calico, een opensource-netwerk- en netwerkbeveiligingsoplossing

U wordt aangeraden Cilium te gebruiken als de netwerkbeleidsengine.

Resourcequota

Beheerders gebruiken resourcequota om resources te reserveren en te beperken voor een ontwikkelingsteam of project. U kunt resourcequota instellen voor een naamruimte en deze gebruiken om limieten voor de volgende resources in te stellen:

Rekenresources, zoals CPU en geheugen, of GPU's
Opslagbronnen, inclusief het aantal volumes of de hoeveelheid schijfruimte voor een bepaalde opslagklasse
Aantal objecten, zoals het maximum aantal geheimen, services of taken dat kan worden gemaakt

Nadat het cumulatieve totaal van resourceaanvragen of -limieten het toegewezen quotum heeft doorgegeven, zijn er geen verdere implementaties geslaagd.

Resourcequota zorgen ervoor dat de totale set pods die zijn toegewezen aan de naamruimte, het resourcequotum van de naamruimte niet kan overschrijden. De front-end kan niet alle resources voor de back-endservices gebruiken en de back-end kan niet alle resources voor de front-endservices gebruiken.

Wanneer u resourcequota definieert, moeten alle pods die in de naamruimte zijn gemaakt, limieten of aanvragen opgeven in hun podspecificaties. Als ze deze waarden niet opgeven, wordt de implementatie geweigerd.

In het volgende voorbeeld ziet u een podspecificatie waarmee resourcequotumaanvragen en -limieten worden ingesteld:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Zie voor meer informatie over resourcequota:

Automatisch schalen

Kubernetes ondersteunt automatisch schalen om het aantal pods te verhogen dat is toegewezen aan een implementatie of om de knooppunten in het cluster te verhogen om de totale beschikbare rekenresources te verhogen. Automatisch schalen is een zelfcorrectied autonoom feedbacksysteem. U kunt pods en knooppunten handmatig schalen, maar automatisch schalen minimaliseert de kans dat services resourcelimieten bereiken bij hoge belastingen. Een strategie voor automatisch schalen moet rekening houden met zowel pods als knooppunten.

Automatische schaalaanpassing van clusters

De automatische schaalaanpassing van clusters (CA) schaalt het aantal knooppunten. Als pods niet kunnen worden gepland vanwege resourcebeperkingen, richt de automatische schaalaanpassing van clusters meer knooppunten in. U definieert een minimum aantal knooppunten om het AKS-cluster en uw workloads operationeel te houden en een maximum aantal knooppunten voor intensief verkeer. De CA controleert om de paar seconden op wachtende pods of lege knooppunten en schaalt het AKS-cluster op de juiste wijze.

In het volgende voorbeeld ziet u de CA-configuratie van de Bicep-sjabloon van het cluster:

autoScalerProfile: {
  'scan-interval': '10s'
  'scale-down-delay-after-add': '10m'
  'scale-down-delay-after-delete': '20s'
  'scale-down-delay-after-failure': '3m'
  'scale-down-unneeded-time': '10m'
  'scale-down-unready-time': '20m'
  'scale-down-utilization-threshold': '0.5'
  'max-graceful-termination-sec': '600'
  'balance-similar-node-groups': 'false'
  expander: 'random'
  'skip-nodes-with-local-storage': 'true'
  'skip-nodes-with-system-pods': 'true'
  'max-empty-bulk-delete': '10'
  'max-total-unready-percentage': '45'
  'ok-total-unready-count': '3'
}

De volgende regels in de Bicep-sjabloon stellen voorbeeld van minimum- en maximumknooppunten voor de automatische schaalaanpassing van clusters in:

minCount: 2
maxCount: 5

Automatische schaalaanpassing van horizontale pods

Met de horizontale automatische schaalaanpassing van pods (HPA) worden pods geschaald op basis van waargenomen CPU, geheugen of aangepaste metrische gegevens. Als u horizontale schaalaanpassing van pods wilt configureren, geeft u metrische doelgegevens en het minimum- en maximum aantal replica's op in de Kubernetes-implementatiepodspecificatie. Test uw services om deze getallen te bepalen.

CA en HPA werken samen, dus schakel beide opties voor automatisch schalen in uw AKS-cluster in. HPA schaalt de toepassing, terwijl ca de infrastructuur schaalt.

In het volgende voorbeeld worden metrische resourcegegevens ingesteld voor HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

HPA bekijkt de werkelijke verbruikte resources of andere metrische gegevens van actieve pods. De CA richt knooppunten in voor pods die nog niet zijn gepland. Als gevolg hiervan kijkt CA naar de aangevraagde resources, zoals opgegeven in de podspecificatie. Gebruik belastingstests om deze waarden af te stemmen.

Zie Schaalopties voor toepassingen in AKS voor meer informatie.

Automatische schaalaanpassing van verticale pods

Met de verticale schaalaanpassing voor pods (VPA) worden de CPU- en geheugenaanvragen voor uw pods automatisch aangepast aan de gebruikspatronen van uw workloads. Wanneer deze is geconfigureerd, stelt de VPA automatisch resourceaanvragen en limieten in voor containers voor elke workload op basis van het eerdere gebruik. De VPA maakt CPU en geheugen beschikbaar voor andere pods en zorgt voor effectief gebruik van uw AKS-clusters.

In deze architectuur verhoogt VPA de CPU- en geheugenaanvragen en limieten voor microservices op basis van hun eerdere gebruik. Als de werkstroommicroservice bijvoorbeeld meer CPU verbruikt dan andere microservices, kan de VPA dit gebruik bewaken en de CPU-limieten voor de microservice van de werkstroom verhogen.

Automatisch schalen op basis van Kubernetes-gebeurtenissen

Met de invoegtoepassing Kubernetes Event Driven Autoscaler (KEDA) kan automatisch schalen op basis van gebeurtenissen uw microservice schalen om op een duurzame en kostenefficiënte manier aan de vraag te voldoen. KEDA kan bijvoorbeeld microservices omhoog schalen wanneer het aantal berichten in de Service Bus-wachtrij specifieke drempelwaarden overschrijdt.

In het scenario voor de levering van fabrikam drone schaalt KEDA de microservice van de werkstroom uit, afhankelijk van de diepte van de Service Bus-wachtrij en op basis van de uitvoer van de opnamemicroservice. Zie Integraties met KEDA op AKS voor een lijst met KEDA-schaalders voor Azure-services.

Statuscontroles

Kubernetes-belasting verdeelt verkeer naar pods die overeenkomen met een labelkiezer voor een service. Alleen pods die zijn gestart en die in orde zijn, ontvangen verkeer. Als een container vastloopt, verwijdert Kubernetes de pod en plant een vervanging.

Kubernetes definieert drie typen statustests die een pod beschikbaar kan maken:

De gereedheidstest vertelt Kubernetes of de pod gereed is voor het accepteren van aanvragen.
De livenesstest vertelt Kubernetes of een pod moet worden verwijderd en een nieuw exemplaar moet worden gestart.
De opstarttest vertelt Kubernetes of de pod is gestart.

De liveness-tests verwerken pods die nog steeds worden uitgevoerd, maar die beschadigd zijn en moeten worden gerecycled. Als een container die HTTP-aanvragen verwerkt bijvoorbeeld vastloopt, loopt de container niet vast, maar stopt het verwerken van aanvragen. De HTTP-livenesstest reageert niet meer, waardoor Kubernetes wordt gewaarschuwd om de pod opnieuw op te starten.

Soms is een pod mogelijk niet gereed voor het ontvangen van verkeer, ook al is de pod met succes gestart. De toepassing die in de container wordt uitgevoerd, kan bijvoorbeeld initialisatietaken uitvoeren. De gereedheidstest geeft aan of de pod gereed is voor het ontvangen van verkeer.

Microservices moeten eindpunten beschikbaar maken in hun code die statustests mogelijk maken, met vertraging en time-out die speciaal is afgestemd op de controles die ze uitvoeren. De HPA-formule is afhankelijk van de fase gereed voor de pod, dus het is van cruciaal belang dat er statustests bestaan en nauwkeurig zijn.

Controleren

In een microservicestoepassing is APM-bewaking (Application Performance Management) cruciaal voor het detecteren van afwijkingen, het diagnosticeren van problemen en het snel begrijpen van de afhankelijkheden tussen services. Application Insights, een functie van Azure Monitor, biedt APM-bewaking voor livetoepassingen die zijn geschreven in .NET Core, Node.js, Java en vele andere toepassingstalen.

Azure biedt verschillende mechanismen voor het bewaken van microserviceworkloads:

Beheerde Prometheus voor het verzamelen van metrieken. Gebruik Prometheus om de prestaties van infrastructuur en workloads te bewaken en te waarschuwen.
Beheerde Azure Monitor-service voor Prometheus en containerinzichten werken samen voor volledige bewaking van uw Kubernetes-omgeving.
Beheerde Grafana voor cluster- en microservicevisualisatie.

Als u servicetelemetrie in Kubernetes wilt contextualiseren, integreert u Azure Monitor-telemetrie met AKS om metrische gegevens te verzamelen van controllers, knooppunten, containers en logboeken van containers en knooppunten. U kunt Application Insights integreren met AKS zonder codewijzigingen.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Well-Architected Framework voor meer informatie.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie voor meer informatie controlelijst ontwerpbeoordeling voor Security.

Houd rekening met de volgende punten wanneer u van plan bent voor beveiliging.

Implementatiebeveiligingen gebruiken in het AKS-cluster. Met implementatiebeveiligingen worden aanbevolen procedures voor Kubernetes in uw AKS-cluster afgedwongen via Azure Policy-besturingselementen.
Integreer beveiligingsscans in de microservice-build- en implementatiepijplijnen. Beheer uw DevOps-omgeving met behulp van Microsoft Defender voor Cloud DevOps-beveiliging. Gebruik codescans zonder agent en voer hulpprogramma's voor statische codeanalyse uit als onderdeel van CI/CD-pijplijnen (continue integratie en continue implementatie), zodat u beveiligingsproblemen met microservicecode kunt identificeren en oplossen als onderdeel van de build- en implementatieprocessen.
Een AKS-pod verifieert zichzelf met behulp van een workloadidentiteit die is opgeslagen in Microsoft Entra-id. U moet een workloadidentiteit gebruiken omdat hiervoor geen clientgeheim is vereist.
Wanneer u beheerde identiteiten gebruikt, kan de toepassing snel OAuth 2.0-tokens van Azure Resource Manager ophalen wanneer deze wordt uitgevoerd. Er zijn geen wachtwoorden of verbindingsreeksen nodig. In AKS kunt u identiteiten toewijzen aan afzonderlijke pods met behulp van workload-id.
Aan elke service in de microservicetoepassing moet een unieke workloadidentiteit worden toegewezen om RBAC-toewijzingen met minimale bevoegdheden te vergemakkelijken. U moet alleen identiteiten toewijzen aan services waarvoor ze zijn vereist.
In gevallen waarin een toepassingsonderdeel kubernetes-API-toegang vereist, moet u ervoor zorgen dat toepassingspods zijn geconfigureerd voor het gebruik van een serviceaccount met de juiste API-toegang. Zie Kubernetes-serviceaccounts beheren voor meer informatie.
Niet alle Azure-services ondersteunen het gebruik van Microsoft Entra ID voor verificatie van gegevensvlakken. Als u referenties of toepassingsgeheimen wilt opslaan voor deze services, voor niet-Microsoft-services of voor API-sleutels, gebruikt u Key Vault. Key Vault biedt gecentraliseerd beheer, toegangsbeheer, versleuteling in rust en controle van alle sleutels en geheimen.
In AKS kunt u een of meer geheimen uit Key Vault koppelen als een volume. De pod kan vervolgens de Key Vault-geheimen lezen, net als een normaal volume. Zie Key Vault-provider gebruiken voor het stuurprogramma Secrets Store CSI in een AKS-cluster voor meer informatie. U wordt aangeraden afzonderlijke sleutelkluizen voor elke microservice te onderhouden.
Als de microservice moet communiceren met resources, zoals externe URL's, buiten het cluster, kunt u de toegang beheren via Azure Firewall. Als de microservice geen uitgaande aanroepen hoeft uit te voeren, gebruikt u geïsoleerde netwerkclusters.
Schakel Microsoft Defender for Containers in om beveiligingspostuurbeheer, evaluatie van beveiligingsproblemen voor microservices, runtime-bedreigingsbeveiliging en andere beveiligingsfuncties te bieden.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie controlelijst ontwerpbeoordeling voor kostenoptimalisatievoor meer informatie.

In de sectie Kostenoptimalisatie in het Well-Architected Framework worden kostenoverwegingen beschreven.
Gebruik de Azure-prijscalculator om de kosten voor uw specifieke scenario te schatten.
In de gratis laag heeft AKS geen kosten verbonden aan de implementatie, het beheer en de bewerkingen van het Kubernetes-cluster. U betaalt alleen voor de VM-exemplaren, opslag en netwerkresources die het cluster verbruikt. Automatische schaalaanpassing van clusters kan de kosten van het cluster aanzienlijk verlagen door lege of ongebruikte knooppunten te verwijderen.
Overweeg het gebruik van de gratis laag van AKS voor ontwikkelworkloads en gebruik de Standard- en Premium-lagen voor productieworkloads.
Overweeg AKS-kostenanalyse in te schakelen voor gedetailleerde kostentoewijzing van clusterinfrastructuur door Kubernetes-specifieke constructies.

Operationele uitmuntendheid

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Zie controlelijst ontwerpbeoordeling voor Operational Excellencevoor meer informatie.

Houd rekening met de volgende punten wanneer u de beheerbaarheid plant.

Beheer de AKS-clusterinfrastructuur via een geautomatiseerde implementatiepijplijn, zoals GitHub Actions-werkstromen .
Het werkstroombestand implementeert alleen de infrastructuur, niet de workload, in het al bestaande virtuele netwerk en de Microsoft Entra-configuratie. Door de infrastructuur en de workload afzonderlijk te implementeren, kunt u verschillende levenscyclus- en operationele problemen aanpakken.
Houd rekening met uw werkstroom als mechanisme voor implementatie in een andere regio als er sprake is van een regionale fout. Bouw de pijplijn zodat u een nieuw cluster in een nieuwe regio kunt implementeren met parameter- en invoerwijzigingen.

Prestatie-efficiëntie

Prestatie-efficiëntie verwijst naar de mogelijkheid van uw workload om efficiënt te voldoen aan de behoeften van de gebruiker. Zie controlelijst ontwerpbeoordeling voor prestatie-efficiëntievoor meer informatie.

Houd rekening met de volgende punten wanneer u de schaalbaarheid plant.

Combineer automatisch schalen en imperatief of declaratief beheer van het aantal replica's niet. Gebruikers en een automatische schaalaanpassing die beide proberen het aantal replica's te wijzigen, kunnen onverwacht gedrag veroorzaken. Wanneer HPA is ingeschakeld, vermindert u het aantal replica's tot het minimumaantal dat u wilt implementeren.
Een neveneffect van automatische schaalaanpassing van pods is dat pods vaak kunnen worden gemaakt of verwijderd wanneer de toepassing wordt ingeschaald of uitgeschaald. Voer de volgende acties uit om deze effecten te beperken:
- Gebruik gereedheidstests om Kubernetes te laten weten wanneer een nieuwe pod gereed is om verkeer te accepteren.
- Gebruik budgetten voor podonderbreking om te beperken hoeveel pods tegelijk uit een service kunnen worden verwijderd.
Als er een groot aantal uitgaande stromen van de microservice is, kunt u overwegen gateways voor netwerkadresomzetting te gebruiken om uitputting van de poort voor bronadresomzetting te voorkomen.
Multitenant of andere geavanceerde workloads hebben mogelijk isolatievereisten voor knooppuntgroepen die meer en waarschijnlijk kleinere subnetten vragen. Zie Knooppuntgroepen met unieke subnetten toevoegen voor meer informatie. Organisaties hebben verschillende standaarden voor hun hub-spoke-implementaties. Zorg ervoor dat u de richtlijnen van uw organisatie volgt.
Overweeg het gebruik van CNI met overlaynetwerken om netwerkadresruimte te besparen.

Volgende stappen

Feedback

Is deze pagina nuttig?