Bonnes pratiques pour la restauration d'une version en cluster

Amazon EKS gère : Annulation du serveur d'API Kubernetes et des composants du plan de contrôle. Pour les clusters en mode automatique, Amazon EKS gère également la restauration des nœuds de travail.

Vous êtes chargé de : annuler les groupes de nœuds gérés, les nœuds autogérés et les nœuds hybrides. Vous devez également valider la compatibilité des modules complémentaires et vous assurer que vos applications, vos contrôleurs personnalisés et vos outils tiers fonctionnent correctement avec la version précédente.

Mises à niveau distinctes du plan de contrôle et du plan de données (clusters non en mode automatique). Pour les clusters qui utilisent des groupes de nœuds gérés ou des nœuds autogérés, envisagez d'abord de mettre à niveau le plan de contrôle et de prévoir une période de cuisson avant de mettre à niveau les nœuds de travail. Tant que les nœuds restent activés N-1, la version de Kubelet Skew Insight reste au statut PASSING. Cela permet de garder le chemin de restauration dégagé sans qu'il soit nécessaire de revenir en arrière au préalable sur les nœuds.

Mettez à niveau les modules complémentaires vers des versions compatibles entre elles. Avant de mettre à niveau le plan de contrôle, assurez-vous que tous les modules complémentaires (gérés et autogérés) sont compatibles avec les versions actuelles et cibles de Kubernetes. Cela permet de disposer d'informations claires sur la compatibilité des modules complémentaires, tant pour la mise à niveau que pour la restauration.

Évitez d'utiliser des API spécifiques à une version pendant la période de cuisson. Si vous créez des ressources qui utilisent des API ou des fonctionnalités disponibles uniquement dans la nouvelle version pendant la période de 7 jours, vous devez les supprimer avant de revenir en arrière. Limitez l'adoption d'API réservées aux nouvelles versions jusqu'à ce que vous soyez certain que la mise à niveau est stable.

Effectuez la mise à niveau plus tôt, pas plus tard. Grâce au rollback disponible, vous pouvez effectuer une mise à niveau en toute confiance peu de temps après la publication d'une nouvelle version plutôt que d'attendre des délais de support prolongés. Une mise à niveau anticipée vous donne plus de temps pour valider et réduit les frais de support étendu.

Tenez compte des restrictions relatives à l'annulation du support étendu. Si votre cluster a été automatiquement mis à niveau à la fin du support étendu, vous ne pouvez pas revenir à la version précédente. Si vous avez été mis à niveau automatiquement à la fin du support standard, vous pouvez revenir en arrière, mais vous devez d'abord modifier la politique de mise à niveau enEXTENDED.

Consultez les informations immédiatement après la mise à niveau. N'attendez pas que quelque chose ne tourne pas rond. Après la mise à niveau, consultez les informations sur le niveau de préparation à la restauration afin de connaître votre position actuelle en matière de restauration.

Traitez les informations relatives aux ERREURS de manière proactive. Si Insights affiche le statut d'ERREUR peu après une mise à niveau, résolvez-les rapidement pendant que le délai de 7 jours est encore ouvert. Plus vous attendez, plus il est probable que l'état de votre cluster diverge et que de nouveaux bloqueurs apparaissent.

Comprenez ce que les informations couvrent et ne couvrent pas. Insights vérifie les versions des modules complémentaires gérés par Amazon EKS, l'utilisation des API, l'asymétrie des versions et l'état du cluster. Ils ne vérifient pas les modules complémentaires autogérés, les contrôleurs personnalisés ou la compatibilité au niveau des applications. Conservez votre propre validation de compatibilité pour les modules complémentaires autogérés (par exemple, cluster-autoscaler, contrôleurs d'entrée, opérateurs personnalisés, agents de surveillance).

Groupes de nœuds gérés. Vous devez rétablir la version précédente de vos groupes de nœuds gérés avant de restaurer le plan de contrôle. Utilisez l'UpdateNodegroupVersionopération avec la version précédente de Kubernetes. L'annulation respecte les paramètres de mise à jour que vous avez configurés (maxUnavailablestratégie de mise à jour).

Self-managed et des nœuds hybrides. Mettez à jour les AMI ou les configurations de votre nœud pour utiliser la version précédente de Kubernetes avant de restaurer le plan de contrôle.

