Usare Le distribuzioni automatizzate di Azure Kubernetes Fleet Manager per gestire il posizionamento delle risorse multi-cluster (anteprima)

Le distribuzioni automatizzate di Azure Kubernetes Fleet Manager possono essere usate per compilare e distribuire un'applicazione da un repository di codice a uno o più cluster del servizio Azure Kubernetes in una flotta. Le distribuzioni automatizzate semplificano il processo di configurazione di un flusso di lavoro di GitHub Action per compilare e distribuire il codice. Dopo la connessione, ogni nuovo commit creato esegue la pipeline.

Le distribuzioni automatizzate si basano su draft.sh. Quando si crea un nuovo flusso di lavoro di distribuzione, è possibile usare un Dockerfile esistente, generare un Dockerfile, usare manifesti Kubernetes esistenti o generare manifesti Kubernetes. I manifesti generati vengono creati tenendo presenti le procedure consigliate per la sicurezza e la resilienza.

Importante

Le funzionalità di anteprima di Gestione flotta Kubernetes di Azure sono disponibili in modalità self-service e opt-in. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime di Gestione flotta Kubernetes di Azure sono parzialmente coperte dal supporto clienti con il massimo sforzo. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione.

Prerequisiti

• Un account GitHub con l'applicazione da distribuire.
• Se non si ha un account Azure, creare un account gratuito prima di iniziare.
• Leggere le panoramiche concettuali delle distribuzioni automatizzate e della propagazione delle risorse per comprendere i concetti e la terminologia usati in questo articolo.
• Gestione flotta Kubernetes con un cluster hub e cluster membri. Se non è disponibile, vedere Creare una risorsa di Gestione flotta Kubernetes di Azure e aggiungere cluster membri usando l'interfaccia della riga di comando di Azure.
• L'utente che completa la configurazione ha le autorizzazioni per l'API Kubernetes del cluster hub Fleet Manager. Per altre informazioni, vedere Accedere all'API Kubernetes per altri dettagli.
• Un namespace di Kubernetes già distribuito sul cluster hub di Fleet Manager.
• Un Azure Container Registry (ACR) con diritti AcrPull concessi ai cluster AKS membri.

Portare il codice sorgente dell'applicazione

Trovare Azure Kubernetes Fleet Manager e avviare la configurazione delle distribuzioni automatizzate.

1. Nel portale di Azure cercare Kubernetes Fleet Manager nella barra di ricerca superiore.
2. Selezionare Kubernetes fleet manager nei risultati della ricerca.
3. Selezionare Azure Kubernetes Fleet Manager dall'elenco delle risorse.
4. Dal menu del servizio Fleet Manager, in Fleet resources (Risorse flotta) selezionare Automated deployments (Distribuzioni automatiche).
5. Selezionare + Crea nel menu in alto. Se questa distribuzione è la prima, è anche possibile selezionare Crea nell'area dell'elenco di distribuzione.

Connettersi al repository del codice sorgente

Creare un flusso di lavoro e autorizzarlo a connettersi al repository e al ramo del codice sorgente desiderato. Completare i dettagli seguenti nella scheda Repository .

1. Immettere un nome significativo per il flusso di lavoro nel campo Nome flusso di lavoro .
2. Selezionare quindi Autorizza l'accesso per autorizzare un utente su GitHub per ottenere un elenco di repository.
3. Per Origine repository selezionare:
   1. I miei repository per i repository di cui l'utente GitHub, attualmente autorizzato, è proprietario, oppure;
   2. Tutti i repository per i repository a cui l'utente GitHub attualmente autorizzato può accedere. È necessario selezionare l'organizzazione proprietaria del repository.
4. Scegliere il repository e il branch.
5. Seleziona il pulsante Avanti.

Specificare l'immagine dell'applicazione e la configurazione della distribuzione

Per preparare un'applicazione per l'esecuzione in Kubernetes, è necessario compilarla in un'immagine del contenitore archiviata in un registro contenitori. Un Dockerfile fornisce istruzioni su come compilare l'immagine del contenitore. Se il repository del codice sorgente non ha già un Dockerfile, le distribuzioni automatizzate possono generarne una automaticamente.

Usa Dockerfile esistente

Se il repository di codice ha già un Dockerfile, è possibile usarlo per compilare l'immagine dell'applicazione.

