Avancerad arkitektur för Azure Kubernetes Service (AKS) för mikrotjänster

Azure Application Gateway

Azure Container Registry

Azure Kubernetes Service (AKS)

Azure Virtual Network

Den här referensarkitekturen beskriver flera konfigurationer att tänka på när du kör mikrotjänster på Azure Kubernetes Service (AKS). I den här artikeln beskrivs konfiguration av nätverksprinciper, automatisk skalning av poddar och distribuerad spårning i ett mikrotjänstbaserat program.

Den här arkitekturen bygger på AKS-baslinjearkitekturen, som fungerar som utgångspunkt för AKS-infrastrukturen. AKS-baslinjen beskriver infrastrukturella funktioner som Microsoft Entra-arbetsbelastnings-ID, begränsningar för inkommande och utgående trafik, resursgränser och andra säkra konfigurationer av AKS-infrastruktur. De här funktionerna beskrivs inte i den här artikeln. Vi rekommenderar att du bekantar dig med AKS-baslinjearkitekturen innan du fortsätter med mikrotjänstinnehållet.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Om du föredrar att börja med ett mer grundläggande mikrotjänstexempel på AKS kan du läsa Mikrotjänstarkitektur på AKS.

Arbetsflöde

Detta begärandeflöde implementerar molndesignmönstren Publisher-Subscriber, Competing Consumers och Gateway Routing.

Följande arbetsflöde motsvarar föregående diagram:

En HTTPS-begäran skickas för att schemalägga en drönarhämtning. Begäran skickas via Azure Application Gateway till inmatningswebbappen, som körs som en mikrotjänst i klustret i AKS.
Inmatningswebbprogrammet skapar ett meddelande och skickar det till Azure Service Bus-meddelandekön.
Serverdelssystemet tilldelar en drönare och meddelar användaren. Arbetsflödets mikrotjänst utför följande uppgifter:
- Förbrukar meddelandeinformation från Service Bus-meddelandekön.
- Skickar en HTTPS-begäran till leveransmikrotjänsten, som skickar data till Azure Managed Redis externa datalagring.
- Skickar en HTTPS-begäran till drone scheduler-mikrotjänsten.
- Skickar en HTTPS-begäran till paketmikrotjänsten, som skickar data till extern Azure DocumentDB-datalagring.
- Advanced Container Networking Services-principer (Cilium NetworkPolicy) styr tjänst-till-tjänst-trafik i klustret, och dataplanet tillämpar transparent valfri poddkryptering mellan noder (WireGuard). Advanced Container Networking Services är inte aktiverat som standard. Den hämtar data på nodnivå och poddnivå och matar in dem i Azure Monitor för synlighet från slutpunkt till slutpunkt.
Arkitekturen använder en HTTPS GET-begäran för att returnera leveransstatus. Den här begäran skickas via Application Gateway till leveransmikrotjänsten.
Leveransmikrotjänsten läser data från Azure Managed Redis.

Komponenter

AKS är en hanterad Kubernetes-plattform som levererar hanterade kluster för distribution och skalning av containerbaserade program. När du använder AKS hanterar Azure Kubernetes API-servern. Klusteroperatorn kan komma åt och hantera Kubernetes-noder eller nodpooler. Den här arkitekturen använder följande AKS-infrastrukturfunktioner:
- AKS-hanterat Microsoft Entra-ID för rollbaserad åtkomstkontroll i Azure (Azure RBAC) är en funktion som integrerar Microsoft Entra-ID med AKS för att framtvinga identitetsbaserad åtkomstkontroll. I den här arkitekturen säkerställer den säker, centraliserad autentisering och auktorisering för klusteranvändare och arbetsbelastningar.
- Azure CNI som drivs av Cilium är den rekommenderade nätverkslösningen för att ansluta direkt till ett virtuellt Azure-nätverk. I den här arkitekturen tilldelar den IP-adresser från det virtuella nätverket till poddar samtidigt som inbyggda nätverksprincipfunktioner och trafiksynlighet ges.
- Advanced Container Networking Services är en uppsättning hanterade nätverksfunktioner för AKS som ger nätverksobservabilitet och förbättrad säkerhet i klustret:
  - Container Network Observability använder eBPF-baserade verktyg (Extended Berkeley Packet Filter), såsom Hubble och Retina, för att samla in förfrågningar om domännamnssystem (DNS), pod-till-pod- och pod-till-tjänstflöden, paketförluster och andra mätvärden. Den fungerar på Cilium- och icke-Cilium Linux-dataplan. Den integreras också med Azure Monitor-hanterad tjänst för Prometheus och Azure Managed Grafana för visualisering och aviseringar. I den här arkitekturen diagnostiserar Container Network Observability felkonfigurationer, DNS-svarstider eller fel och trafikobalanser mellan mikrotjänster.
  - Container Network Security gäller för kluster som använder Azure CNI som drivs av Cilium. Det framtvingar Cilium NetworkPolicy-resurser, inklusive fullständigt kvalificerade domännamn (FQDN)-baserad utgående filtrering, för att implementera noll förtroendenätverkssegmentering och minska driftkostnaderna. I den här arkitekturen fungerar FQDN-principer i klustret med Azure Firewall eller Azure NAT Gateway för att framtvinga lägsta möjliga utgående behörighet samtidigt som principunderhållet förenklas.
