Skapa en CI/CD-pipeline för mikrotjänster på Kubernetes med hjälp av Azure DevOps och Helm

Det kan vara svårt att skapa en tillförlitlig process för kontinuerlig integrering och kontinuerlig leverans (CI/CD) för en mikrotjänstarkitektur. Varje team måste släppa tjänster snabbt och tillförlitligt, utan att störa andra team eller destabilisera programmet som helhet.

Den här artikeln beskriver ett exempel på en CI/CD-pipeline för distribution av mikrotjänster till Azure Kubernetes Service (AKS). Varje team och projekt är olika, så ta inte den här artikeln som en uppsättning hårda och snabba regler. Använd den i stället som utgångspunkt för att utforma din egen CI/CD-process.

I följande lista sammanfattas målen för en CI/CD-pipeline för Kubernetes-värdbaserade mikrotjänster:

• Teams kan skapa och distribuera sina tjänster oberoende av varandra.
• Kodändringar som skickar CI-processen distribueras automatiskt till en produktionsliknande miljö.
• Varje steg i pipelinen tillämpar kvalitetsgrindar.
• En ny version av en tjänst kan distribueras sida vid sida med den tidigare versionen.

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

Antaganden

I det här exemplet finns här några antaganden om utvecklingsteamet och kodbasen:

• Kodlagringsplatsen är en monorepo med mappar ordnade efter mikrotjänst.
• Teamets förgreningsstrategi bygger på trunkbaserad utveckling.
• Teamet använder versionsgrenar för att hantera versioner. Separata versioner skapas för varje mikrotjänst.
• CI/CD-processen använder Azure-pipelines för att skapa, testa och distribuera mikrotjänsterna till AKS.
• Containeravbildningarna för alla mikrotjänster lagras i en enda, delad Azure Container Registry instans, med en separat lagringsplats för varje mikrotjänst. Använd Behörigheter för Container Registry Azure ABAC-lagringsplats för att omfångsbegränsa varje pipelineidentitet till en egen lagringsplats eller använda separata register där starkare förtroendegränser krävs.
• Teamet använder Helm-diagram för att paketera varje mikrotjänst.
• En push-distributionsmodell används, där Azure-pipelines och associerade agenter utför distributioner genom att ansluta direkt till AKS-klustret.

Dessa antaganden ligger till grund för många av de specifika detaljerna i CI/CD-pipelinen. Du kan dock anpassa den grundläggande metod som beskrivs här för andra processer, verktyg och tjänster, till exempel GitHub Actions, Jenkins eller Docker Hub.

Alternatives

När du väljer en CI/CD-strategi med AKS bör du överväga följande vanliga alternativ:

• I stället för att använda Helm som pakethanterings- och distributionsverktyg kan du använda Kustomize, ett Kubernetes-inbyggt konfigurationshanteringsverktyg som introducerar ett mallfritt sätt att anpassa och parametrisera programkonfiguration.

• I stället för att använda Azure DevOps för Git-lagringsplatser och pipelines kan du använda GitHub lagringsplatser för privata och offentliga Git-lagringsplatser och GitHub Actions för CI/CD-pipelines.

  GitHub Actions tillhandahåller integrering med AKS med startarbetsflöden och stöder OpenID Connect (OIDC) för säker, hemlighetslös autentisering till Azure.

• I stället för att använda en push-distributionsmodell bör du överväga att hantera Kubernetes-konfigurationen i stor skala med hjälp av en GitOps (pull-distributionsmodell). En Kubernetes-operatör i klustret som Flux eller Argo CD synkroniserar klustertillståndet baserat på konfigurationen som lagras på en Git-lagringsplats. GitOps eliminerar behovet av att pipelines har direkt klusteråtkomst, minskar attackytan och tillhandahåller funktioner för självåterställning och driftidentifiering.

  Tip

  När du utvärderar push-baserade eller pull-baserade distributionsmodeller (GitOps) bör du överväga dina arbetsbelastningskrav. Push-baserade distributioner erbjuder deterministiska uppdateringar och direkt pipelinekontroll, vilket passar säkra distributionsmetoder. Pull-baserade distributioner (GitOps) ger konsekvens, granskning och självåterställning, vilket gör dem idealiska för miljöer där kluster måste stämma av mot ett önskat tillstånd utan direkt åtkomst från pipeline till kluster.

