Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Activez le mode automatique Amazon EKS sur les clusters EKS à l'aide d' GitHub actions *Urbija Goswami et Anugrah Lakra, Amazon Web Services* ## Résumé Les clusters [Amazon Elastic Kubernetes Service (EKS](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/amazon-elastic-kubernetes-service.html)) nécessitent généralement une gestion manuelle des ressources de calcul via des groupes de nœuds. Cela crée une surcharge opérationnelle pour : + Planification des capacités et décisions de mise à l'échelle + Provisionnement des nœuds et gestion du cycle de vie + Optimisation des coûts pour différents types de charge de travail + Maintenance et mises à jour de l'infrastructure Amazon EKS [Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) automatise la gestion des ressources informatiques en provisionnant et en dimensionnant dynamiquement les nœuds en fonction des demandes de charge de travail, éliminant ainsi le besoin de gestion manuelle des groupes de nœuds. Cependant, de nombreuses entreprises ont du mal à activer et à gérer de manière cohérente le mode automatique d'Amazon EKS sur leurs clusters existants et nouveaux. Les défis courants sont notamment les suivants : + Processus de migration complexes à partir de groupes de nœuds existants + Risque d'interruption de service pendant la transition + Nécessité de planifier et de tester soigneusement les capacités + Exigence d'autorisations et de [configurations Amazon IAM](https://aws.amazon.com/iam/?trk=6a436c72-0178-4620-97ad-0220ccc59fd0&sc_channel=ps&ef_id=CjwKCAjw7vzOBhBxEiwAc7WNr57daOn9724PwXVGy7aBxG_uuEHktjCWJbcY1q1BrZBaApyi1sAb_BoCQj0QAvD_BwE:G:s&s_kwcid=AL!4422!3!795924581177!e!!g!!amazon%20iam!23523526050!193629723318&gad_campaignid=23523526050&gbraid=0AAAAADjHtp_aCwsziIR-n3ST_xwoCqAuc&gclid=CjwKCAjw7vzOBhBxEiwAc7WNr57daOn9724PwXVGy7aBxG_uuEHktjCWJbcY1q1BrZBaApyi1sAb_BoCQj0QAvD_BwE) spécifiques + Coordination entre plusieurs équipes et environnements Ce modèle implémente un flux de travail [GitHub Actions](https://docs.github.com/en/actions) qui active le mode automatique EKS sur les clusters EKS d'une région AWS spécifique. [Avant d'activer le mode automatique, le flux de travail crée des sauvegardes horodatées de l'état du cluster (configuration du cluster, groupes de nœuds, versions Helm et ressources personnalisées) et les télécharge dans un compartiment Amazon S3.](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) Après avoir activé le mode automatique, le flux de travail vide et supprime les anciens groupes de nœuds, met à jour les autorisations relatives aux rôles du cluster et nettoie les composants de dimensionnement précédents tels que Karpenter et Cluster Autoscaler. Le flux de travail peut être intégré aux pipelines d'intégration continue et de continuous delivery/deployment (CI/CD) existants. ## Conditions préalables et limitations **Conditions préalables** **1. Nécessaire** + Un [GitHub compte](https://github.com/) et votre propre GitHub référentiel pour exécuter le flux de travail + Un [compte AWS](https://aws.amazon.com/account/) actif avec des autorisations administratives **2. Installation d'outils locaux** + [Terraform](https://developer.hashicorp.com/terraform/install) version 1.13.0 ou ultérieure + [GitHub CLI](https://cli.github.com/) (gh), configurée avec les informations d'identification appropriées + [kubectl et [eksctl](https://docs.aws.amazon.com/eks/latest/eksctl/installation.html)](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html), configurés pour la gestion de clusters **3. Exigences du cluster EKS** + Kubernetes version 1.29 ou ultérieure + Configuration de l'accès aux terminaux : + Soit il est défini sur des points de terminaison publics ou privés  + Ou point de terminaison privé avec passerelle NAT dans des sous-réseaux privés + [API EKS](https://docs.aws.amazon.com/eks/latest/userguide/grant-k8s-access.html) et accès au [ConfigMap](https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html)cluster activés (nécessaire pour permettre à EKS de gérer dynamiquement les nœuds en mode automatique et de mettre à jour l'aws-auth ConfigMap pour une authentification correcte du cluster lors de la migration) + [Groupes de nœuds actifs ou pools de nœuds gérés](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) **4. Exigences de configuration IAM OIDC** + Le rôle IAM et le fournisseur d'identité à GitHub cet égard incluent : + Politique de confiance pour l' GitHub OIDC + Autorisations pour : + Gestion du cluster EKS + Accès au compartiment S3 + Gestion des rôles IAM + Gestion du réseau EC2 + Consultez le code [iam.tf](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/blob/main/iam.tf) pour une configuration simple à l'aide de Terraform. Le rôle IAM (GitHubActionsEKSRole) sera créé lorsque le code Terraform sera appliqué. **Limites** + Supporte uniquement les clusters EKS avec Kubernetes version 1.29 et supérieure + Compatible uniquement avec les versions 1.1.0 et supérieures de Karpenter + Region-specific mise en œuvre. Certains services AWS ne sont pas disponibles dans toutes les régions AWS. Pour connaître la disponibilité par région, consultez la section [Services AWS par région](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) + Nécessite l'accessibilité des terminaux du cluster + Limité aux groupes de AWS-managed nœuds ## Architecture **Pile technologique cible** 1. [https://docs.github.com/en/actions](https://docs.github.com/en/actions) 1. [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 1. [https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/amazon-elastic-kubernetes-service.html](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/amazon-elastic-kubernetes-service.html) 1. [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) **Architecture cible** ![](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/images/pattern-img/e1fa4e49-96a5-42ae-9886-766298664db4/images/a2c46a84-3bf5-4f1e-8216-ab29b4ba894e.png) 1. Le flux de travail GitHub Actions est déclenché depuis le GitHub référentiel par l'utilisateur. 1. Le flux de travail GitHub Actions assume un rôle IAM en utilisant OIDC pour apporter les modifications nécessaires au compte AWS. Il vérifie également la présence du rôle EKS Auto Node dans le compte et, s'il n'est pas présent, le rôle est créé et les politiques nécessaires sont jointes. 1. Une sauvegarde de l'état actuel du cluster EKS nécessitant l'activation du mode automatique est téléchargée dans un compartiment S3. 1. Le rôle de cluster du cluster nécessitant l'activation du mode automatique est récupéré et des autorisations supplémentaires (AmazonEKSComputePolicy, AmazonEKSBlockStoragePolicy, AmazonEKSLoadBalancingPolicy, AmazonEKSNetworkingPolicy, AmazonEKSClusterPolicy) y sont ajoutées si le mode automatique EKS n'est pas présent. En outre, en tant qu'étape préalable à la migration, les sous-réseaux des clusters sont mis à jour avec des balises pour l'activation du mode automatique EKS. 1. Le flux de travail active le mode automatique EKS dans le cluster EKS. 1. Les anciens groupes de nœuds sont identifiés et supprimés. Cette opération est ignorée si l'utilisateur n'a pas accordé les autorisations pour le rôle IAM décrites dans les étapes de configuration facultatives ci-dessous. 1. Les composants de mise à l'échelle (Karpenter et Cluster Autoscaler) sont également supprimés s'ils étaient présents précédemment. Le flux de travail GitHub Actions comprend trois tâches principales : 1. `check-clusters`: identifie les clusters dont le mode automatique n'est pas activé et met à jour les politiques IAM et les balises de sous-réseau. 1. `backup-and-check`: sauvegarde l'état du cluster avant la migration. 1. `gradual-migration`: Active le mode automatique tout en vidant progressivement les groupes de nœuds existants et en nettoyant les anciens composants de dimensionnement. Il effectue également une vérification finale de l'état des clusters après la migration. **Note** Si vous avez besoin de sauvegardes de configuration de nœuds ou si vous prévoyez de supprimer nodes/node des groupes lors de la migration vers le mode automatique EKS, vous pouvez ajouter le rôle IAM créé à l'aide du code terraform à aws-auth. ConfigMap Sans cela, vous pouvez toujours consulter les configurations des groupes de nœuds.  ## Outils *CLI AWS :* [L'interface de ligne de commande AWS (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) est un outil open source qui vous permet d'interagir avec les services AWS par le biais de commandes dans votre shell de ligne de commande. Dans notre solution, nous utilisons l'interface de ligne de commande des services AWS pour exécuter les mises à jour de configuration du cluster EKS, les mises à jour des rôles IAM et demander l'état du cluster tout au long du processus d'automatisation. *Amazon EKS :* [Amazon Elastic Kubernetes Service (Amazon](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) EKS) vous aide à exécuter Kubernetes sur AWS sans avoir à installer ou à gérer votre propre plan de contrôle ou vos propres nœuds Kubernetes. Dans ce modèle, Amazon EKS est le service cible dans lequel le mode automatique est activé pour automatiser le provisionnement du calcul et le dimensionnement des nœuds sur les clusters d'une région spécifique. *IAM :* [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) vous aide à gérer en toute sécurité l'accès à vos ressources AWS en contrôlant qui est authentifié et autorisé à les utiliser. Dans notre solution, nous l'utilisons pour gérer les autorisations relatives aux GitHub actions visant à modifier les configurations du cluster EKS via la fédération OIDC. La solution modifie également les autorisations des rôles de cluster et ajoute une tâche pour créer le rôle de nœud EKS afin que le mode automatique d'EKS puisse planifier les pods en attente dans les nouveaux nœuds qu'il lance dans le cadre des pools de nœuds. *Amazon S3* **:** [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) est un service de stockage d'objets basé sur le cloud qui vous permet de stocker, de protéger et de récupérer n'importe quel volume de données. Dans notre solution, nous utilisons un compartiment S3 pour stocker les sauvegardes horodatées des clusters avant que le mode automatique EKS ne soit activé dans ceux-ci, ce qui facilitera la reprise après sinistre. **Autres outils :** *GitHub Actions :* [GitHub Actions](https://docs.github.com/en/actions) est une CI/CD plate-forme utilisée dans notre solution pour automatiser le flux de travail d'activation du mode automatique EKS. Il fournit également une authentification sécurisée via OIDC et gère l'exécution du pipeline sur plusieurs clusters.   *HashiCorp Terraforme :* [Terraform](https://developer.hashicorp.com/terraform/docs) est un outil d'infrastructure en tant que code (IaC) qui vous aide à utiliser le code pour provisionner et gérer l'infrastructure et les ressources du cloud. Notre solution utilise Terraform pour fournir des rôles et des politiques IAM et pour ajouter la configuration du fournisseur OIDC pour une intégration sécurisée des actions. GitHub   **Référentiel de code** Le code de ce modèle est disponible dans le référentiel GitHub [EKS Auto Mode Enablement via GitHub Actions](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/tree/main). ## Bonnes pratiques + **Sécurité**: + Respectez le principe du moindre privilège et accordez les autorisations minimales requises pour effectuer une tâche. Pour plus d'informations, consultez G [rant Least Privilege et les meilleures pratiques en matière de sécurité dans la documentation IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege.). Consultez le fichier [iam.tf](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/blob/main/iam.tf) dans le référentiel pour connaître la configuration minimale requise.  + Appliquez la politique de confiance aux rôles IAM à votre GitHub référentiel et à votre branche spécifiques afin d'empêcher les flux de travail non autorisés d'assumer ce rôle.  + Activez la journalisation du plan de contrôle EKS (serveur API, audit, authentificateur) avant de commencer la migration afin de pouvoir diagnostiquer les problèmes de planification ou d'authentification une fois le mode automatique activé.  + Ajoutez --sse AES256 à toutes les commandes aws s3 cp dans le [script de sauvegarde](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/blob/main/scripts/backup-cluster-state.sh) pour appliquer le chiffrement côté serveur aux sauvegardes de l'état du cluster.  + **Fiabilité** : + Testez d'abord le flux de travail par rapport à un cluster hors production. Vérifiez que les charges de travail sont correctement replanifiées sur les nœuds en mode automatique avant de migrer les clusters de production.  + Vérifiez que les sauvegardes S3 se sont bien déroulées et contiennent des données de configuration de cluster, de groupe de nœuds, de version de Helm et de ressources personnalisées valides avant de procéder à l'activation du mode automatique.  + Après avoir activé le mode automatique, surveillez les événements de planification des pods et la latence du provisionnement des nœuds à l'aide d'[Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) pour détecter les problèmes à un stade précoce.  + **Rendement** : + Passez régulièrement en revue les modèles de dimensionnement du pool de nœuds en mode automatique et ajustez les demandes et les limites des ressources de charge de travail afin d'éviter le surprovisionnement ou les retards de planification. + **Coût:** + Ajoutez des métadonnées d'environnement et de propriété aux clusters EKS et aux ressources associées (rôles IAM, compartiments de sauvegarde S3, sous-réseaux) pour faciliter le suivi des coûts et la visibilité opérationnelle. Pour plus d'informations, consultez la [documentation sur le balisage des ressources AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html.). Vous pouvez modifier le fichier de flux de travail pour ajouter des balises personnalisées pendant le processus de migration.  + Configurez des alertes AWS Cost Explorer pour surveiller l'évolution des coûts de calcul après avoir activé le mode automatique, car le mode automatique peut modifier les types d'instances et le comportement de dimensionnement. Pour plus d'informations, consultez la [documentation relative à l'analyse de vos coûts avec AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html.).   + **Opérations** : + Conservez le fichier de flux de travail et les configurations Terraform sous contrôle de version et documentez toute dérogation spécifique à l'environnement, telle que la région, l'ARN du rôle ou le nom du compartiment S3.    ## Épopées ### Outil SetUp | Sous-tâche | Description | Compétences requises | | --- | --- | --- | | Configurez le GitHub référentiel. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html) | AWS DevOps, architecte du cloud | ### (Facultatif) Configurer un rôle IAM | Sous-tâche | Description | Compétences requises | | --- | --- | --- | | Configurer IAM pour la sauvegarde et la suppression de groupes de nœuds | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html)
eksctl create iamidentitymapping \ --cluster $CLUSTER_NAME\ --region us-east-1 \ --arn arn:aws:iam::$ACCOUNT_ID:role/GitHubActionsEKSRole \ --group system:masters \ --username github-actions
Remplacez **$CLUSTER\_NAME et **$ACCOUNT\_ID**** par les valeurs appropriées. [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html)
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