- Azure Policy-tillägget för AKS är ett inbyggt tillägg som ger styrnings- och efterlevnadskontroller direkt i dina AKS-kluster. Den tillämpar styrningsregler mellan AKS-resurser med hjälp av Azure Policy. I den här arkitekturen framtvingar den efterlevnad genom att verifiera konfigurationer och begränsa obehöriga distributioner.
- Hanterad NGINX-ingress med tillägget för programroutning är en funktion i AKS som hjälper dig att exponera dina program på Internet med hjälp av HTTP- eller HTTPS-trafik. Den tillhandahåller en förkonfigurerad NGINX-ingresskontrollant för AKS. I den här arkitekturen sköter den trafikroutning till tjänster och gör det möjligt att exponera poddar för Application Gateway.
- Uppdelning av system- och användarnodpooler är en arkitekturmetod som delar upp klusternoder i två olika typer av nodpooler och isolerar AKS-infrastrukturkomponenter från programarbetsbelastningar. I den här arkitekturen förbättras säkerheten och resurseffektiviteten genom att nodpooler anges till specifika driftsroller.
- Arbetsbelastnings-ID är ett säkert och skalbart sätt för Kubernetes-arbetsbelastningar att komma åt Azure-resurser med hjälp av Microsoft Entra-ID utan att behöva hemligheter eller autentiseringsuppgifter som lagras i klustret. Med arbetsbelastnings-ID kan AKS-arbetsbelastningar på ett säkert sätt komma åt Azure-resurser med hjälp av federerad identitet. I den här arkitekturen eliminerar den behovet av hemligheter och förbättrar säkerhetsstatusen genom identitetsbaserad åtkomst.
Application Gateway är en Azure-hanterad tjänst som tillhandahåller layer-7-belastningsutjämning och waf-funktioner (web application firewall). I den här arkitekturen exponerar den inmatningsmikrotjänsten som en offentlig slutpunkt och balanserar inkommande webbtrafik till programmet.
Azure Firewall är en Azure-hanterad tjänst som levererar intelligent, molnbaserad nätverkssäkerhet och skydd mot hot. I den här arkitekturen styr den utgående kommunikation från mikrotjänster till externa resurser, vilket endast tillåter godkända FQDN som utgående trafik. Brandväggen utför också källnätverksadressöversättning (SNAT) på utgående flöden, så dess offentliga IP-adresser blir klustrets utgående identitet för partner-tillåtna listor.
Azure Private Link är en Azure-hanterad tjänst som möjliggör privat anslutning till PaaS-erbjudanden (Plattform som en tjänst) via Microsofts stamnätverk. I den här arkitekturen tilldelar den privata IP-adresser för åtkomst till Azure Container Registry och Azure Key Vault från AKS-nodpooler via privata slutpunkter.
Azure Virtual Network är en Azure-hanterad tjänst som tillhandahåller isolerade och säkra miljöer för att köra program och virtuella datorer (VM). I den här arkitekturen använder den en peered hub-spoke-topologi. Hubbnätverket är värd för Azure Firewall och Azure Bastion. Ekernätverket innehåller undernät för AKS-system och användarnodpooler, tillsammans med undernät för Application Gateway.

Extern lagring och andra komponenter

