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.

Arrêtez en toute sécurité les charges de travail Amazon ECS exécutées sur les instances EC2

Le drainage géré des instances facilite la résiliation progressive des instances Amazon EC2 . Cela permet à vos charges de travail de s’arrêter en toute sécurité et d’être reprogrammées vers des instances qui ne sont pas en cours de résiliation. La maintenance et les mises à jour de l’infrastructure sont effectuées sans perturber les charges de travail. En utilisant le drainage d'instance géré, vous simplifiez les flux de travail de gestion de votre infrastructure qui nécessitent le remplacement des EC2 instances Amazon, tout en garantissant la résilience et la disponibilité de vos applications.

Le drainage d'instance géré par Amazon ECS fonctionne avec les remplacements d'instances de groupe Amazon EC2 Auto Scaling. Sur la base de l’actualisation des instances et de leur durée de vie maximale, les clients peuvent s’assurer qu’ils restent conformes aux dernières réglementations en matière de système d’exploitation et de sécurité en matière de capacité.

Le drainage d’instance gérée ne peut être utilisé qu’avec les fournisseurs de capacité Amazon ECS. Vous pouvez activer le drainage géré des instances lorsque vous créez ou mettez à jour les fournisseurs de capacité de votre groupe Amazon EC2 Auto Scaling à l'aide de la console Amazon ECS ou du SDK. AWS CLI

Les événements suivants sont couverts par le drainage d’instance gérée Amazon ECS.

Le cycle de vie EC2 d'Amazon Amazon EC2 Auto Scaling s'accroche à la gestion du drainage des instances

Les hooks du cycle de vie du groupe Amazon EC2 Auto Scaling permettent au client de créer des solutions déclenchées par certains événements du cycle de vie de l'instance et d'effectuer une action personnalisée lorsque cet événement se produit. Un groupe Amazon EC2 Auto Scaling autorise jusqu'à 50 hooks. Plusieurs hooks de terminaison peuvent exister et sont exécutés en parallèle, et le groupe Amazon EC2 Auto Scaling attend que tous les hooks soient terminés avant de mettre fin à une instance.

En plus de la résiliation de hook gérée par Amazon ECS, vous pouvez également configurer vos propres hooks de résiliation de cycle de vie. Les hooks du cycle de vie ont une default action, et nous vous recommandons de le définir sur continue par défaut pour garantir que les autres hooks, tels que le hook géré par Amazon ECS, ne soient pas affectés par les erreurs provenant des hooks personnalisés.

Si vous avez déjà configuré un hook de fin de cycle de vie de groupe Amazon EC2 Auto Scaling et que vous avez également activé le drainage d'instance géré par Amazon ECS, les deux hooks de cycle de vie sont exécutés. Les horaires relatifs ne sont toutefois pas garantis. Les hooks du cycle de vie disposent d’un paramètre default action permettant de spécifier l’action à entreprendre lorsque le délai expire. En cas d’échec, nous vous recommandons d’utiliser continue comme résultat par défaut votre hook personnalisé. Cela garantit que les autres hooks, en particulier les hooks gérés par Amazon ECS, ne sont pas affectés par des erreurs dans votre hook de cycle de vie personnalisé. Le résultat alternatif abandon provoque l’ignorance de tous les autres hooks et doit être évité. Pour plus d'informations sur les hooks du cycle de vie du groupe Amazon EC2 Auto Scaling, consultez les crochets du cycle de vie EC2 Amazon EC2 Auto Scaling dans le guide de l'utilisateur EC2Amazon Amazon EC2 Auto Scaling.

Tâches et drainage d’instance gérée

Le drainage d’instance gérée Amazon ECS utilise la fonctionnalité de drainage existante présente dans les instances de conteneur. La fonctionnalité de drainage des instances de conteneur remplace et arrête les tâches de réplica appartenant à un service Amazon ECS. Une tâche autonome, telle qu’une tâche invoquée par RunTask, qui est à l’état PENDING ou RUNNING reste inchangée. Vous devez attendre qu’elles soient terminées ou qu’elles soient arrêtées manuellement. L’instance de conteneur reste dans l’état DRAINING jusqu’à ce que toutes les tâches soient arrêtées ou jusqu’à ce que 48 heures se soient écoulées. Les tâches du démon sont les dernières à s’arrêter après l’arrêt de toutes les tâches de réplica.

