AKS-arkitektur (Advanced Azure Kubernetes Service)

Application Gateway
Container Registry
Kubernetes Service
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 poddskalning och distribuerad spårning i ett mikrotjänstbaserat program.

Den här arkitekturen bygger på AKS-baslinjearkitekturen, Microsofts rekommenderade startpunkt för AKS-infrastruktur. AKS-baslinjen innehåller information om infrastrukturfunktioner som Azure Active Directory-poddidentitet (Azure AD), ingress- och utgående begränsningar, resursgränser och andra säkra AKS-infrastrukturkonfigurationer. Den här infrastrukturinformationen tas inte upp i det här dokumentet. Vi rekommenderar att du bekantar dig med AKS-baslinjen innan du fortsätter med mikrotjänstinnehållet.

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

Nätverksdiagram som visar nav-eker-nätverket med två peer-ade virtuella nätverk och de Azure-resurser som implementeringen använder.

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

Komponenter

I den här arkitekturen används 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.

De AKS-infrastrukturfunktioner 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 (VM) och program. I den här referensarkitekturen används en peer-ut peer-eker-topologi för virtuella nätverk. Det virtuella hubbnätverket innehåller Azure-brandväggen Azure Bastion undernät. Det virtuella ekernätverket innehåller undernäten för AKS-systemet och användarnodpoolen och Azure Application Gateway undernätet.

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

Azure Application Gateway med brandvägg för webbaserade program (WAF) exponerar HTTP(S)-vägar för AKS-klustret och belastningsutjämnar webbtrafik till webbprogrammet. Den här arkitekturen Azure Application Gateway Ingress Controller (AGIC) som Kubernetes ingress-kontrollant.

Azure Bastion ger säker RDP(Remote Desktop Protocol) och SSH-åtkomst (Secure Shell) till virtuella datorer i de virtuella nätverken med hjälp av ett säkert socketlager (SSL), utan att de virtuella datorerna behöver exponeras 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 hjälp Container Registry azure AD-hanterad identitet. Du kan också använda andra containerregister som Docker Hub.

Azure Cosmos DB data med hjälp av API:et för 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 har stöd för asynkrona meddelandemönster som är gemensamma för 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 komponenter för driftsstödsystem (OSS):

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 CSI-providernSecret Store 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.

Flöde för begäran

Exemplet Fabrikam Drone Delivery Shipping App som visas i föregående diagram implementerar arkitekturkomponenterna och metoderna som beskrivs i den här artikeln. I det här exemplet hanterar Fabrikam, Inc., ett fiktivt företag, en flotta med drönarplan. 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 backend-systemet 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 BERÄKNAD.

Det här begärandeflödet implementerar molndesignmönstren Publisher-Subscriber,Konkurrerandekonsumenter och Gateway Routing. Meddelandeflödet fortsätter enligt följande:

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

  2. Inmatningswebbappen genererar ett meddelande och skickar det till Service Bus kön.

  3. Backend-systemet tilldelar en drönare och meddelar användaren. Arbetsflödet:

    • Använder meddelandeinformation från den Service Bus meddelandekön.
    • Skickar en HTTPS-begäran till mikrotjänsten Delivery som skickar data till Azure Cache for Redis extern datalagring.
    • Skickar en HTTPS-begäran till Drone Scheduler-mikrotjänsten.
    • Skickar en HTTPS-begäran till mikrotjänsten Package som skickar data till den externa MongoDB-datalagringen.

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

  5. Mikrotjänsten för leverans läser data från Azure Cache for Redis.

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 ingress-kontrollanten hanterar de flesta API-gatewayfunktioner genom att:

Routning av klientbegäranden till rätt servertjänst 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 trafik mellan klienten och backend.
  • Avlastningsfunktioner som SSL-avslutning, autentisering, IP-begränsningar och begränsning av klientfrekvens eller begränsning från servertjänster.

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

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