Fargate. La restauration de version n'est pas prise en charge pour les nœuds de travail Fargate. Supprimez les pods Fargate exécutant la même version que le plan de contrôle avant de lancer le rollback, ou --force utilisez-les pour contourner l'aperçu du biais des versions (ce qui peut entraîner un comportement inattendu jusqu'au remplacement des pods).

Passez en revue les budgets d'interruption avant de lancer une annulation. Amazon EKS fournit des informations sur l'état de préparation à la réduction des budgets liés aux NodePool interruptions de service. Les budgets définis à 0 déclenchent un aperçu des erreurs, qui bloque le rollback indéfiniment. Les budgets restrictifs et PodDisruptionBudgets (PDB) déclenchent des alertes, qui peuvent ralentir le retour en arrière mais permettre de progresser vers l'avenir. Corrigez les informations relatives aux ERREURS avant de lancer le rollback.

Soyez prêt à ajuster les budgets lors de la rétrogradation. Si la restauration prend plus de temps que prévu, vous pouvez ajuster les budgets d' NodePool interruption et les PDB kubectl pendant que la restauration est en cours. L'augmentation du budget permet d'augmenter le nombre de remplacements de nœuds simultanés.

Supprimez les annotations « Ne pas perturber » des nœuds bloquants. L'karpenter.sh/do-not-disruptannotation sur les nœuds bloque le rollback indéfiniment. Supprimez-le des nœuds qui doivent être remplacés.

Suivez la progression de la restauration des nœuds. kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wideÀ utiliser pour surveiller les nœuds qui ont été remplacés par l'AMI de la version précédente.

À utiliser CancelUpdate si nécessaire. Si la restauration prend trop de temps ou cause plus de problèmes qu'elle n'en résout, annulez-la. Après l'annulation, les nœuds reviennent à la version actuelle et vous pouvez adopter une approche différente.

Définissez un délai d'expiration approprié. Utilisez le timeoutMinutes paramètre rollbackConfig pour vous aligner sur vos attentes opérationnelles. La valeur par défaut est de 720 minutes (12 heures). Pour les clusters dont le budget est modéré, envisagez de l'augmenter. Pour les IaC-managed clusters, alignez-vous sur le délai d'expiration de votre outil.

DescribeUpdate opération. describe-updateÀ utiliser pour vérifier l'état actuel de l'opération de restauration (InProgress,, SuccessfulFailed,Cancelled). Pour suivre la progression de l'annulation, vérifiez l'cancellationobjet dans la réponse.

Informations sur les clusters. Amazon EKS revérifie les informations avant de procéder à la restauration du plan de contrôle (une fois la restauration du nœud terminée pour le mode automatique). Surveillez les nouvelles informations d'erreur qui auraient pu apparaître.

État du cluster. Pour les clusters en mode automatique, l'état du cluster demeure ACTIVE pendant la restauration des nœuds et change UPDATING uniquement pendant la restauration du plan de contrôle. Ne vous fiez pas uniquement à l'état du cluster pour savoir qu'une annulation est en cours DescribeUpdate : utilisez-le.

Versions des nœuds. Pour le mode automatique, vérifiez les versions des nœuds Kubernetes pour suivre la progression du remplacement des nœuds. Pour les groupes de nœuds gérés, surveillez l'état de mise à jour des groupes de nœuds.

AWS CloudFormation prend en charge jusqu'à 36 heures par ressource. Si le rollback dépasse ce seuil, CloudFormation traitez-le comme non opérationnel, ce qui peut laisser le cluster dans un état dérivé où le modèle ne reflète pas la version réelle du cluster. Le délai d'annulation par défaut est de 720 minutes (12 heures).

Terraform Enterprise/Cloud a des délais d'expiration d'environ 24 heures, bien que les délais varient du côté client.

Alignez le délai timeoutMinutes d'expiration de votre outil iAC pour éviter que l'outil iAC n'expire avant qu'Amazon EKS n'ait terminé la restauration.

Envisagez de lancer la restauration CLI/API pour les clusters en mode automatique dont les budgets sont restreints, plutôt que via IaC. À utiliser CancelUpdate directement si la couche IaC expire.

Le rollback d'AWS CloudFormation Stack ne déclenche pas le retour en arrière de version. Si la mise à jour d'une CloudFormation pile AWS échoue, le retour automatique à une version de modèle précédente ne déclenche pas de restauration de la version du cluster. Vous devez lancer explicitement une restauration de version.

Le rollback complète les tests, il ne les remplace pas. Continuez à utiliser les informations sur les clusters, les tests préalables à la mise à niveau dans des environnements hors production et les déploiements par étapes. Le rollback gère les cas que les tests ne parviennent pas à détecter, à savoir les problèmes qui apparaissent uniquement en production.

Le rollback réduit le besoin de procédures de sauvegarde et de capture d'écran manuelles en tant que principal mécanisme de sécurité. La restauration native étant disponible, vous n'avez plus besoin de vous fier uniquement aux instantanés etcd ou aux scripts de restauration personnalisés pour la reprise après sinistre lors des mises à niveau.

Les informations sont le meilleur moyen et ce, à un moment précis. Amazon EKS les évalue lorsque vous déclenchez le rollback. Les modifications apportées après cette vérification (par exemple, la création de ressources avec de nouvelles API) ne sont pas capturées et peuvent entraîner des problèmes une fois la restauration terminée.

Le rollback ne garantit pas la restauration de l'application. Amazon EKS rétablit le plan de contrôle en toute sécurité, mais il est de votre responsabilité de valider vos applications, configurations et dépendances par rapport à la version précédente.

Restaurer le cluster à la version précédente de Kubernetes

Restaurer les clusters en mode automatique Amazon EKS

Meilleures pratiques pour les mises à niveau de clusters

Informations sur les clusters

Cycle de vie des versions de Kubernetes sur EKS