Geautomatiseerde implementaties van Azure Kubernetes Fleet Manager gebruiken om de plaatsing van resources met meerdere clusters te stimuleren (preview)

Geautomatiseerde implementaties van Azure Kubernetes Fleet Manager kunnen worden gebruikt om een toepassing te bouwen en te implementeren vanuit een codeopslagplaats naar een of meer AKS-clusters in een vloot. Geautomatiseerde implementaties vereenvoudigen het instellen van een GitHub Action-werkstroom voor het bouwen en implementeren van uw code. Zodra er verbinding is gemaakt, wordt bij elke nieuwe commit de pijplijn uitgevoerd.

Geautomatiseerde implementaties bouwen voort op draft.sh. Wanneer u een nieuwe implementatiewerkstroom maakt, kunt u een bestaand Dockerfile gebruiken, een Dockerfile genereren, bestaande Kubernetes-manifesten gebruiken of Kubernetes-manifesten genereren. De gegenereerde manifesten worden opgesteld met de beste praktijken voor beveiliging en veerkracht in gedachten.

Belangrijk

Preview-functies van Azure Kubernetes Fleet Manager zijn beschikbaar op basis van selfservice, opt-in. Previews worden geleverd 'zoals het is' en 'voor zover beschikbaar' en zijn uitgesloten van de serviceovereenkomsten en beperkte garantie. Previews van Azure Kubernetes Fleet Manager worden gedeeltelijk gedekt door klantondersteuning op basis van best effort. Zodoende zijn deze functies niet bedoeld voor productiegebruik.

Vereiste voorwaarden

• Een GitHub-account met de toepassing die moet worden geïmplementeerd.
• Als u geen Azure-account hebt, maak dan een gratis account aan voordat u begint.
• Lees de conceptuele overzichten van geautomatiseerde implementaties en resourcedoorgifte om inzicht te hebben in de concepten en terminologie die in dit artikel worden gebruikt.
• Een Kubernetes Fleet Manager met een hubcluster en lidclusters. Als u nog geen resource hebt, raadpleegt u Een Azure Kubernetes Fleet Manager-resource maken en lidclusters koppelen met behulp van de Azure CLI.
• De gebruiker die de configuratie voltooit, heeft machtigingen voor de Kubernetes-API van het Fleet Manager-hubcluster. Zie De Kubernetes-API voor meer informatie.
• Een Kubernetes-naamruimte die al is geïmplementeerd in het Fleet Manager-hubcluster.
• Een Azure Container Registry (ACR) met AcrPull-rechten die zijn verleend aan AKS-clusters.

De broncode van uw toepassing meenemen

Zoek uw Azure Kubernetes Fleet Manager en start de configuratie van geautomatiseerde implementaties.

1. Zoek in Azure Portal naar Kubernetes Fleet Manager in de bovenste zoekbalk.
2. Selecteer Kubernetes Fleet Manager in de zoekresultaten.
3. Selecteer uw Azure Kubernetes Fleet Manager in de lijst met resources.
4. Selecteer Geautomatiseerde implementaties in het servicemenu Fleet Manager onder Fleet-resources.
5. Selecteer + Maken in het bovenste menu. Als deze implementatie uw eerste is, kunt u ook Maken selecteren in het gebied met de implementatielijst.

Verbinding maken met broncodeopslagplaats

Maak een werkstroom en autoriseer deze om verbinding te maken met de gewenste broncodeopslagplaats en -vertakking. Vul de volgende details in op het tabblad Opslagplaats .

1. Voer een betekenisvolle naam in voor de werkstroom in het veld Werkstroomnaam .
2. Selecteer vervolgens Toegang autoriseren om een gebruiker te autoriseren voor GitHub om een lijst met opslagplaatsen te verkrijgen.
3. Selecteer voor opslagplaatsbron een van de volgende opties:
   1. Mijn opslagplaatsen voor opslagplaatsen waar de momenteel geautoriseerde GitHub-gebruiker eigenaar van is, of;
   2. Alle opslagplaatsen die toegankelijk zijn voor de momenteel geautoriseerde GitHub-gebruiker. U moet de organisatie selecteren die eigenaar is van de opslagplaats.
4. Kies de Repository en Branch.
5. Selecteer de Volgende knop.

Applicatie-afbeeldingen en implementatieconfiguratie specificeren

Om een toepassing klaar te maken om te draaien op Kubernetes, moet u deze bouwen tot een containerafbeelding die u opslaat in een containerregister. Een Dockerfile bevat instructies voor het bouwen van de containerimage. Als uw opslagplaats voor broncode nog geen Dockerfile heeft, kunnen geautomatiseerde implementaties er een voor u genereren.

Bestaand Dockerfile gebruiken

Als uw codeopslagplaats al een Dockerfile heeft, kunt u deze gebruiken om de toepassingsinstallatiekopieën te bouwen.

