Redigera

Dela via

Arkitektur för mikrotjänster i Azure Kubernetes Service

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Load Balancer
Azure Pipelines
Azure Monitor

Den här referensarkitekturen visar ett mikrotjänstprogram som distribuerats till Azure Kubernetes Service (AKS). Den beskriver en grundläggande AKS-konfiguration som du kan använda som startpunkt för de flesta distributioner. Den här artikeln förutsätter att du har en grundläggande förståelse för Kubernetes. Artikeln belyser främst infrastruktur- och DevOps-aspekterna för hur du hanterar mikrotjänster på AKS. Mer information om hur du utformar mikrotjänster finns i Arkitekturdesign för Mikrotjänster.

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

Arkitektur

diagram som visar mikrotjänsterna i AKS-referensarkitekturen.

Helm är ett varumärke som tillhör Cloud Native Computing Foundation (CNCF). Inget godkännande understås av användningen av det här märket.

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

Om du vill se ett exempel på en mer avancerad mikrotjänst som bygger på AKS-baslinjearkitekturkan du läsa avancerad AKS-mikrotjänstarkitektur.

Arbetsflöde

Det här begärandeflödet implementerar publisher-subscriber, konkurrerande konsumenteroch gatewayroutning molndesignmönster.

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

  1. Klientprogrammet skickar en JSON-nyttolast via HTTPS till det offentliga fullständigt kvalificerade domännamnet för lastbalanseraren (hanterad ingresskontrollant) för att schemalägga en drönarhämtning.

    • Den hanterade ingresskontrollanten dirigerar begäran till inmatningsmikrotjänsten.

    • Inmatningsmikrotjänsten bearbetar begäran och köar leveransbegäranden i en Azure Service Bus-kö.

  2. Arbetsflödets mikrotjänst:

    • Förbrukar meddelandeinformation från Service Bus-meddelandekön.

    • Skickar en HTTPS-begäran till leveransmikrotjänsten, som skickar data till extern datalagring i Azure Cache for Redis.

    • Skickar en HTTPS-begäran till drone scheduler-mikrotjänsten.

    • Skickar en HTTPS-begäran till paketets mikrotjänst, som skickar data till extern datalagring i MongoDB.

  3. En HTTPS GET-begäran returnerar leveransstatusen. Den här begäran skickar via den hanterade ingresskontrollanten till leveransmikrotjänsten. Sedan läser mikrotjänsten leveransdata från Azure Cache for Redis.

Mer information om exempelprogrammet för mikrotjänster finns i Microservices referensimplementeringsexempel.

Komponenter

  • AKS är ett hanterat Kubernetes-kluster som finns i Azure-molnet. AKS minskar komplexiteten och driftkostnaderna för att hantera Kubernetes genom att avlasta en stor del av det ansvaret till Azure.

  • En ingressserver exponerar HTTP(S) vägar till tjänster i klustret. Referensimplementeringen använder en hanterad NGINX-baserad ingresskontrollant via ett tillägg för programroutning. Ingresskontrollanten implementerar API-gatewayen mönster för mikrotjänster.

  • Externa datalager, till exempel Azure SQL Database eller Azure Cosmos DB, används av tillståndslösa mikrotjänster för att skriva sina data och annan tillståndsinformation. Referensimplementeringen använder Azure Cosmos DB, Azure Cache for Redis, Azure Cosmos DB for MongoDB och Service Bus som datalager eller platser där tillstånd ska lagras.

  • Microsoft Entra-ID krävs för AKS-klustret. Det ger en hanterad identitet som används för att komma åt Azure Container Registry och för att få åtkomst till och etablera Azure-resurser som lastbalanserare och hanterade diskar. Arbetsbelastningar som distribueras i ett AKS-kluster kräver också en identitet i Microsoft Entra för att få åtkomst till Microsoft Entra-skyddade resurser, till exempel Azure Key Vault och Microsoft Graph. I den här referensarkitekturen Microsoft Entra-arbetsbelastnings-ID integreras med Kubernetes och ger arbetsbelastningar med identiteter. Du kan också använda hanterade identiteter eller programautentiseringsuppgifter för varje arbetsbelastning.

  • Container Registry kan användas för att lagra privata containeravbildningar som distribueras till klustret. AKS kan autentisera med Container Registry med hjälp av dess Microsoft Entra-identitet. I referensimplementeringen skapas och skickas containeravbildningar för mikrotjänster till Container Registry.

  • Azure Pipelines ingår i Azure DevOps-sviten och kör automatiserade versioner, tester och distributioner. En kontinuerlig integrering och kontinuerlig distribution (CI/CD) metod rekommenderas starkt i mikrotjänstmiljöer. Olika team kan självständigt skapa och distribuera mikrotjänster till AKS med hjälp av Azure Pipelines.

  • Helm är en pakethanterare för Kubernetes som tillhandahåller en mekanism för att paketera och standardisera Kubernetes-objekt i en enda enhet som kan publiceras, distribueras, versioneras och uppdateras.

  • Azure Monitor- samlar in och lagrar mått och loggar, programtelemetri och plattformsmått för Azure-tjänster. Azure Monitor integreras med AKS för att samla in mått från styrenheter, noder och containrar.

  • Application Insights övervakar mikrotjänster och containrar. Det kan användas för att tillhandahålla observerbarhet för mikrotjänster, vilket inkluderar trafikflöde, svarstid från slutpunkt till slutpunkt och felprocent. Mikrotjänsternas hälsa och relationerna mellan dem kan visas på en enda programkarta.

