Arkitektur för mikrotjänster i Azure Kubernetes Service

Den här referensarkitekturen visar ett mikrotjänstprogram som distribuerats till Azure Kubernetes Service (AKS). Den beskriver en grundläggande AKS-konfiguration som kan vara startpunkten för de flesta distributioner. Den här artikeln förutsätter grundläggande kunskaper om Kubernetes. Artikeln fokuserar främst på infrastruktur och DevOps-överväganden för att köra en mikrotjänstarkitektur på AKS. Vägledning om hur du utformar mikrotjänster finns i Skapa mikrotjänster i Azure.

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

Arkitektur

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

Om du föredrar att se ett mer avancerat mikrotjänstexempel som bygger på AKS-baslinjearkitekturen kan du läsa Avancerad Azure Kubernetes Service-mikrotjänstarkitektur (AKS)

Workflow

Arkitekturen består av följande komponenter.

Azure Kubernetes Service (AKS). AKS är ett hanterat Kubernetes-kluster som finns i Azure-molnet. Azure hanterar Kubernetes API-tjänsten och du behöver bara hantera agentnoderna.

Virtuellt nätverk. Som standard skapar AKS ett virtuellt nätverk som agentnoder är anslutna till. Du kan skapa det virtuella nätverket först för mer avancerade scenarier, vilket gör att du kan styra saker som konfiguration av undernät, lokal anslutning och IP-adressering. Mer information finns i Konfigurera avancerade nätverk i Azure Kubernetes Service (AKS).

Ingress. En ingressserver exponerar HTTP(S) vägar till tjänster i klustret. Mer information finns i avsnittet API Gateway nedan.

Azure Load Balancer. När du har skapat ett AKS-kluster är klustret redo att använda lastbalanseraren. När NGINX-tjänsten har distribuerats konfigureras lastbalanseraren sedan med en ny offentlig IP-adress som frontar ingresskontrollanten. På så sätt dirigerar lastbalanseraren internettrafik till ingressen.

Externa datalager. Mikrotjänster är vanligtvis tillståndslösa och skrivtillstånd till externa datalager, till exempel Azure SQL Database eller Azure Cosmos DB.

Microsoft Entra-ID. AKS använder en Microsoft Entra-identitet för att skapa och hantera andra Azure-resurser, till exempel Azure-lastbalanserare. Microsoft Entra-ID rekommenderas också för användarautentisering i klientprogram.

Azure Container Registry. Använd Container Registry för att lagra privata Docker-avbildningar som distribueras till klustret. AKS kan autentisera med Container Registry med hjälp av dess Microsoft Entra-identitet. AKS kräver inte Azure Container Registry. Du kan använda andra containerregister, till exempel Docker Hub. Se bara till att containerregistret matchar eller överskrider serviceavtalet (SLA) för din arbetsbelastning.

Azure Pipelines. Azure Pipelines ingår i Azure DevOps Services och kör automatiserade versioner, tester och distributioner. Du kan också använda CI/CD-lösningar från tredje part, till exempel Jenkins.

Helm. Helm är pakethanterare för Kubernetes, ett sätt att paketera och generalisera Kubernetes-objekt i en enda enhet som kan publiceras, distribueras, versionshanteras och uppdateras.

Azure Monitor. Azure Monitor samlar in och lagrar mått och loggar, programtelemetri och plattformsmått för Azure-tjänsterna. Använd dessa data för att övervaka programmet, konfigurera aviseringar, instrumentpaneler och utföra rotorsaksanalys av fel. Azure Monitor integreras med AKS för att samla in mått från styrenheter, noder och containrar.

Överväganden

Designa

Den här referensarkitekturen fokuserar på mikrotjänstarkitekturer, även om många av de rekommenderade metoderna gäller för andra arbetsbelastningar som körs på AKS.

Microservices

En mikrotjänst är en löst kopplad, oberoende distribuerad kodenhet. Mikrotjänster kommunicerar vanligtvis via väldefinierade API:er och kan identifieras via någon form av tjänstidentifiering. Tjänsten ska alltid kunna nås även när poddarna flyttas runt. Kubernetes Service-objektet är ett naturligt sätt att modellera mikrotjänster i Kubernetes.

