Meilleures pratiques pour la restauration des versions de cluster

Amazon EKS gère : la restauration du serveur 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 responsable de : la restauration des groupes de nœuds gérés, des nœuds autogérés et des 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 en mode non 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 préparation avant de mettre à niveau les nœuds de travail. Tant que les nœuds restent actifs N-1, la version kubelet skew insight reste en statut PASSING. Cela permet de garder le chemin d'annulation clair sans avoir à annuler les nœuds au préalable.

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, à la fois pour la mise à niveau et pour la restauration.

Évitez d'utiliser des API spécifiques à la 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 des API réservées aux nouvelles versions jusqu'à ce que vous soyez certain que la mise à niveau est stable.

Effectuez la mise à niveau le plus tôt possible. La restauration étant disponible, vous pouvez effectuer une mise à niveau en toute confiance peu de temps après la sortie d'une nouvelle version, au lieu d'attendre des délais de support prolongés. Une mise à niveau plus précoce vous donne plus de temps pour valider et réduit les frais de support étendus.

Soyez conscient des restrictions d'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.

Passez en revue 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 relatives à la préparation à la restauration afin de connaître votre position de restauration actuelle.

Traitez les informations relatives aux ERREURS de manière proactive. Si les informations indiquent le statut ERROR peu de temps après une mise à niveau, résolvez-les rapidement pendant que la fenêtre de 7 jours est encore ouverte. Plus vous attendez, plus il est probable que l'état de votre cluster diverge et que de nouveaux bloqueurs apparaissent.

Comprenez ce que les insights couvrent et ne couvrent pas. Les informations vérifient 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. La restauration respecte les paramètres de mise à jour que vous avez configurés (stratégie maxUnavailable 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 la restauration, ou utilisez-les --force pour contourner l'aperçu de l'asymétrie de version (ce qui peut entraîner un comportement inattendu jusqu'à ce que les pods soient remplacés).

Passez en revue les budgets relatifs aux interruptions avant de procéder à une réduction. Amazon EKS fournit des informations sur la préparation à la restauration pour les budgets liés aux NodePool interruptions. Les budgets définis sur 0 déclenchent un aperçu ERROR, qui bloque la restauration indéfiniment. Les restrictions budgétaires et PodDisruptionBudgets (PDB) déclenchent des alertes, qui peuvent ralentir le retour en arrière mais permettre de progresser. Corriger les informations relatives aux ERREURS avant de lancer la restauration.

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

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. Permet kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide de contrôler quels nœuds ont été remplacés par la version précédente de l'AMI.

À 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 convergent vers la version actuelle et vous pouvez adopter une approche différente.

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

DescribeUpdate opération. Permet describe-update de 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 des nœuds terminée pour le mode automatique). Surveillez les nouvelles informations sur les ERREURS qui auraient pu apparaître.

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

Versions des nœuds. Pour le mode automatique, vérifiez les versions de Kubernetes des nœuds 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, il CloudFormation est considéré comme un no-op, ce qui peut laisser le cluster dans un état de dérive 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'attente d'environ 24 heures, bien que les délais d'attente côté client varient.

timeoutMinutesRespectez le délai 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 dotés de budgets restreints, plutôt que via IaC. À utiliser CancelUpdate directement si la couche IaC expire.

La restauration de la CloudFormation pile AWS ne déclenche pas de restauration de version. Si une mise à jour de la CloudFormation pile AWS échoue, le retour automatique à une version de modèle précédente de la pile 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. Rollback gère les cas que les tests ne peuvent pas détecter, à savoir les problèmes qui n'apparaissent qu'en production.

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

Les informations sont obtenues au meilleur moment et au meilleur moment. Amazon EKS les évalue lorsque vous déclenchez la restauration. 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.

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

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

Restaurer les clusters Amazon EKS en mode automatique

Meilleures pratiques pour les mises à niveau des clusters

Informations sur les clusters

Cycle de vie des versions de Kubernetes sur EKS