View a markdown version of this page

Abilita la modalità automatica di Amazon EKS tra i cluster EKS utilizzando GitHub Actions - Prontuario AWS
RiepilogoPrerequisiti e limitazioniArchitectureTools (Strumenti)Best practiceEpicheRisoluzione dei problemiRisorse correlate

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Abilita la modalità automatica di Amazon EKS tra i cluster EKS utilizzando GitHub Actions

Urbija Goswami e Anugrah Lakra, Amazon Web Services

Riepilogo

I cluster Amazon Elastic Kubernetes Service (EKS) richiedono tradizionalmente la gestione manuale delle risorse di elaborazione tramite gruppi di nodi. Ciò crea un sovraccarico operativo per:

  • Decisioni relative alla pianificazione e alla scalabilità della capacità

  • Provisioning dei nodi e gestione del ciclo di vita

  • Ottimizzazione dei costi per diversi tipi di carichi di lavoro

  • Manutenzione e aggiornamenti dell'infrastruttura

La modalità automatica di Amazon EKS automatizza la gestione delle risorse di elaborazione effettuando il provisioning e la scalabilità dinamici dei nodi in base alle richieste del carico di lavoro, eliminando la necessità di una gestione manuale dei gruppi di nodi.

Tuttavia, molte organizzazioni hanno difficoltà ad abilitare e gestire in modo coerente Amazon EKS Auto Mode nei cluster esistenti e nuovi. Le sfide più comuni includono:

  • Processi di migrazione complessi da gruppi di nodi esistenti

  • Rischio di interruzione del servizio durante la transizione

  • Necessità di un'attenta pianificazione e test della capacità

  • Requisiti per autorizzazioni e configurazioni specifiche di Amazon IAM

  • Coordinamento tra più team e ambienti

Questo modello implementa un flusso di lavoro GitHub Actions che abilita la modalità automatica EKS sui cluster EKS in una regione AWS specifica. Prima di abilitare la modalità automatica, il flusso di lavoro crea backup con data e ora dello stato del cluster (configurazione del cluster, gruppi di nodi, versioni Helm e risorse personalizzate) e li carica in un bucket Amazon S3.

Dopo aver abilitato la modalità automatica, il flusso di lavoro scarica ed elimina i vecchi gruppi di nodi, aggiorna le autorizzazioni dei ruoli del cluster e ripulisce i componenti di scalabilità precedenti come Karpenter e Cluster Autoscaler. Il flusso di lavoro può essere integrato con le pipeline di integrazione continua e continuous () esistenti. delivery/deployment CI/CD

Prerequisiti e limitazioni

Prerequisiti

1. Richiesto

  • Un GitHub account e un GitHub repository personale per eseguire il flusso di lavoro

  • Un account AWS attivo con autorizzazioni amministrative

2. Installazione degli strumenti locali

3. Requisiti del cluster EKS

  • Kubernetes versione 1.29 o successiva

  • Configurazione dell'accesso agli endpoint:

    • O è impostato su endpoint pubblici e privati 

    • Oppure endpoint privato con gateway NAT in sottoreti private

  • API EKS e accesso al ConfigMapcluster abilitati (necessario per consentire a EKS di gestire dinamicamente i nodi Auto Mode e aggiornare ConfigMap aws-auth per una corretta autenticazione del cluster durante la migrazione)

  • Gruppi di nodi attivi o pool di nodi gestiti

4. Requisiti di configurazione IAM OIDC

  • Il provider di ruoli e identità IAM a GitHub tal fine include:

    • Politica di fiducia per GitHub OIDC

    • Autorizzazioni per:

      • Gestione dei cluster EKS

      • Accesso al bucket S3

      • Gestione del ruolo IAM

      • Gestione della rete EC2

  • Vedi il codice iam.tf per una semplice configurazione con Terraform. Il ruolo IAM (GitHubActionsEKSRole) verrà creato quando viene applicato il codice Terraform.

Limitazioni

  • Supporta solo i cluster EKS con Kubernetes versione 1.29 e successive

  • Supporta solo la versione 1.1.0 e successive di Karpenter

  • Region-specific implementazione. Alcuni servizi AWS non sono disponibili in tutte le regioni AWS. Per la disponibilità regionale, consulta i servizi AWS per regione

  • Richiede l'accessibilità degli endpoint del cluster

  • Limitato ai gruppi di nodi AWS-managed

Architecture

Stack tecnologico Target

  1. GitHub Azioni

  2. AWS IAM

  3. AWS EKS

  4. Amazon S3