Application Gateway har inbyggda funktioner för automatisk skalning, till skillnad från in-klusteringressstyrenheter 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 webbaserade program (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 för flera innehavare, eller ett enda kluster som stöder utvecklings- och testmiljöer, kan kräva fler ingress-styrenheter.

Principer för nollförtroende för nätverk

Nätverksprinciper anger hur AKS-poddar får kommunicera med varandra och med andra nätverksslutpunkter. Som standard tillåts all in- 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 tjänster, enheter, program eller datalager kräver explicit konfiguration.

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

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

När en begränsande princip är på plats börjar du definiera specifika nätverksregler som tillåter trafik till och från varje podd i mikrotjänsten. I följande exempel tillämpas nätverksprincipen på alla poddar i namnområdet backend-dev med en etikett som app.kubernetes.io/component: backend. Principen nekar all trafik om den inte kommer från en podd med en etikett som 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 i ett namnområde och använda dem för att ange begränsningar för:

  • Beräkningsresurser, till exempel processor och minne, eller GPU:er.
  • Storage resurser, 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 ackumulerade summan av resursbegäranden eller resursgränser har passerat den tilldelade kvoten lyckas inga ytterligare distributioner.

Resurskvoterna säkerställer att den totala uppsättningen poddar som tilldelats namnområdet inte får överskrida resurskvoten för namnområdet. Frontend-tjänsten kan inte spara resurser eller tvärtom på backend-tjänsterna.

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

I följande exempel visas en poddspecifikt som anger begäranden och begränsningar för resurskvoter:

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

Mer information om resurskvoter finns i:

Automatisk skalning

Kubernetes stöder autoskalning för att öka antalet poddar som allokerats till en distribution eller öka noderna i klustret för att öka det totala antalet tillgängliga beräkningsresurser. Autoskalning är ett själv korrigerande autonomt feedbacksystem. Även om du kan skala poddar och noder manuellt, minimerar autoskalning risken för att tjänster blir resurssvultade vid höga belastningar. En strategi för automatisk skalning måste ta hänsyn till både poddar och noder.

Automatisk skalning av kluster

Autoskalning av kluster (CA) skalar antalet noder. Anta att poddar inte kan schemaläggas på grund av resursbegränsningar. autoskalning av kluster till att skapa 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. Certifikatutfärdaren söker med några sekunder efter väntande poddar eller tomma noder och skalar AKS-klustret på lämpligt 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å minsta och högsta noder för CA:en:

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

Automatisk skalning av poddar

Horizontal Pod Autoscaler (HPA) skalar poddar baserat på observerad processor, minne eller anpassade mått. Om du vill konfigurera horisontell poddskalning anger du målmått och det lägsta och högsta 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 autoskalningsalternativen i ditt AKS-kluster. HPA skalar programmet, medan CA 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 CERTIFIKATutfärdaren tiller noder för poddar som inte har schemalagts ännu. Certifikatutfärdaren tittar därför på de begärda resurserna, som anges i poddspecifikationen. Använd belastningstestning för att finjustera dessa värden.

Hälsotillståndsavsökningar

Kubernetes lastbalanserar 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ökning:

  • Liveavsö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.

Liveavsökningarna hanterar poddar som fortfarande körs men som inte är felhälsosamma och som bör återanvändas. Om till exempel en container som betjänar HTTP-begäranden låser sig kraschar inte containern, men den slutar att betjäna 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 startades korrekt. Programmet som körs i containern kan till exempel 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 skräddarsytts specifikt för de kontroller som de utför. HPA-formelnycklarna nästan uteslutande utanför ready-fasen på 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 upptäcka 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 live-program 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 sammanhangsbaserad information i spårningar.

För att kontextualisera telemetri för tjänster med Kubernetes-världen integrerar du Azure Monitor-telemetri med AKS för att samla in mått från kontrollanter, noder och containrar samt container- och nodloggar. Om du använder .NET berikar biblioteket Application Insights for Kubernetes Application Insights-telemetri 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 telemetrispårning för AKS-mikrotjänster:

Exempel på ett Program Insights beroendemappning för ett AKS-mikrotjänstprogram.

Mer information om alternativ för att instrumentera vanliga språk för Application Insights-integrering finns i Programövervakning för Kubernetes.

Skalbarhetsöverväganden

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

  • Kombinera inte autoskalning och imperativ eller deklarativ hantering av antalet repliker. Både användare och autoskalning som försöker ändra antalet repliker kan orsaka oväntade resultat. När HPA är aktiverat minskar du antalet repliker till det lägsta antal som du vill distribuera.

  • En sidoeffekt av automatisk poddskalning är att poddar kan skapas eller avlägsnas ofta, allt eftersom utskalning och inskalning sker. 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 ta emot trafik.
    • Använd poddavbrottsbudgetar för att begränsa hur många poddar som kan tas bort från en tjänst i taget.

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

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

Överväganden för hantering

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

  • Hantera AKS-klusterinfrastrukturen via en automatiserad distributionspipeline. Referensimplementering för den här arkitekturen ger 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 befintliga virtuella nätverket och Azure AD-konfigurationen. Genom att distribuera infrastruktur och arbetsbelastning separat kan du hantera olika livscykel- och driftsproblem.

  • Överväg ditt arbetsflöde som en mekanism för att distribuera till en annan region om det uppstår ett regionalt haveri. Skapa pipelinen så att du kan distribuera ett nytt kluster i en ny region med parameter- och indataändringar.

Säkerhetsöverväganden

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

  • En AKS-podd autentiserar sig själv med hjälp av antingen en hanterad identitet som lagras i Azure AD eller ett Azure AD-tjänsthuvudnamn tillsammans med en klienthemlighet. Det är bättre att använda en poddidentitet eftersom det inte krävs någon klienthemlighet.

  • Med hanterade identiteter kan den körande processen snabbt komma Azure Resource Manager OAuth 2.0-tokens; det finns inget behov av lösenord eller anslutningssträngar. I AKS kan du tilldela identiteter till enskilda poddar med hjälp Azure Active Directory poddidentitet (Azure AD).

  • Varje tjänst i mikrotjänstprogrammet ska tilldelas en unik poddidentitet för att underlätta minsta privilegierade RBAC-tilldelningar. Du bör endast tilldela identiteter till tjänster som kräver dem.

  • I de fall där en programkomponent kräver Kubernetes API-åtkomst, se till att programpoddar är konfigurerade för att använda ett tjänstkonto med lämplig begränsad API-åtkomst. Mer information om hur du konfigurerar och hanterar Ett Konto för Kubernetes-tjänster finns i Hantera Kubernetes-tjänstkonton.

  • Alla Azure-tjänster stöder inte dataplansautentisering med hjälp av Azure AD. 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. Key Vault 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 hemligheter precis som en vanlig volym. Mer information finns i projektet secrets-store-csi-driver-provider-azure på GitHub.

Prissättning

Nästa steg