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) 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 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
spécifiques Coordination entre plusieurs équipes et environnements
Ce modèle implémente un flux de travail GitHub Actions
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
et votre propre GitHub référentiel pour exécuter le flux de travail Un compte AWS
actif avec des autorisations administratives
2. Installation d'outils locaux
Terraform
version 1.13.0 ou ultérieure GitHub CLI
(gh), configurée avec les informations d'identification appropriées kubectl et eksctl, 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 et accès au ConfigMapcluster 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)
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
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
Nécessite l'accessibilité des terminaux du cluster
Limité aux groupes de AWS-managed nœuds
Architecture
Pile technologique cible
Architecture cible

Le flux de travail GitHub Actions est déclenché depuis le GitHub référentiel par l'utilisateur.
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.
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.
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.
Le flux de travail active le mode automatique EKS dans le cluster EKS.
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.
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 :
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.backup-and-check: sauvegarde l'état du cluster avant la migration.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) 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 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) 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) 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
HashiCorp Terraforme :
Terraform
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
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. Consultez le fichier 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
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 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. 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.
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
| Sous-tâche | Description | Compétences requises |
|---|---|---|
Configurez le GitHub référentiel. |
| AWS DevOps, architecte du cloud |
| Sous-tâche | Description | Compétences requises |
|---|---|---|
Configurer IAM pour la sauvegarde et la suppression de groupes de nœuds |
Remplacez $CLUSTER_NAME et $ACCOUNT_ID par les valeurs appropriées.
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 |
| 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 | AWS DevOps, architecte du cloud |
| Sous-tâche | Description | Compétences requises |
|---|---|---|
Mise en œuvre d'un déploiement multi-environnement. |
|
| Sous-tâche | Description | Compétences requises |
|---|---|---|
nettoyer les ressources. |
| 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 | <role-arn>• 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 | <cluster-name>• 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 |