Alternativ

Azure Container Apps ger en hanterad serverlös Kubernetes-upplevelse. Det fungerar som ett enklare alternativ till AKS för att hantera mikrotjänster när du inte behöver direkt åtkomst till Kubernetes eller dess API:er och inte behöver kontroll över klusterinfrastrukturen.

I stället för den hanterade ingressgatewayen i AKS kan du använda alternativ som Application Gateway för containrar, Istio-ingressgateway eller icke-Microsoft-lösningar. Mer information finns i Ingress i AKS.

Du kan lagra containeravbildningar i containerregister som inte kommer från Microsoft, till exempel Docker Hub.

För mikrotjänster som behöver underhålla tillståndsinformation tillhandahåller Dapr ett abstraktionslager för hantering av mikrotjänsttillstånd.

Du kan använda GitHub Actions för att skapa och distribuera mikrotjänster, eller välja CI/CD-lösningar som inte kommer från Microsoft, till exempel Jenkins.

Mikrotjänstobservabilitet kan uppnås med alternativa verktyg som Kiali.

Scenarioinformation

Exemplet mikrotjänstreferensimplementering implementerar arkitekturkomponenterna och metoderna som beskrivs i den här artikeln. I det här exemplet hanterar ett fiktivt företag som heter Fabrikam, Inc., en flotta av drönarflygplan. Företag registrerar sig för tjänsten och användare kan begära en drönare för att hämta varor för leverans. När en kund schemalägger en upphämtning tilldelar serverdelssystemet en drönare och meddelar användaren en uppskattad leveranstid. När leveransen pågår kan kunden spåra drönarens plats med en kontinuerligt uppdaterad uppskattad leveranstid.

Scenariot syftar till att demonstrera metodtipsen för mikrotjänsters arkitektur och distribution i AKS.

Potentiella användningsfall

Anta följande metodtips från scenariot till att skapa komplexa mikrotjänstbaserade program i AKS:

  • Komplexa webbprogram
  • Affärslogik som utvecklats med hjälp av designprinciper för mikrotjänster

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 i Microsoft Azure Well-Architected Framework.

Designa

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

Mikrotjänster

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. Kubernetes-tjänstobjektet är ett typiskt sätt att modellera mikrotjänster i Kubernetes.

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. Den här processen kan inträffa när tjänster delar samma underliggande datascheman. När tjänster hanterar sina egna datalager kan de använda rätt datalager för sina specifika krav. Mer information finns i Dataöverväganden för mikrotjänster.

Undvik att lagra beständiga data i lokal klusterlagring eftersom den metoden binder data till noden. Använd i stället en extern tjänst som 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 Disk Storage eller Azure Files. Mer information finns i Lagringsalternativ för program i AKS.

API-gateway

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

I Kubernetes hanterar en ingresskontrollant främst funktionerna i en API-gateway. Ingress- och ingresskontrollanten arbetar tillsammans med:

  • Dirigera klientbegäranden till rätt serverdelsmikrotjä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-adressbegränsningar eller klientfrekvensbegränsning (kallas begränsning).

