Använda automatiserade distributioner i Azure Kubernetes Fleet Manager för att skapa resursplacering för flera kluster (förhandsversion)

2025-06-16

Automatiserade distributioner i Azure Kubernetes Fleet Manager kan användas för att skapa och distribuera ett program från en kodlagringsplats till ett eller flera AKS-kluster i en flotta. Automatiserade distributioner förenklar processen med att konfigurera ett GitHub Action-arbetsflöde för att skapa och distribuera din kod. När du har anslutit kör varje ny commit som du gör pipelinen.

Automatiserade distributioner bygger på draft.sh. När du skapar ett nytt distributionsarbetsflöde kan du använda en befintlig Dockerfile, generera en Dockerfile, använda befintliga Kubernetes-manifest eller generera Kubernetes-manifest. De genererade manifesten skapas med bästa praxis för säkerhet och återhämtning i åtanke.

Viktigt!

Förhandsversionsfunktionerna i Azure Kubernetes Fleet Manager är tillgängliga via självbetjäning och opt-in. Förhandsversioner tillhandahålls "i befintligt skick" och "i mån av tillgång," och de är undantagna från servicenivåavtal och begränsad garanti. Förhandsversioner av Azure Kubernetes Fleet Manager omfattas delvis av kundsupport på bästa sätt. Dessa funktioner är därmed inte avsedda för produktionsanvändning.

Förutsättningar

Ett GitHub-konto med programmet som ska distribueras.
Om du inte har något Azure-konto skapar du ett kostnadsfritt konto innan du börjar.
Läs de konceptuella översikterna över automatiserade distributioner och resursspridning för att förstå begreppen och terminologin som används i den här artikeln.
En Kubernetes Fleet Manager med ett hubbkluster och medlemskluster. Om du inte har en kan du läsa Skapa en Azure Kubernetes Fleet Manager-resurs och ansluta till medlemskluster med hjälp av Azure CLI.
Användaren som slutför konfigurationen har behörigheter till Fleet Manager-hubbklustrets Kubernetes API. Mer information finns i Åtkomst till Kubernetes API för mer information.
Ett Kubernetes-namnområde som redan har distribuerats i Fleet Manager-hubbklustret.
Ett Azure Container Registry (ACR) med AcrPull-rättigheter beviljade till AKS medlemskluster.

Hämta programmets källkod

Leta upp din Azure Kubernetes Fleet Manager och starta konfigurationen av automatiserade distributioner.

I Azure-portalen söker du efter Kubernetes Fleet Manager i det övre sökfältet.
Välj Kubernetes fleet manager i sökresultaten.
Välj din Azure Kubernetes Fleet Manager i resurslistan.
Välj Automatiserade distributioner under Fleet-resurser på Fleet Manager-tjänstmenyn.
Välj + Skapa på den översta menyn. Om den här distributionen är din första kan du också välja Skapa i distributionslistan.

Ansluta till källkodslagringsplatsen

Skapa ett arbetsflöde och auktorisera det för att ansluta till önskad källkodslagringsplats och -gren. Fyll i följande information på fliken Lagringsplats .

Ange ett beskrivande namn för arbetsflödet i fältet Arbetsflödesnamn .
Välj sedan Auktorisera åtkomst för att auktorisera en användare mot GitHub för att hämta en lista över lagringsplatser.
För Lagringsplatskälla väljer du antingen:
1. Mina lagringsplatser för lagringsplatser som den för närvarande auktoriserade GitHub-användaren äger, eller;
2. Alla lagringsplatser för lagringsplatser som den för närvarande auktoriserade GitHub-användaren kan komma åt. Du måste välja den organisation som äger lagringsplatsen.
Välj lagringsplats och gren.
Välj knappen Nästa.

Ange programbild och distributionskonfiguration

För att förbereda ett program för körning på Kubernetes måste du skapa det till en containeravbildning som du lagrar i ett containerregister. En Dockerfile innehåller instruktioner om hur du skapar containeravbildningen. Om källkodslagringsplatsen inte redan har en Dockerfile kan automatiserade distributioner generera en åt dig.

Använda befintlig Dockerfile
Generera en Dockerfile

Om din kodlagringsplats redan har en Dockerfile kan du använda den för att skapa programbilden.