Architettura Target

  1. Il flusso di lavoro GitHub delle azioni viene attivato dal GitHub Repository dall'utente.

  2. GitHub Actions Workflow assume un ruolo IAM utilizzando OIDC per apportare le modifiche necessarie all'account AWS. Verifica inoltre la presenza del ruolo EKS Auto Node nell'account e, se non è presente, il ruolo viene creato e vengono allegate le politiche necessarie.

  3. Un backup dello stato corrente del cluster EKS che richiede l'attivazione della modalità automatica viene caricato su un bucket S3.

  4. Il ruolo del cluster che richiede l'attivazione della modalità automatica viene recuperato e vengono aggiunte autorizzazioni aggiuntive (AmazonEKSComputePolicy,,, AmazonEKSBlockStoragePolicy AmazonEKSLoadBalancingPolicy AmazonEKSNetworkingPolicy, AmazonEKSClusterPolicy) se non sono presenti per EKS Auto Mode. Inoltre, come fase precedente alla migrazione, le sottoreti dei cluster vengono aggiornate con tag per l'abilitazione della modalità EKS Auto.

  5. Il flusso di lavoro abilita la modalità EKS Auto nel cluster EKS.

  6. I vecchi gruppi di nodi vengono identificati ed eliminati. Questa operazione viene ignorata se l'utente non ha fornito le autorizzazioni per il ruolo IAM descritto nei passaggi di configurazione opzionali riportati di seguito.

  7. Anche i componenti di scalabilità (Karpenter e Cluster Autoscaler) vengono rimossi se presenti in precedenza.

Il flusso di lavoro GitHub Actions è composto da tre processi principali:

  1. check-clusters: identifica i cluster senza la modalità automatica abilitata e aggiorna le policy IAM e i tag di sottorete.

  2. backup-and-check: esegue il backup dello stato del cluster prima della migrazione.

  3. gradual-migration: attiva la modalità automatica mentre svuota gradualmente i gruppi di nodi esistenti e pulisce i vecchi componenti di scalabilità. Esegue anche una verifica finale degli stati dei cluster dopo la migrazione.

Nota

Se hai bisogno di backup della configurazione dei nodi o prevedi di eliminare i nodes/node gruppi durante la migrazione a EKS Auto Mode, puoi aggiungere il ruolo IAM creato utilizzando il codice terraform ad aws-auth. ConfigMap Senza di esso, puoi comunque visualizzare le configurazioni dei gruppi di nodi. 

Tools (Strumenti)

CLI AWS:

AWS Command Line Interface (AWS CLI) è uno strumento open source che ti aiuta a interagire con i servizi AWS tramite comandi nella tua shell a riga di comando. Nella nostra soluzione, utilizziamo l'interfaccia a riga di comando per i servizi AWS per eseguire aggiornamenti della configurazione del cluster EKS, aggiornamenti dei ruoli IAM e interrogare lo stato del cluster durante tutto il processo di automazione.

Amazon EKS:

Amazon Elastic Kubernetes Service (Amazon EKS) ti aiuta a eseguire Kubernetes su AWS senza dover installare o gestire il tuo piano di controllo o i tuoi nodi Kubernetes. In questo modello, Amazon EKS è il servizio di destinazione in cui la modalità automatica è abilitata per automatizzare il provisioning di elaborazione e la scalabilità dei nodi tra i cluster in una regione specifica.

IAM/

AWS Identity and Access Management (IAM) ti aiuta a gestire in modo sicuro l'accesso alle tue risorse AWS controllando chi è autenticato e autorizzato a utilizzarle. Nella nostra soluzione, la utilizziamo per gestire le autorizzazioni relative alle azioni di modifica delle GitHub configurazioni dei cluster EKS tramite la federazione OIDC. La soluzione modifica anche le autorizzazioni dei ruoli del cluster e aggiunge un processo per creare EKS Node Role in modo che EKS Auto Mode possa pianificare i pod in sospeso nei nuovi nodi che attiva come parte dei pool di nodi.

Amazon S3:

Amazon Simple Storage Service (Amazon S3) è un servizio di archiviazione degli oggetti basato sul cloud che consente di archiviare, proteggere e recuperare qualsiasi quantità di dati. Nella nostra soluzione, utilizziamo un bucket S3 per archiviare i backup con data e ora dei cluster prima che in essi venga abilitata la modalità EKS Auto, il che aiuterebbe nel ripristino di emergenza.

Altri strumenti:

GitHub Operazioni:

GitHub Actions è una CI/CD piattaforma utilizzata nella nostra soluzione per automatizzare il flusso di lavoro di abilitazione di EKS Auto Mode. Fornisce inoltre un'autenticazione sicura tramite OIDC e gestisce l'esecuzione della pipeline su più cluster.  

HashiCorp Terraform:

Terraform è uno strumento Infrastructure as Code (IaC) che consente di utilizzare il codice per fornire e gestire l'infrastruttura e le risorse cloud. La nostra soluzione utilizza terraform per fornire ruoli e politiche IAM e per aggiungere la configurazione del provider OIDC per l'integrazione sicura di Actions. GitHub  

