View a markdown version of this page

Aktivieren Sie den automatischen Amazon EKS-Modus für alle EKS-Cluster mithilfe von GitHub Aktionen - AWS Prescriptive Guidance

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Aktivieren Sie den automatischen Amazon EKS-Modus für alle EKS-Cluster mithilfe von GitHub Aktionen

Urbija Goswami und Anugrah Lakra, Amazon Web Services

Zusammenfassung

Amazon Elastic Kubernetes Service (EKS) -Cluster erfordern traditionell eine manuelle Verwaltung der Rechenressourcen über Knotengruppen. Dadurch entsteht betrieblicher Overhead für:

  • Entscheidungen zur Kapazitätsplanung und Skalierung

  • Bereitstellung von Knoten und Lebenszyklusmanagement

  • Kostenoptimierung für verschiedene Workload-Typen

  • Wartung und Aktualisierung der Infrastruktur

Amazon EKS Auto Mode automatisiert das Rechenressourcenmanagement durch die dynamische Bereitstellung und Skalierung von Knoten auf der Grundlage der Workload-Anforderungen, sodass kein manuelles Knotengruppenmanagement erforderlich ist.

Viele Unternehmen haben jedoch Schwierigkeiten, Amazon EKS Auto Mode in ihren bestehenden und neuen Clustern konsistent zu aktivieren und zu verwalten. Zu den häufigsten Herausforderungen gehören:

  • Komplexe Migrationsprozesse aus bestehenden Knotengruppen

  • Risiko einer Betriebsunterbrechung während der Umstellung

  • Sorgfältige Kapazitätsplanung und Tests sind erforderlich

  • Anforderung bestimmter Amazon IAM-Berechtigungen und -Konfigurationen

  • Koordination zwischen mehreren Teams und Umgebungen

Dieses Muster implementiert einen GitHub Actions-Workflow, der den automatischen EKS-Modus auf EKS-Clustern in einer bestimmten AWS-Region aktiviert. Vor der Aktivierung des automatischen Modus erstellt der Workflow Backups des Cluster-Status (Cluster-Konfiguration, Knotengruppen, Helm-Releases und benutzerdefinierte Ressourcen) mit Zeitstempel und lädt sie in einen Amazon S3 S3-Bucket hoch.

Nach der Aktivierung des automatischen Modus entleert und löscht der Workflow alte Knotengruppen, aktualisiert die Cluster-Rollenberechtigungen und bereinigt frühere Skalierungskomponenten wie Karpenter und Cluster Autoscaler. Der Workflow kann in bestehende Continuous Integrations- und Continuous () -Pipelines integriert werden. delivery/deployment CI/CD

Voraussetzungen und Einschränkungen

Voraussetzungen

1. Erforderlich

  • Ein GitHub Konto und Ihr eigenes GitHub Repository, um den Workflow auszuführen

  • Ein aktives AWS-Konto mit Administratorberechtigungen

2. Installation lokaler Tools

3. Anforderungen an den EKS-Cluster

  • Kubernetes Version 1.29 oder höher

  • Konfiguration des Endpunktzugriffs:

    • Entweder ist es auf öffentliche und private Endpunkte eingestellt 

    • Oder privater Endpunkt mit NAT Gateway in privaten Subnetzen

  • EKS-API und ConfigMapClusterzugriff aktiviert (erforderlich, damit EKS Knoten im automatischen Modus dynamisch verwalten und aws-auth ConfigMap für eine korrekte Clusterauthentifizierung während der Migration aktualisieren kann)

  • Aktive Knotengruppen oder verwaltete Knotenpools

4. IAM OIDC-Konfigurationsanforderungen

  • Dazu gehören die IAM-Rolle und der Identitätsanbieter: GitHub

    • Vertrauensrichtlinie für OIDC GitHub

    • Berechtigungen für:

      • EKS-Clusterverwaltung

      • S3-Bucket-Zugriff

      • IAM-Rollen-Verwaltung

      • EC2-Netzwerkmanagement

  • Eine einfache Einrichtung mit Terraform finden Sie im iam.tf-Code. Die IAM-Rolle (GitHubActionsEKSRole) wird erstellt, wenn der Terraform-Code angewendet wird.