Det finns ingresskontrollanter för omvända proxyservrar, däribland NGINX, HAProxy, Traefik och Azure Application Gateway. AKS innehåller flera hanterade ingressalternativ. Du kan välja mellan en hanterad NGINX-baserad ingresskontrollant via programdirigeringstillägget Application Gateway for Containers. Eller så kan du välja Istio-ingressgateway som ingresskontrollant. Mer information finns i Ingress i AKS.

De inkommande resurserna Kubernetes-objekt har ersatts av det mer avancerade och mångsidiga Kubernetes Gateway-API:et. Ingresskontrollanten och Gateway-API:et är båda Kubernetes-objekt som används för trafikhanteringsroutning och belastningsutjämning. Gateway-API:et är utformat för att vara generiskt, uttrycksfullt, utökningsbart och rollorienterat och är en modern uppsättning API:er för att definiera L4- och L7-routningsregler i Kubernetes.

Ingresskontrollanten fungerar som gränsrouter eller omvänd proxy. En omvänd proxyserver är en potentiell flaskhals eller en enskild felpunkt, så vi rekommenderar att du distribuerar minst två repliker för att säkerställa hög tillgänglighet.

När du ska välja ingresskontrollanter eller Gateway-API

Ingressresurser är lämpliga för följande användningsfall:

  • Ingresskontrollanter är enkla att konfigurera och passar för mindre och mindre komplexa Kubernetes-distributioner som prioriterar enkel konfiguration.

  • Om du för närvarande har ingresskontrollanter konfigurerade i kubernetes-klustret och de uppfyller dina krav effektivt kanske det inte finns något omedelbart behov av att övergå till Kubernetes Gateway-API:et.

Du bör använda Gateway-API:et:

  • När du hanterar komplexa routningskonfigurationer, trafikdelning och avancerade strategier för trafikhantering. Flexibiliteten som tillhandahålls av Kubernetes Gateway-API:ets routningsresurser är viktig.

  • Om nätverkskraven behöver anpassade lösningar eller integrering av plugin-program som inte kommer från Microsoft. Kubernetes Gateway-API:ets metod, baserat på anpassade resursdefinitioner, kan ge förbättrad utökningsbarhet.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i checklistan för Designgranskning för tillförlitlighet.

Partitionering av mikrotjänster

Använd namnområden för att organisera tjänster i klustret. Varje objekt i ett Kubernetes-kluster tillhör ett namnområde. Det är en bra idé att använda namnområden för att organisera resurserna i klustret.

Namnrymder hjälper 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. Med namnrymder kan du också:

  • Tillämpa resursbegränsningar på ett namnområde så att den totala uppsättningen poddar som tilldelats till namnområdet inte kan överskrida resurskvoten för namnområdet.

  • Tillämpa principer på namnområdesnivå, som omfattar rollbaserad åtkomstkontroll (RBAC) och säkerhetsprinciper.

När flera team utvecklar och distribuerar mikrotjänster kan du använda namnområden som en praktisk mekanism för att styra områden som varje team kan distribuera till. Utvecklingsteamet A kan till exempel endast ges åtkomst till namnområde A och utvecklingsteam B kan endast ges åtkomst till namnområde B via Kubernetes RBAC-principer.

För en arkitektur för mikrotjänster 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 klusterövervakningsverktyg som Elasticsearch och Prometheus till ett namnområde för övervakning.

Hälsotillståndsavsökningar

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

  • Beredskapsavsökning: meddelar Kubernetes om podden är redo att acceptera begäranden.

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

  • Startavsökning: meddelar Kubernetes om podden har startats.

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

Ibland kanske en podd inte är redo att ta emot trafik, även om den har startats. Det kan till exempel finnas initieringsuppgifter på gång, till exempel när programmet som körs i containern läser in data i minnet eller läser konfigurationsfiler. Du kan använda en startavsökning för dessa långsamma containrar. Den här metoden hjälper till att förhindra att Kubernetes avslutar dem innan de kan initieras helt.

Liveness-avsökningar används för att kontrollera om en podd körs men inte fungerar korrekt och måste startas om. Om en container till exempel hanterar HTTP-begäranden men plötsligt slutar svara utan att krascha identifierar liveness-avsökningen den här händelsen och utlöser en omstart av podden. Om du konfigurerar en liveness-avsökning ser den när en container inte svarar och uppmanar Kubernetes att starta om podden om containern upprepade gånger misslyckas med avsökningen.