1. Selezionare Dockerfile esistente per la configurazione del contenitore.
2. Seleziona il Dockerfile dal tuo repository.
3. Immettere il contesto di compilazione Dockerfile per passare il set di file e directory al processo di compilazione (in genere la stessa cartella del Dockerfile). Questi file vengono usati per compilare l'immagine e sono inclusi nell'immagine finale, a meno che non vengano ignorati tramite l'inclusione in un .dockerignore file.
4. Selezionare un Registro Azure Container esistente. Questo registro viene usato per archiviare l'immagine dell'applicazione compilata. A qualsiasi cluster del servizio Azure Kubernetes che può ricevere l'applicazione devono essere concesse le autorizzazioni AcrPull sul Registro.
5. Impostare il nome dell'immagine del Registro Azure Container . È necessario usare questo nome immagine nei manifesti di distribuzione di Kubernetes.

Genera un Dockerfile

Usare le distribuzioni automatiche di Fleet Manager per generare un Dockerfile per molti linguaggi e framework, ad esempio Go, C#, Node.js, Python, Java, Gradle, Clojure, PHP, Ruby, Erlang, Swift e Rust. Il supporto linguistico è basato su ciò che è disponibile in draft.sh.

1. Selezionare Auto-containerize (generate Dockerfile) per la configurazione del contenitore.
2. Imposta la posizione di Salva i file nel repository su una cartella nel repository di origine.
3. Scegliere l'ambiente dell'applicazione dall'elenco di linguaggi e framework supportati.
4. Immettere la porta dell'applicazione.
5. Selezionare un Registro Azure Container esistente. Questo registro viene usato per archiviare l'immagine dell'applicazione compilata. A qualsiasi cluster del servizio Azure Kubernetes che può ricevere l'applicazione devono essere concesse le autorizzazioni AcrPull sul Registro.
6. Impostare il nome dell'immagine del Registro Azure Container . È necessario usare questo nome immagine nei manifesti di distribuzione di Kubernetes.
7. Esaminare i file Dockerfile e .dockerignore generati.

Scegliere la configurazione del manifesto Kubernetes

Un'applicazione in esecuzione in Kubernetes è costituita da molti componenti primitivi kubernetes. Questi componenti descrivono l'immagine del contenitore da usare, il numero di repliche da eseguire, se è necessario un indirizzo IP pubblico per esporre l'applicazione e così via. Per altre informazioni, vedere la documentazione ufficiale di Kubernetes. Se il repository del codice sorgente non ha già manifesti Kubernetes, le distribuzioni automatizzate possono generarle automaticamente. È anche possibile scegliere un grafico Helm esistente.

Avvertimento

Non scegliere il fleet-system né alcuno degli spazi dei nomi fleet-member, poiché sono spazi dei nomi interni utilizzati da Fleet Manager e non possono essere usati per posizionare l'applicazione.

Usare manifesti Kubernetes esistenti

Se il repository di codice ha già un manifesto Kubernetes, è possibile selezionarlo per controllare quale carico applicativo viene implementato e configurato tramite un'allocazione delle risorse del cluster.

1. Selezionare l'opzione Usa file esistenti di manifesto Kubernetes per la distribuzione per le opzioni di distribuzione.
2. Selezionare il file o la cartella manifest di Kubernetes dal repository.
3. Seleziona il Namespace del Fleet Manager esistente dove organizzare il carico di lavoro.
4. Seleziona il pulsante Avanti.

Generare manifesti Kubernetes

Usare le distribuzioni automatiche di Fleet Manager per generare un set di file manifesto Kubernetes di base per rendere operativa l'applicazione. Attualmente, le distribuzioni automatizzate creano un Deploymentoggetto , un Servicee un oggetto ConfigMap.

I manifesti generati sono progettati per applicare raccomandazioni sulle misure di sicurezza della distribuzione, ad esempio:

• Generazione automatica di probe di attività, idoneità e avvio.
• Preferenza per anti-affinità pod e vincoli di estensione topologia che estendono le repliche su nodi diversi per migliorare la resilienza.
• Applicazione del RuntimeDefaultprofilo di elaborazione sicuro che stabilisce un ulteriore livello di protezione dalle vulnerabilità comuni delle chiamate di sistema sfruttate da attori malintenzionati.
• Eliminazione di tutte le funzionalità di Linux, consentendo solo un set limitato seguendo gli standard di base di sicurezza dei pod Kubernetes.

Per generare manifesti Kubernetes:

1. Selezionare Genera file di distribuzione dell'applicazione per le opzioni di distribuzione.
2. Immettere la porta dell'applicazione. Questa porta viene usata nell'elemento Service generato.
3. Seleziona il Namespace del Fleet Manager esistente dove organizzare il carico di lavoro.
4. Imposta la posizione di Salva i file nel repository su una cartella nel repository di origine.
5. Seleziona il pulsante Avanti.

Usa grafico Helm esistente

Se il repository di codice ha già un grafico Helm, è possibile selezionarlo per compilare l'immagine dell'applicazione.

1. Selezionare Usa grafico Helm esistente per le opzioni di distribuzione.
2. Selezionare la cartella Percorso dei grafici dal repository.
3. Selezionare il percorso del file Values.yaml dal repository.
4. Facoltativamente, specificare gli override del grafico Helm.
5. Seleziona il Namespace del Fleet Manager esistente dove organizzare il carico di lavoro.
6. Seleziona il pulsante Avanti.

Rivedere la configurazione

Esaminare la configurazione per il repository, l'immagine e la configurazione della distribuzione.

Selezionare Avanti per avviare il processo che esegue queste azioni:

1. Creare credenziali federate per consentire a GitHub Action di:
   1. Pubblicare l'immagine del contenitore compilata su Azure Container Registry.
   2. Collocare i manifesti Kubernetes nello spazio dei nomi selezionato nel cluster hub di Gestione flotta.
2. Creare una richiesta pull nel repository di codice con tutti i file generati e il flusso di lavoro.

Il programma di installazione richiede alcuni minuti, quindi non uscire dalla pagina Distribuisci.

Esaminare e unire una richiesta pull

Al termine della fase Distribuisci, selezionare il pulsante Approva richiesta pull per aprire la richiesta pull generata nel repository di codice.

Annotazioni

Esiste un problema noto con la denominazione della richiesta pull generata in cui viene indicato che distribuisce in AKS. Nonostante questo nome non corretto, il flusso di lavoro risultante esegue lo staging del carico di lavoro nel cluster hub di Gestione flotta nello spazio dei nomi selezionato.

1. Esaminare le modifiche in File modificate e apportare le modifiche desiderate.
2. Selezionare Merge pull request per unire le modifiche nel repository di codice.

L'unione delle modifiche avvia il flusso di lavoro di GitHub Actions che costruisce l'applicazione in un'immagine del container e la archivia nel Registro dei Container di Azure selezionato.

Controllare le risorse generate

Al termine della pipeline, è possibile esaminare l'immagine del contenitore creata nel portale di Azure individuando l'istanza di Registro Azure Container configurata e aprendo il repository di immagini.

È anche possibile visualizzare la configurazione di Fleet Manager Automated Deployment. Selezionando il workflow nome si apre GitHub in GitHub Action.

Infine, è possibile verificare che le risorse Kubernetes previste siano in fase di gestione temporanea nel cluster hub di Fleet Manager.

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

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

L'output è simile a quanto indicato di seguito. Le repliche pari a 0 sono previste perché i carichi di lavoro non sono pianificati nel cluster hub di Gestione flotta. Assicurarsi che la proprietà Image punti all'immagine creata nel Registro Container di Azure.

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>

Definire il posizionamento delle risorse del cluster

Durante l'anteprima, per configurare il posizionamento del carico di lavoro a fasi nei cluster membri, è possibile seguire questa procedura.

1. Nel repository del codice sorgente per l'applicazione, creare una cartella nella radice del repository denominata fleet.

2. Creare un nuovo file deploy-contoso-ns-two-regions.yaml nella cartella fleet e aggiungere il contenuto visualizzato. Questo esempio distribuisce lo contoso-store spazio dei nomi tra due cluster che devono trovarsi in due aree di Azure diverse.

   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. Modificare il file del flusso di lavoro di GitHub Action aggiungendo un riferimento al file CRP.

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

4. Effettuare il commit del nuovo manifesto CRP e aggiornare il file del flusso di lavoro GitHub Action.

5. Controllare che il carico di lavoro venga inserito in base ai criteri definiti nella definizione CRP. Puoi controllare utilizzando il portale di Azure oppure kubectl dalla riga di comando.

Passaggi successivi

• Usare il posizionamento delle risorse cluster per distribuire i carichi di lavoro in più cluster.
• Posizionamento intelligente delle risorse Kubernetes tra cluster in base alle proprietà dei cluster membri.
• Domande frequenti sulle distribuzioni automatizzate.