Einschränkungen

  • Unterstützt nur EKS-Cluster mit Kubernetes Version 1.29 und höher

  • Unterstützt nur Karpenter Version 1.1.0 und höher

  • Region-specific Implementierung. Einige AWS-Services sind nicht in allen AWS-Regionen verfügbar. Informationen zur regionalen Verfügbarkeit finden Sie unter AWS-Services nach Regionen

  • Erfordert Barrierefreiheit am Cluster-Endpunkt

  • Beschränkt auf AWS-managed Knotengruppen

Architektur

Zieltechnologie-Stack

Zielarchitektur

  1. Der GitHub Aktionsworkflow wird vom Benutzer aus dem GitHub Repository ausgelöst.

  2. Der GitHub Aktionsworkflow nimmt eine IAM-Rolle an und verwendet OIDC, um die erforderlichen Änderungen am AWS-Konto vorzunehmen. Außerdem wird geprüft, ob die EKS Auto Node-Rolle im Konto vorhanden ist. Falls nicht vorhanden, wird die Rolle erstellt und die erforderlichen Richtlinien werden angehängt.

  3. Eine Sicherungskopie des aktuellen Status des EKS-Clusters, für den der automatische Modus aktiviert sein muss, wird in einen S3-Bucket hochgeladen.

  4. Die Clusterrolle des Clusters, für den der automatische Modus aktiviert sein muss, wird abgerufen und ihr werden zusätzliche Berechtigungen (AmazonEKSComputePolicy AmazonEKSBlockStoragePolicy, AmazonEKSLoadBalancingPolicy,, AmazonEKSNetworkingPolicy, AmazonEKSClusterPolicy) hinzugefügt, falls sie nicht für den EKS-Automatikmodus vorhanden sind. Zusätzlich werden vor der Migration die Subnetze der Cluster mit Tags für die Aktivierung des EKS Auto Mode aktualisiert.

  5. Der Workflow aktiviert den automatischen EKS-Modus im EKS-Cluster.

  6. Alte Knotengruppen werden identifiziert und gelöscht. Dies wird übersprungen, wenn der Benutzer der IAM-Rolle nicht die in den nachfolgenden optionalen Einrichtungsschritten beschriebenen Berechtigungen erteilt hat.

  7. Skalierungskomponenten (Karpenter und Cluster Autoscaler) werden ebenfalls entfernt, sofern sie zuvor vorhanden waren.

Der GitHub Aktionsablauf besteht aus drei Hauptaufgaben:

  1. check-clusters: Identifiziert Cluster, für die der automatische Modus nicht aktiviert ist, und aktualisiert IAM-Richtlinien und Subnetz-Tags.

  2. backup-and-check: Sichert den Clusterstatus vor der Migration.

  3. gradual-migration: Aktiviert den automatischen Modus, während bestehende Knotengruppen schrittweise geleert und alte Skalierungskomponenten bereinigt werden. Es führt auch eine abschließende Überprüfung des Clusterstatus nach der Migration durch.

Anmerkung

Wenn Sie Backups der Knotenkonfiguration benötigen oder während der Migration zum automatischen EKS-Modus nodes/node Gruppen löschen möchten, können Sie die mit dem Terraform-Code erstellte IAM-Rolle zu aws-auth hinzufügen. ConfigMap Ohne sie können Sie immer noch Knotengruppenkonfigurationen anzeigen. 

Tools

AWS-CLI:

AWS Command Line Interface (AWS CLI) ist ein Open-Source-Tool, mit dem Sie über Befehle in Ihrer Befehlszeilen-Shell mit AWS-Services interagieren können. In unserer Lösung nutzen wir die Befehlszeilenschnittstelle für AWS-Services, um EKS-Cluster-Konfigurationsupdates und IAM-Rollenaktualisierungen auszuführen und den Cluster-Status während des gesamten Automatisierungsprozesses abzufragen.