Azure Managed Redis är en Azure-hanterad tjänst som tillhandahåller ett datalager med höga prestanda i minnet för cachelagring, sessionslagring och dataåtkomst i realtid. Utöver traditionell cachelagring innehåller den stöd för avancerade datatyper och funktioner som JSON-dokumentlagring, fulltext- och vektorsökning och dataströmbearbetning. I den här arkitekturen använder leveransmikrotjänsten Azure Managed Redis som tillståndsarkiv och sidocache för att förbättra hastigheten och svarstiden under tung trafik.
Container Registry är en Azure-hanterad tjänst som lagrar privata containeravbildningar för distribution i AKS. I den här arkitekturen innehåller den containeravbildningarna för mikrotjänster och AKS autentiserar med den med hjälp av sin Microsoft Entra-hanterade identitet. Du kan också använda andra register, till exempel Docker Hub.
Azure Cosmos DB är en Azure-hanterad, globalt distribuerad NoSQL-, relations- och vektordatabastjänst. I den här arkitekturen fungerar Azure Cosmos DB och Azure DocumentDB som externa datalager för varje mikrotjänst.
Key Vault är en Azure-hanterad tjänst som lagrar och hanterar hemligheter, nycklar och certifikat på ett säkert sätt. I den här arkitekturen lagrar Key Vault autentiseringsuppgifter som mikrotjänster använder för åtkomst till Azure Cosmos DB och Azure Managed Redis.
Azure Monitor är en Azure-hanterad observerbarhetsplattform som samlar in mått, loggar och telemetri mellan tjänster. I den här arkitekturen möjliggör övervakning av programmet, aviseringar, dashboardar och root cause-analys vid fel i AKS och integrerade tjänster.

Container Network Observability for Advanced Container Networking Services använder Hubble för flödessynlighet och Retina för kuraterad nätverkstelemetri. De här verktygen integreras med serverdelar för hanterad observerbarhet, till exempel Azure Monitor-hanterad tjänst för Prometheus och Azure Managed Grafana, för felsökning och SLO-rapportering (servicenivåmål).
Service Bus är en Azure-hanterad meddelandetjänst som stöder tillförlitlig och asynkron kommunikation mellan distribuerade program. I den här arkitekturen fungerar Service Bus som kölager mellan inmatnings- och arbetsflödesmikrotjänster, vilket möjliggör frikopplat och skalbart meddelandeutbyte.

Andra komponenter i driftstödsystem

Flux är en Lösning med Azure-stöd, öppen källkod och utökningsbar kontinuerlig leverans för Kubernetes som möjliggör GitOps i AKS. I den här arkitekturen automatiserar Flux distributioner genom att synkronisera programmanifestfiler från en Git-lagringsplats, vilket säkerställer konsekvent och deklarativ leverans av mikrotjänster till AKS-klustret.
Helm är en Kubernetes-intern pakethanterare som paketerar Kubernetes-objekt i en enda enhet för publicering, distribution, versionshantering och uppdatering. I den här arkitekturen används Helm för att paketera och distribuera mikrotjänster till AKS-klustret.
Key Vault Secrets Store CSI Driver Provider är en Azure-integrerad drivrutin som gör det möjligt för AKS-kluster att montera hemligheter från Key Vault med hjälp av CSI-volymer. I den här arkitekturen monteras hemligheter direkt i mikrotjänstcontainrar, vilket möjliggör säker hämtning av autentiseringsuppgifter för Azure Cosmos DB och Azure Managed Redis.

Alternativ

I stället för att använda ett tillägg för programroutning kan du använda alternativ som Application Gateway för containrar och Istio gateway-tillägg. En jämförelse av ingressalternativ i AKS finns i Ingress i AKS. Application Gateway för containrar är en vidareutveckling av Application Gateway-ingresskontrollen och erbjuder ytterligare funktioner som trafikdelning och lastbalansering med viktad round-robin.

Du kan använda ArgoCD som GitOps-verktyg i stället för Flux. Både Flux och ArgoCD är tillgängliga som klustertillägg.

I stället för att lagra autentiseringsuppgifter för Azure Cosmos DB och Azure Managed Redis i nyckelvalv rekommenderar vi att du använder hanterade identiteter för att autentisera eftersom mekanismer för lösenordsfri autentisering är säkrare. Mer information finns i Använda hanterade identiteter för att ansluta till Azure Cosmos DB från en virtuell Azure-dator och autentisera en hanterad identitet med hjälp av Microsoft Entra-ID för att få åtkomst till Service Bus-resurser. Azure Managed Redis stöder även autentisering med hjälp av hanterade identiteter.

Information om scenario