Drainage d’instance gérée et protection contre la résiliation gérée

Le drainage d’instance gérée fonctionne même si la résiliation gérée est désactivée. Pour plus d’informations sur la protection contre la résiliation gérée, consultez la section Contrôle des instances résiliées par Amazon ECS.

Le tableau suivant récapitule le comportement des différentes combinaisons de résiliation gérée et de drainage géré.

Drainage d’instance gérée et drainage d’instance Spot

Avec le drainage d’instance Spot, vous pouvez définir une variable d’environnement ECS_ENABLE_SPOT_INSTANCE_DRAINING sur l’agent Amazon ECS permettant à Amazon ECS de placer une instance en état de drainage en réponse à une interruption Spot de deux minutes. Le drainage des instances géré par Amazon ECS facilite l'arrêt progressif des EC2 instances Amazon en cours de résiliation pour de nombreuses raisons, et pas simplement pour une interruption ponctuelle. Par exemple, vous pouvez utiliser le rééquilibrage de capacité d' EC2 Amazon Amazon EC2 Auto Scaling pour remplacer de manière proactive une instance Spot en cas de risque élevé d'interruption, et le drainage géré des instances effectue l'arrêt progressif de l'instance Spot remplacée. Lorsque vous utilisez le drainage d'instance géré, vous n'avez pas besoin d'activer le drainage d'instance Spot séparément. Par conséquent, dans le groupe ECS_ENABLE_SPOT_INSTANCE_DRAINING Amazon EC2 Auto Scaling, les données utilisateur sont redondantes. Pour plus d’informations sur les instances Spot, consultez la section Instances Spot.

Comment fonctionne le drainage géré des instances avec EventBridge

Les événements de vidange des instances gérées par Amazon ECS sont publiés sur Amazon EventBridge, et Amazon ECS crée une règle EventBridge gérée dans le bus par défaut de votre compte pour prendre en charge le drainage des instances gérées. Vous pouvez filtrer ces événements vers d'autres AWS services tels que Lambda, Amazon SNS et Amazon SQS à des fins de surveillance et de résolution des problèmes.

Résolution des problèmes liés au drainage d’instance gérée Amazon ECS

Il se peut que vous deviez résoudre les problèmes liés au drainage d’instance gérée. Vous trouverez ci-dessous un exemple de problème et de résolution que vous pourriez rencontrer lors de son utilisation.

Les instances ne s’arrêtent pas après avoir dépassé leur durée de vie maximale lors de l’utilisation de l’autoscaling.

Si vos instances ne s’arrêtent pas même après avoir atteint ou dépassé la durée de vie maximale lors de l’utilisation d’un groupe Auto Scaling, c’est peut-être parce qu’elles sont protégées contre la réduction horizontale. Vous pouvez désactiver la gestion de la résiliation et autoriser le drainage géré pour gérer le recyclage des instances.

Comportement du drainage pour les instances gérées Amazon ECS

Les instances gérées Amazon ECS mettent en œuvre des processus sophistiqués de drainage et de résiliation qui garantissent une transition progressive des charges de travail tout en optimisant les coûts et en maintenant en état le système. Le système de résiliation offre trois voies décisionnelles distinctes pour la résiliation d’instance, chacune présentant des caractéristiques différentes en termes de délais et d’impact sur le client.

Voies de décision en matière de résiliation

Tous les chemins de terminaison convergent vers le même mécanisme d'exécution via le hook de cycle de vie POST_DEREGISTER qui déclenche l'API de Node Manager ReleaseNode pour la résiliation immédiate de l'instance Amazon. EC2

Drainage progressif et migration de la charge de travail