API-gateway

API-gatewayer är ett allmänt designmönster för mikrotjänster. En API-gateway finns mellan externa klienter och mikrotjänsterna. Den fungerar som en omvänd proxy och dirigerar begäranden från klienter till mikrotjänster. Den kan också utföra olika övergripande uppgifter som autentisering, SSL-avslutning och hastighetsbegränsning. Mer information finns i:

• Använda API-gatewayer i mikrotjänster
• Välja en gateway-teknik

I Kubernetes hanteras funktionerna i en API-gateway främst av en ingresskontrollant. Övervägandena beskrivs i avsnittet Ingress .

Datalagring

I en mikrotjänstarkitektur bör tjänsterna inte dela datalagringslösningar. Varje tjänst bör hantera sin egen datauppsättning för att undvika dolda beroenden mellan tjänster. Dataseparation hjälper till att undvika oavsiktlig koppling mellan tjänster, vilket kan inträffa när tjänster delar samma underliggande datascheman. När tjänster hanterar sina egna datalager kan de också använda rätt datalager för sina specifika krav.

Mer information finns i Designa mikrotjänster: Dataöverväganden.

Undvik att lagra beständiga data i lokal klusterlagring eftersom det binder data till noden. Använd i stället en extern tjänst som Azure SQL Database eller Azure Cosmos DB. Ett annat alternativ är att montera en beständig datavolym till en lösning med hjälp av Azure Disks eller Azure Files.

Mer information finns i Lagringsalternativ för program i Azure Kubernetes Service.

Serviceobjekt

Kubernetes Service-objektet innehåller en uppsättning funktioner som matchar mikrotjänstkraven för tjänstidentifiering:

• IP-adress. Tjänstobjektet tillhandahåller en statisk intern IP-adress för en grupp poddar (ReplicaSet). När poddar skapas eller flyttas runt kan tjänsten alltid nås på den här interna IP-adressen.

• Belastningsutjämning. Trafik som skickas till tjänstens IP-adress lastbalanseras till poddarna.

• Tjänstidentifiering. Tjänster tilldelas interna DNS-poster av Kubernetes DNS-tjänsten. Det innebär att API-gatewayen kan anropa en serverdelstjänst med hjälp av DNS-namnet. Samma mekanism kan användas för tjänst-till-tjänst-kommunikation. DNS-posterna ordnas efter namnområde, så om dina namnområden motsvarar avgränsade kontexter mappas DNS-namnet för en tjänst naturligt till programdomänen.

Följande diagram visar den konceptuella relationen mellan tjänster och poddar. Den faktiska mappningen till slutpunkts-IP-adresser och portar görs av kube-proxy, Kubernetes-nätverksproxyn.

Ingress

I Kubernetes kan ingresskontrollanten implementera API Gateway-mönstret. I så fall fungerar ingress- och ingresskontrollanten tillsammans för att tillhandahålla följande funktioner:

• Dirigera klientbegäranden till rätt serverdelstjänster. Den här routningen ger en enda slutpunkt för klienter och hjälper till att frikoppla klienter från tjänster.

• Aggregera flera begäranden i en enda begäran för att minska chattigheten mellan klienten och serverdelen.

• Avlasta funktioner från serverdelstjänsterna, till exempel SSL-avslutning, autentisering, IP-begränsningar eller begränsning av klientfrekvens (begränsning).

Ingress abstraherar konfigurationsinställningarna för en proxyserver. Du behöver också en ingresskontrollant som tillhandahåller den underliggande implementeringen av ingressen. Det finns ingresskontrollanter för bland annat Nginx, HAProxy, Traefik och Azure Application Gateway.

Ingress-resursen kan uppfyllas av olika tekniker. För att fungera tillsammans måste de distribueras som ingresskontrollant i klustret. Den fungerar som gränsrouter eller omvänd proxy. En omvänd proxyserver är en potentiell flaskhals eller en felpunkt, så distribuera alltid minst två repliker för hög tillgänglighet.

Att konfigurera proxyservern kräver ofta komplexa filer, vilket kan vara svårt att finjustera om du inte är expert. Därför ger ingresskontrollanten en fin abstraktion. Ingresskontrollanten har också åtkomst till Kubernetes-API:et, så att den kan fatta intelligenta beslut om routning och belastningsutjämning. Till exempel kringgår Nginx-ingresskontrollanten kube-proxy-nätverksproxyn.

