Redigera

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 Services. Ämnena omfattar 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, Microsofts rekommenderade startpunkt för AKS-infrastrukturen. AKS-baslinjen beskriver infrastrukturella funktioner som Microsoft Entra-arbetsbelastnings-ID, begränsningar för ingress och utgående trafik, resursgränser och andra säkra konfigurationer av AKS-infrastruktur. Dessa infrastrukturdetaljer beskrivs inte i det här dokumentet. Vi rekommenderar att du bekantar dig med AKS-baslinjen innan du fortsätter med mikrotjänstinnehållet.

GitHub logo En referensimplementering av den här arkitekturen finns på GitHub.

Arkitektur

Network diagram showing the hub-spoke network with two peered virtual networks and the Azure resources this implementation uses.

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

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

Arbetsflöde

Det här begärandeflödet implementerar designmönstren Publisher-Subscriber, Competing Consumers och Gateway Routing cloud. Meddelandeflödet fortsätter på följande sätt:

  1. En HTTPS-begäran skickas för att schemalägga en drönarhämtning. Begäranden skickas via Azure Application Gateway till inmatningswebbappen, som körs som en mikrotjänst i klustret i AKS.

  2. Inmatningswebbprogrammet skapar ett meddelande och skickar det till Service Bus-meddelandekön.

  3. Serverdelssystemet tilldelar en drönare och meddelar användaren. Arbetsflödet:

    • Förbrukar meddelandeinformation från Service Bus-meddelandekön.
    • Skickar en HTTPS-begäran till mikrotjänsten Leverans, som skickar data till Azure Cache for Redis externa datalagring.
    • Skickar en HTTPS-begäran till Drone Scheduler-mikrotjänsten.
    • Skickar en HTTPS-begäran till mikrotjänsten Package, som skickar data till MongoDB extern datalagring.

  4. En HTTPS GET-begäran används för att returnera leveransstatus. Den här begäran skickas via Application Gateway till mikrotjänsten Leverans.

  5. Leveransmikrotjänsten läser data från Azure Cache for Redis.

Komponenter

Den här arkitekturen använder följande Azure-komponenter:

Azure Kubernetes Service är ett Azure-erbjudande som tillhandahåller ett hanterat Kubernetes-kluster. När du använder AKS hanteras Kubernetes API-servern av Azure. Kubernetes-noderna eller nodpoolerna är tillgängliga och kan hanteras av klusteroperatorn.

Funktionerna i AKS-infrastrukturen som används i den här arkitekturen är:

Virtuella Azure-nätverk är isolerade och mycket säkra miljöer för att köra virtuella datorer och program. Den här referensarkitekturen använder en peered hub-spoke-topologi för virtuella nätverk. Det virtuella hubbnätverket innehåller Azure-brandväggen och Azure Bastion-undernäten. Det virtuella ekernätverket innehåller AKS-systemet och undernäten för användarnodpoolen och Azure Application Gateway-undernätet.

Azure Private Link allokerar specifika privata IP-adresser för åtkomst till Azure Container Registry och Key Vault från privata slutpunkter i AKS-systemet och undernätet för användarnodpoolen.

Azure Application Gateway med brandvägg för webbprogram (WAF) exponerar HTTP(S) vägar till AKS-klustret och belastningsutjämning av webbtrafik till webbprogrammet. Den här arkitekturen använder Azure Application Gateway Ingress Controller (AGIC) som Kubernetes-ingresskontrollant.

Azure Bastion ger säker fjärrskrivbordsprotokoll (RDP) och SSH-åtkomst (Secure Shell) till virtuella datorer i de virtuella nätverken med hjälp av ett säkert socketlager (SSL), utan att behöva exponera de virtuella datorerna via offentliga IP-adresser.

Azure Firewall är en nätverkssäkerhetstjänst som skyddar alla Azure Virtual Network-resurser. Brandväggen tillåter endast godkända tjänster och fullständigt kvalificerade domännamn (FQDN) som utgående trafik.

Extern lagring och andra komponenter:

Azure Key Vault lagrar och hanterar säkerhetsnycklar för AKS-tjänster.