Valideringskonstruktioner

Anta att en utvecklare arbetar med en mikrotjänst som heter Delivery Service. När du utvecklar en ny funktion kontrollerar utvecklaren koden i en funktionsgren. Enligt konvention heter funktionsgrenar feature/*.

Versionsdefinitionsfilen innehåller en utlösare som filtreras efter grennamnet och källsökvägen:

trigger:
  batch: true
  branches:
    include:
    # for new release to production: release flow strategy
    - release/delivery/v*
    - refs/release/delivery/v*
    - main
    - feature/delivery/*
    - topic/delivery/*
  paths:
    include:
    - /src/shipping/delivery/

När du använder den här metoden kan varje team ha en egen bygg-pipeline. Endast kod som är incheckad i /src/shipping/delivery mappen utlöser en version av Delivery Service. Pushar commits till en branch som matchar filtret utlöser ett CI-bygge. Nu i arbetsflödet kör CI-versionen en minimal kodverifiering:

1. Skapa koden.
2. Kör enhetstester.

Målet är att hålla byggtiden kort så att utvecklaren kan få snabb feedback. När funktionen är redo att slås samman till main öppnar utvecklaren en PR. Den här åtgärden utlöser en annan CI-version som utför några ytterligare kontroller:

1. Skapa koden.
2. Kör enhetstester.
3. Kör säkerhetstestning av statiska program (SAST) på källkoden.
4. Skapa containeravbildningen runtime.
5. Kör sårbarhetsgenomsökningar på avbildningen.

Fullständigt CI/CD-bygge

När teamet är redo att distribuera en ny version av Delivery Service skapar versionshanteraren en gren från huvudgrenen med hjälp av det här namngivningsmönstret: release/<microservice name>/<semver>. Till exempel release/delivery/v1.0.2.

När du skapar den här grenen utlöses en fullständig CI-version som kör alla föregående steg och följande steg:

1. Skicka containeravbildningen till Container Registry. Bilden är taggad med versionsnumret i grennamnet.
2. Kör helm package för att paketera Helm-diagrammet för tjänsten. Diagrammet är också taggat med ett versionsnummer.
3. Skicka Helm-paketet till Container Registry.

Om den här versionen lyckas utlöser den en distributionsprocess (CD) med hjälp av en Azure-pipelines versionspipeline. Den här pipelinen innehåller följande steg:

1. Distribuera Helm-diagrammet till en QA-miljö.
2. En godkännare signerar innan paketet flyttas till produktion. Se Versionsdistributionskontroll med godkännanden.
3. Lägg till Docker-avbildningen igen för produktionsnamnområdet i Container Registry. Om den aktuella taggen till exempel är myrepo.azurecr.io/delivery:v1.0.2är myrepo.azurecr.io/prod/delivery:v1.0.2produktionstaggen .
4. Distribuera Helm-diagrammet till produktionsmiljön.

Även i en monorepo kan du omfångsbegränsa dessa uppgifter till enskilda mikrotjänster så att teamen kan distribuera oberoende av varandra. Processen innehåller några manuella steg: att godkänna PR:er, skapa versionsgrenar och godkänna distributioner i produktionsklustret. Arbetsbelastningsteam kan automatisera de här stegen om de vill.

Isolering av miljöer

Du distribuerar tjänster till flera miljöer, inklusive miljöer för utveckling, röktestning, integreringstestning, belastningstestning och produktion. De här miljöerna behöver en viss isoleringsnivå. I Kubernetes kan du välja mellan fysisk isolering och logisk isolering. Fysisk isolering distribueras till separata kluster. Logisk isolering använder namnområden och principer.

Vår rekommendation är att skapa ett dedikerat produktionskluster tillsammans med ett separat kluster för dina utvecklings-/testmiljöer. Använd logisk isolering för att avgränsa miljöer i dev/test-klustret. Tjänster som distribueras till dev/test-klustret bör aldrig ha åtkomst till datalager som innehåller affärsdata.

Utför följande steg för att framtvinga isolering i ett kluster:

• Namnområden: Använd Kubernetes-namnområden för att logiskt avgränsa miljöer (till exempel dev, staging, qa).
• Nätverksprinciper: Använd Kubernetes-nätverksprinciper för att neka podd-till-pod-kommunikation mellan namnområden.
• Resurskvoter: Använd resurskvoter per namnområde för att förhindra problem med bullriga grannar i delade kluster.
• Microsoft Entra ID integrering: Kombinera Microsoft Entra ID autentisering med Kubernetes RBAC och Microsoft Entra ID för att styra vilka Microsoft Entra användare och grupper som kan komma åt varje namnområde.

Autentisering och auktorisering

Använd hemlighetslös autentisering där det är möjligt, både för pipelines som distribuerar dina mikrotjänster och för de arbetsbelastningar som dessa pipelines distribuerar:

• Arbetsbelastningsidentitetsfederation för pipelines: För Azure-pipelines använder du en tjänstanslutning för arbetsbelastningsidentitetsfederation för att autentisera till Azure utan att lagra långvariga hemligheter för tjänstens huvudnamn. För GitHub Actions konfigurerar du OIDC för att uppnå samma hemlighetslösa autentisering.
• Microsoft Entra Workload ID för distribuerade arbetsbelastningar: Konfigurera de mikrotjänster som din pipeline distribuerar för att använda Microsoft Entra Workload ID i stället för att mata in autentiseringsuppgifter via manifest, Helm-värden eller Kubernetes-hemligheter. Arbetsbelastnings-ID federerar Kubernetes-tjänstkonton med Microsoft Entra ID så att poddar kan autentisera till Azure tjänster (till exempel Azure Key Vault, Container Registry eller Azure SQL) utan att pipelinen hanterar några hemligheter.

Hantering av hemligheter

Bädda aldrig in hemligheter (anslutningssträngar, API-nycklar, databaslösenord) direkt i källkod, Dockerfiles, Helm-värden eller pipelinedefinitioner. Istället:

• Lagra hemligheter i Key Vault.
• Använd CSI-drivrutinen för Key Vault Provider for Secrets Store för att montera hemligheter direkt i poddar som volymer eller miljövariabler. Den här metoden håller hemligheter borta från Kubernetes-objekt Secret , som är base64-kodade, inte krypterade som standard.
• För pipelinehemligheter använder du Key Vault integrering med Azure-pipelines eller GitHub Actions hemligheter.
• Aktivera Key Vault skydd mot mjuk borttagning och rensning för att skydda mot oavsiktlig eller skadlig hemlighetsborttagning.

Byggprocessen

Paketera byggprocessen i en Docker-container när det är möjligt. Med den här konfigurationen kan du skapa kodartefakter med hjälp av Docker utan att konfigurera en byggmiljö på varje byggdator. En containerbaserad byggprocess förenklar utskalningen av CI-pipelinen genom att lägga till nya byggagenter. Dessutom kan alla utvecklare i teamet skapa koden genom att köra byggcontainern.

Genom att använda flerstegsversioner i Docker kan du definiera byggmiljön och körningsavbildningen i en enskild Dockerfile. Följande Dockerfile skapar till exempel ett .NET 10-program:

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS base
USER app
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src/Fabrikam.Workflow.Service

COPY Fabrikam.Workflow.Service/Fabrikam.Workflow.Service.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.csproj

COPY Fabrikam.Workflow.Service/. .
RUN dotnet build Fabrikam.Workflow.Service.csproj -c Release -o /app/build --no-restore

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

FROM build AS publish
RUN dotnet publish Fabrikam.Workflow.Service.csproj -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Fabrikam.Workflow.Service.dll"]

Den här Dockerfile definierar flera byggsteg. Observera att den namngivna base fasen använder .NET 10 ASP.NET körningsavbildning, medan den namngivna build fasen använder hela .NET 10 SDK. Fasen build skapar .NET projektet. Men den slutliga körningscontainern är byggd från base, som endast innehåller körningstiden och är betydligt mindre än den fullständiga SDK-bilden.

Skapa en testkörare

En annan bra metod är att köra enhetstester i containern. Följande kod visar till exempel en del av en Dockerfile som skapar en testlöpare:

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

En utvecklare kan använda den här Dockerfile för att köra testerna lokalt:

docker build . -t delivery-test:1 --target=testrunner
docker run delivery-test:1

CI-pipelinen bör också köra testerna som en del av byggverifieringssteget.

Den här filen använder Docker-kommandot ENTRYPOINT , inte Docker-kommandot RUN , för att köra testerna.

• Om du använder RUN kommandot körs testerna varje gång du skapar avbildningen. Om du använder ENTRYPOINTär testerna angivna. De körs bara när du uttryckligen inriktar dig på testrunner steget.
• Ett misslyckat test gör inte att Docker-kommandot build misslyckas. Med det här beteendet kan du skilja containerbyggfel från testfel.
• Testresultat kan sparas på en monterad volym.

Metodtips för containrar

Här följer några andra metodtips för containrar:

• Definiera organisationsomfattande konventioner för containertaggar, versionshantering och namngivningskonventioner för resurser som distribueras till klustret (till exempel poddar och tjänster). Med hjälp av dessa konventioner kan det bli enklare att diagnostisera distributionsproblem.
• Under utvecklings- och testcykeln skapar CI/CD-processen många containeravbildningar. Endast vissa av dessa bilder är kandidater för lansering, och endast några av dessa versionskandidater befordras till produktion. Ha en tydlig versionsstrategi så att du vet vilka avbildningar som för närvarande distribueras till produktion och enkelt kan återställa till en tidigare version om det behövs.
• Distribuera alltid specifika containerversionstaggar, inte latest.
• Använd namnrymder i Container Registry för att isolera avbildningar som är godkända för produktion från avbildningar som fortfarande testas. Flytta inte en image till produktionsnamnområdet förrän du är redo att implementera den i produktion. Genom att kombinera den här metoden med semantisk versionshantering av containeravbildningar kan du minska risken för att oavsiktligt distribuera en version som inte är godkänd för lansering.
• Följ principen om minsta behörighet genom att köra containrar som en icke-privilegierad användare. I Kubernetes använder du Pod Security Standards med Pod Security-antagning (som ersatte de inaktuella poddsäkerhetsprinciperna i Kubernetes 1.25) för att tillämpa begränsningar som att förhindra att containrar körs som rot. Använd profilen restricted för produktionsarbetsbelastningar.
• Använd minimala eller distrolösa basavbildningar (till exempel Alpine-baserade avbildningar, Azure Linux-basbilder eller distrolösa bilder eller mejslade .NET bilder) för att minska attackytan för dina containeravbildningar.
• För Premium-register konfigurerar du en kvarhållningsprincip för Container Registry för att ta bort otaggade manifest. Om du vill rensa taggar efter ålder eller namn schemalägger du en Container Registry-uppgift som kör acr-rensning. Bevara avbildningar som refererar till aktiva distributioner och återställningsplaner.

Helm-diagram

Överväg att använda Helm för att hantera skapandet och distributionen av tjänster. Följande Helm-funktioner stöder en CI/CD-pipeline:

• En enskild mikrotjänst definieras ofta av flera Kubernetes-objekt. Helm gör att dessa objekt kan paketeras i ett enda Helm-diagram.
• Du kan distribuera ett diagram med hjälp av ett enda Helm-kommando i stället för en serie kubectl-kommandon.
• Diagram är uttryckligen versionshanterade. Använd Helm för att släppa en version, visa versioner och återställa till en tidigare version. Helm använder semantisk versionshantering för att spåra uppdateringar och revisioner.
• Helm-diagram använder mallar för att undvika att duplicera information, till exempel etiketter och väljare, i många filer.
• Helm kan hantera beroenden mellan diagram.
• Du kan lagra diagram på en Helm-lagringsplats, till exempel Container Registry, och integrera dem i bygg-pipelinen.

Mer information finns i Använda Container Registry som en Helm-lagringsplats för dina programdiagram.

En enskild mikrotjänst kan kräva flera Kubernetes-konfigurationsfiler. Om du vill uppdatera en tjänst kan du behöva redigera alla dessa filer för att uppdatera väljare, etiketter och bildtaggar. Helm behandlar dessa filer som ett enda paket som kallas för ett diagram och gör det enkelt att uppdatera YAML-filerna med hjälp av variabler. Helm använder ett mallspråk (baserat på Go-mallar) som gör att du kan skriva parameteriserade YAML-konfigurationsfiler.

Här är till exempel en del av en YAML-fil som definierar en distribution:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "package.fullname" . | replace "." "" }}
  labels:
    app.kubernetes.io/name: {{ include "package.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

...

spec:
  template:
    spec:
      containers:
      - name: &package-container_name fabrikam-package
        image: {{ .Values.dockerregistry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        env:
        - name: LOG_LEVEL
          value: {{ .Values.log.level }}

Du kan se att distributionsnamnet, etiketterna och containerspecifikationen alla använder mallparametrar som du anger vid distributionstillfället. Till exempel från kommandoraden:

helm install <release-name> oci://<registry>/<repository>/<package-chart-name> --version <desiredVersion> \
     --set image.tag=0.1.0 \
     --set image.repository=package \
     --set dockerregistry=$ACR_SERVER \
     --namespace backend

Även om en CI/CD-pipeline kan installera ett diagram direkt till Kubernetes skapar du ett diagramarkiv (.tgz-fil) och skickar diagrammet till en Helm-lagringsplats, till exempel Container Registry. Mer information finns i Paketera och distribuera Helm-diagram (HelmDeploy-uppgift).

Revisions

Helm-diagram har alltid ett versionsnummer som måste använda semantisk versionshantering. Ett diagram kan också ha en appVersion. Det här fältet är valfritt och behöver inte vara relaterat till diagramversionen. Vissa team kanske vill versionsprogram separat från uppdateringar till diagrammen. En enklare metod är att använda ett versionsnummer, så det finns en 1:1-relation mellan diagramversionen och programversionen. På så sätt kan du lagra ett diagram per version och enkelt distribuera önskad version:

helm install <package-chart-name> --version <desiredVersion>

En annan bra metod är att ange en ändringsorsaksanteckning i distributionsmallen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "delivery.fullname" . | replace "." "" }}
  labels:
     ...
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

Med den här kommentaren kan du visa ändringsorsaksfältet för varje revision med hjälp kubectl rollout history av kommandot . I föregående exempel anges ändringsorsaken som en Helm-diagramparameter.

kubectl rollout history deployments/delivery-v010 -n backend

deployment.apps/delivery-v010
REVISION  CHANGE-CAUSE
1         Initial deployment

Du kan också använda helm list kommandot för att visa revisionshistoriken:

helm list -n backend

NAME              NAMESPACE   REVISION    UPDATED                                 STATUS      CHART               APP VERSION
delivery-v0.1.0   backend     1           2024-04-07 00:25:30.000000 +0000 UTC    deployed    delivery-v0.1.0     v0.1.0

Azure-pipelines

Azure-pipelines, en tjänst i Azure DevOps, har två pipelinetyper: bygg-pipelines och versionspipelines. Bygg-pipelinen kör CI-processen och skapar byggartefakter. För en mikrotjänstarkitektur på Kubernetes är dessa artefakter containeravbildningar och Helm-diagram som definierar varje mikrotjänst. Versionspipelinen kör CD-processen som distribuerar en mikrotjänst till ett kluster.

Baserat på CI-flödet som beskrevs tidigare i den här artikeln kan en byggpipeline bestå av följande uppgifter:

1. Skapa testkörcontainern med hjälp Docker av uppgiften.
2. Kör testerna genom att docker run anropa mot testkörcontainern med hjälp av uppgiften Docker .
3. Publicera testresultaten PublishTestResults med hjälp av uppgiften. Mer information finns i Skapa en avbildning.
4. Kör SAST på källkoden.
5. Skapa körningscontainern med hjälp av lokalt docker build och uppgiften Docker eller med hjälp av Container Registry-versioner och uppgiften AzureCLI . Generera en programvarufaktura (SBOM) för avbildningen, till exempel med hjälp av verktyget Microsoft SBOM, och publicera den som en pipelineartefakt som är associerad med avbildningens sammandrag eller koppla den till avbildningen i Container Registry.
6. Kör sårbarhetsgenomsökning av containeravbildningar (till exempel genom att använda Microsoft Defender för containrar eller ett icke-Microsoft verktyg som Trivy) för att identifiera kända säkerhetsrisker innan avbildningen publiceras.
7. Skicka containeravbildningen till Container Registry (eller ett annat containerregister) med hjälp Docker av uppgiften eller AzureCLI .
8. Signera den push-överförda bilden med oföränderlig sammandrag för att säkerställa dess integritet och äkthet. För Azure-pipelines följer du vägledningen för notationssignering.
9. Paketera Helm-diagrammet med hjälp HelmDeploy av uppgiften.
10. Skicka Helm-paketet till Container Registry (eller en annan Helm-lagringsplats) med hjälp HelmDeploy av uppgiften.

Utdata från CI-pipelinen är en produktionsklar containeravbildning och ett uppdaterat Helm-diagram för mikrotjänsten. Nu kan release-pipelinen ta över. Det finns en unik versionspipeline för varje mikrotjänst. Utgivningspipelinen är konfigurerad för att ha en triggningskälla inställd på CI-pipelinen som publicerade artefakten. Med den här pipelinen kan du distribuera varje mikrotjänst separat. Utgivningspipelinen utför följande steg:

1. Distribuera Helm-diagrammet till utvecklings-/QA/mellanlagringsmiljöer. Du kan använda helm upgrade kommandot med --install flaggan för att stödja den första installationen och efterföljande uppgraderingar.
2. Vänta tills en godkännare godkänner eller avvisar distributionen.
3. Ändra storlek på containeravbildningen för lansering.
4. Skicka versionstaggen till containerregistret.
5. Distribuera Helm-diagrammet i produktionsklustret. Använd Ratify med Azure Policy för att verifiera avbildningssignaturer under antagningen och konfigurera en princip för tillåtna avbildningar för att begränsa avbildningar till betrodda register.

Mer information om hur du skapar en versionspipeline finns i Versionspipelines, utkastversioner och lanseringsalternativ.

Följande diagram visar hela CI/CD-processen från början till slut som beskrivs i den här artikeln.

GitHub Actions alternativ

Om ditt team använder GitHub för källkontroll tillhandahåller GitHub Actions en motsvarande CI/CD-plattform. Utöver de startarbetsflöden och OIDC-autentisering som antecknades tidigare bör du överväga dessa GitHub-specifika funktioner när du riktar in dig på AKS:

• Miljöer och skyddsregler. Om din GitHub plan- och lagringsplatssynlighet stöder dem använder du GitHub miljöer med nödvändiga granskare, väntetider och distributionsgrenar för att implementera godkännandegrindar.
• Containergenomsökning. Använd GitHub Actions Marketplace-åtgärder för Trivy, Microsoft Defender för DevOps eller liknande verktyg för genomsökning av containeravbildningar direkt i arbetsflödet.

Observerbarhet och övervakning

Implementera observerbarhet i hela CI/CD-pipelinen och körningsmiljön:

• Pipelineövervakning. Spåra byggvaraktighet, testpassfrekvenser, distributionsfrekvens och felfrekvenser. Azure DevOps tillhandahåller inbyggd analys. GitHub Actions kan använda instrumentpaneler som inte är Microsoft.
• Körningsövervakning. Använd Azure Monitor hanterad tjänst för Prometheus och Azure Managed Grafana för att övervaka HÄLSO- och arbetsbelastningsmått för AKS-kluster.
• Programtelemetri. Instrumentera dina mikrotjänster med Azure Monitor Application Insights för distribuerad spårning, loggning av begäranden och beroendespårning.
• Larma. Konfigurera aviseringar för distributionsfel, omstarter av poddar, höga felfrekvenser och resursmättnad för att aktivera snabb incidenthantering.

Well-Architected Framework-justering

När du utformar din CI/CD-pipeline för mikrotjänster på Kubernetes bör du tänka på grundpelarna i Azure Well-Architected Framework:

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande bidragsgivare skrev den här artikeln.

Huvudförfattare:

• Ray Kao | Huvudlösningstekniker

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

Nästa steg

• Använd en förgreningsstrategi på Git
• Vad är Azure-pipelines?
• Versionspipelines, utkastversioner och lanseringsalternativ
• Distributionskontroll med godkännanden
• Introduktion till Azure Container Registry
• Microsoft Entra Workload ID med AKS
• Azure Key Vault-provider för Secrets Store CSI-drivrutin
• DevSecOps på AKS

Relaterade resurser

• CI/CD för mikrotjänster
• Microservices-arkitektur på AKS
• GitOps för Azure Kubernetes Service
• Baslinjearkitektur för ett AKS-kluster
• CI/CD-baslinjearkitektur med Azure-pipelines