Om du däremot behöver fullständig kontroll över inställningarna kanske du vill kringgå den här abstraktionen och konfigurera proxyservern manuellt. Mer information finns i Distribuera Nginx eller HAProxy till Kubernetes.

Information om belastningsutjämningstjänster i Azure finns i Översikt över alternativ för belastningsutjämning i Azure.

TLS/SSL-kryptering

I vanliga implementeringar används ingresskontrollanten för SSL-avslutning. Som en del av distributionen av ingresskontrollanten måste du därför skapa ett TLS-certifikat. Använd endast självsignerade certifikat i utvecklings-/testsyfte. Mer information finns i Skapa en HTTPS-ingresskontrollant och använd dina egna TLS-certifikat på Azure Kubernetes Service (AKS).

För produktionsarbetsbelastningar hämtar du signerade certifikat från betrodda certifikatutfärdare (CA). Information om hur du genererar och konfigurerar Let's Encrypt-certifikatfinns i Skapa en ingresskontrollant med en statisk offentlig IP-adress i Azure Kubernetes Service (AKS).

Du kan också behöva rotera dina certifikat enligt organisationens principer. Mer information finns i Rotera certifikat i Azure Kubernetes Service (AKS).

Namnområden

Använd namnområden för att organisera tjänster i klustret. Varje objekt i ett Kubernetes-kluster tillhör ett namnområde. När du skapar ett nytt objekt hamnar det som standard i default namnområdet. Men det är en bra idé att skapa namnområden som är mer beskrivande för att organisera resurserna i klustret.

För det första hjälper namnrymder till att förhindra namngivningskollisioner. När flera team distribuerar mikrotjänster till samma kluster, med eventuellt hundratals mikrotjänster, blir det svårt att hantera om alla går in i samma namnområde. Dessutom kan du med namnrymder:

• Använd resursbegränsningar för ett namnområde, så att den totala uppsättningen poddar som tilldelats till namnområdet inte får överskrida resurskvoten för namnområdet.

• Tillämpa principer på namnområdesnivå, inklusive RBAC och säkerhetsprinciper.

För en mikrotjänstarkitektur bör du överväga att organisera mikrotjänsterna i avgränsade kontexter och skapa namnområden för varje begränsad kontext. Till exempel kan alla mikrotjänster som är relaterade till den avgränsade kontexten "Order Fulfillment" gå till samma namnområde. Du kan också skapa ett namnområde för varje utvecklingsteam.

Placera verktygstjänster i sitt eget separata namnområde. Du kan till exempel distribuera Elasticsearch eller Prometheus för klusterövervakning eller Tiller för Helm.

Hälsotillståndsavsökningar

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

• Beredskapsavsökning: Meddelar Kubernetes om podden är redo att ta emot begäranden.

• Liveness-avsökning: Meddelar Kubernetes om en podd ska tas bort och en ny instans startas.

När du tänker på avsökningar är det bra att komma ihåg hur en tjänst fungerar i Kubernetes. En tjänst har en etikettväljare som matchar en uppsättning (noll eller fler) poddar. Kubernetes-belastningen balanserar trafik till poddarna som matchar väljaren. Endast poddar som har startats och är felfria tar emot trafik. Om en container kraschar dödar Kubernetes podden och schemalägger en ersättning.

Ibland kanske en podd inte är redo att ta emot trafik, även om podden har startats. Det kan till exempel finnas initieringsuppgifter där programmet som körs i containern läser in saker i minnet eller läser konfigurationsdata. Om du vill ange att en podd är felfri men inte redo att ta emot trafik definierar du en beredskapsavsökning.

Liveness-avsökningar hanterar det fall där en podd fortfarande körs, men är inte felfri och bör återvinnas. Anta till exempel att en container hanterar HTTP-begäranden men låser sig av någon anledning. Containern kraschar inte, men den har slutat hantera alla begäranden. Om du definierar en HTTP-livenessavsökning slutar avsökningen att svara och det informerar Kubernetes om att starta om podden.