Archivio di codice

Il codice per questo pattern è disponibile nel repository GitHub EKS Auto Mode Enablement via GitHub Actions.

Best practice

  • Sicurezza:

    • Segui il principio del privilegio minimo e concedi le autorizzazioni minime necessarie per eseguire un'attività. Per ulteriori informazioni, consulta le best practice di G rant least privilege e Security nella documentazione IAM. Consulta il file iam.tf nel repository per la configurazione minima richiesta. 

    • Amplia la policy di fiducia dei ruoli IAM in base al tuo GitHub repository e filiale specifici per evitare che vengano eseguiti flussi di lavoro non autorizzati ad assumere il ruolo. 

    • Abilita la registrazione del piano di controllo EKS (server API, audit, authenticator) prima di iniziare la migrazione in modo da poter diagnosticare problemi di pianificazione o autenticazione dopo aver abilitato la modalità automatica. 

    • Aggiungi --sse AES256 a tutti i comandi aws s3 cp nello script di backup per applicare la crittografia lato server sui backup dello stato del cluster. 

  • Affidabilità:

    • Verifica prima il flusso di lavoro su un cluster non di produzione. Verifica che i carichi di lavoro vengano riprogrammati correttamente sui nodi Auto Mode prima di migrare i cluster di produzione. 

    • Verifica che i backup S3 siano stati completati correttamente e contengano configurazioni di cluster, gruppi di nodi, release Helm e dati di risorse personalizzati validi prima di procedere con l'attivazione della modalità Auto. 

    • Dopo aver abilitato la modalità automatica, monitora gli eventi di pianificazione dei pod e la latenza di provisioning dei nodi utilizzando Amazon CloudWatch Container Insights per rilevare tempestivamente i problemi. 

  • Prestazioni:

    • Rivedi periodicamente i modelli di scalabilità dei pool di nodi in modalità automatica e modifica le richieste e i limiti delle risorse del carico di lavoro per evitare ritardi nell'eccessivo provisioning o nella pianificazione.

  • Costo:

    • Contrassegna i cluster EKS e le risorse associate (ruoli IAM, bucket di backup S3, sottoreti) con metadati di ambiente e proprietà per supportare il monitoraggio dei costi e la visibilità operativa. Per ulteriori informazioni, consulta la documentazione sull'etichettatura delle risorse AWS. Puoi modificare il file del flusso di lavoro per aggiungere tag personalizzati durante il processo di migrazione. 

    • Imposta gli avvisi di AWS Cost Explorer per monitorare le variazioni dei costi di calcolo dopo aver abilitato la modalità automatica, poiché la modalità automatica può modificare i tipi di istanze e il comportamento di scalabilità. Per ulteriori informazioni, consulta la documentazione sull'analisi dei costi con AWS Cost Explorer.  

  • Operazioni:

    • Conserva il file del flusso di lavoro e le configurazioni Terraform nel controllo della versione e documenta eventuali modifiche specifiche dell'ambiente come regione, ruolo ARN o nome del bucket S3.   

Epiche

OperazioneDescriptionCompetenze richieste

Configura il GitHub repository.

  1. Clona e crea un fork del repository. GitHub Una volta clonato, copia il file del flusso di lavoro nel tuo repository GitHub  

    git clone https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions.git
    cd sample-enable-eks-auto-mode-using-github-actions
    cp .github/workflows/enable-eks-auto-mode.yml /path/to/your/repository/.github/workflows

  2. Conferma e invia le modifiche al tuo repository GitHub 

    cd <path/to/your/repository>
git add .
git commit -m "Added EKS Auto Mode configurations"
git push origin main

  3. Imposta i git secrets per il repository:

    gh auth login --web  #authenticate to your github account using web
    #create secrets
gh secret set AWS_REGION --body "us-east-1" 
    gh secret set AWS_ROLE_ARN --body "arn:aws:iam:ACCOUNT_ID:role/GitHubActionsEKSRole" 
#replace the account id with your account ID
AWS DevOps, architetto del cloud
OperazioneDescriptionCompetenze richieste

Configura IAM per il backup e l'eliminazione dei gruppi di nodi

  1. Aggiungi il ruolo a aws-auth ConfigMap usando il tuo terminale:

eksctl create iamidentitymapping \ --cluster $CLUSTER_NAME\ --region us-east-1 \ --arn arn:aws:iam::$ACCOUNT_ID:role/GitHubActionsEKSRole \ --group system:masters \ --username github-actions

Sostituisci $CLUSTER_NAME e $ACCOUNT_ID con i valori appropriati.

  1. Per più di un cluster, puoi eseguire i seguenti comandi nel terminale assumendo un ruolo con accesso di livello amministratore o equivalente all'account:

CLUSTERS=$(aws eks list-clusters --region $AWS_REGION --query 'clusters[]' --output text)

CLUSTERS_NEEDING_AUTO_MODE=""

for cluster in $CLUSTERS; do
    
    
    AUTO_MODE=$(aws eks describe-cluster --name $cluster --region $AWS_REGION --query 'cluster.computeConfig.enabled' --output text 2>/dev/null || echo "false")
    
    if [ "$AUTO_MODE" != "True" ]; then
       
        CLUSTERS_NEEDING_AUTO_MODE="$CLUSTERS_NEEDING_AUTO_MODE $cluster"
        
        echo " Adding role access to cluster..."
        eksctl create iamidentitymapping \
          --cluster $cluster \
          --region $AWS_REGION \
          --arn $ROLE_ARN \
          --group system:masters\
          --username github-actions || echo "  ⚠️  Role mapping may already exist"
        
        echo "  ✅ Role access configured for $cluster"
done

Sostituisci $AWS_REGION e $ROLE_ARN rispettivamente con la regione specifica e l'arn del ruolo IAM creati sopra.

AWS DevOps, architetto del cloud
OperazioneDescriptionCompetenze richieste

Attiva il flusso di lavoro GitHub Actions.

Il flusso di lavoro viene attivato automaticamente quando vengono apportate modifiche ai rami delle funzionalità, principale o di sviluppo. Per attivare manualmente tramite l' GitHub interfaccia utente: 1. Vai al repository su GitHub 2. Fai clic sulla scheda «Azioni» 3. Seleziona il flusso di lavoro (auto-mode-pipeline) 4. Fai clic sul pulsante «Esegui flusso di lavoro» 5. Scegli il ramo e fai clic su «Esegui flusso di lavoro»

Il flusso di lavoro gestisce la verifica dopo la migrazione interrogando la configurazione di calcolo di ogni cluster migrato utilizzando l'AWS CLI per confermare che EKS Auto Mode è stata abilitata correttamente e visualizza le impostazioni di calcolo correnti in un formato tabellare.

AWS DevOps, architetto del cloud
OperazioneDescriptionCompetenze richieste

Implementazione di una distribuzione multiambiente.

  • La soluzione può essere resa specifica per l'ambiente sfruttando le implementazioni basate sulle filiali.

  • Diversi rami (main, dev, feat/*) attivano flussi di lavoro con configurazioni specifiche dell'ambiente tramite segreti (AWS_REGION, S3_BACKUP_BUCKET). GitHub AWS_ROLE_ARN

  • Ciò consente regioni AWS, ruoli IAM e set di cluster separati per ambiente, mantenendo al contempo una logica di automazione coerente in tutti gli ambienti.

OperazioneDescriptionCompetenze richieste

Eliminare le risorse.

  1. Per scollegare il ruolo IAM da aws-auth ConfigMap, usa il seguente comando da terminale:

    eksctl delete iamidentitymapping \   --cluster $cluster \   --region $AWS_REGION \   --arn $ROLE_ARN
General AWS, architetto del cloud

Risoluzione dei problemi

ProblemaSoluzione

Problemi di autenticazione

• Verificare che il provider GitHub OIDC sia configurato correttamente in AWS IAM

• Verifica che il ruolo IAM ARN in git secrets corrisponda al ruolo effettivo creato con terraform () GitHubActionsEKSRole

• Assicurati che il GitHub repository abbia i segreti necessari configurati: AWS_REGION e. AWS_ROLE_ARN

• Verifica che le impostazioni della regione AWS corrispondano alle posizioni dei cluster

Problemi di autorizzazione

<role-arn>• Verifica i permessi dei ruoli IAM localmente: bash aws sts assume-role --role-arn --role-session-name test-session aws eks list-clusters

• Assicurati che UpdateClusterConfig il DescribeCluster ruolo abbia i permessi eks: ed eks:

Compatibilità con i cluster

<cluster-name>• Conferma che i cluster EKS eseguano Kubernetes 1.29 o versioni successive: bash aws eks describe-cluster --name --query 'cluster.version'

• Verifica che i cluster siano in stato ATTIVO prima di abilitare la modalità automatica

Errori del flusso di lavoro

• Controlla i registri GitHub delle azioni per messaggi di errore specifici

• Verificare la sintassi del file di workflow in. github/workflows/auto-mode-pipeline.yml

• Assicurarsi che le variabili di ambiente siano impostate correttamente nel flusso di lavoro

Risorse correlate

  1. Documentazione ufficiale di EKS Auto Mode per iniziare

  2. Aggiorna la documentazione CLI di configurazione del cluster

  3. GitHub segreti per le azioni GitHub

  4. GitHub Documentazione sulle azioni 

  5. Documentazione della federazione OIDC