Azure Container Registry lagrar privata containeravbildningar som kan köras i AKS-klustret. AKS autentiserar med Container Registry med hjälp av sin Microsoft Entra-hanterade identitet. Du kan också använda andra containerregister som Docker Hub.

Azure Cosmos DB lagrar data med hjälp av Azure Cosmos DB med öppen källkod för MongoDB. Mikrotjänster är vanligtvis tillståndslösa och skriver sitt tillstånd till externa datalager. Azure Cosmos DB är en NoSQL-databas med API:er med öppen källkod för MongoDB och Cassandra.

Azure Service Bus erbjuder tillförlitliga molnmeddelanden som en tjänst och enkel hybridintegrering. Service Bus stöder asynkrona meddelandemönster som är vanliga med mikrotjänstprogram.

Azure Cache for Redis lägger till ett cachelagringslager i programarkitekturen för att förbättra hastighet och prestanda för tung trafikbelastning.

Azure Monitor samlar in och lagrar mått och loggar, inklusive programtelemetri och Azure-plattforms- och tjänstmått. Du kan använda dessa data för att övervaka programmet, konfigurera aviseringar och instrumentpaneler och utföra rotorsaksanalys av fel.

Andra oss-komponenter (operations support system):

Helm, en pakethanterare för Kubernetes som paketerar Kubernetes-objekt i en enda enhet som du kan publicera, distribuera, version och uppdatera.

Azure Key Vault Secret Store CSI-provider, hämtar hemligheter som lagras i Azure Key Vault och använder CSI-drivrutinsgränssnittet för Secret Store för att montera dem i Kubernetes-poddar.

Flux, en öppen och utökningsbar lösning för kontinuerlig leverans för Kubernetes, som drivs av GitOps Toolkit.

Information om scenario

Exemplet Fabrikam Drone Delivery Shipping App som visas i föregående diagram implementerar de arkitekturkomponenter och metoder som beskrivs i den här artikeln. 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. Medan leveransen pågår kan kunden spåra drönarens plats med en kontinuerligt uppdaterad ETA.

Potentiella användningsfall

Den här lösningen är idealisk för flygplans-, flyg- och flygindustrin.

Rekommendationer

Implementera dessa rekommendationer när du distribuerar avancerade AKS-mikrotjänstarkitekturer.

Application Gateway Ingress Controller (AGIC)

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:

Routning av klientbegäranden till rätt serverdelstjänster ger en enda slutpunkt för klienter och hjälper till att frikoppla klienter från tjänster.

  • Aggregera flera begäranden till en enda begäran för att minska chatten mellan klienten och serverdelen.
  • Avlastning av funktioner som SSL-avslutning, autentisering, IP-begränsningar och klientfrekvensbegränsning eller begränsning från serverdelstjänsterna.

Tillståndet för AKS-klustret översätts till Application Gateway-specifik konfiguration och tillämpas via Azure Resource Manager.

Externa ingresskontrollanter förenklar trafikinmatning i AKS-kluster, förbättrar säkerhet och prestanda och sparar resurser. Den här arkitekturen använder Azure Application Gateway Ingress Controller (AGIC) för ingresskontroll. Att använda Application Gateway för att hantera all trafik eliminerar behovet av en extra lastbalanserare. Eftersom poddar upprättar direkta anslutningar mot Application Gateway minskas antalet nödvändiga hopp, vilket ger bättre prestanda.

Application Gateway har inbyggda funktioner för automatisk skalning, till skillnad från ingresskontrollanter i klustret som måste skalas ut om de förbrukar en oönskad mängd beräkningsresurser. Application Gateway kan utföra layer-7-routning och SSL-avslutning och har TLS (End-to-End Transport Layer Security) integrerat med en inbyggd brandvägg för webbprogram (WAF).

För alternativet AGIC-ingress måste du aktivera CNI-nätverk när du konfigurerar AKS-klustret eftersom Application Gateway distribueras till ett undernät i det virtuella AKS-nätverket. Arbetsbelastningar med flera klientorganisationer, eller ett enda kluster som stöder utvecklings- och testmiljöer, kan kräva fler ingresskontrollanter.