Här följer några saker att tänka på när du utformar avsökningar:

• Om koden har lång starttid finns det en risk att en liveness-avsökning rapporterar fel innan starten är klar. Om du vill förhindra det här avsökningsfelet använder du inställningen initialDelaySeconds , vilket gör att avsökningen inte startar.

• En liveness-avsökning hjälper inte om det inte är troligt att omstarten av podden återställer den till ett felfritt tillstånd. Du kan använda en liveness-avsökning för att minimera minnesläckor eller oväntade dödlägen, men det är ingen idé att starta om en podd som omedelbart kommer att misslyckas igen.

• Ibland används beredskapsavsökningar för att kontrollera beroende tjänster. Om en podd till exempel har ett beroende av en databas kan avsökningen kontrollera databasanslutningen. Den här metoden kan dock skapa oväntade problem. En extern tjänst kan vara tillfälligt otillgänglig av någon anledning. Det gör att beredskapsavsökningen misslyckas för alla poddar i tjänsten, vilket gör att alla tas bort från belastningsutjämningen och därmed skapar sammanhängande fel uppströms. En bättre metod är att implementera återförsökshantering i tjänsten, så att tjänsten kan återställas korrekt från tillfälliga fel.

Resursbegränsningar

Resurskonkurration kan påverka tillgängligheten för en tjänst. Definiera resursbegränsningar för containrar så att en enda container inte kan överbelasta klusterresurserna (minne och CPU). För icke-containerresurser, till exempel trådar eller nätverksanslutningar, bör du överväga att använda bulkhead-mönstret för att isolera resurser.

Använd resurskvoter för att begränsa det totala antalet resurser som tillåts för ett namnområde. På så sätt kan klientdelen inte svälta serverdelstjänsterna för resurser eller vice versa.

Säkerhet

Rollbaserad åtkomstkontroll (RBAC)

Både Kubernetes och Azure har mekanismer för rollbaserad åtkomstkontroll (RBAC):

• Azure RBAC styr åtkomsten till resurser i Azure, inklusive möjligheten att skapa nya Azure-resurser. Behörigheter kan tilldelas till användare, grupper eller tjänstens huvudnamn. (Ett huvudnamn för tjänsten är en säkerhetsidentitet som används av program.)

• Kubernetes RBAC styr behörigheter till Kubernetes API. Att till exempel skapa poddar och visa poddar är åtgärder som kan auktoriseras (eller nekas) till en användare via Kubernetes RBAC. Om du vill tilldela Kubernetes-behörigheter till användare skapar du roller och rollbindningar:

  • En roll är en uppsättning behörigheter som gäller inom ett namnområde. Behörigheter definieras som verb (hämta, uppdatera, skapa, ta bort) för resurser (poddar, distributioner osv.).

  • Ett Rollbindning tilldelar användare eller grupper till en roll.

  • Det finns också ett ClusterRole-objekt, som är som en roll men som gäller för hela klustret, i alla namnområden. Om du vill tilldela användare eller grupper till en ClusterRole skapar du en ClusterRoleBinding.

AKS integrerar dessa två RBAC-mekanismer. När du skapar ett AKS-kluster kan du konfigurera det så att det använder Microsoft Entra-ID för användarautentisering. Mer information om hur du konfigurerar detta finns i Integrera Microsoft Entra-ID med Azure Kubernetes Service.

När detta har konfigurerats måste en användare som vill komma åt Kubernetes API (till exempel via kubectl) logga in med sina Microsoft Entra-autentiseringsuppgifter.

Som standard har en Microsoft Entra-användare ingen åtkomst till klustret. För att bevilja åtkomst skapar klusteradministratören rollbindningar som refererar till Microsoft Entra-användare eller -grupper. Om en användare inte har behörighet för en viss åtgärd misslyckas den.

Hur har klusteradministratören behörighet att skapa rollbindningarna i första hand om användarna inte har någon åtkomst som standard? Ett AKS-kluster har faktiskt två typer av autentiseringsuppgifter för att anropa Kubernetes API-servern: klusteranvändare och klusteradministratör. Autentiseringsuppgifterna för klusteradministratören ger fullständig åtkomst till klustret. Azure CLI-kommandot az aks get-credentials --admin laddar ned autentiseringsuppgifterna för klusteradministratören och sparar dem i kubeconfig-filen. Klusteradministratören kan använda den här kubeconfig för att skapa roller och rollbindningar.