Remplacez **$AWS\_REGION** et **$ROLE\_ARN** par la région spécifique et l'ARN du rôle IAM créés ci-dessus respectivement. | AWS DevOps, architecte du cloud | ### Exécuter et valider | Sous-tâche | Description | Compétences requises | | --- | --- | --- | | Déclenchez le flux de travail GitHub Actions. | Le flux de travail est déclenché automatiquement lorsque des modifications sont apportées aux branches feature, main ou dev. Pour déclencher manuellement via l' GitHub interface utilisateur : 1. Accédez au référentiel le GitHub 2. Cliquez sur l'onglet « Actions » 3. Sélectionnez le flux de travail (mode automatique, pipeline) 4. Cliquez sur le bouton « Exécuter le flux de travail » 5. Choisissez la branche et cliquez sur « Exécuter le flux de travail »
Le flux de travail gère la [vérification](https://github.com/aws-samples/sample-enable-eks-auto-mode-using-github-actions/blob/22b546b05630c63e5637928ad8a4f5947ad8fb33/.github/workflows/enable-eks-auto-mode.yml#L283) après la migration en interrogeant la configuration de calcul de chaque cluster migré à l'aide de l'AWS CLI pour confirmer que le mode automatique EKS a été correctement activé et affiche les paramètres de calcul actuels sous forme de tableau. | AWS DevOps, architecte du cloud | ### Configuration du déploiement dans plusieurs environnements | Sous-tâche | Description | Compétences requises | | --- | --- | --- | | Mise en œuvre d'un déploiement multi-environnement. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html) | | ### Nettoyage | Sous-tâche | Description | Compétences requises | | --- | --- | --- | | nettoyer les ressources. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/enable-eks-auto-mode-using-github-actions.html) | AWS général, architecte du cloud | ## Résolution des problèmes | Problème | Solution | | --- | --- | | **Problèmes d'authentification**

| • Vérifiez que le fournisseur GitHub OIDC est correctement configuré dans AWS IAM
• Vérifiez que l'ARN du rôle IAM dans git secrets correspond au rôle réel créé avec terraform () GitHubActionsEKSRole
• Assurez-vous que GitHub le référentiel contient les secrets nécessaires configurés - AWS\_REGION et. AWS\_ROLE\_ARN
• Vérifiez que les paramètres de la région AWS correspondent à l'emplacement de votre cluster | | **Problèmes d'autorisation**

| • Testez les autorisations des rôles IAM localement : bash aws sts assume-role --role-arn --role-session-name test-session aws eks list-clusters
• Assurez-vous que le rôle dispose des DescribeCluster autorisations eks : UpdateClusterConfig et eks : | | **Compatibilité avec les clusters**

| • Vérifiez que les clusters EKS exécutent Kubernetes 1.29 ou une version ultérieure : bash aws eks describe-cluster --name --query 'cluster.version'
• Vérifiez que les clusters sont à l'état ACTIF avant d'activer le mode automatique | | **Défaillances du workflow**
| • Vérifiez les journaux d' GitHub actions pour détecter les messages d'erreur spécifiques
• Vérifiez la syntaxe du fichier de flux de travail dans. github/workflows/auto-mode-pipeline.yml
• Assurez-vous que les variables d'environnement sont correctement définies dans le flux de travail | ## Ressources connexes 1. [Documentation officielle d'EKS Auto Mode pour commencer](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) 1. [Mettre à jour la documentation de la CLI de configuration du cluster](https://docs.aws.amazon.com/cli/latest/reference/eks/update-cluster-config.html) 1. [GitHub secrets pour les GitHub actions](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets) 1. [GitHub Documentation sur les actions](https://docs.github.com/en/actions)  1. [Documentation de la fédération OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html)