## Introduction Les quotas de ressources Kubernetes sont essentiels pour contrôler la consommation de ressources dans les espaces de noms, mais ils ne sont efficaces que si vous pouvez les observer. Dans ce guide, vous apprendrez quoi surveiller, quelles métriques sont importantes, comment configurer des alertes avec Prometheus et comment créer un tableau de bord dans Grafana. Nous aborderons également les flux de travail de réponse aux incidents afin que vous puissiez agir rapidement lorsqu'un quota est sur le point d'être dépassé. Les quotas de ressources empêchent une seule équipe d'épuiser les ressources du cluster, mais sans surveillance, vous risquez de ne pas vous en rendre compte avant que les charges de travail ne soient rejetées. Par exemple, un espace de noms atteignant sa limite de CPU peut provoquer des échecs de planification des pods. En surveillant l'utilisation des quotas et en définissant des alertes, vous pouvez gérer la capacité de manière proactive. Cet article fournit des exemples pratiques, notamment des commandes, des extraits de configuration et les sorties attendues. Vous trouverez également une liste de vérification pour valider votre configuration et un plan de récupération pour les modes de défaillance courants. ## Inventaire des versions et de l'environnement Avant de commencer, assurez-vous de disposer d'un cluster Kubernetes avec les quotas de ressources activés (ils le sont par défaut). Les exemples de cet article supposent : - Kubernetes version 1.20 ou ultérieure (version d'API v1 pour ResourceQuota). - Prometheus déployé dans le cluster (par exemple, via Prometheus Operator ou Helm). - Grafana pour les tableaux de bord (version 7.0 ou supérieure). - L'outil de ligne de commande kubectl configuré. - Un espace de noms avec un quota de ressources existant ou vous en créerez un. Pour vérifier votre version de Kubernetes : ``` kubectl version --short ``` Sortie attendue : ``` Client Version: v1.21.0 Server Version: v1.21.0 ``` Pour vérifier que ResourceQuota est disponible : ``` kubectl api-resources | grep resourcequota ``` Sortie attendue : ``` resourcequotas quota v1 true ResourceQuota ``` Si vous voyez cela, vous êtes prêt à continuer. Ensuite, confirmez que Prometheus collecte les métriques de kube-state-metrics, qui expose les métriques des quotas de ressources. Si vous n'avez pas kube-state-metrics, installez-le (par exemple, via Helm : `helm install kube-state-metrics prometheus-community/kube-state-metrics`). ## Chemin de configuration sûr Commencez avec un seul espace de noms pour éviter le bruit. Par exemple, créez un espace de noms `team-a` et appliquez un quota de ressources : ``` kubectl create namespace team-a cat < 80 for: 5m labels: severity: warning annotations: summary: "Quota de ressources {{ $labels.resource }} dans l'espace de noms {{ $labels.namespace }} utilisé à plus de 80%" description: "Le quota pour {{ $labels.resource }} dans l'espace de noms {{ $labels.namespace }} a dépassé 80% (valeur actuelle : {{ $value }}%)" ``` Appliquez cette règle et attendez que Prometheus l'évalue. Il s'agit de la mise en œuvre sûre et limitée : un espace de noms, un quota, seuil d'alerte simple. Une fois vérifié, vous pouvez étendre à plus d'espaces de noms ou de ressources. ## Vérification et diagnostics Pour vérifier que la surveillance fonctionne, vérifiez d'abord que Prometheus collecte les métriques. Faites un port-forward vers Prometheus et exécutez une requête : ``` kubectl port-forward -n monitoring svc/prometheus-k8s 9090:9090 ``` Ensuite, ouvrez `http://localhost:9090` et entrez la requête : ``` kube_resourcequota{namespace="team-a", resource="pods"} ``` Résultat attendu : une série temporelle avec des étiquettes `type="hard"` valeur 10 et `type="used"` valeur 2 (ou le nombre de pods actuel). Vous pouvez également vérifier via curl : ``` curl 'http://localhost:9090/api/v1/query?query=kube_resourcequota%7Bnamespace%3D%22team-a%22%2Cresource%3D%22pods%22%7D' ``` Réponse JSON attendue (tronquée) : ``` {"status":"success","data":{"resultType":"vector","result":[{"metric":{"namespace":"team-a","resource":"pods","type":"hard"},"value":[1618000000,"10"]},{"metric":{"namespace":"team-a","resource":"pods","type":"used"},"value":[1618000000,"2"]}]}} ``` Si vous ne voyez pas de métriques, vérifiez si kube-state-metrics est en cours d'exécution et si son service est découvert par Prometheus. Consultez la page des cibles de Prometheus (`http://localhost:9090/targets`) pour kube-state-metrics. Ensuite, vérifiez la règle d'alerte. Dans l'interface de Prometheus, allez dans Alertes et recherchez `ResourceQuotaAlmostFull`. Pour la déclencher, augmentez le pourcentage utilisé en faisant évoluer le déploiement au-delà de 80 % du quota de pods (8 pods). Par exemple : ``` kubectl scale deployment nginx --replicas=8 -n team-a ``` Attendez quelques minutes (`for: 5m`) et vérifiez les alertes. L'alerte doit être en état En attente ou Actif. Vous pouvez également interroger l'expression de l'alerte pour voir la valeur actuelle. Pour les tableaux de bord, créez un panneau Grafana avec la requête PromQL : ``` 100 * (sum(kube_resourcequota{type="used"}) by (namespace, resource) / sum(kube_resourcequota{type="hard"}) by (namespace, resource)) ``` Définissez l'unité en pourcentage et visualisez sous forme de tableau ou de jauge à barres. Cela donne un aperçu rapide de tous les quotas. ## Modes de défaillance et récupération Modes de défaillance courants : - **Métriques manquantes** : Si kube-state-metrics n'est pas en cours d'exécution ou n'est pas collecté, aucune alerte ne se déclenche. Vérifiez la santé des cibles Prometheus et les journaux de kube-state-metrics. Corrigez en vous assurant que le service est opérationnel et que la configuration ServiceMonitor ou de collecte est correcte. - **Fausses alertes dues à une division par zéro** : Si un quota a une valeur dure de 0 (illimité), la division dans l'expression d'alerte peut produire NaN ou inf. Excluez ces cas en ajoutant `kube_resourcequota{type="hard"} > 0` à la requête. - **Tempête d'alertes** : Si de nombreux espaces de noms atteignent 80 % simultanément, vous risquez d'être submergé. Utilisez des règles de regroupement et d'inhibition, ou ajustez les seuils. - **Quota mal configuré** : Un quota de ressources avec des limites trop basses peut interrompre les charges de travail existantes. Pour annuler, supprimez le quota : ``` kubectl delete resourcequota compute-quota -n team-a ``` Ou modifiez-le : ``` kubectl edit resourcequota compute-quota -n team-a ``` Ensuite, augmentez les valeurs dures. Après l'annulation, vérifiez que l'espace de noms revient à la normale et que les charges de travail s'exécutent. - **Règle Prometheus non déclenchée** : Vérifiez l'évaluation de la règle. Dans l'interface de Prometheus, allez dans Statut > Règles et trouvez la règle. Assurez-vous que l'expression est valide et active. Vérifiez les erreurs de syntaxe. Liste de vérification pour la récupération : - Identifiez le composant défaillant (métriques, alertes, tableau de bord). - Vérifiez les journaux : `kubectl logs -n monitoring deployment/kube-state-metrics`. - Vérifiez les cibles Prometheus. - Ajustez le quota si nécessaire. - Documentez l'incident pour référence future. ## Pièges courants et comment les éviter Au-delà des modes de défaillance ci-dessus, plusieurs problèmes subtils piègent les équipes lors de la surveillance des quotas de ressources. Comprendre ces pièges vous fera gagner des heures de débogage. 1. **Ignorer la différence entre requêtes et limites**. Un quota peut limiter à la fois `requests.cpu` et `limits.cpu`. Les alertes qui ne regardent qu'un seul aspect manqueront la surallocation de l'autre. Surveillez toujours l'utilisation des requêtes et des limites pour les ressources de calcul. Par exemple, si un espace de noms a un quota de 4 CPU pour les limites mais seulement 2 pour les requêtes, et qu'une équipe définit des limites élevées mais des requêtes faibles, le quota de requêtes peut être épuisé avant celui des limites. Vos règles d'alerte doivent couvrir tous les types de ressources qui vous intéressent, pas seulement les pods. 2. **Utiliser des seuils de pourcentage naïfs pour les petits quotas**. Pour les petits quotas (par exemple, 5 pods), un seuil de 80 % peut se déclencher lorsqu'il ne reste qu'un seul pod. Cela pourrait être trop tard. Envisagez des seuils absolus en plus des pourcentages. Par exemple, alertez lorsque `used >= hard - 2` pour les pods, quel que soit le pourcentage. Cela donne un avertissement plus précoce pour les petits quotas. 3. **Ne pas tenir compte des quotas multiples dans un espace de noms**. Kubernetes autorise plusieurs objets ResourceQuota dans un espace de noms, et leurs effets sont combinés. Si vous avez des quotas distincts pour le calcul et le nombre d'objets, une règle d'alerte unique qui additionne tous les quotas peut produire des pourcentages trompeurs. Au lieu de cela, interrogez par type de ressource dans tous les quotas de l'espace de noms. Par exemple, `sum by (namespace, resource) (kube_resourcequota{type="used"})` agrègera l'utilisation de tous les quotas pour la même ressource dans l'espace de noms. 4. **Négliger la métrique `kube_resourcequota_created`**. Cette métrique indique quand le quota a été créé et peut aider à détecter les quotas supprimés ou recréés. Si un quota est supprimé et recréé, vos règles d'alerte peuvent le manquer brièvement. Surveillez les changements de cette métrique ou utilisez-la dans les tableaux de bord pour afficher l'âge du quota. 5. **Supposer que kube-state-metrics est toujours à jour**. kube-state-metrics peut être en retard par rapport à l'état réel de Kubernetes, en particulier dans les grands clusters. Si vous constatez des écarts, vérifiez son intervalle de collecte et sa consommation de ressources. Dans certains cas, vous devrez peut-être réduire son intervalle de collecte ou augmenter ses ressources. 6. **Ne pas tester les alertes avec un trafic réaliste**. Simulez une utilisation élevée dans un cluster de staging avec les mêmes quotas que la production pour vous assurer que les alertes se déclenchent comme prévu. Cela inclut de tester les canaux de notification et les étapes du manuel de procédures. Pour éviter ces pièges, nous recommandons une revue hebdomadaire des règles d'alerte et des panneaux du tableau de bord avec au moins un ingénieur de l'équipe plateforme (par exemple, le responsable de la plateforme Kubernetes, Priya Shah) comme propriétaire responsable. La revue doit inclure la vérification des nouveaux espaces de noms, des quotas modifiés et des faux positifs, avec un point spécifique à l'ordre du jour pour réviser les seuils en fonction des tendances d'utilisation récentes. ## Liste de vérification des opérations Utilisez cette liste de vérification pour les opérations courantes : | Fréquence | Tâche | Détails | |-----------|------|---------| | Quotidienne | Vérifier le tableau de bord | Rechercher les espaces de noms avec une utilisation supérieure à 70 %. | | Hebdomadaire | Examiner les alertes | Identifier les espaces de noms proches des limites. | | Mensuelle | Tester les alertes | Simuler une utilisation élevée pour s'assurer que les alertes se déclenchent. | | Lors d'un changement | Vérifier les changements de quota | S'assurer que la surveillance reflète les nouvelles valeurs dures. | | Intégration | Ajouter de nouveaux espaces de noms | Les inclure dans les tableaux de bord et les alertes. | | Incident | Suivre les étapes de récupération | Revoir les seuils après incident. | Exemple de commande de vérification quotidienne : ``` kubectl get resourcequota --all-namespaces ``` Sortie attendue : liste des quotas avec les valeurs utilisées et dures. Vous pouvez également créer un script pour alerter en cas d'utilisation élevée. Gardez cette liste de vérification accessible à l'équipe et mettez-la à jour à mesure que votre environnement évolue. ## Conclusion La surveillance des quotas de ressources Kubernetes est essentielle pour prévenir l'épuisement des ressources et garantir une utilisation équitable. Dans ce guide, vous avez appris à : - Configurer un quota de ressources et consommer des ressources. - Configurer des alertes Prometheus pour une utilisation élevée des quotas. - Vérifier la surveillance avec des requêtes PromQL et les sorties attendues. - Gérer les modes de défaillance courants et annuler les modifications. - Utiliser une liste de vérification des opérations pour la gestion continue. Prochaines étapes : - Étendre la surveillance à tous les espaces de noms et ressources qui vous intéressent (CPU, mémoire, stockage). - Intégrer les alertes aux canaux de notification comme Slack ou par e-mail. - Créer des tableaux de bord Grafana complets avec des seuils et un code couleur. - Envisager des alertes prédictives basées sur les tendances d'utilisation. N'oubliez pas : commencez petit et itérez. Un projet pilote étroit et mesurable vous aidera à valider votre configuration de surveillance avant de la mettre à l'échelle.