I stället för att hantera Kubernetes-klusterroll och rollbindningsobjekt internt i Kubernetes, är det bättre att använda Azure RBAC för Kubernetes-auktorisering. Detta möjliggör enhetlig hantering och åtkomstkontroll över Azure-resurser, AKS- och Kubernetes-resurser. Dessa Azure RBAC-rolltilldelningar kan riktas mot klustret eller namnrymderna i klustret för mer detaljerad åtkomstkontroll. Azure RBAC stöder en begränsad uppsättning standardbehörigheter och du kan kombinera den med den interna Kubernetes-mekanismen för att hantera roll- och rollbindningar för att stödja avancerade eller mer detaljerade åtkomstmönster. När det är aktiverat verifieras Microsoft Entra-huvudkonton exklusivt av Azure RBAC medan vanliga Kubernetes-användare och tjänstkonton verifieras exklusivt av Kubernetes RBAC.

Eftersom autentiseringsuppgifterna för klusteradministratören är så kraftfulla använder du Azure RBAC för att begränsa åtkomsten till dem:

• "Administratörsrollen för Azure Kubernetes-tjänstkluster" har behörighet att ladda ned autentiseringsuppgifterna för klusteradministratören. Endast klusteradministratörer ska tilldelas till den här rollen.

• "Användarrollen för Azure Kubernetes-tjänstkluster" har behörighet att ladda ned autentiseringsuppgifterna för klusteranvändaren. Användare som inte är administratörer kan tilldelas till den här rollen. Den här rollen ger inte några särskilda behörigheter för Kubernetes-resurser i klustret – den tillåter bara att en användare ansluter till API-servern.

När du definierar dina RBAC-principer (både Kubernetes och Azure) bör du tänka på rollerna i din organisation:

• Vem kan skapa eller ta bort ett AKS-kluster och ladda ned administratörsautentiseringsuppgifterna?
• Vem kan administrera ett kluster?
• Vem kan skapa eller uppdatera resurser i ett namnområde?

Det är en bra idé att begränsa Kubernetes RBAC-behörigheter efter namnområde med hjälp av roller och rollbindningar i stället för ClusterRoles och ClusterRoleBindings.

Slutligen är det frågan om vilka behörigheter AKS-klustret har för att skapa och hantera Azure-resurser, till exempel lastbalanserare, nätverk eller lagring. För att autentisera sig med Azure-API:er använder klustret ett Microsoft Entra-tjänsthuvudnamn. Om du inte anger ett huvudnamn för tjänsten när du skapar klustret skapas ett automatiskt. Det är dock en bra säkerhetspraxis att skapa tjänstens huvudnamn först och tilldela den minimala RBAC-behörigheten. Mer information finns i Tjänstens huvudnamn med Azure Kubernetes Service.

Autentiseringsuppgifter för hantering av hemligheter och program

Program och tjänster behöver ofta autentiseringsuppgifter som gör att de kan ansluta till externa tjänster som Azure Storage eller SQL Database. Utmaningen är att skydda dessa autentiseringsuppgifter och inte läcka dem.

För Azure-resurser är ett alternativ att använda hanterade identiteter. Tanken med en hanterad identitet är att ett program eller en tjänst har en identitet som lagras i Microsoft Entra-ID och använder den här identiteten för att autentisera med en Azure-tjänst. Programmet eller tjänsten har ett tjänsthuvudnamn som skapats för det i Microsoft Entra-ID och autentiserar med OAuth 2.0-token. Den körande processkoden kan transparent hämta den token som ska användas. På så sätt behöver du inte lagra några lösenord eller anslutningssträng. Du kan använda hanterade identiteter i AKS genom att tilldela Microsoft Entra-identiteter till enskilda poddar med hjälp av Microsoft Entra-arbetsbelastnings-ID (förhandsversion).

För närvarande stöder inte alla Azure-tjänster autentisering med hanterade identiteter. En lista finns i Azure-tjänster som stöder Microsoft Entra-autentisering.