Tänk på följande när du utformar avsökningar för mikrotjänster.

  • 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ördröja starten av en liveness-avsökning använder du startavsökningen eller använder inställningen initialDelaySeconds med liveness-avsökningen.

  • En liveness-avsökning hjälper bara om det ä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 finns ingen anledning 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. Den här otillgängligheten gör att beredskapsavsökningen misslyckas för alla poddar i tjänsten, vilket resulterar i att de tas bort från belastningsutjämningen. Den här borttagningen 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. Som ett alternativ kan återförsökshantering, feltolerans och kretsbrytare implementeras av Istio-tjänstnät för att skapa elastisk arkitektur som kan hantera mikrotjänstfel.

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, till exempel minne och PROCESSOR. För icke-containerresurser, till exempel trådar eller nätverksanslutningar, bör du överväga att använda Skottmönster 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. Den här begränsningen säkerställer att klientdelen inte kan svälta serverdelstjänsterna för resurser eller vice versa. Resurskvoter kan hjälpa till att allokera resurser i samma kluster till flera utvecklingsteam för mikrotjänster.

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.

TLS- och SSL-kryptering

I många implementeringar används ingresskontrollanten för SSL-avslutning. Som en del av distributionen av ingresskontrollanten måste du skapa eller importera ett TLS-certifikat (Transport Layer Security). Använd endast självsignerade certifikat i utvecklings- och testsyfte. Mer information finns i Konfigurera ett anpassat domännamn och SSL-certifikat med tillägget för programroutning.

För produktionsarbetsbelastningar hämtar du signerade certifikat från betrodda certifikatutfärdare.

Du kan också behöva rotera dina certifikat beroende på organisationens principer. Du kan använda Key Vault för att rotera certifikat som mikrotjänster använder. Mer information finns i Konfigurera automatisk rotation av certifikat i Key Vault.

RBAC

När flera team utvecklar och distribuerar mikrotjänster samtidigt kan AKS RBAC-mekanismer ge detaljerad kontroll och filtrering av användaråtgärder. Du kan antingen använda Kubernetes RBAC eller Azure RBAC med Microsoft Entra-ID för att styra åtkomsten till klusterresurserna. Mer information finns i åtkomst- och identitetsalternativ för AKS.

Autentisering och auktorisering

Mikrotjänster kan kräva att de förbrukande tjänsterna eller användarna autentiserar och auktoriserar åtkomst till mikrotjänsten med hjälp av certifikat, autentiseringsuppgifter och RBAC-mekanismer. Microsoft Entra-ID kan användas för att implementera OAuth 2.0-token för auktorisering. Tjänstnät som Istio även tillhandahålla auktoriserings- och autentiseringsmekanismer för mikrotjänster, som omfattar validering av OAuth-token och tokenbaserad routning. Referensimplementeringen omfattar inte autentiserings- och auktoriseringsscenarier för mikrotjänster.

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 använder du hanterade identiteter när det är möjligt. En hanterad identitet är som ett unikt ID för ett program eller en tjänst som lagras i Microsoft Entra-ID. Den använder den här identiteten för att autentisera med en Azure-tjänst. Programmet eller tjänsten har ett huvudnamn för tjänsten som skapats för det i Microsoft Entra-ID och autentiserar med hjälp av OAuth 2.0-token. Koden som körs i processen kan transparent hämta token. Den här metoden hjälper dig att se till att du inte behöver lagra några lösenord eller anslutningssträngar. Om du vill använda hanterade identiteter kan du tilldela Microsoft Entra-identiteter till enskilda poddar i AKS med hjälp av Microsoft Entra Workload ID.

Även när du använder hanterade identiteter kan du fortfarande behöva lagra vissa autentiseringsuppgifter eller andra programhemligheter. Den här lagringen är nödvändig för Azure-tjänster som inte stöder hanterade identiteter, tjänster som inte kommer från Microsoft eller API-nycklar. Du kan använda följande alternativ för att lagra hemligheter på ett säkrare sätt:

Att använda en lösning som Key Vault ger flera fördelar, bland annat:

  • Centraliserad kontroll av hemligheter.
  • Hjälper till att säkerställa att alla hemligheter krypteras i vila.
  • Centraliserad nyckelhantering.
  • Åtkomstkontroll av hemligheter.
  • Nyckellivscykelhantering.
  • Granskning.

Referensimplementeringen lagrar Azure Cosmos DB-anslutningssträngar och andra hemligheter i Key Vault. Referensimplementeringen använder en hanterad identitet för mikrotjänster för att autentisera till Key Vault och komma åt hemligheter.