Amazon EKS:

Amazon Elastic Kubernetes Service (Amazon EKS) hilft Ihnen dabei, Kubernetes auf AWS auszuführen, ohne Ihre eigene Kubernetes-Steuerebene oder Knoten installieren oder verwalten zu müssen. In diesem Muster ist Amazon EKS der Zielservice, bei dem der Auto-Modus aktiviert ist, um die Rechenbereitstellung und die Knotenskalierung über Cluster in einer bestimmten Region hinweg zu automatisieren.

IAM:

AWS Identity and Access Management (IAM) hilft Ihnen dabei, den Zugriff auf Ihre AWS-Ressourcen sicher zu verwalten, indem kontrolliert wird, wer authentifiziert und autorisiert ist, diese zu verwenden. In unserer Lösung verwenden wir es, um Berechtigungen für GitHub Aktionen zur Änderung von EKS-Cluster-Konfigurationen über den OIDC-Verbund zu verwalten. Die Lösung ändert auch die Berechtigungen der Clusterrollen und fügt einen Job zur Erstellung der EKS-Knotenrolle hinzu, sodass der automatische EKS-Modus die ausstehenden Pods in neuen Knoten einplanen kann, die dann als Teil der Knotenpools eingerichtet werden.

Amazon S3:

Amazon Simple Storage Service (Amazon S3) ist ein cloudbasierter Objektspeicherservice, der Sie beim Speichern, Schützen und Abrufen beliebiger Datenmengen unterstützt. In unserer Lösung verwenden wir einen S3-Bucket, um die Backups der Cluster mit Zeitstempel zu speichern, bevor der automatische EKS-Modus in ihnen aktiviert wird. Dies würde bei der Notfallwiederherstellung helfen.

Andere Tools:

GitHub Aktionen:

GitHub Actions ist eine CI/CD Plattform, die in unserer Lösung verwendet wird, um den Workflow zur Aktivierung des EKS-Automodus zu automatisieren. Sie bietet auch eine sichere Authentifizierung über OIDC und verwaltet die Pipeline-Ausführung über mehrere Cluster hinweg.  

HashiCorp Terraform:

Terraform ist ein Infrastructure-as-Code-Tool (IaC), mit dem Sie mithilfe von Code Cloud-Infrastruktur und -Ressourcen bereitstellen und verwalten können. Unsere Lösung verwendet Terraform, um IAM-Rollen und -Richtlinien bereitzustellen und die OIDC-Anbieterkonfiguration für eine sichere Aktionsintegration hinzuzufügen. GitHub  

Code-Repository

Der Code für dieses Muster ist im Repository GitHub EKS Auto Mode Enablement via GitHub Actions verfügbar.