Välj Befintlig Dockerfile för containerkonfigurationen.
Välj Dockerfile från lagringsplatsen.
Ange Dockerfile-byggkontexten för att skicka uppsättningen filer och kataloger till byggprocessen (vanligtvis samma mapp som Dockerfile). Dessa filer används för att skapa avbildningen och de ingår i den slutliga avbildningen, såvida de inte ignoreras genom inkludering i en .dockerignore fil.
Välj ett befintligt Azure Container Registry. Det här registret används för att lagra den byggda programbilden. Alla AKS-kluster som kan ta emot programmet måste ha AcrPull behörighet i registret.
Ange containerbildnamnet för Azure Container Registry. Du måste använda det här avbildningsnamnet i Kubernetes-distribueringsmanifester.

Använd Automatiserade distributioner i Fleet Manager för att generera en Dockerfile för många språk och ramverk som Go, C#, Node.js, Python, Java, Gradle, Clojure, PHP, Ruby, Erlang, Swift och Rust. Språkstöd bygger på vad som är tillgängligt i draft.sh.

Välj Autocontainerize (generera Dockerfile) för containerkonfigurationen.
Ange placeringen Spara filer i lagringsplatsen till en mapp i källlagringsplatsen.
Välj programmiljön i listan över språk och ramverk som stöds.
Ange applikationsporten.
Välj ett befintligt Azure Container Registry. Det här registret används för att lagra den byggda programbilden. Alla AKS-kluster som kan ta emot programmet måste ha AcrPull behörighet i registret.
Ange containerbildnamnet för Azure Container Registry. Du måste använda det här avbildningsnamnet i Kubernetes-distribueringsmanifester.
Granska genererade Dockerfile filer och .dockerignore filer.

Välj Kubernetes-manifestkonfigurationen

Ett program som körs på Kubernetes består av många primitiva Kubernetes-komponenter. Dessa komponenter beskriver vilken containeravbildning som ska användas, hur många repliker som ska köras, om det krävs en offentlig IP-adress för att exponera programmet osv. Mer information finns i den officiella Kubernetes-dokumentationen. Om källkodslagringsplatsen inte redan har Kubernetes-manifest kan automatiserade distributioner generera dem åt dig. Du kan också välja ett befintligt Helm-diagram.

Varning

Använd inte fleet-system eller något av fleet-member namnrymderna eftersom dessa är interna namnrymder som används av Fleet Manager och inte kan användas för att placera ditt program.

Om din kodlagringsplats redan har ett Kubernetes-manifest kan du välja det för att styra vilken arbetsbelastning som distribueras och konfigureras av en klusterresursplacering.

Välj Använd befintliga Kubernetes-manifestdistributionsfiler för distributionsalternativen.
Välj Kubernetes-manifestfilen eller -mappen från lagringsplatsen.
Välj det befintliga Fleet Manager-namnområdet för att mellanlagra arbetsbelastningen i.
Välj knappen Nästa.

Använd automatiserade distributioner i Fleet Manager för att generera en uppsättning grundläggande Kubernetes-manifestfiler för att få igång ditt program. För närvarande skapar automatiserade distributioner en Deployment, en Serviceoch en ConfigMap.

De genererade manifesten är utformade för att tillämpa rekommendationer för distributionsskydd, till exempel:

Generera hälsotillstånd, beredskap och startprober automatiskt.
Föredrar pod-antipati och topologispridningsbegränsningar som sprider repliker till olika noder för förbättrad robusthet.
Framtvinga den RuntimeDefaultsäkra databehandlingsprofil som etablerar ett extra skyddslager mot vanliga systemanropssårbarheter som utnyttjas av skadliga aktörer.
Ta bort alla Linux-kapabiliteter och endast tillåta en begränsad uppsättning enligt grundläggande Kubernetes poddsäkerhetsstandarder.

Så här genererar du Kubernetes-manifest:

Välj Generera programdistributionsfiler för distributionsalternativen.
Ange applikationsporten. Den här porten används på den genererade Service.
Välj det befintliga Fleet Manager-namnområdet för att mellanlagra arbetsbelastningen i.
Ange placeringen Spara filer i lagringsplatsen till en mapp i källlagringsplatsen.
Välj knappen Nästa.

Granska konfigurationen

Granska konfigurationen för lagringsplatsen, avbildningen och distributionskonfigurationen.

Välj Nästa för att starta processen som utför följande åtgärder:

Skapa federerade autentiseringsuppgifter så att GitHub-åtgärden kan:
1. Skicka den skapade containeravbildningen till Azure Container Registry.
2. Mellanlagra Kubernetes-manifesten i det valda namnområdet i Fleet Manager-hubbklustret.
Skapa en pull-begäran på kodlagringsplatsen med alla genererade filer och arbetsflödet.

Installationen tar några minuter, så gå inte bort från sidan Distribuera.

Granska och sammanfoga pull-begäran

När distributionssteget är klart väljer du knappen Godkänn pull-begäran för att öppna den genererade pull-begäran på kodlagringsplatsen.

Anmärkning

Det finns ett känt problem med namnet på den genererade pull-begäran där det står att den distribuerar till AKS. Trots det här felaktiga namnet mellanlagrar det resulterande arbetsflödet din arbetsbelastning på Fleet Manager-hubbklustret i det namnområde som du har valt.

Granska ändringarna under Filer har ändrats och gör önskade ändringar.
Välj Koppla pull-begäran för att sammanfoga ändringarna till din kodlagringsplats.

Genom att slå ihop ändringen körs GitHub Actions-arbetsflödet som bygger ditt program som en containeravbildning och lagrar det i det valda Azure Container Registry.

Kontrollera de genererade resurserna

När pipelinen är klar kan du granska den skapade containeravbildningen på Azure-portalen genom att hitta den Azure Container Registry-instans som du konfigurerade och öppna avbildningslagringsplatsen.

Du kan också visa konfigurationen för automatiserad distribution i Fleet Manager. Om du väljer workflow namnet öppnas GitHub på GitHub Action.

Slutligen kan du bekräfta att de förväntade Kubernetes-resurserna mellanlagras i Fleet Manager-hubbklustret.

az fleet get-credentials \
    --resource-group ${GROUP} \
    --name ${FLEET}

kubectl describe deployments virtual-worker --namespace=contoso-store

Utdata ser ut ungefär som nedan. Replikerna av 0 förväntas eftersom arbetsbelastningar inte schemaläggs i Fleet Manager-hubbklustret. Kontrollera att Image egenskapen pekar på den inbyggda avbildningen i Azure Container Registry.

Name:                   virtual-worker
Namespace:              contoso-store
CreationTimestamp:      Thu, 24 Apr 2025 01:56:49 +0000
Labels:                 workflow=actions.github.com-k8s-deploy
                        workflowFriendlyName=contoso-store-deploy
Annotations:            <none>
Selector:               app=virtual-worker
Replicas:               1 desired | 0 updated | 0 total | 0 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=virtual-worker
  Containers:
   virtual-worker:
    Image:      contoso03.azurecr.io/virtual-worker:latest
    Port:       <none>
    Host Port:  <none>
    Limits:
      cpu:     2m
      memory:  20Mi
    Requests:
      cpu:     1m
      memory:  1Mi
    Environment:
      MAKELINE_SERVICE_URL:  http://makeline-service:3001
      ORDERS_PER_HOUR:       100
    Mounts:                  <none>
  Volumes:                   <none>
  Node-Selectors:            kubernetes.io/os=linux
  Tolerations:               <none>
Events:                      <none>

Definiera placering av klusterresurser

Under förhandsversionen kan du följa de här stegen för att konfigurera placeringen av din mellanlagrade arbetsbelastning på medlemskluster.

I källkodslagringsplatsen för ditt program skapar du en mapp i lagringsplatsens rot som heter fleet.

Skapa en ny fil deploy-contoso-ns-two-regions.yaml i mappen fleet och lägg till innehållet som visas. Det här exemplet distribuerar contoso-store namnområdet mellan två kluster som måste finnas i två olika Azure-regioner.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: distribute-virtual-worker-two-regions
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      version: v1          
      name: contoso-store
  policy:
    placementType: PickN
    numberOfClusters: 2
    topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule

Ändra arbetsflödesfilen för GitHub Action och lägg till en referens till CRP-filen.

DEPLOYMENT_MANIFEST_PATH: |
  ./virtual-worker.yaml
  ./fleet/deploy-contoso-ns-two-regions.yaml

Lägg till det nya CRP-manifestet och den uppdaterade arbetsflödesfilen för GitHub Action.
Kontrollera att arbetsbelastningen är placerad enligt principen som definierats i CRP-definitionen. Du kontrollerar antingen med hjälp av Azure-portalen eller kubectl på kommandoraden.

Nästa steg

Feedback

Var den här sidan till hjälp?