1. Selecteer Bestaand Dockerfile voor de containerconfiguratie.
2. Selecteer het Dockerfile in uw opslagplaats.
3. Voer de Dockerfile-buildcontext in om de set bestanden en mappen door te geven aan het buildproces (meestal dezelfde map als het Dockerfile). Deze bestanden worden gebruikt om de afbeelding te bouwen en ze worden opgenomen in de uiteindelijke afbeelding, tenzij ze worden genegeerd door opname in een .dockerignore bestand.
4. Selecteer een bestaand Azure Container Registry. Dit register wordt gebruikt voor het opslaan van de ingebouwde toepassingsinstallatiekopie. Elk AKS-cluster dat de toepassing kan ontvangen, moet machtigingen krijgen AcrPull voor het register.
5. Stel de naam van de Azure Container Registry-image in. U moet deze installatiekopieënnaam gebruiken in uw Kubernetes-implementatiemanifesten.

Een Dockerfile genereren

Gebruik Geautomatiseerde implementaties van Fleet Manager om een Dockerfile te genereren voor veel talen en frameworks, zoals Go, C#, Node.js, Python, Java, Gradle, Clojure, PHP, Ruby, Erlang, Swift en Rust. De taalondersteuning is gebaseerd op wat er beschikbaar is in draft.sh.

1. Selecteer Automatisch containeriseren (Dockerfile genereren) voor de containerconfiguratie.
2. Stel de opslagbestanden in de opslagplaatslocatie in op een map in de bronopslagplaats.
3. Kies de toepassingsomgeving in de lijst met ondersteunde talen en frameworks.
4. Voer de toepassingspoort in.
5. Selecteer een bestaand Azure Container Registry. Dit register wordt gebruikt voor het opslaan van de ingebouwde toepassingsinstallatiekopie. Elk AKS-cluster dat de toepassing kan ontvangen, moet machtigingen krijgen AcrPull voor het register.
6. Stel de naam van de Azure Container Registry-image in. U moet deze installatiekopieënnaam gebruiken in uw Kubernetes-implementatiemanifesten.
7. Bekijk de gegenereerde Dockerfile en .dockerignore bestanden.

De Configuratie van het Kubernetes-manifest kiezen

Een toepassing die wordt uitgevoerd op Kubernetes bestaat uit veel primitieve Kubernetes-onderdelen. Deze onderdelen beschrijven welke containerinstallatiekopie moet worden gebruikt, hoeveel replica's moeten worden uitgevoerd, als er een openbaar IP-adres is vereist om de toepassing beschikbaar te maken, enzovoort. Zie de officiële Kubernetes-documentatie voor meer informatie. Als uw broncodeopslagplaats nog geen Kubernetes-manifesten heeft, kunnen geautomatiseerde implementaties deze voor u genereren. U kunt ook een bestaande Helm-grafiek kiezen.

Waarschuwing

Kies fleet-system de of een van de fleet-member naamruimten niet, omdat dit interne naamruimten zijn die worden gebruikt door Fleet Manager en kunnen niet worden gebruikt om uw toepassing te plaatsen.

Bestaande Kubernetes-manifesten gebruiken

Als uw codeopslagplaats al een Kubernetes-manifest heeft, kunt u dit selecteren om te bepalen welke werkbelasting wordt geïmplementeerd en geconfigureerd door de plaatsing van een clusterresource.

1. Selecteer Bestaande Kubernetes-manifestimplementatiebestanden gebruiken voor de implementatieopties.
2. Selecteer het Kubernetes-manifestbestand of de map in uw opslagplaats.
3. Selecteer de bestaande Fleet Manager Namespace om de workload in te faseren.
4. Selecteer de Volgende knop.

Kubernetes-manifesten genereren

Gebruik Geautomatiseerde implementaties van Fleet Manager om een set eenvoudige Kubernetes-manifestbestanden te genereren om uw toepassing actief te maken. Op dit moment maken geautomatiseerde implementaties een Deployment, een Serviceen een ConfigMap.

De gegenereerde manifesten zijn ontworpen om aanbevelingen van implementatiebeveiligingen toe te passen, zoals:

• Automatisch liveness, gereedheid en opstarttests genereren.
• Voorkeur voor antiaffiniteit van pods en topologiebeperkingen die replica's op verschillende knooppunten verspreiden voor verbeterde tolerantie.
• Het RuntimeDefault afdwingen waarmee een extra beveiligingslaag wordt vastgesteld tegen veelvoorkomende beveiligingsproblemen die worden misbruikt door kwaadwillende actoren.
• Alle Linux-mogelijkheden verwijderen en alleen een beperkte set toestaan volgens de Basislijn Kubernetes Pod Security Standards.

Kubernetes-manifesten genereren:

1. Selecteer Toepassingsimplementatiebestanden genereren voor de implementatieopties.
2. Voer de toepassingspoort in. Deze poort wordt gebruikt voor de gegenereerde Service.
3. Selecteer de bestaande Fleet Manager Namespace om de workload in te faseren.
4. Stel de opslagbestanden in de opslagplaatslocatie in op een map in de bronopslagplaats.
5. Selecteer de Volgende knop.

Bestaande Helm-grafiek gebruiken

Als uw coderepository al een Helm-chart heeft, kunt u deze selecteren om de applicatieafbeelding te bouwen.

1. Selecteer Bestaande Helm-grafiek gebruiken voor de implementatieopties.
2. Selecteer de Charts path map in de opslagplaats.
3. Selecteer het pad naar het bestand Values.yaml in uw opslagplaats.
4. Geef desgewenst Helm-chart-overrides op.
5. Selecteer de bestaande Fleet Manager Namespace om de workload in te faseren.
6. Selecteer de Volgende knop.

Configuratie controleren

Controleer de configuratie voor de opslagplaats, afbeelding en implementatie.

Selecteer Volgende om het proces te starten dat deze acties uitvoert:

1. Federatieve referenties maken om de GitHub-actie toe te staan:
   1. Push de gemaakte containerinstallatiekopie naar Azure Container Registry.
   2. Faseer de Kubernetes-manifesten in de geselecteerde naamruimte op het Fleet Manager-hubcluster.
2. Maak een pull-aanvraag in de codeopslagplaats met alle gegenereerde bestanden en de werkstroom.

Het instellen duurt enkele minuten, dus navigeer niet weg van de pagina Implementeren.

Pull-aanvraag controleren en samenvoegen

Wanneer de implementatiefase is voltooid, selecteert u de knop Pull-aanvraag goedkeuren om de gegenereerde pull-aanvraag in uw codeopslagplaats te openen.

Opmerking

Er is een bekend probleem met de naamgeving van de gegenereerde pull-aanvraag, waarbij wordt aangegeven dat deze wordt geïmplementeerd in AKS. Ondanks deze onjuiste naam voert de resulterende werkstroom uw workload uit op het Fleet Manager-hubcluster in de naamruimte die u hebt geselecteerd.

1. Controleer de wijzigingen onder Bestanden gewijzigd en breng eventueel gewenste wijzigingen aan.
2. Selecteer Pull-aanvraag samenvoegen om de wijzigingen samen te voegen in uw codeopslagplaats.

Het samenvoegen van de wijziging voert de GitHub Actions-werkstroom uit die uw toepassing bouwt in een containerafbeelding en deze opslaat in de geselecteerde Azure Container Registry.

De gegenereerde bronnen controleren

Nadat de pijplijn is voltooid, kunt u de gemaakte containerinstallatiekopieën bekijken in Azure Portal door de Azure Container Registry-instantie te zoeken die u hebt geconfigureerd en de opslagplaats voor installatiekopieën te openen.

U kunt ook de configuratie van de geautomatiseerde implementatie van Fleet Manager bekijken. Als u de workflow naam selecteert, wordt GitHub geopend in de GitHub-actie.

Ten slotte kunt u controleren of de verwachte Kubernetes-resources zijn geplaatst op de hubcluster van de Fleet Manager.

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

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

De output ziet er ongeveer zo uit. De replica's van 0 worden verwacht omdat workloads niet zijn gepland op het Fleet Manager-hubcluster. Zorg ervoor dat de Image eigenschap verwijst naar de gebouwde image in uw 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>

Plaatsing van clusterresources definiëren

Tijdens de preview kunt u deze stappen volgen om de plaatsing van uw gefaseerde werkbelasting aan te passen aan lidclusters.

1. Maak in de opslagplaats met broncode voor uw toepassing een map in de hoofdmap van de opslagplaats met de naam fleet.

2. Maak een nieuw bestand deploy-contoso-ns-two-regions.yaml in de vlootmap en voeg de weergegeven inhoud toe. In dit voorbeeld wordt de contoso-store naamruimte geïmplementeerd in twee clusters die zich in twee verschillende Azure-regio's moeten bevinden.

   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
   

3. Wijzig het GitHub Action-werkstroombestand en voeg een verwijzing toe aan het CRP-bestand.

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

4. Voer het nieuwe CRP-manifest en bijgewerkt GitHub Action-werkstroombestand door.

5. Controleer of de werkbelasting is geplaatst volgens het beleid dat is gedefinieerd in de CRP-definitie. U controleert dit via de Azure Portal of kubectl via de opdrachtregelinterface.

Volgende stappen

• Gebruik plaatsing van resources in clusters om workloads in meerdere clusters te implementeren.
• Intelligente plaatsing van Kubernetes-resources tussen clusters op basis van eigenschappen van lidclusters.
• Veelgestelde vragen over geautomatiseerde implementaties.