I det här exemplet hanterar Fabrikam, Inc., ett fiktivt företag, en flotta av drönarflygplan. Företag registrerar sig för tjänsten och användare kan begära att en drönare hämtar gods för leverans. När en kund schemalägger en upphämtning tilldelar serverdelssystemet en drönare och meddelar användaren en uppskattad leveranstid. Kunden kan spåra drönarens plats och se en kontinuerligt uppdaterad uppskattad ankomsttid medan leveransen pågår.

Rekommendationer

Du kan tillämpa följande rekommendationer på de flesta scenarier. Följ dessa rekommendationer om du inte har ett visst krav som åsidosätter dem.

Hanterad NGINX-ingress med tillägg för programroutning

API Gateway-routning är ett allmänt designmönster för mikrotjänster. En API-gateway fungerar som en omvänd proxy som dirigerar begäranden från klienter till mikrotjänster. Kubernetes-ingressresursen och ingresskontrollanten hanterar de flesta API Gateway-funktioner genom att utföra följande åtgärder:

Dirigera klientbegäranden till rätt serverdelstjänster för att tillhandahålla en enskild slutpunkt för klienter och hjälpa till att frikoppla klienter från tjänster
Aggregera flera begäranden till en enda begäran för att minska pratet mellan klienten och serverdelen
Avlastning av funktioner som SSL-avslutning (Secure Sockets Layer), autentisering, IP-adressbegränsningar och hastighetsbegränsning för klienter från serverdelstjänsterna

Ingresskontrollanter förenklar trafikinmatning till AKS-kluster, förbättrar säkerhet och prestanda och sparar resurser. Den här arkitekturen använder den hanterade NGINX-ingressen med tillägget för programroutning för ingresskontroll.

Vi rekommenderar att du använder ingresskontrollanten med en intern (privat) IP-adress och en intern lastbalanserare och integrerar till privata Azure DNS-zoner för värdnamnsmatchning av mikrotjänster. Konfigurera den privata IP-adressen eller värdnamnet för ingresskontroller som back-end-pooladress i Application Gateway. Application Gateway tar emot trafik på den offentliga slutpunkten, utför WAF-inspektioner och dirigerar trafiken till den inkommande privata IP-adressen.

Konfigurera ingresskontrollanten med ett anpassat domännamn och SSL-certifikat så att trafiken krypteras från slutpunkt till slutpunkt. Application Gateway tar emot trafik på HTTPS-lyssnaren. Efter WAF-inspektioner dirigerar Application Gateway trafik till HTTPS-slutpunkten för ingresskontrollanten. Konfigurera alla mikrotjänster för att använda anpassade domännamn och SSL-certifikat, vilket skyddar kommunikation mellan mikrotjänster i AKS-klustret.

Arbetsbelastningar för flera hyresgäster eller ett enda kluster som stöder utvecklings- och testmiljöer kan kräva fler ingresskontrollers. Tillägget för programroutning stöder avancerade konfigurationer och anpassningar, inklusive flera ingresskontrollanter i samma AKS-kluster och med anteckningar för att konfigurera inkommande resurser.

Nätverk och nätverkspolicy

Använd Azure CNI som drivs av Cilium. eBPF-dataplanet har lämplig routningsprestanda och stöder alla storlekskluster. Cilium tillämpar Kubernetes NetworkPolicy internt och ger omfattande trafikobservabilitet. Mer information finns i Konfigurera Azure CNI som drivs av Cilium i AKS.

Viktigt!

Om du behöver Windows-noder i din mikrotjänstarkitektur kan du läsa Ciliums aktuella linux-begränsning och planera på lämpligt sätt för pooler med blandade operativsystem. För mer information, se begränsningar för Azure CNI med Cilium.

För specifika behov av IP-adresshantering stöder Azure CNI som drivs av Cilium både virtuella nätverksroutade och overlay pod-IP-modeller. Mer information finns i Azure CNI som drivs av Cilium.

Nätverksprinciper med noll förtroende

Nätverksprinciper anger hur AKS-poddar kommunicerar med varandra och med andra nätverksslutpunkter. Som standard tillåts all inkommande och utgående trafik till och från poddar. När du utformar hur dina mikrotjänster kommunicerar med varandra och med andra slutpunkter bör du överväga att följa principen noll förtroende, där åtkomst till alla tjänster, enheter, program eller datalagringsplatser kräver explicit konfiguration. Definiera och framtvinga Kubernetes NetworkPolicy (implementerat av Advanced Container Networking Services/Cilium) för att segmentera trafik mellan mikrotjänster och begränsa utgående trafik till endast tillåtna FQDN.