Nätverksprinciper med noll förtroende

Nätverksprinciper anger hur AKS-poddar tillåts kommunicera 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 en nollförtroendeprincip där åtkomst till alla tjänster, enheter, program eller datalagringsplatser kräver explicit konfiguration.

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 skulle gälla för alla poddar som finns i serverdels-dev-namnområdet.

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

När en restriktiv princip är på plats 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 nätverksprincipen på alla poddar i serverdels-dev-namnområdet med en etikett som matchar app.kubernetes.io/component: serverdel. Principen nekar all trafik om den inte kommer från en podd med en etikett som matchar 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

Mer information om Kubernetes-nätverksprinciper och ytterligare exempel på potentiella standardprinciper finns i Nätverksprinciper i Kubernetes-dokumentationen.

Resurskvoter

Resurskvoter är ett sätt för administratörer 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:

  • Beräkningsresurser, till exempel CPU och minne, eller GPU:er.
  • Lagringsresurser, inklusive antalet volymer eller mängden diskutrymme för en viss 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. Klientdelen kan inte svälta serverdelstjänsterna för resurser eller vice versa.

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:

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 självkorrigeringssystem för autonom feedback. Även om du kan skala poddar och noder manuellt minimerar automatisk skalning risken för att tjänster blir resurssvultna 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 autoskalning (CA) skalar antalet noder. Anta att poddar inte kan schemaläggas på grund av resursbegränsningar. klustrets autoskalning etablerar 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 ARM-mallen:

"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 ARM-mallen anger exempel på lägsta och högsta noder för CA:en:

"minCount": 2,
"maxCount": 5,

Automatisk skalning av poddar

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

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

I följande exempel anges resursmått för HPA:

apiVersion: autoscaling/v2beta2
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
        targetAverageUtilization: 60

HPA tittar på faktiska resurser som förbrukas eller andra mått från poddar som körs, men CA:en etablerar noder för poddar som inte har schemalagts ännu. Därför tittar CA på de begärda resurserna enligt vad som anges i poddspecifikationen. Använd belastningstestning för att finjustera dessa värden.

Hälsotillståndsavsökningar

Kubernetes-belastningen balanserar trafik till poddar som matchar en etikettväljare för en tjänst. Endast poddar som har startats och är felfria tar emot trafik. Om en container kraschar tar Kubernetes bort podden och schemalägger en ersättning.

I Kubernetes kan en podd exponera två typer av hälsoavsökningar:

  • Liveness-avsökningen talar om för Kubernetes om en podd har startats och är felfri.
  • Beredskapsavsökningen talar om för Kubernetes om en podd är redo att acceptera begäranden.

Liveness-avsökningarna hanterar poddar som fortfarande körs men som inte är felfria och bör återvinnas. Om till exempel en container som betjänar HTTP-begäranden låser sig kraschar inte containern, men den slutar att hantera begäranden. HTTP-livenessavsökningen slutar svara, vilket informerar Kubernetes om att starta om podden.

Ibland kanske en podd inte är redo att ta emot trafik, även om podden har startats. Till exempel kan programmet som körs i containern utföra initieringsuppgifter. Beredskapsavsökningen 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 tidsgräns som är skräddarsydd specifikt för de kontroller de utför. HPA-formelnycklarna är nästan uteslutande utanför fasen Klar i en podd, så det är viktigt att hälsoavsökningar finns och är korrekta.

Övervakning

I ett mikrotjänstprogram är övervakning av programprestandahantering (APM) avgörande för att identifiera avvikelser, diagnostisera problem och snabbt förstå beroenden mellan tjänster. Application Insights, som är en del av Azure Monitor, tillhandahåller APM-övervakning för liveprogram som skrivits i .NET Core, Node.js, Java och många andra programspråk.

Application Insights:

  • Loggar HTTP-begäranden, inklusive svarstid och resultatkod.
  • Aktiverar distribuerad spårning som standard.
  • Innehåller ett åtgärds-ID i spårningar, så att du kan matcha alla spårningar för en viss åtgärd.
  • Innehåller ofta ytterligare kontextuell information i spårningar.