Best Practices

  • Sicherheit:

    • Folgen Sie dem Prinzip der geringsten Rechte und gewähren Sie die Mindestberechtigungen, die zur Ausführung einer Aufgabe erforderlich sind. Weitere Informationen finden Sie in der IAM-Dokumentation unter Geringste Rechte gewähren und bewährte Methoden zur Sicherheit. Die erforderliche Mindestkonfiguration finden Sie in der Datei iam.tf im Repository. 

    • Richten Sie die Vertrauensrichtlinie für IAM-Rollen auf Ihr spezifisches GitHub Repository und Ihren Branch ein, um zu verhindern, dass unautorisierte Workflow-Läufe die Rolle übernehmen. 

    • Aktivieren Sie die Protokollierung der EKS-Kontrollebene (API-Server, Audit, Authenticator), bevor Sie mit der Migration beginnen, damit Sie Probleme mit der Planung oder Authentifizierung diagnostizieren können, nachdem der automatische Modus aktiviert wurde. 

    • Fügen Sie --sse AES256 zu allen aws s3 cp-Befehlen im Backup-Skript hinzu, um serverseitige Verschlüsselung bei Clusterstatus-Backups durchzusetzen. 

  • Zuverlässigkeit:

    • Testen Sie den Workflow zunächst mit einem Cluster, der nicht zur Produktion gehört. Stellen Sie sicher, dass Workloads auf Knoten im automatischen Modus korrekt neu geplant werden, bevor Sie Produktionscluster migrieren. 

    • Stellen Sie sicher, dass S3-Backups erfolgreich abgeschlossen wurden und gültige Clusterkonfigurations-, Knotengruppen-, Helm-Release- und benutzerdefinierte Ressourcendaten enthalten, bevor Sie mit der Aktivierung des automatischen Modus fortfahren. 

    • Nachdem Sie den automatischen Modus aktiviert haben, können Sie Pod-Scheduling-Ereignisse und die Latenz bei der Knotenbereitstellung mithilfe von Amazon CloudWatch Container Insights überwachen, um Probleme frühzeitig zu erkennen. 

  • Leistung:

    • Überprüfen Sie regelmäßig die Skalierungsmuster für Knotenpools im automatischen Modus und passen Sie die Anforderungen und Grenzwerte für Workload-Ressourcen an, um Überbereitstellungen oder Verzögerungen bei der Planung zu vermeiden.

  • Kosten:

    • Kennzeichnen Sie EKS-Cluster und zugehörige Ressourcen (IAM-Rollen, S3-Backup-Buckets, Subnetze) mit Umgebungs- und Eigentumsmetadaten, um die Kostenverfolgung und betriebliche Transparenz zu unterstützen. Weitere Informationen finden Sie in der Dokumentation zum Taggen von AWS-Ressourcen. Sie können die Workflow-Datei bearbeiten, um während des Migrationsprozesses benutzerdefinierte Tags hinzuzufügen. 

    • Richten Sie AWS Cost Explorer Explorer-Benachrichtigungen ein, um Änderungen der Rechenkosten nach der Aktivierung des automatischen Modus zu überwachen, da der automatische Modus die Instance-Typen und das Skalierungsverhalten ändern kann. Weitere Informationen finden Sie in der Dokumentation Analysieren Ihrer Kosten mit AWS Cost Explorer.  

  • Operationen:

    • Behalten Sie die Versionskontrolle für die Workflow-Datei und die Terraform-Konfigurationen bei und dokumentieren Sie alle umgebungsspezifischen Überschreibungen wie Region, Rollen-ARN oder S3-Bucket-Namen.   

Epen

AufgabeDescriptionErforderliche Fähigkeiten

Konfigurieren Sie das GitHub Repository.

  1. Klonen und forken Sie das GitHub Repository. Kopieren Sie die Workflow-Datei nach dem Klonen in Ihr 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. Übernehmen Sie die Änderungen und übertragen Sie sie in Ihr Repository GitHub

    cd <path/to/your/repository> git add . git commit -m "Added EKS Auto Mode configurations" git push origin main
  3. Richten Sie die Git-Secrets für das Repository ein:

    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, Cloud-Architekt
AufgabeDescriptionErforderliche Fähigkeiten

Richten Sie IAM für die Sicherung und das Löschen von Knotengruppen ein

  1. Fügen Sie die Rolle über Ihr Terminal zur aws-auth ConfigMap hinzu:

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

Ersetzen Sie $CLUSTER_NAME und $ACCOUNT_ID durch die entsprechenden Werte.

  1. Für mehr als einen Cluster können Sie die folgenden Befehle im Terminal ausführen und dabei eine Rolle annehmen, die über Administratorzugriff oder eine gleichwertige Zugriffsberechtigung auf Ihr Konto verfügt:

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

Ersetzen Sie $AWS_REGION und $ROLE_ARN durch die spezifische Region bzw. den ARN der oben erstellten IAM-Rolle.

AWS DevOps, Cloud-Architekt
AufgabeDescriptionErforderliche Fähigkeiten