En strategi för att implementera en nollförtroendeprincip är att skapa en nätverksprincip som nekar all inkommande och utgående trafik till alla poddar i målnamnområdet. I följande exempel visas en neka alla principer som gäller för alla poddar som finns i backend-dev namnområdet.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
  namespace: backend-dev
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  ingress:
  - fromEntities: []
  egress:
  - toEntities: []

När en restriktiv princip har införts börjar du definiera specifika nätverksregler för att tillåta trafik till och från varje podd i mikrotjänsten. I följande exempel tillämpas Cilium-nätverksprincipen på alla poddar i backend-dev namnområdet som har en etikett som matchar app.kubernetes.io/component: backend. Policyn nekar all trafik om den inte kommer från en pod som har en etikett som matchar app.kubernetes.io/part-of: dronedelivery.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/part-of: dronedelivery
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

Mer information om Kubernetes-nätverksprinciper och fler exempel på potentiella standardprinciper finns i Nätverksprinciper i Kubernetes-dokumentationen. Metodtips för nätverksprinciper i AKS finns i Använda nätverksprinciper i AKS.

När du använder Azure CNI som drivs av Cilium tillämpas Kubernetes NetworkPolicy av Cilium. För särskilda krav tillhandahåller Azure andra nätverksprincipmotorer, inklusive Azure Network Policy Manager och Calico. Vi rekommenderar Cilium som standardmotor för nätverksprinciper.

Resurskvoter

Administratörer använder resurskvoter för att reservera och begränsa resurser i ett utvecklingsteam eller projekt. Du kan ange resurskvoter för ett namnområde och använda dem för att ange gränser för följande resurser:

Beräkningsresurser, till exempel centrala bearbetningsenheter (PROCESSORer), minnes- och grafikprocessorer (GPU:er)
Lagringsresurser, inklusive antalet volymer eller mängden diskutrymme för en specifik lagringsklass
Antal objekt, till exempel det maximala antalet hemligheter, tjänster eller jobb som kan skapas

När den kumulativa summan av resursbegäranden eller gränser har passerat den tilldelade kvoten lyckas inga ytterligare distributioner.

Resurskvoter säkerställer att den totala uppsättningen poddar som tilldelats namnområdet inte får överskrida resurskvoten för namnområdet. Frontend kan inte använda alla resurser för back-end-tjänsterna och backend kan inte använda alla resurser för front-end-tjänsterna.

När du definierar resurskvoter måste alla poddar som skapats i namnområdet ange gränser eller begäranden i poddspecifikationerna. Om de inte anger dessa värden avvisas distributionen.

I följande exempel visas en poddspecifikation som anger resurskvotbegäranden och gränser:

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

Mer information om resurskvoter finns i följande artiklar:

Automatisk skalning

Kubernetes stöder automatisk skalning för att öka antalet poddar som allokerats till en distribution eller öka noderna i klustret för att öka de totala tillgängliga beräkningsresurserna. Autoskalning är ett autonomt, självkorrigerande feedbacksystem. Du kan skala poddar och noder manuellt, men automatisk skalning minimerar risken för att tjänster når resursgränser vid hög belastning. En strategi för automatisk skalning måste ta hänsyn till både poddar och noder.

Autoskalning av kluster

Klustrets Autoskalare (CA) skalar antalet noder. Om poddar inte kan schemaläggas på grund av resursbegränsningar lägger Cluster Autoscaler till fler noder. Du definierar ett minsta antal noder för att hålla AKS-klustret och dina arbetsbelastningar i drift och ett maximalt antal noder för tung trafik. Ca:en söker efter väntande poddar eller tomma noder med några sekunders mellanrum och skalar AKS-klustret på rätt sätt.

I följande exempel visas CA-konfigurationen från klustrets Bicep-mall:

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'
}

Följande rader i Bicep-mallen anger exempel på lägsta och högsta noder för CA:en:

minCount: 2
maxCount: 5

Vågrät automatisk skalning av Poddar

HPA (Horizontal Pod Autoscaler) skalar poddar baserat på observerad CPU, minne eller anpassade mått. För att konfigurera horisontell poddskalning anger du målmått och det minsta och högsta antalet repliker i Kubernetes-distributionspoddens specifikation. Belastningstesta dina tjänster för att fastställa dessa siffror.

Certifikatautoriteten och HPA fungerar tillsammans, så aktivera båda alternativen för autoskalare i AKS-klustret. HPA skalar programmet medan CA:en skalar infrastrukturen.

