## Introduction
L'optimisation des performances des baux Kubernetes avec des exemples pratiques devrait aider les opérateurs à passer d'un problème observé à un résultat vérifié. Commencez par identifier la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté.
Cet article se concentre sur les performances des baux Kubernetes pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie l'optimisation des baux Kubernetes, le réglage des baux Kubernetes, la latence des baux Kubernetes et les goulots d'étranglement des baux Kubernetes à des commandes, des sorties attendues, des signaux d'échec et des décisions de récupération correspondant à la technologie choisie.
L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et documenter la récupération si l'état attendu n'est pas atteint.
## Comprendre les objets Lease de Kubernetes
Avant de procéder au réglage, vous devez comprendre ce qu'est un Lease et où il est utilisé. Un Lease est une primitive de coordination légère dans l'API Kubernetes. Il permet à un composant de détenir un verrou nommé pendant une durée limitée. Le détenteur renouvelle périodiquement le bail. Si le bail expire parce que le détenteur n'a pas réussi à le renouveler à temps, un autre composant peut prendre le relais.
Les baux sont utilisés par plusieurs composants principaux :
- kube-controller-manager : élection de leader pour les contrôleurs tels que le contrôleur de nœuds, le contrôleur de jobs et le contrôleur de comptes de service.
- kube-scheduler : élection de leader pour le planificateur.
- kube-apiserver : coordination de la migration des versions de stockage.
- Battement de cœur des nœuds : les versions récentes de Kubernetes utilisent des objets Lease au lieu des mises à jour NodeStatus pour les battements de cœur des nœuds, ce qui réduit la charge sur etcd.
Chaque bail possède une spec avec holderIdentity , leaseDurationSeconds , acquireTime , renewTime et leaseTransitions . Le champ leaseDurationSeconds indique au système la durée de validité d'un bail avant qu'il ne soit considéré comme expiré. Le champ holderIdentity identifie le détenteur actuel, comme un nom de pod ou un nom d'hôte.
Les problèmes de performance liés aux baux se manifestent généralement par :
- Élection de leader lente : lorsqu'un leader échoue, les nouvelles élections prennent trop de temps, entraînant des temps d'arrêt.
- Charge excessive sur etcd : trop de renouvellements de baux ou de battements de cœur trop fréquents peuvent surcharger etcd.
- Fluctuation de l'état des nœuds : si les battements de cœur des nœuds sont retardés, le plan de contrôle peut marquer un nœud sain comme NotReady .
- Blocage des contrôleurs : si un contrôleur perd son bail, les contrôleurs peuvent cesser de traiter jusqu'à l'élection d'un nouveau leader.
Comprendre ces symptômes vous aide à cibler le bon composant et à régler les paramètres appropriés.
## Inventaire des versions et de l'environnement
Pour les performances des baux Kubernetes, l'inventaire des versions et de l'environnement doit nommer le composant concerné, la plage de versions prise en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.
### Identifier votre version de Kubernetes et l'utilisation des baux
Les baux ont été introduits en tant qu'API v1 dans Kubernetes 1.14. Ils sont stables dans Kubernetes 1.19 et versions ultérieures, mais leur implémentation diffère selon les versions. En tant qu'opérateur, vous devez connaître :
- La version du serveur Kubernetes et la distribution (par exemple, v1.27.3 , v1.28.2 , EKS, GKE, Kubeadm).
- Quels composants utilisent des baux. Par exemple, les battements de cœur des nœuds utilisant des baux sont activés par défaut à partir de Kubernetes 1.17, mais peuvent être désactivés dans certaines distributions.
- La version d'etcd et le backend de stockage, car les taux de renouvellement des baux affectent directement etcd.
- Le nombre de nœuds et de pods, qui détermine le taux de rotation des baux.
- Tout contrôleur ou opérateur personnalisé utilisant l'API coordination.k8s.io pour sa propre élection de leader.
Prérequis pour une observation sûre :
- kubectl configuré avec un accès en lecture seule au cluster, idéalement un compte de service avec les autorisations get , list et watch sur coordination.k8s.io/leases .
- jq installé localement si vous souhaitez analyser la sortie JSON.
- Metrics Server ou Prometheus si vous souhaitez surveiller les métriques liées aux baux.
- Accès en écriture à un espace de noms de test si vous prévoyez d'expérimenter avec des baux personnalisés.
### Commandes d'observation en lecture seule
La première étape consiste à observer l'état actuel sans rien modifier. Utilisez ces commandes :
# Lister tous les baux dans l'espace de noms kube-system (où s'exécutent les composants du plan de contrôle)
kubectl get leases -n kube-system
# Décrire un bail spécifique pour voir l'identité du détenteur et les heures de renouvellement
kubectl describe lease -n kube-system kube-controller-manager
# Lister les baux dans tous les espaces de noms (peut être nombreux)
kubectl get leases --all-namespaces
# Examiner les baux de battement de cœur des nœuds (un par nœud dans l'espace de noms kube-node-lease)
kubectl get leases -n kube-node-lease
Exemple de sortie pour kubectl get leases -n kube-system :
NAME HOLDER AGE
kube-controller-manager ip-10-0-12-34.eu-west-1.compute.internal 5d
kube-scheduler ip-10-0-12-34.eu-west-1.compute.internal 5d
Pour une vue détaillée, utilisez :
kubectl get lease -n kube-system kube-controller-manager -o yaml
Une sortie réduite pourrait ressembler à ceci :
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
name: kube-controller-manager
namespace: kube-system
spec:
holderIdentity: ip-10-0-12-34.eu-west-1.compute.internal
leaseDurationSeconds: 15
acquireTime: "2024-01-15T10:00:00Z"
renewTime: "2024-01-15T10:05:23Z"
leaseTransitions: 1
Ici, la durée du bail est de 15 secondes, ce qui signifie que le détenteur doit renouveler au moins toutes les 15 secondes. Si le détenteur ne renouvelle pas dans les 15 secondes, un autre prétendant peut acquérir le bail. Le champ renewTime indique le dernier renouvellement ; s'il est plus ancien que 15 secondes, le bail est expiré.
### Garder le test local petit
Pour l'inventaire des versions et de l'environnement, gardez le test local petit. Appliquez un seul manifeste, inspectez les ressources générées et vérifiez le trafic avec kubectl port-forward ou un type de service local avant de passer à un équilibreur de charge cloud ou à un contrôleur d'entrée.
Par exemple, pour tester un bail personnalisé dans un espace de noms de bac à sable :
# Créer un espace de noms de test
kubectl create namespace lease-test
# Créer un manifeste de bail simple
cat < 10257:10257
# Dans un autre terminal
curl -k https://localhost:10257/metrics | grep leader_election
(Remarque : le port et les paramètres TLS varient selon le cluster ; vérifiez les indicateurs --secure-port et --bind-address .)
### Diagnostiquer les problèmes de battement de cœur des nœuds
Si les nœuds fluctuent entre Ready et NotReady , le problème peut être dû à des retards de renouvellement du bail. Vérifiez les horodatages du bail du nœud :
# Obtenir le renewTime actuel pour un bail de nœud spécifique
kubectl get lease -n kube-node-lease -o jsonpath='{.spec.renewTime}{"\n"}'
# Obtenir l'heure système sur le nœud (via SSH ou kubectl node-shell)
date -u
Si le renewTime est plus ancien que la fréquence de mise à jour de l'état du nœud, le kubelet peut être incapable de mettre à jour le bail. Vérifiez les journaux du kubelet pour les erreurs :
# Sur le nœud
journalctl -u kubelet -n 50 --no-pager
Recherchez des messages tels que Failed to update lease , etcdserver: request timed out ou connection refused . Ceux-ci indiquent des problèmes etcd ou réseau.
### Vérifier le basculement de l'élection de leader
Pour tester le basculement, vous pouvez simuler une défaillance du leader en supprimant le pod leader (dans un environnement de test). Par exemple, pour le kube-scheduler :
# Déterminer le leader actuel à partir du bail
kubectl get lease -n kube-system kube-scheduler -o jsonpath='{.spec.holderIdentity}{"\n"}'
# Identifier le pod correspondant à cette identité
kubectl get pods -n kube-system -o wide | grep
# Supprimer ce pod pour forcer une nouvelle élection
kubectl delete pod -n kube-system
# Surveiller le bail pour voir quand le détenteur change
kubectl get lease -n kube-system kube-scheduler -w
Comportement attendu : en quelques secondes, le holderIdentity du bail passe au réplica suivant du planificateur et leaseTransitions s'incrémente. Si le basculement prend trop de temps, vérifiez les durées du bail et l'état de préparation des autres réplicas.
## Modes de défaillance et récupération
Pour les performances des baux Kubernetes, les modes de défaillance et la récupération doivent nommer le composant concerné, la plage de versions prise en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.
### Modes de défaillance courants
- Surcharge d'etcd : trop de renouvellements de baux de la part de nombreux contrôleurs peuvent submerger etcd, entraînant une latence élevée et des délais d'attente de requête. Les symptômes comprennent une augmentation de etcd_disk_wal_fsync_duration_seconds , une utilisation élevée du processeur sur etcd et des réponses lentes de l'API.
- Dérive d'horloge : si les horloges des nœuds dérivent, les horodatages de renouvellement du bail peuvent être erronés, entraînant une expiration prématurée ou un basculement retardé. Ceci est particulièrement problématique dans les clusters multi-datacenters.
- Partitionnement du réseau : si le leader est isolé du réseau etcd, il ne peut pas renouveler son bail. Après l'expiration du bail, un autre nœud peut prendre le relais, mais l'ancien leader peut encore penser qu'il est actif, entraînant un comportement de split-brain. Ceci est atténué par un cloisonnement approprié (pas toujours mis en œuvre).
- Épuisement des ressources : si le composant détenant le bail est limité en processeur ou manque de mémoire, il peut échouer à renouveler à temps. Cela peut provoquer des changements de leader fréquents et un comportement instable.
### Étapes de récupération
Si vous rencontrez des défaillances liées aux baux, suivez ces étapes de récupération :
Étape 1 : Arrêter l'hémorragie - Si un contrôleur fluctue, réduisez la charge ou suspendez les opérations non critiques. Par exemple, réduisez le nombre de réplicas ou suspendez temporairement les tâches cron.
Étape 2 : Inspecter les journaux et les métriques - Examinez les journaux du composant et les métriques etcd. Pour etcd, vérifiez :
# Métriques etcd (via port-forward ou directement)
curl http://localhost:2379/metrics | grep -E 'etcd_server_leader_changes_seen_total|etcd_disk_wal_fsync_duration_seconds'
Un etcd_server_leader_changes_seen_total élevé indique une instabilité du leader etcd.
Étape 3 : Ajuster les paramètres du bail - Augmentez temporairement leaseDurationSeconds et renewDeadline pour réduire la pression de renouvellement. Par exemple, définissez leaseDurationSeconds sur 30 s et renewDeadline sur 20 s. Cela donne au composant plus de temps pour récupérer.
Étape 4 : Corriger la cause profonde - Si etcd est surchargé, envisagez de déplacer les objets de bail vers un cluster etcd séparé ou de régler etcd. Si la dérive d'horloge est un problème, configurez correctement NTP.
Étape 5 : Vérifier la stabilité - Après les modifications, surveillez pendant au moins 15 minutes. Vérifiez que le renouvellement du bail est régulier et qu'aucun basculement inattendu ne se produit.
### Annuler les modifications
Ayez toujours un plan de restauration. Pour les composants de pod statique, conservez une sauvegarde du fichier manifeste :
cp /etc/kubernetes/manifests/kube-controller-manager.yaml /root/kube-controller-manager.yaml.bak
Si une modification cause des problèmes, restaurez la sauvegarde et redémarrez le kubelet :
cp /root/kube-controller-manager.yaml.bak /etc/kubernetes/manifests/kube-controller-manager.yaml
sudo systemctl restart kubelet
Pour les modifications de configuration du kubelet, revenez au fichier de configuration et redémarrez le kubelet.
## Liste de contrôle des opérations
Pour les performances des baux Kubernetes, la liste de contrôle des opérations doit nommer le composant concerné, la plage de versions prise en charge, les prérequis, une observation en lecture seule, le plus petit changement justifié et la commande ou le signal qui vérifie le résultat.
Utilisez cette liste de contrôle avant et après le réglage :
- [ ] Confirmer la version et la distribution de Kubernetes ( kubectl version --short ou kubectl version ).
- [ ] Identifier les composants utilisant des baux : lister les baux dans kube-system et kube-node-lease .
- [ ] Capturer les heures de renouvellement de bail de référence et l'état de l'élection de leader.
- [ ] Déterminer si le problème de performance est lié aux baux (vérifier les journaux, les métriques et les symptômes).
- [ ] Sélectionner le plus petit changement : ajuster un paramètre à la fois.
- [ ] Appliquer le changement dans un environnement de test d'abord, si possible.
- [ ] Vérifier le changement avec des commandes concrètes (par exemple, vérifier renewTime , l'état du leader).
- [ ] Surveiller pendant au moins 15 minutes pour la stabilité.
- [ ] Documenter le changement, le résultat attendu et les étapes de restauration.
- [ ] En cas d'échec, exécuter la restauration et réévaluer.
De plus, tenez compte des points pratiques suivants :
- Utiliser un accès en lecture seule : commencez toujours par des commandes en lecture seule ; évitez de faire des modifications sans comprendre l'état actuel.
- Protéger les valeurs sensibles : évitez de mettre des secrets dans les commandes de configuration ; utilisez des variables d'environnement ou des cartes de configuration.
- Limiter le rayon d'impact : modifiez un composant à la fois ; évitez les modifications simultanées du gestionnaire de contrôleurs et du planificateur.
- Vérifier avec des signaux : utilisez kubectl get lease -o yaml pour confirmer les mises à jour de renewTime ; utilisez les métriques pour vérifier les taux de renouvellement.
- Conserver la documentation : enregistrez les valeurs d'origine pour pouvoir revenir rapidement.
## Conclusion
L'optimisation des performances des baux Kubernetes avec des exemples pratiques n'est utile que si chaque recommandation est versionnée, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure d'exploitation.
Comme prochaine étape, choisissez une vérification à faible risque pour les performances des baux Kubernetes, enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et examinez les dépendances telles que Node, Kubectl et Event.
Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.
Rappelez-vous : les baux sont des primitives de coordination qui assurent le bon fonctionnement du plan de contrôle de votre cluster. En comprenant leur comportement et en les réglant avec soin, vous pouvez améliorer les temps de basculement, réduire la charge sur etcd et garantir que le rapport de santé des nœuds fonctionne comme prévu. Utilisez les commandes et les vérifications de ce guide pour construire une pratique opérationnelle solide autour des performances des baux.