Le système de drainage progressif met en œuvre une coordination sophistiquée avec la gestion des services Amazon ECS afin de garantir que les tâches gérées par les services sont correctement migrées hors des instances dont l’arrêt est prévu.

Coordination du drainage des tâches de service

Lorsqu’une instance passe à l’état DRAINAGE, le planificateur Amazon ECS arrête automatiquement de placer de nouvelles tâches sur l’instance tout en mettant en œuvre des procédures d’arrêt progressif pour les tâches de service existantes. Le drainage des tâches de service inclut la coordination avec les stratégies de déploiement de service, les exigences en matière de surveillance de l’état et vos préférences en matière de drainage, afin de garantir un calendrier de migration et des taux de réussite optimaux.

Gestion autonome des tâches

Les tâches autonomes nécessitent un traitement différent, car elles ne bénéficient pas de la gestion automatique des services. Le système évalue les caractéristiques des tâches autonomes, notamment les estimations de durée des tâches, l’analyse des probabilités d’achèvement et l’évaluation de l’impact sur le client. La stratégie d’exécution progressive permet aux tâches autonomes de s’exécuter naturellement pendant une période de grâce prolongée, tandis que la résiliation forcée garantit que l’actualisation de l’infrastructure se produit dans des délais acceptables lorsque les tâches ne se sont pas résiliées naturellement.

Stratégie de réalisation en deux phases

Le système de résiliation met en œuvre une approche en deux phases qui équilibre la continuité de la charge de travail avec les exigences de gestion de l’infrastructure.

Phase 1 : période d’achèvement progressif

Au cours de cette phase, le système met en œuvre des stratégies de drainage progressif qui privilégient la continuité de la charge de travail. Les tâches de service sont progressivement drainées par le biais des processus de planification habituels d’Amazon ECS, les tâches autonomes continuent de s’exécuter et peuvent se terminer naturellement, et le système surveille que toutes les tâches atteignent l’état d’arrêt grâce à des processus d’achèvement naturels.

Phase 2 : application stricte des délais

Lorsque l’achèvement progressif ne permet pas d’atteindre les objectifs de résiliation dans des délais acceptables, le système met en œuvre une application stricte des délais. Le délai strict est généralement fixé à la date de début du drainage plus sept jours, ce qui laisse suffisamment de temps pour mener à bien l’opération tout en respectant les exigences opérationnelles. L’application de ce délai comprend l’invocation automatique des procédures de désinscription forcée et l’arrêt immédiat de toutes les tâches restantes, quel que soit le statut d’achèvement.

Coordination interservices et gestion de l’état

Le processus de résiliation nécessite une coordination sophistiquée entre le Cluster Management Backend Service (CMBS) et le Node Manager afin de garantir que le désenregistrement des instances de conteneur et le nettoyage des ressources EC2 Amazon se déroulent dans le bon ordre tout en préservant la cohérence.

Exécution du hook POST_DEREGISTER

Le hook de cycle de vie POST_DEREGISTER représente le point de convergence où les trois voies de décision de terminaison exécutent la même logique de nettoyage. Lorsqu'une instance de conteneur atteint l'état DEREGISTERED, le hook POST_DEREGISTER déclenche automatiquement l'API de Node Manager ReleaseNode pour commencer les opérations de nettoyage des ressources Amazon. EC2 La mise en œuvre du hook inclut une gestion sophistiquée des erreurs pour divers scénarios de défaillance, notamment les problèmes de connectivité réseau, les problèmes de disponibilité des EC2 services Amazon et les défaillances de coordination entre les composants du système.

Nettoyage et désallocation des EC2 ressources Amazon

Le processus de résiliation des EC2 instances Amazon met en œuvre une coordination complète avec AWS les services afin de garantir que les ressources de calcul sous-jacentes sont correctement allouées. Cela inclut le nettoyage de l’interface réseau pour éviter les fuites de ressources, la gestion des enregistrements de base de données avec des pistes d’audit complètes, ainsi que des mécanismes appropriés de gestion des erreurs et de restauration pour divers scénarios de défaillance.