I följande exempel anges resursmått för 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 analyserar faktiska resurser som förbrukas eller andra mått från poddar som körs. CA allokerar noder för poddar som inte har schemalagts ännu. Därför tittar CA på de begärda resurserna enligt poddspecifikationen. Använd belastningstestning för att finjustera dessa värden.

Mer information finns i Skalningsalternativ för program i AKS.

Automatisk lodrät skalanpassing av podd

VPA (Vertical Pod Autoscaler) justerar automatiskt processor- och minnesbegäranden för dina poddar så att de matchar användningsmönstren för dina arbetsbelastningar. När den har konfigurerats anger VPA automatiskt resursbegäranden och begränsningar för containrar för varje arbetsbelastning baserat på tidigare användning. VPA gör CPU och minne tillgängligt för andra poddar och hjälper till att säkerställa effektiv användning av dina AKS-kluster.

I den här arkitekturen ökar VPA cpu- och minnesbegäranden och gränserna för mikrotjänster baserat på deras tidigare användning. Om arbetsflödets mikrotjänst till exempel förbrukar mer PROCESSOR jämfört med andra mikrotjänster kan VPA övervaka den här användningen och öka CPU-gränserna för arbetsflödets mikrotjänst.

Kubernetes Event-Driven automatisk skalning

Tillägget Kubernetes Event-Driven Autoscaling (KEDA) gör det möjligt för händelsedriven autoskalning att skala din mikrotjänst för att möta efterfrågan på ett hållbart och kostnadseffektivt sätt. KEDA kan till exempel skala upp mikrotjänster när antalet meddelanden i Service Bus-kön överskrider specifika tröskelvärden.

I scenariot för leverans av Fabrikam-drönare skalar KEDA upp mikrotjänsten för arbetsflödet beroende på Service Bus-ködjupet och baserat på utdata från inmatningsmikrotjänsten. En lista över KEDA-skalare för Azure-tjänster finns i Integreringar med KEDA på AKS.

Hälsokontroller

Kubernetes fördelar trafiken till de poddar som matchar en etikettväljare för en tjänst. Endast poddar som startar framgångsrikt och är hälsosamma tar emot trafik. Om en container kraschar tar Kubernetes bort podden och schemalägger en ersättning. Kubernetes definierar tre typer av hälsoavsökningar som en podd kan exponera:

Beredskapskontrollen talar om för Kubernetes om podden är redo att ta emot förfrågningar.
Liveness-avsökningen talar om för Kubernetes om en podd ska tas bort och en ny instans startas.
Startavsökningen informerar Kubernetes om podden har startat.

Liveness-undersökningarna hanterar poddar som fortfarande körs men som är ohälsosamma och bör omstartas. Om till exempel en container som hanterar HTTP-begäranden låser sig kraschar inte containern, men den slutar att betjäna begäranden. HTTP-liveness-kontrollen slutar svara, vilket signalerar Kubernetes att starta podden på nytt.

Ibland kan en pod inte vara redo att ta emot trafik, även om poden startar framgångsrikt. Till exempel kan programmet som körs i containern utföra initieringsuppgifter. Beredskapskontrollen anger om podden är redo att ta emot trafik.

Mikrotjänster bör exponera slutpunkter i sin kod som underlättar hälsoavsökningar, med fördröjning och timeout som är skräddarsydd specifikt för de kontroller som de utför. HPA-formeln förlitar sig på poddens redofas, så det är viktigt att hälsosonder finns och är korrekta.

Övervakning

Övervakning är viktigt i en mikrotjänstarkitektur för att identifiera avvikelser, diagnostisera problem och förstå tjänstberoenden. Application Insights, som är en del av Azure Monitor, tillhandahåller övervakning av programprestanda (APM) för program som skrivits i .NET, Node.js, Java och många andra språk. Azure har flera integrerade funktioner för synlighet från slutpunkt till slutpunkt:

Azure Monitor-hanterad tjänst för Prometheus samlar in och aviseringar om infrastruktur- och arbetsbelastningsmått.
Funktionen Live Data i Container Insights övervakar AKS-kluster, noder och containrar för hälso- och resursanvändning.
Azure Managed Grafana visualiserar mått och instrumentpaneler för kluster och mikrotjänster.