Även med hanterade identiteter måste du förmodligen lagra vissa autentiseringsuppgifter eller andra programhemligheter, oavsett om det gäller Azure-tjänster som inte stöder hanterade identiteter, tjänster från tredje part, API-nycklar och så vidare. Här följer några alternativ för att lagra hemligheter på ett säkert sätt:

• Azure Key Vault. I AKS kan du montera en eller flera hemligheter från Key Vault som en volym. Volymen läser hemligheterna från Key Vault. Podden kan sedan läsa hemligheterna precis som en vanlig volym. Mer information finns i Använda Azure Key Vault-providern för Secrets Store CSI-drivrutinen i ett AKS-kluster.

  Podden autentiserar sig själv med hjälp av antingen en arbetsbelastningsidentitet eller med hjälp av en användare eller en systemtilldelad hanterad identitet. Mer information finns i Ange en identitet för åtkomst till Azure Key Vault-providern för Secrets Store CSI-drivrutinen .

• HashiCorp Vault. Kubernetes-program kan autentisera med HashiCorp Vault med hjälp av Microsoft Entra-hanterade identiteter. Se HashiCorp Vault talar Microsoft Entra ID. Du kan distribuera själva valvet till Kubernetes, överväg att köra det i ett separat dedikerat kluster från ditt programkluster.

• Kubernetes-hemligheter. Ett annat alternativ är helt enkelt att använda Kubernetes-hemligheter. Det här alternativet är det enklaste att konfigurera men har vissa utmaningar. Hemligheter lagras i etcd, vilket är ett distribuerat nyckelvärdeslager. AKS krypterar etc. i vila. Microsoft hanterar krypteringsnycklarna.

Att använda ett system som HashiCorp Vault eller Azure Key Vault ger flera fördelar, till exempel:

• Centraliserad kontroll av hemligheter.
• Se till att alla hemligheter krypteras i vila.
• Centraliserad nyckelhantering.
• Åtkomstkontroll av hemligheter.
• Granskning

Säkerhet för container och Orchestrator

Det här är rekommenderade metoder för att skydda dina poddar och containrar:

• Hotövervakning: Övervaka hot med hjälp av Microsoft Defender för containrar (eller funktioner från tredje part). Om du är värd för containrar på en virtuell dator använder du Microsoft Defender för servrar eller en tredjepartsfunktion. Dessutom kan du integrera loggar från containerövervakningslösningen i Azure Monitor till Microsoft Sentinel eller en befintlig SIEM-lösning.

• Sårbarhetsövervakning: Övervaka kontinuerligt avbildningar och köra containrar för kända sårbarheter med hjälp av Microsoft Defender för molnet eller en lösning från tredje part som är tillgänglig via Azure Marketplace.

• Automatisera avbildningskorrigering med hjälp av ACR Tasks, en funktion i Azure Container Registry. En containeravbildning byggs upp från lager. Basskikten innehåller os-avbildningen och programramverksavbildningarna, till exempel ASP.NET Core eller Node.js. Basavbildningarna skapas vanligtvis uppströms från programutvecklarna och underhålls av andra projektunderhållare. När dessa avbildningar korrigeras uppströms är det viktigt att uppdatera, testa och distribuera om dina egna avbildningar, så att du inte lämnar några kända säkerhetsrisker. ACR Tasks kan hjälpa dig att automatisera den här processen.

• Lagra avbildningar i ett betrott privat register , till exempel Azure Container Registry eller Docker Trusted Registry. Använd en valideringswebbhook för antagning i Kubernetes för att säkerställa att poddar bara kan hämta avbildningar från det betrodda registret.

• Tillämpa lägsta behörighetsprincip

  • Kör inte containrar i privilegierat läge. Privilegierat läge ger en container åtkomst till alla enheter på värden.
  • Undvik att köra processer som rot inuti containrar när det är möjligt. Containrar ger inte fullständig isolering från säkerhetssynpunkt, så det är bättre att köra en containerprocess som en icke-privilegierad användare.

DevOps

Den här referensarkitekturen innehåller en Azure Resource Manager-mall för etablering av molnresurser och dess beroenden. Med hjälp av [Azure Resource Manager-mallar][arm-template] kan du använda Azure DevOps Services för att etablera olika miljöer på några minuter, till exempel för att replikera produktionsscenarier. På så sätt kan du bara spara kostnader och etablera belastningstestningsmiljön när det behövs.

