Assurez-vous que les charges de travail sont prêtes en cas d'interruption

Les applications exécutées dans les clusters Google Kubernetes Engine (GKE) doivent être préparées aux interruptions, telles que les mises à niveau de nœuds et d'autres événements de maintenance. Les applications avec état, qui nécessitent souvent du temps pour arrêter correctement l'E/S et les désinstaller de l'espace de stockage, sont particulièrement vulnérables aux interruptions. Vous pouvez utiliser des fonctionnalités Kubernetes telles que les budgets d'interruption de pod (PDB) et les sondes de disponibilité pour maintenir la disponibilité des applications lors des mises à niveau.

GKE surveille vos clusters et utilise le service de recommandation pour vous fournir des conseils sur la façon d'optimiser votre utilisation de la plate-forme. GKE détecte les opportunités de préparation de vos charges de travail pour les interruptions et fournit des conseils sur la mise à jour de vos PDB ou de vérifications d'aptitude pour maximiser la résilience de vos charges de travail aux interruptions. Par exemple, si un StatefulSet n'est pas protégé par un PDB, votre cluster peut supprimer tous les pods en même temps lors de la mise à niveau d'un nœud. Pour éviter cela, GKE fournit des conseils pour créer un PDB afin que la plupart des pods puissent continuer à s'exécuter pendant une mise à niveau.

Pour connaître les conditions spécifiques dans lesquelles GKE fournit des conseils liés aux interruptions, consultez la section Cas où GKE identifie les charges de travail vulnérables aux interruptions.

Pour en savoir plus sur la gestion des insights et des recommandations fournis par les outils de recommandation, consultez la section Optimiser l'utilisation de GKE avec des insights et des recommandations.

Identifier les charges de travail vulnérables aux interruptions

GKE génère des insights identifiant les charges de travail vulnérables aux interruptions de votre cluster. Pour obtenir ces insights, suivez les instructions pour afficher des insights et des recommandations à l'aide de la Google Cloud CLI ou de l'API Recommender. Utilisez les sous-types listés dans la section suivante pour filtrer les insights spécifiques. Ces insights ne sont pas disponibles dans la console Google Cloud .

Cas où GKE identifie des charges de travail vulnérables aux interruptions

Consultez le tableau suivant pour connaître les scénarios dans lesquels GKE fournit un insight et une recommandation, ainsi que le sous-type approprié :

Sous-type d'insight Description Action
PDB_UNPROTECTED_STATEFULSET Alerte lorsqu'un objet StatefulSet existe alors qu'aucun libellé PDB existant ne correspond aux étiquettes du sélecteur de pod du StatefulSet. Cela signifie que tous les pods du StatefulSet peuvent être arrêtés lors d'un événement tel que la mise à niveau d'un nœud. Ajoutez un PDB dont les étiquettes correspondent à ceux du champ de sélection de pod du StatefulSet. Spécifiez dans ce PDB le degré d'interruption que le StatefulSet peut tolérer. La recommandation associée à cet insight suggère les libellés qu'un PDB doit définir pour couvrir le StatefulSet mentionné.
PDB_UNPERMISSIVE Alertes lorsqu'il est impossible de respecter un PDB correspondant à un pod pour des activités de maintenance, comme la mise à niveau d'un nœud. Un PDB doit autoriser l'interruption d'au moins un pod. Par conséquent, GKE ne respecte pas ce PDB pour une maintenance nécessaire après une heure. Ajustez le paramètre minAvailable du PDB pour qu'il soit inférieur au nombre total de pods, ou le paramètre maxUnavailable pour qu'il soit supérieur à zéro.
PDB_STATEFULSET_WITHOUT_PROBES Alerte lorsqu'un StatefulSet est configuré avec un PDB, mais sans vérifications d'aptitude. Par conséquent, le PDB n'est pas aussi efficace qu'il le devrait pour l'évaluation de l'aptitude de l'application. Les PodDisruptionBudgets (PDB) effectuent les vérifications d'aptitude lorsqu'ils examinent quels pods peuvent être considérés comme sains. Par conséquent, si un pod couvert par un PDB ne comporte pas de vérification d'aptitude configurée, le PDB a une visibilité limitée quant à savoir si le pod est sain ou simplement opérationnel. Ajoutez des vérifications d'aptitude aux pods des StatefulSets pour le PDB mentionné dans l'insight. Nous vous recommandons également d'ajouter des vérifications d'activité.
DEPLOYMENT_MISSING_PDB Alerte lorsqu'un déploiement existe avec un sélecteur de pods qui ne correspond pas à un PDB existant et que le déploiement comporte plusieurs répliques ou que l'autoscaling horizontal de pods est activé. Cela signifie que tous les pods du déploiement peuvent être supprimés lors d'un événement tel que la mise à niveau d'un nœud. Ajoutez un PDB dont les étiquettes correspondent à celles du champ du sélecteur de pods du déploiement. Spécifiez dans ce budget d'interruptions de pods le degré d'interruption que le déploiement peut tolérer. La recommandation associée à cet insight suggère les libellés qu'un PDB doit définir pour couvrir le déploiement mentionné.

Mettre en œuvre les conseils pour améliorer la préparation aux perturbations

Si vous avez reçu des insights et des recommandations pour les charges de travail de votre cluster et que vous souhaitez améliorer leur préparation aux interruptions, mettez en œuvre les instructions décrites dans les recommandations et la marche à suivre pour ce sous-type d'insight, comme indiqué dans le section précédente.

Les recommandations étant évaluées une fois par jour, leur résolution peut prendre jusqu'à 24 heures.

Si vous ne souhaitez pas appliquer la recommandation, vous pouvez l'ignorer.

Étapes suivantes