Avancerade Container Networking Services-observabilitet kompletterar dessa verktyg genom att erbjuda djup eBPF-baserad insyn i AKS-klustrens nätverksbeteende. Den samlar in DNS-svarstider, pod-till-pod-flöden och tjänsteflöden, bortfall av nätverkspolicyer samt protokollmått på applikationslagernivå såsom HTTP-statuskoder och svarstider. Den här telemetrin integreras med Azure Monitor-hanterad tjänst för Prometheus för metrik och Azure Managed Grafana för dashboards. Dataplanet Cilium eBPF ger synlighet och felsökning på flödesnivå. I kombination med Advanced Container Networking Services och Azure Monitor ger den här funktionen nätverksobservabilitet från slutpunkt till slutpunkt. Den här integreringen möjliggör identifiering av flaskhalsar i nätverket, felkonfigurationer av principer och kommunikationsproblem som traditionella APM kan missa.

Tips/Råd

Kombinera Advanced Container Networking Services-nätverksdata med Azure Monitor-telemetri för en fullständig vy över programmets och infrastrukturens hälsa. Du kan också integrera Application Insights med AKS utan att göra kodändringar för att korrelera programprestanda med kluster- och nätverksinsikter.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. För mer information, se Well-Architected Framework.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i checklistan för Designgranskning för Security.

Tänk på följande när du planerar för säkerhet:

Använd distributionsskydd i AKS-klustret. Distribueringsskydd upprätthåller bästa praxis för Kubernetes i ditt AKS-kluster via Azure Policy-kontroller.
Integrera säkerhetsgenomsökning i pipelines för utveckling och distribution av mikrotjänster. Hantera din DevOps-miljö med hjälp av Microsoft Defender för Cloud DevOps-säkerhet. Använd agentlös kodgenomsökning och kör verktyg för analys av statisk kod som en del av CI/CD-pipelines (kontinuerlig integrering och kontinuerlig distribution) så att du kan identifiera och åtgärda sårbarheter i mikrotjänstkoden som en del av bygg- och distributionsprocesserna.
En AKS-podd autentiserar sig själv med hjälp av en arbetsbelastningsidentitet som lagras i Microsoft Entra ID. Du bör använda en arbetsbelastningsidentitet eftersom den inte kräver någon klienthemlighet.
När du använder hanterade identiteter kan programmet snabbt hämta Azure Resource Manager OAuth 2.0-token när det körs. Den behöver inte lösenord eller anslutningssträngar. I AKS kan du tilldela identiteter till enskilda poddar med hjälp av arbetsbelastnings-ID.
Varje tjänst i mikrotjänstprogrammet ska tilldelas en unik arbetsbelastningsidentitet för att underlätta minst privilegierade Azure RBAC-tilldelningar. Tilldela endast identiteter till tjänster som kräver dem.
I de fall där en programkomponent kräver Kubernetes API-åtkomst kontrollerar du att programpoddar är konfigurerade för att använda ett tjänstkonto med rätt begränsad API-åtkomst. Mer information finns i Hantera Kubernetes-tjänstkonton.
Alla Azure-tjänster har inte stöd för Microsoft Entra-ID för dataplansautentisering. Om du vill lagra autentiseringsuppgifter eller programhemligheter för dessa tjänster, för tjänster som inte kommer från Microsoft eller för API-nycklar använder du Key Vault. Det ger centraliserad hantering, åtkomstkontroll, kryptering i vila och granskning för alla nycklar och hemligheter.
I AKS kan du montera en eller flera hemligheter från Key Vault som en volym. Podden kan sedan läsa Key Vault-hemligheterna precis som en vanlig volym. Mer information finns i Använda Key Vault-providern för Secrets Store CSI-drivrutinen i ett AKS-kluster. Vi rekommenderar att du underhåller separata nyckelvalv för varje mikrotjänst.

Advanced Container Networking Services tillhandahåller nätverkssegmentering inom klustret och nollförtroendekontroller för AKS-kluster. Använd Cilium-nätverksprinciper på Azure CNI som drivs av Cilium för att implementera segmentering layer-3 och layer-4 i klustret. Advanced Container Networking Services-säkerhet utökar den här grunden genom att lägga till avancerade funktioner:

FQDN-baserad utgående filtrering för att begränsa utgående trafik till godkända domäner.
Nivå-7-medvetna principer för protokoll som HTTP och gRPC Remote Procedure Call (gRPC) för att verifiera och kontrollera kommunikation på programnivå.
WireGuard-kryptering för att skydda pod-till-pod-trafik och skydda känslig data i transit.