Överväg att följa kriterierna för arbetsbelastningsisolering för att strukturera ARM-mallen, en arbetsbelastning definieras vanligtvis som en godtycklig funktionsenhet. Du kan till exempel ha en separat mall för klustret och sedan en annan för de beroende tjänsterna. Med arbetsbelastningsisolering kan DevOps utföra kontinuerlig integrering och kontinuerlig leverans (CI/CD), eftersom varje arbetsbelastning är associerad och hanteras av motsvarande DevOps-team.

Överväganden för distribution (CI/CD)

Här följer några mål för en robust CI/CD-process för en mikrotjänstarkitektur:

• Varje team kan skapa och distribuera de tjänster som de äger oberoende av varandra, utan att påverka eller störa andra team.
• Innan en ny version av en tjänst distribueras till produktion distribueras den till utvecklings-/test-/QA-miljöer för validering. Kvalitetsgrindar framtvingas i varje steg.
• En ny version av en tjänst kan distribueras sida vid sida med den tidigare versionen.
• Det finns tillräckligt med principer för åtkomstkontroll.
• För containerbaserade arbetsbelastningar kan du lita på de containeravbildningar som distribueras till produktion.

Mer information om utmaningarna finns i CI/CD för mikrotjänstarkitekturer.

Specifika rekommendationer och metodtips finns i CI/CD för mikrotjänster på Kubernetes.

Kostnadsoptimering

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure. Andra överväganden beskrivs i avsnittet Kostnad i Microsoft Azure Well-Architected Framework.

Här följer några saker att tänka på för några av de tjänster som används i den här arkitekturen.

Azure Kubernetes Service (AKS)

Det finns inga kostnader för AKS i distribution, hantering och drift av Kubernetes-klustret. Du betalar bara för de virtuella datorinstanser, lagrings- och nätverksresurser som förbrukas av ditt Kubernetes-kluster.

Om du vill beräkna kostnaden för de resurser som krävs använder du Container Services-kalkylatorn.

Azure Load Balancer

Du debiteras endast för antalet konfigurerade regler för belastningsutjämning och utgående trafik. Inkommande NAT-regler är kostnadsfria. Det debiteras ingen timavgift för Standard Load Balancer när inga regler har konfigurerats.

Mer information finns i Prissättning för Azure Load Balancer.

Azure-pipelines

Den här referensarkitekturen använder endast Azure Pipelines. Azure erbjuder Azure Pipeline som en enskild tjänst. Du får ett kostnadsfritt Microsoft-värdbaserat jobb med 1 800 minuter per månad för CI/CD och ett lokalt jobb med obegränsade minuter per månad, extra jobb har avgifter. Mer information finns i Prissättning för Azure DevOps Services.

Azure Monitor

För Azure Monitor Log Analytics debiteras du för datainmatning och kvarhållning. Mer information finns i Prissättning för Azure Monitor.

Distribuera det här scenariot

Om du vill distribuera referensimplementeringen för den här arkitekturen följer du stegen i GitHub-lagringsplatsen.

Nästa steg

• Tjänstens huvudnamn med Azure Kubernetes Service
• Microsoft Defender för containrar
• Microsoft Defender för servrar
• Lösning för containerövervakning i Azure Monitor
• Microsoft Sentinel eller en befintlig SIEM-lösning.
• Microsoft Defender för molnet eller en tredjepartslösning som är tillgänglig via Azure Marketplace.
• ACR-uppgifter

Relaterade resurser

• Information om hur du går igenom ett mer avancerat mikrotjänstexempel finns i Avancerad azure Kubernetes Service-mikrotjänstarkitektur (AKS)
• Mer information om övervakning av den här arkitekturen finns i Övervaka en mikrotjänstarkitektur i Azure Kubernetes Service (AKS).
• Information om hur vi mätte prestanda för det här programmet finns i Scenario för prestandajustering: Distribuerade affärstransaktioner.
• CI/CD för arkitekturer för mikrotjänster
• CI/CD för mikrotjänster på Kubernetes