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 préparation pour maintenir les applications disponibles pendant les 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 d'une mise à niveau de nœud. Pour éviter cela, GKE fournit des conseils pour créer un PDB afin que la plupart des pods puissent rester en cours d'exécution lors d'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 supprimés lors d'un événement tel qu'une mise à niveau de 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 Envoi d'alertes lorsqu'un PDB correspondant à un pod est impossible à respecter pour toute activité de maintenance, telle qu'une mise à niveau de 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 dans les 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 pod qui ne correspond pas à un PDB existant et que le déploiement comporte plusieurs réplications ou que l'autoscaling horizontal des pods est activé. Cela signifie que tous les pods du déploiement peuvent être supprimés lors d'un événement tel qu'une mise à niveau de nœud. Ajoutez un PDB dont les étiquettes correspondent à celles du champ de sélection de pod du déploiement. Spécifiez dans ce PDB le degré d'interruption pouvant être toléré par le déploiement. La recommandation associée à cet insight suggère les libellés qu'un PDB doit définir pour couvrir le déploiement mentionné.

Implémenter 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 implémenter la recommandation, vous pouvez l'ignorer.

Étapes suivantes