De här funktionerna fungerar tillsammans med perimeterskydd som nätverkssäkerhetsgrupper (NSG:er) och Azure Firewall för att leverera en nivåbaserad säkerhetsmetod som framtvingar trafikkontroll inifrån klustret.
Om mikrotjänsten behöver kommunicera med resurser, till exempel externa URL:er utanför klustret, kontrollerar du åtkomsten via Azure Firewall. Om mikrotjänsten inte behöver göra några utgående anrop använder du isolerade nätverkskluster.
Aktivera Microsoft Defender för containrar för att tillhandahålla hantering av säkerhetsstatus, sårbarhetsbedömning för mikrotjänster, skydd mot hot under körning och andra säkerhetsfunktioner.

Nätverksdataplan och principmotorer

Cilium på AKS stöds för Linux-noder och upprätthåller för närvarande NetworkPolicy i dataplanet. Var medveten om policyundantag som ipBlock-användning för nodens IP-adresser och poddarnas IP-adresser och att värdnätverkspoddar använder en värdidentitet. Principer på poddnivå gäller inte. Justera AKS- och Cilium-versioner med den versionsmatris som stöds. För mer information, se begränsningar för Azure CNI med Cilium.

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i checklistan Designgranskning för kostnadsoptimering.

I avsnittet Kostnadsoptimering i Well-Architected Framework beskrivs kostnadsöverväganden.
Använd Priskalkylatorn för Azure för att beräkna kostnaderna för ditt specifika scenario.
På den kostnadsfria nivån har AKS inga kostnader kopplade till distribution, hantering och åtgärder för Kubernetes-klustret. Du betalar bara för de VM-instanser, lagrings- och nätverksresurser som klustret använder. Automatisk skalning av kluster kan avsevärt minska kostnaden för klustret genom att ta bort tomma eller oanvända noder.
Överväg att använda den kostnadsfria nivån för AKS för utvecklingsarbetsbelastningar och använd nivåerna Standard och Premium för produktionsarbetsbelastningar.
Överväg att aktivera AKS-kostnadsanalys för detaljerad klusterinfrastrukturkostnadsallokering av Kubernetes-specifika konstruktioner.

Operativ skicklighet

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i checklistan för Designgranskning för Operational Excellence.

Tänk på följande när du planerar för hanterbarhet:

Hantera AKS-klusterinfrastrukturen via en automatiserad distributionspipeline, till exempel GitHub Actions-arbetsflöden .
Arbetsflödesfilen distribuerar endast infrastrukturen, inte arbetsbelastningen, till det redan befintliga virtuella nätverket och Microsoft Entra-konfigurationen. Genom att distribuera infrastrukturen och arbetsbelastningen separat kan du hantera olika livscykel- och driftproblem.
Betrakta arbetsflödet som en mekanism för att distribuera till en annan region om det uppstår ett regionalt fel. Skapa pipelinen så att du kan distribuera ett nytt kluster i en ny region med parameter- och indataändringar.

Prestandaeffektivitet

Prestandaeffektivitet syftar på arbetsbelastningens förmåga att skala för att effektivt uppfylla användarnas krav. Mer information finns i checklistan för Designgranskning för prestandaeffektivitet.

Tänk på följande när du planerar för skalbarhet:

Blanda inte autoskalning med imperativ eller deklarativ hantering av antalet repliker. Om både användare och en autoskalare försöker ändra antalet repliker kan oväntat beteende inträffa. När HPA är aktiverat minskar du antalet repliker till det minsta antal som du vill distribuera.
En bieffekt av automatisk skalning av poddar är att poddar kan skapas eller avlägsnas ofta när programmet skalar in eller skalar ut. Utför följande åtgärder för att minimera dessa effekter:
- Använd readiness probes för att meddela Kubernetes när en ny podd är redo att acceptera trafik.
- Använd poddstörningsbudgetar för att begränsa hur många poddar som kan tas bort från en tjänst i taget.
Om det finns ett stort antal utgående flöden från mikrotjänsten bör du överväga att använda NAT-gateways (network address translation) för att undvika portuttömning av SNAT (källnätverksadressöversättning).
Multitenant eller andra avancerade arbetsbelastningar kan ha krav på isolering av nodpooler som kräver mer och sannolikt mindre undernät. Mer information finns i Lägga till nodpooler som har unika undernät. Organisationer har olika standarder för sina hub-spoke-implementeringar. Se till att följa organisationens riktlinjer.
Överväg att använda Azure CNI med överläggsnätverk för att spara nätverksadressutrymme.

Nästa steg

Feedback

Var den här sidan till hjälp?