Om du vill kontextualisera tjänstetelemetri med Kubernetes-världen integrerar du Azure Monitor-telemetri med AKS för att samla in mått från styrenheter, noder och containrar samt container- och nodloggar. Om du använder .NET berikar Application Insights-telemetrin application insights med information om avbildning, container, nod, podd, etikett och replikuppsättning.

Följande diagram visar ett exempel på programberoendekartan som Application Insights genererar för en AKS-telemetrispårning för mikrotjänster:

Example of an Application Insights dependency map for an AKS microservices application.

Mer information om alternativ för instrumentering av vanliga språk för application insights-integrering finns i Programövervakning för Kubernetes.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Skalbarhet

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

  • Kombinera inte autoskalning och imperativ eller deklarativ hantering av antalet repliker. Användare och en autoskalning som båda försöker ändra antalet repliker kan orsaka oväntat beteende. 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, eftersom utskalnings- och inskalningshändelser inträffar. Så här åtgärdar du dessa effekter:

    • Använd beredskapsavsökningar 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.

  • Du kan inte ändra storleken på den virtuella datorn när du har skapat ett kluster, så gör den inledande kapacitetsplaneringen för att välja en lämplig VM-storlek för agentnoderna när du skapar klustret.

  • Flera klientorganisationer eller andra avancerade arbetsbelastningar kan ha krav på isolering av nodpooler som kräver mer och sannolikt mindre undernät. Mer information om hur du skapar nodpooler med unika undernät finns i Lägga till en nodpool med ett unikt undernät. Organisationer har olika standarder för sina hub-spoke-implementeringar. Se till att följa organisationens riktlinjer.

Hanterbarhet

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

  • Hantera AKS-klusterinfrastrukturen via en automatiserad distributionspipeline. Referensimplementeringen för den här arkitekturen innehåller ett GitHub Actions-arbetsflöde som du kan referera till när du skapar din pipeline.

  • Arbetsflödesfilen distribuerar endast infrastrukturen, inte arbetsbelastningen, till det redan befintliga virtuella nätverket och Microsoft Entra-konfigurationen. När du distribuerar infrastruktur och arbetsbelastningar 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.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

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

  • En AKS-podd autentiserar sig själv med hjälp av en arbetsbelastningsidentitet som lagras i Microsoft Entra-ID. Att använda en arbetsbelastningsidentitet är att föredra eftersom det inte kräver någon klienthemlighet.

  • Med hanterade identiteter kan körningsprocessen snabbt hämta Azure Resource Manager OAuth 2.0-token. det finns inget behov av lösenord eller anslutningssträng. I AKS kan du tilldela identiteter till enskilda poddar med hjälp av Microsoft Entra-arbetsbelastnings-ID.

  • Varje tjänst i mikrotjänstprogrammet ska tilldelas en unik arbetsbelastningsidentitet för att underlätta rbac-tilldelningar med minst privilegier. Du bör bara tilldela 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 om hur du konfigurerar och hanterar Kubernetes-tjänstkonto finns i Hantera Kubernetes-tjänstkonton.

  • Alla Azure-tjänster stöder inte autentisering med dataplanet med hjälp av Microsoft Entra-ID. Om du vill lagra autentiseringsuppgifter eller programhemligheter för dessa tjänster, för tjänster från tredje part eller för API-nycklar använder du Azure Key Vault. Azure Key Vault tillhandahåller centraliserad hantering, åtkomstkontroll, kryptering i vila och granskning av 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 projektet secrets-store-csi-driver-provider-azure på GitHub.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

  • I avsnittet Kostnad i Microsoft Azure Well-Architected Framework beskrivs kostnadsöverväganden. Använd Priskalkylatorn för Azure för att beräkna kostnaderna för ditt specifika scenario.

  • AKS har inga kostnader kopplade till distribution, hantering och drift av 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.

  • Information om hur du beräknar kostnaden för de resurser som krävs finns i Container Services-kalkylatorn.

  • Överväg att aktivera AKS-kostnadsanalys för detaljerad klusterinfrastrukturkostnadsallokering av Kubernetes-specifika konstruktioner.

Nästa steg