Säkerhet för container och orchestrator

Följande rekommenderade metoder kan hjälpa dig att skydda dina poddar och containrar.

  • Övervaka hot. Övervaka hot med hjälp av Microsoft Defender för containrar eller en funktion som inte kommer från Microsoft. Om du är värd för containrar på en virtuell dator (VM) använder du Microsoft Defender för servrar eller en funktion som inte kommer från Microsoft. Dessutom kan du integrera loggar från containerövervakningslösning i Azure Monitor till Microsoft Sentinel- eller en befintlig SIEM-lösning (säkerhetsinformation och händelsehantering).

  • Övervaka sårbarheter. Övervaka kontinuerligt avbildningar och containrar som körs för kända sårbarheter med hjälp av Microsoft Defender för Cloud eller en lösning som inte är från Microsoft.

  • Automatisera bildkorrigering. Använd Azure Container Registry-uppgifter, en funktion i Container Registry, för att automatisera avbildningskorrigering. 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 programutvecklare och andra projektunderhållare underhåller dem. 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. Azure Container Registry-uppgifter kan hjälpa dig att automatisera den här processen.

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

  • Tillämpa principen om lägsta behörighet. 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.

Överväganden för DISTRIBUTIONS-CI/CD

Överväg följande 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- och Q-&A-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.

Med hjälp av ett tjänstnät som Istio kan du hjälpa till med CI/CD-processer, till exempel kanariedistributioner, A/B-testning av mikrotjänster och mellanlagrade distributioner med procentbaserade trafikdelningar.

Mer information om specifika rekommendationer och metodtips finns i Skapa en CI/CD-pipeline för mikrotjänster på Kubernetes med Azure DevOps och Helm.

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.

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

Tänk på följande för några av de tjänster som används i den här arkitekturen.

AKS

  • På den kostnadsfria nivånfinns det inga kostnader för AKS i distribution, hantering och drift av Kubernetes-klustret. Du betalar bara för de vm-instanser, lagrings- och nätverksresurser som kubernetes-klustret använder.

  • Överväg att använda horisontell autoskalning av poddar för att automatiskt skala in mikrotjänster eller skala ut dem beroende på belastning.

  • Konfigurera autoskalning av kluster för att skala in noderna eller skala ut dem beroende på belastning.

  • Överväg att använda skalningsnoder som värd för icke-kritiska mikrotjänster.

  • Granska metodtipsen för kostnadsoptimering för AKS.

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

Azure Load Balancer (Azure Belastningsutjämnare)

Du debiteras endast för antalet konfigurerade regler för belastningsutjämning och utgående trafik. Regler för översättning av inkommande nätverksadresser ä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 tillhandahåller pipelinen som en enskild tjänst. Du får ett kostnadsfritt Microsoft-värdbaserat jobb med 1 800 minuter för varje månad för CI/CD och ett lokalt jobb med obegränsade minuter för varje månad. Extra jobb medför mer kostnader. Mer information finns i prissättning för Azure DevOps-tjänster.

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.

Operational Excellence

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.

Den här referensarkitekturen innehåller Bicep-filer för etablering av molnresurser och deras beroenden. Du kan använda Azure Pipelines för att distribuera dessa Bicep-filer och snabbt konfigurera olika miljöer, till exempel replikering av produktionsscenarier. Den här metoden hjälper dig att spara kostnader genom att endast etablera belastningstestningsmiljöer när det behövs.

Överväg att följa arbetsbelastningsisoleringskriterierna för att strukturera Bicep-filen. En arbetsbelastning definieras vanligtvis som en godtycklig funktionsenhet. Du kan till exempel ha en separat Bicep-fil för klustret och sedan en annan fil för de beroende tjänsterna. Du kan använda Azure DevOps för att utföra CI/CD med arbetsbelastningsisolering eftersom varje arbetsbelastning är associerad och hanterad av sitt eget team.

Distribuera det här scenariot

Om du vill distribuera referensimplementeringen för den här arkitekturen följer du stegen i GitHub-lagringsplatsen. Mer information finns i referensimplementeringen AKS-mikrotjänster.

Bidragsgivare

Microsoft ansvarar för denna artikel. Följande deltagare skrev den här artikeln.

Huvudförfattare:

Övriga medarbetare:

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg