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 Microsoft rekommenderar 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 bekanta 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

Det här begärandeflödet implementerar designmönstren Publisher-Subscriber, Competing Consumers och Gateway Routing cloud. 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 Cache for Redis externa datalagring
- Skickar en HTTPS-begäran till drone scheduler-mikrotjänsten
- Skickar en HTTPS-begäran till paketets mikrotjänst, som skickar data till MongoDB extern datalagring
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 Cache for Redis.

Komponenter

AKS tillhandahåller ett hanterat Kubernetes-kluster. 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 (RBAC) 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 Container Networking Interface är ett plugin-program som gör det möjligt för containrar att ansluta direkt till ett virtuellt Azure-nätverk, vilket gör att poddar kan ta emot IP-adresser från virtuella Azure-nätverk. I den här arkitekturen möjliggör den integrering med Azure-nätverkstjänster och ger kontroll över trafikflödet.
- Azure Monitor Container Insights är en funktion som ger djup insyn i PRESTANDA och hälsa för AKS-kluster. I den här arkitekturen samlar den in mått, loggar och telemetri för övervakning och diagnostik.
- 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 förenklar hur du exponerar dina program för Internet med hjälp av HTTP/HTTPS-trafik. Den tillhandahåller en förkonfigurerad NGINX-ingresskontrollant för AKS. I den här arkitekturen hanterar den trafikroutning till tjänster och möjliggör offentlig exponering av arbetsbelastningar.
- 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 fullständigt kvalificerade domännamn (FQDN) som utgående trafik.
Azure Private Link är en Azure-hanterad tjänst som möjliggör privat anslutning till PaaS-erbjudanden (Plattform som en tjänst) i Azure 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 mycket säkra miljöer för program som körs och virtuella datorer. 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, medan ekernätverket innehåller undernät för AKS-system- och användarnodpooler tillsammans med Application Gateway-undernätet.

Extern lagring och andra komponenter

Azure Cache for Redis är en Azure-hanterad tjänst som lägger till ett cachelagringslager med höga prestanda i program. I den här arkitekturen använder leveransmikrotjänsten Azure Cache for Redis som tillståndsarkiv och sidocache för att förbättra hastigheten och svarstiden under tung trafik.
Azure 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. Andra register som Docker Hub kan också användas.
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 Cosmos DB for MongoDB 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 används av mikrotjänster för åtkomst till Azure Cosmos DB och Azure Cache for 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 den övervakning av programmet, aviseringar, instrumentpaneler och rotorsaksanalys för fel i AKS och integrerade tjänster.
Azure 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 åtgärder stöder systemkomponenter

Flux är en Azure-stödd, öppen och utökningsbar lösning för 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 Cache for 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-gatewaytillägg. En jämförelse av ingressalternativ i AKS finns i Ingress i AKS. Application Gateway för containrar är en utveckling av Application Gateway-ingresskontrollanten och ger extra funktioner som trafikdelning och viktad resursallokeringsbelastningsutjämning.

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 Cache for 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 Cache for 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. Medan leveransen pågår kan kunden spåra drönarens plats och se en kontinuerligt uppdaterad uppskattad ankomsttid.

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 i Azures privata domännamnssystemzoner för värdnamnsmatchning av mikrotjänster. Konfigurera den privata IP-adressen eller värdnamnet för ingresskontrollanten som serverdelspooladress 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.

Du bör 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. Alla mikrotjänster ska konfigureras med anpassade domännamn och SSL-certifikat så att kommunikation mellan mikrotjänster i AKS-klustret också skyddas med hjälp av SSL.

Multitenantarbetsbelastningar eller ett enda kluster som stöder utvecklings- och testmiljöer kan kräva fler ingresskontrollanter. 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.

Noll förtroende nätverksprinciper

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 principen Noll förtroende, där åtkomst till alla tjänster, enheter, program eller datalagringsplatser kräver explicit konfiguration.

En strategi för att implementera en Noll förtroende-princip ä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: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

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 nätverksprincipen på alla poddar i backend-dev namnområdet som har en etikett som matchar app.kubernetes.io/component: backend. Principen nekar all trafik om den inte kommer från en podd som har 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 fler exempel på potentiella standardprinciper finns i Nätverksprinciper i Kubernetes-dokumentationen.

Azure tillhandahåller tre nätverksprincipmotorer för att framtvinga nätverksprinciper:

Cilium för AKS-kluster som använder Azure CNI som drivs av Cilium
Azure Network Policy Manager
Calico, en nätverks- och nätverkssäkerhetslösning med öppen källkod

Vi rekommenderar att du använder Cilium som nätverksprincipmotor.

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 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 använda alla resurser för serverdelstjänsterna och serverdelen kan inte använda alla resurser för klientdelstjä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:

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. 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

Kluster autoskalning (CA) skalar antalet noder. Om poddar inte kan schemaläggas på grund av resursbegränsningar etablerar autoskalning av kluster 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 klustrets autoskalning:

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.

CA och HPA fungerar 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/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 tittar på faktiska resurser som förbrukas eller andra mått från poddar som körs. Ca:en etablerar 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 händelsedriven autoskalning

Med tillägget Kubernetes Event Driven Autoscaler (KEDA) kan händelsedriven autoskalning 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 ut arbetsflödets mikrotjänst beroende på Service Bus-ködjupet och baserat på mikrotjänstutdata för inmatning. En lista över KEDA-skalare för Azure-tjänster finns i Integreringar med KEDA på AKS.

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.

Kubernetes definierar tre typer av hälsoavsökningar som en podd kan exponera:

Beredskapsavsökningen talar om för Kubernetes om podden är redo att ta emot begäranden.
Liveness-avsökningen talar om för Kubernetes om en podd ska tas bort och en ny instans startas.
Startavsökningen talar om för Kubernetes om podden har startats.

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 aviserar Kubernetes 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 timeout som är skräddarsydd specifikt för de kontroller som de utför. HPA-formeln förlitar sig på poddens redo fas, 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, en funktion i Azure Monitor, tillhandahåller APM-övervakning för liveprogram som skrivits i .NET Core, Node.js, Java och många andra programspråk.

Azure tillhandahåller olika mekanismer för övervakning av mikrotjänstarbetsbelastningar:

Hanterad Prometheus för metrikinsamling. Använd Prometheus för att övervaka och varna om prestanda för infrastruktur och arbetsbelastningar.
Azure Monitor-hanterad tjänst för Prometheus och containerinsikter fungerar tillsammans för fullständig övervakning av kubernetes-miljön.
Hanterad Grafana för kluster- och mikrotjänstvisualisering.

Om du vill kontextualisera tjänsttelemetri i Kubernetes integrerar du Azure Monitor-telemetri med AKS för att samla in mått från kontrollanter, noder, containrar och container- och nodloggar. Du kan integrera Application Insights med AKS utan kodändringar.

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. Mer information finns iWell-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 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 finns i Hantera Kubernetes-tjänstkonton.
Inte alla Azure-tjänster stöder användning av Microsoft Entra-ID för autentisering med dataplan. 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. 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 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.
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 körningshot och andra säkerhetsfunktioner.

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.

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 när programmet skalar in eller skalas ut. Utför följande åtgärder för att minimera 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.
Om det finns ett stort antal utgående flöden från mikrotjänsten kan du överväga att använda gatewayer för nätverksadressöversättning för att undvika portöversättning av källnätverksadress.
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 med 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 CNI med överläggsnätverk för att spara nätverksadressutrymme.

Nästa steg

Feedback

Var den här sidan till hjälp?