Löst den GitHub Aktionen-Workflow aus.

Der Workflow wird automatisch ausgelöst, wenn Änderungen an den Feature-, Main- oder Dev-Branches vorgenommen werden. Manuelles Auslösen über die GitHub Benutzeroberfläche: 1. Gehe zum Repository am GitHub 2. Klicken Sie auf die Registerkarte „Aktionen“ 3. Wählen Sie den Workflow (Auto-Mode-Pipeline) 4. Klicken Sie auf die Schaltfläche „Workflow ausführen“ 5. Wählen Sie den Zweig aus und klicken Sie auf „Workflow ausführen“

Der Workflow führt die Überprüfung nach der Migration durch, indem er die Rechenkonfiguration jedes migrierten Clusters mithilfe der AWS-CLI abfragt, um zu bestätigen, dass der automatische EKS-Modus erfolgreich aktiviert wurde, und zeigt die aktuellen Recheneinstellungen in einem Tabellenformat an.

AWS DevOps, Cloud-Architekt
AufgabeDescriptionErforderliche Fähigkeiten

Implementierung der Bereitstellung in mehreren Umgebungen.

  • Die Lösung kann umgebungsspezifisch gestaltet werden, indem Bereitstellungen in Zweigstellen genutzt werden.

  • Verschiedene Branches (main, dev, feat/*) lösen Workflows mit umgebungsspezifischen Konfigurationen mithilfe von Geheimnissen (AWS_REGION,, S3_BACKUP_BUCKET) aus. GitHub AWS_ROLE_ARN

  • Dies ermöglicht separate AWS-Regionen, IAM-Rollen und Clustergruppen pro Umgebung bei gleichzeitiger Beibehaltung einer konsistenten Automatisierungslogik in allen Umgebungen.

AufgabeDescriptionErforderliche Fähigkeiten

Bereinigen Sie die Ressourcen.

  1. Verwenden Sie den folgenden Terminalbefehl, um die IAM-Rolle von aws-auth ConfigMap zu trennen:

    eksctl delete iamidentitymapping \ --cluster $cluster \ --region $AWS_REGION \ --arn $ROLE_ARN
Allgemein AWS, Cloud-Architekt

Fehlerbehebung

ProblemLösung

Probleme mit der Authentifizierung

• Stellen Sie sicher, dass der GitHub OIDC-Anbieter in AWS IAM korrekt konfiguriert ist

• Überprüfe, ob der ARN der IAM-Rolle in Git Secrets mit der tatsächlichen Rolle übereinstimmt, die mit terraform () erstellt wurde GitHubActionsEKSRole

• Stellen Sie sicher, dass GitHub das Repository die erforderlichen Geheimnisse konfiguriert hat — AWS_REGION und. AWS_ROLE_ARN

• Stellen Sie sicher, dass die AWS-Regionseinstellungen mit Ihren Cluster-Standorten übereinstimmen

Probleme mit Genehmigungen

<role-arn>• Testen Sie IAM-Rollenberechtigungen lokal: bash aws sts assume-role --role-arn --role-session-name test-session aws eks list-clusters

• Stellen Sie sicherUpdateClusterConfig , DescribeCluster dass die Rolle die Berechtigungen eks: und eks: hat

Cluster-Kompatibilität

<cluster-name>• Vergewissern Sie sich, dass auf EKS-Clustern Kubernetes 1.29 oder höher ausgeführt wird: bash aws eks describe-cluster --name --query 'cluster.version'

• Stellen Sie sicher, dass sich die Cluster im Status AKTIV befinden, bevor Sie den automatischen Modus aktivieren

Workflow-Fehler

• Suchen Sie in den GitHub Aktionsprotokollen nach bestimmten Fehlermeldungen

• Überprüfen Sie die Syntax der Workflow-Datei in. github/workflows/auto-modus-pipeline.yml

• Stellen Sie sicher, dass die Umgebungsvariablen im Workflow richtig gesetzt sind

Zugehörige Ressourcen