## Introduction La planification de capacité pour les services Kubernetes consiste à déterminer la bonne quantité de ressources de calcul, de mémoire et de réseau dont votre service a besoin pour gérer le trafic actuel et futur tout en restant rentable et résilient. Bien réalisée, elle évite les pannes dues à l'épuisement des ressources, le gaspillage d'argent sur des clusters surprovisionnés et donne confiance à votre équipe lors de la montée en charge ou du déploiement de nouvelles fonctionnalités. Ce guide se concentre sur des techniques pratiques et concrètes pour les développeurs, les consultants DevOps et les équipes techniques de startups exécutant des charges de travail Kubernetes en production. Nous verrons comment analyser l'utilisation des ressources de votre service, configurer les requêtes et les limites, mettre à l'échelle horizontalement et verticalement, diagnostiquer les goulots d'étranglement de performance et préparer des procédures de récupération pour les modes de défaillance courants. Plutôt que de traiter la planification de capacité comme un exercice ponctuel, nous insistons sur une boucle itérative : observer, mesurer, ajuster et vérifier. À la fin de cet article, vous comprendrez comment utiliser les outils natifs de Kubernetes tels que Metrics Server, Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA) et les commandes kubectl pour prendre des décisions de capacité éclairées pour les services. Chaque recommandation inclut des commandes concrètes, des extraits de configuration et les sorties attendues afin que vous puissiez les tester dans votre propre environnement. ## 1. Inventaire de la version et de l'environnement Avant de toucher à toute configuration en production, vous devez savoir exactement avec quoi vous travaillez. Commencez par enregistrer les versions du serveur et du client Kubernetes, car les comportements de HPA, VPA et de gestion des ressources changent entre les versions. Exécutez les commandes suivantes et sauvegardez la sortie : ```bash kubectl version --short # Exemple de sortie : # Client Version: v1.25.3 # Server Version: v1.25.3 ``` Ensuite, vérifiez que Metrics Server est installé et renvoie des données. Metrics Server agrège l'utilisation du CPU et de la mémoire depuis le kubelet et est requis pour HPA et kubectl top. Vérifiez sa disponibilité avec : ```bash kubectl get deployment metrics-server -n kube-system # Sortie attendue si installé : # NAME READY UP-TO-DATE AVAILABLE AGE # metrics-server 1/1 1 1 10d ``` Si le déploiement est absent, installez-le selon la documentation de votre fournisseur de cluster. Sans Metrics Server, les commandes kubectl top échoueront avec une erreur du type « Metrics API not available ». Recueillez des informations contextuelles sur les services que vous prévoyez de planifier. Listez tous les services de votre namespace et notez leurs types : ```bash kubectl get svc -n your-namespace # Exemple de sortie : # NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE # frontend ClusterIP 10.96.0.10 80/TCP 5d # api LoadBalancer 10.96.0.11 35.190.10.20 443:31000/TCP 5d # internal-db ClusterIP None 5432/TCP 5d ``` Documentez quels services servent le trafic de production, leurs temps de réponse moyens et toute contrainte de mise à l'échelle connue. Cet inventaire constitue la base de toutes les analyses ultérieures. Enfin, examinez la capacité des nœuds de votre cluster et l'allocation actuelle à l'aide de kubectl describe nodes. Recherchez la section « Allocated resources » pour voir combien de CPU et de mémoire sont déjà demandés par les pods : ```bash kubectl describe nodes | grep -A5 "Allocated resources" # Exemple de sortie condensée : # Allocated resources: # (Total limits may be over 100 percent, i.e., overcommitted.) # CPU Requests CPU Limits Memory Requests Memory Limits # 1200m (30%) 3000m (75%) 2Gi (25%) 4Gi (50%) ``` Cet aperçu vous indique la marge disponible à l'échelle du cluster avant même de commencer à mettre à l'échelle un seul service. ## 2. Mesurer l'utilisation actuelle des ressources La planification de capacité commence par des mesures précises de la consommation actuelle des ressources de votre service. Utilisez kubectl top pour observer l'utilisation du CPU et de la mémoire des pods soutenant votre service : ```bash kubectl top pods -l app=frontend --sort-by=cpu # Exemple de sortie : # NAME CPU(cores) MEMORY(bytes) # frontend-7c5f9b8c6d-2xq4l 150m 256Mi # frontend-7c5f9b8c6d-7z8pt 120m 248Mi # frontend-7c5f9b8c6d-k9m2n 180m 270Mi ``` Effectuez ces mesures pendant les heures de pointe pour voir la charge maximale. Laissez la collecte s'exécuter pendant au moins un cycle complet d'activité (par exemple, 24 à 48 heures) pour capturer les pics et les creux quotidiens. Pour des tendances à plus long terme, intégrez Prometheus et Grafana, qui fournissent des données historiques et des requêtes comme `rate(container_cpu_usage_seconds_total[5m])` ou `sum by (pod) (container_memory_working_set_bytes)`. Analysez les données pour déterminer les besoins en ressources de base et de pointe. Par exemple, si les pods frontend ci-dessus utilisent 150-180m de CPU en pointe et 50m au repos, vous pouvez définir une requête CPU de 100m (pour couvrir la charge moyenne) et une limite de 500m (pour permettre des pointes) dans un premier temps, puis affiner après observation du comportement. Surveillez également les métriques réseau de votre service. Les services Kubernetes n'ont pas de limites de bande passante intégrées, mais la capacité réseau du nœud sous-jacent compte. Si votre service est un LoadBalancer, consultez les métriques du fournisseur cloud pour le total des octets entrants/sortants et les taux de connexion. Utilisez `kubectl get endpoints ` pour voir comment le trafic est réparti entre les pods. ```bash kubectl get endpoints frontend # Exemple de sortie : # NAME ENDPOINTS AGE # frontend 10.244.1.5:8080,10.244.2.3:8080,10.244.3.7:8080 5d ``` Si tout le trafic atteint un seul pod, vous avez peut-être un problème de configuration d'affinité de session ou de répartition de charge côté client. Assurez-vous que le paramètre `sessionAffinity` de votre service est correctement défini (par défaut None) à moins d'avoir spécifiquement besoin de sessions collantes. ## 3. Définir les requêtes et limites de ressources Les requêtes et limites de ressources sont la base de la planification de capacité des services. Les requêtes garantissent une quantité minimale de CPU et de mémoire pour vos conteneurs et sont utilisées par le planificateur pour placer les pods sur les nœuds. Les limites plafonnent l'utilisation maximale des ressources. Bien les définir évite à la fois la famine et les problèmes de voisin bruyant. Pour chaque déploiement soutenant votre service, définissez les ressources dans le modèle de pod. Voici un exemple d'extrait YAML pour le déploiement frontend : ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: frontend spec: replicas: 3 selector: matchLabels: app: frontend template: metadata: labels: app: frontend spec: containers: - name: frontend image: yourregistry/frontend:1.2.3 ports: - containerPort: 8080 resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "512Mi" ``` Choisissez les requêtes en fonction de l'utilisation moyenne mesurée plus une petite marge (par exemple, 10-20 %). Choisissez les limites en fonction de l'utilisation de pointe attendue, mais évitez de les fixer trop bas, sinon votre pod sera tué par OOM (pour la mémoire) ou limité (pour le CPU). Pour la mémoire, une pratique courante consiste à définir la requête égale à la limite pour éviter les expulsions imprévues dues au surprovisionnement. Cependant, pour les charges de travail avec des pics, vous pouvez définir une limite supérieure à la requête. Une bonne formule de départ : - Requête CPU = p95 de l'utilisation CPU sur 7 jours, arrondie aux 10m supérieurs. - Requête mémoire = p95 de l'utilisation mémoire + 20 % de marge. - Limite CPU = soit 2x la requête ou p99 de l'utilisation, selon la plus élevée, mais sans dépasser le CPU allouable par pod sur le nœud. - Limite mémoire = requête * 1,5 ou 2x, mais soyez prudent : si la limite est trop élevée, une fuite de mémoire peut consommer tout le nœud. Appliquez le déploiement mis à jour : ```bash kubectl apply -f frontend-deployment.yaml kubectl rollout status deployment/frontend # Sortie attendue : deployment "frontend" successfully rolled out ``` Après le déploiement, vérifiez que les pods fonctionnent avec les nouveaux paramètres de ressources : ```bash kubectl get pods -l app=frontend -o jsonpath='{.items[*].spec.containers[0].resources}' # Exemple de sortie : {"limits":{"cpu":"500m","memory":"512Mi"},"requests":{"cpu":"100m","memory":"128Mi"}} ``` Surveillez les pods pendant quelques heures pour vous assurer qu'aucun OOMKill ou étranglement excessif ne se produit. Si l'utilisation de la mémoire reste constamment proche de la limite, augmentez la limite ; si l'étranglement CPU est élevé (vérifiez la métrique `container_cpu_cfs_throttled_seconds_total`), augmentez la limite CPU ou optimisez le code. ## 4. Stratégies de mise à l'échelle : horizontale et verticale ### Horizontal Pod Autoscaler (HPA) HPA ajuste automatiquement le nombre de réplicas de pods en fonction de l'utilisation du CPU ou de métriques personnalisées. Il est idéal pour les services avec des modèles de trafic variables. Pour créer un HPA pour le déploiement frontend ciblant 60 % d'utilisation moyenne du CPU : ```bash kubectl autoscale deployment frontend --cpu-percent=60 --min=3 --max=10 ``` Ou définissez un manifeste HPA : ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: frontend-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: frontend minReplicas: 3 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 ``` Appliquez-le et vérifiez l'état du HPA : ```bash kubectl apply -f frontend-hpa.yaml kubectl get hpa frontend-hpa # Exemple de sortie : # NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE # frontend-hpa Deployment/frontend 45%/60% 3 10 3 5m ``` À mesure que la charge augmente, le HPA augmentera le nombre de réplicas. Vérifiez les événements : ```bash kubectl describe hpa frontend-hpa # Recherchez des événements du type : "New size: 4; reason: cpu resource utilization (percentage of request) above target" ``` Notez que HPA réagit aux métriques actuelles, pas aux prédictions. Il peut prendre quelques minutes pour mettre à l'échelle, alors prévoyez une capacité de pointe en définissant minReplicas de manière appropriée ou en utilisant des métriques personnalisées pour une réaction plus rapide. ### Vertical Pod Autoscaler (VPA) VPA ajuste les requêtes et limites de CPU et de mémoire des conteneurs en fonction de l'utilisation. Il est utile pour les charges de travail stables où la mise à l'échelle horizontale n'est pas possible (par exemple, bases de données avec état) ou lorsque vous souhaitez dimensionner correctement les ressources. Contrairement à HPA, VPA nécessite généralement des redémarrages de pods pour appliquer les nouvelles ressources, utilisez-le donc avec précaution. Installez VPA depuis le dépôt autoscaler de Kubernetes s'il n'est pas présent. Créez ensuite une ressource VPA : ```yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: frontend-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: frontend updatePolicy: updateMode: "Auto" ``` VPA en mode Auto expulsera les pods pour appliquer les nouvelles recommandations de ressources. Cela peut provoquer une brève interruption, donc pour les services critiques, utilisez le mode « Off » pour obtenir uniquement des recommandations : ```bash kubectl get vpa frontend-vpa # Exemple de sortie (les recommandations apparaissent plus tard via describe) : # NAME MODE CPU MEM PROVIDED AGE # frontend-vpa Off 150m 200Mi True 10m ``` Examinez les recommandations : ```bash kubectl describe vpa frontend-vpa # La section Recommendation peut montrer : # Container: frontend # Lower Bound: CPU 100m, Memory 128Mi # Target: CPU 150m, Memory 200Mi # Upper Bound: CPU 300m, Memory 400Mi ``` Appliquez manuellement les recommandations cibles à votre déploiement. ### Mise à l'échelle manuelle et préchauffage Parfois, vous devez mettre à l'échelle manuellement avant un événement connu (par exemple, un lancement de produit). Utilisez : ```bash kubectl scale deployment frontend --replicas=8 kubectl rollout status deployment/frontend ``` Assurez-vous que le load balancer du service et les endpoints se mettent à jour en conséquence. ## 5. Configuration du service pour la capacité Au-delà des ressources des pods, l'objet Service lui-même a des paramètres qui affectent la capacité. Champs clés : - **Type** : ClusterIP, NodePort, LoadBalancer ou ExternalName. LoadBalancer fournit un accès externe mais peut avoir des limites de débit du fournisseur cloud. - **ExternalTrafficPolicy** : Cluster (par défaut) ou Local. Avec Local, le trafic est acheminé uniquement vers les nœuds avec des pods en cours d'exécution, préservant l'IP source du client mais pouvant provoquer un déséquilibre. - **SessionAffinity** : None ou ClientIP. ClientIP maintient les requêtes du même client vers le même pod, ce qui peut aider avec les caches mais peut provoquer une répartition de charge inégale. - **ipFamilyPolicy** : SingleStack ou DualStack pour IPv4/IPv6. Pour les services à fort trafic, utilisez `externalTrafficPolicy: Local` et assurez une répartition uniforme des pods sur les nœuds pour éviter de surcharger le réseau d'un seul nœud. Cependant, la politique Local peut ne pas bien fonctionner si les contrôles de santé du load balancer ne reflètent pas correctement l'état de préparation des pods. Exemple de service avec LoadBalancer et politique Local : ```yaml apiVersion: v1 kind: Service metadata: name: frontend spec: type: LoadBalancer externalTrafficPolicy: Local selector: app: frontend ports: - port: 80 targetPort: 8080 protocol: TCP ``` Vérifiez les endpoints du service et l'allocation des nœuds après la mise à l'échelle : ```bash kubectl get svc frontend -o wide kubectl get endpoints frontend kubectl get pods -l app=frontend -o wide | awk '{print $1, $7}' ``` Cela montre sur quels nœuds se trouvent les pods, vous aidant à identifier les goulots d'étranglement réseau potentiels. ## 6. Vérification et diagnostics Après tout changement de capacité, vérifiez que le trafic circule correctement et que les ressources sont dans les plages attendues. Exécutez un test de charge contre votre service. Pour un service ClusterIP interne, utilisez un pod temporaire avec un outil de génération de charge comme `hey` ou `ab` : ```bash kubectl run load-generator --image=busybox --restart=Never -- sh -c "while true; do wget -q -O- http://frontend; done" # Mieux : utilisez un outil comme hey ou vegeta depuis un pod avec une image appropriée. ``` Utilisez `kubectl port-forward` pour accéder au service localement et envoyer des requêtes : ```bash kubectl port-forward svc/frontend 8080:80 # Dans un autre terminal : hey -z 30s -c 50 http://localhost:8080 # Exemple de sortie : # Total: 30.0167 secs # Slowest: 0.2345 secs # Fastest: 0.0009 secs # Average: 0.0121 secs # Requests/sec: 4123.4567 ``` Pendant le test de charge, surveillez les métriques des pods : ```bash kubectl top pods -l app=frontend --sort-by=cpu # Surveillez les pods approchant les limites kubectl describe pods -l app=frontend | grep -E "State|Reason|OOMKilled|Throttling" ``` Vérifiez également les événements HPA : ```bash kubectl describe hpa frontend-hpa # Recherchez les événements de mise à l'échelle ``` Si vous voyez des événements OOMKilled, augmentez les limites de mémoire. Si un étranglement CPU se produit (indiqué par la métrique `container_cpu_cfs_throttled_seconds_total`), augmentez les limites CPU ou réduisez les requêtes CPU pour donner plus de marge. Les diagnostics doivent également inclure des vérifications au niveau réseau. Utilisez `kubectl exec` dans un pod et testez la connectivité au DNS du service : ```bash kubectl exec -it frontend-7c5f9b8c6d-2xq4l -- nslookup frontend # Attendu : résout vers ClusterIP kubectl exec -it frontend-7c5f9b8c6d-2xq4l -- wget -q -O- http://frontend # Attendu : renvoie la réponse de votre application ``` ## 7. Pièges courants et comment les éviter Les erreurs de planification de capacité peuvent entraîner des pannes, une dégradation des performances ou des factures cloud gonflées. Voici les pièges les plus fréquents et comment les contourner. ### 1. Définir des requêtes trop élevées ou trop basses - **Pourquoi cela arrive** : Les équipes devinent les valeurs sans mesurer l'utilisation réelle, ou copient depuis d'autres projets. - **Conséquence** : Des requêtes élevées gaspillent la capacité du cluster et empêchent les pods d'être planifiés ; des requêtes basses provoquent un surprovisionnement et peuvent entraîner une pression sur les nœuds et des expulsions. - **Comment éviter** : Basez toujours les requêtes sur des métriques mesurées. Utilisez les recommandations VPA comme point de départ, puis ajustez après observation du trafic réel. ### 2. Ignorer les différences entre mémoire et CPU - **Pourquoi cela arrive** : Traiter le CPU et la mémoire de la même manière. Le CPU est compressible (étranglé), la mémoire ne l'est pas (OOMKilled). - **Conséquence** : Définir une limite de mémoire basse provoque des redémarrages de pods ; définir une limite CPU élevée avec une requête basse peut affamer d'autres pods. - **Comment éviter** : Définissez les limites de mémoire proches des requêtes pour éviter l'expulsion, et définissez les limites CPU plus élevées pour tolérer les pointes. ### 3. Ne pas tenir compte du temps de démarrage des pods - **Pourquoi cela arrive** : HPA augmente l'échelle, mais les nouveaux pods prennent du temps à s'initialiser (par exemple, chargement du cache, connexion aux bases de données). - **Conséquence** : Pendant un pic de trafic, le service peut être submergé avant que les nouveaux pods ne soient prêts, provoquant des délais d'attente. - **Comment éviter** : Utilisez des sondes de préparation pour retarder le trafic vers les pods non prêts, et préchauffez les pods avant les pics attendus. Envisagez d'utiliser des sondes de démarrage de conteneur pour les applications à initialisation lente. ### 4. Négliger la bande passante réseau - **Pourquoi cela arrive** : Surveillance du CPU/mémoire uniquement ; la capacité réseau est souvent ignorée. - **Conséquence** : Un seul nœud peut devenir un goulot d'étranglement réseau, saturant sa carte réseau et provoquant une latence élevée pour tous les pods qui s'y trouvent. - **Comment éviter** : Répartissez les pods sur les nœuds à l'aide de l'anti-affinité de pods, surveillez l'utilisation du réseau des nœuds (par exemple, via node exporter), et envisagez d'utiliser un maillage de services ou un contrôleur d'entrée avec une meilleure répartition de charge. ### 5. Ne pas tester les scénarios de défaillance - **Pourquoi cela arrive** : Les équipes supposent que tout fonctionne jusqu'à ce que ce ne soit pas le cas ; pas d'ingénierie du chaos ni d'exercices de défaillance. - **Conséquence** : Lorsqu'un pod échoue ou qu'un nœud tombe en panne, le service peut se dégrader de manière imprévisible et la récupération est lente. - **Comment éviter** : Simulez régulièrement des défaillances de pods (kubectl delete pod) et des drainages de nœuds. Assurez-vous que minReplicas de HPA couvre une défaillance d'un seul nœud. Testez le comportement du service avec un nombre réduit de réplicas. ### 6. S'appuyer uniquement sur la mise à l'échelle automatique - **Pourquoi cela arrive** : Faire confiance à HPA pour gérer tous les scénarios sans supervision manuelle. - **Conséquence** : HPA peut ne pas mettre à l'échelle assez rapidement pour des pics soudains, ou peut réduire trop agressivement, provoquant des fluctuations. - **Comment éviter** : Définissez minReplicas approprié en fonction de la charge de base. Utilisez des métriques personnalisées pour une mise à l'échelle plus rapide. Surveillez les événements HPA et définissez des alertes pour l'activité de mise à l'échelle. ## 8. Modes de défaillance et procédures de récupération Même avec une planification minutieuse, des défaillances surviennent. Définissez des procédures de récupération pour les scénarios courants. ### Pod OOMKilled **Symptôme** : Le pod redémarre avec la raison OOMKilled, l'application plante. **Diagnostic** : `kubectl describe pod ` montre le dernier état terminé avec la raison OOMKilled. L'utilisation de la mémoire a dépassé la limite. **Récupération** : Augmentez temporairement la limite de mémoire pour stabiliser, puis enquêtez sur la fuite de mémoire. Mettez à jour le déploiement. ```bash kubectl set resources deployment frontend --limits=memory=1Gi --requests=memory=512Mi kubectl rollout restart deployment/frontend ``` Après récupération, analysez les modèles d'utilisation de la mémoire et ajustez les limites de manière permanente. ### Étranglement CPU **Symptôme** : Latence élevée, réponses lentes, mais les pods fonctionnent. L'utilisation du CPU atteint la limite ; les métriques d'étranglement augmentent. **Diagnostic** : Vérifiez `kubectl top pods` et Prometheus pour `container_cpu_cfs_throttled_seconds_total`. **Récupération** : Augmentez la limite CPU ou optimisez le code. ```bash kubectl set resources deployment frontend --limits=cpu=1 --requests=cpu=200m ``` ### Nœud non prêt **Symptôme** : Les pods sur un nœud deviennent inconnus, les endpoints du service manquent. **Diagnostic** : `kubectl get nodes` montre NotReady. `kubectl describe node ` montre les problèmes. **Récupération** : Drainez le nœud si possible, ou laissez le cluster replanifier les pods. Assurez-vous d'avoir suffisamment de capacité. ```bash kubectl cordon kubectl drain --ignore-daemonsets --delete-emptydir-data # Les pods seront replanifiés sur d'autres nœuds ; mettez à jour HPA si nécessaire. ``` ### Endpoints du service manquants **Symptôme** : Le service n'a pas d'endpoints, le trafic échoue. **Diagnostic** : `kubectl get endpoints ` montre une liste vide. Vérifiez les étiquettes du sélecteur et l'état de préparation des pods. **Récupération** : Corrigez le sélecteur ou la sonde de préparation. Exemple : si le sélecteur est `app: frontend` mais que les pods ont `app: frontend-app`, mettez à jour le sélecteur du service. ```bash kubectl patch svc frontend -p '{"spec":{"selector":{"app":"frontend-app"}}}' ``` ### HPA ne met pas à l'échelle **Symptôme** : Les métriques cibles de HPA montrent inconnu ou aucune mise à l'échelle malgré une charge élevée. **Diagnostic** : `kubectl describe hpa` montre les événements. Cause fréquente : le serveur de métriques n'est pas disponible, ou les requêtes de ressources manquent sur les pods (HPA nécessite des requêtes pour l'utilisation du CPU). **Récupération** : Assurez-vous que Metrics Server fonctionne et que les pods ont des requêtes de ressources. Corrigez et réappliquez HPA. ## 9. Liste de contrôle opérationnelle pour la planification de capacité Utilisez cette liste de contrôle avant de déployer un nouveau service ou de modifier la capacité. Chaque élément doit avoir un responsable unique et une cadence de révision. | Élément | Responsable | Fréquence | Commande/Vérification | |------|-------|-----------|---------------| | Vérifier que Metrics Server est installé et rapporte | Priya Shah, responsable ingénierie | Mensuelle | `kubectl get deployment metrics-server -n kube-system` | | Examiner les requêtes et limites de ressources par rapport à l'utilisation réelle | Alex Chen, ingénieur DevOps | Hebdomadaire | Comparer `kubectl top pods` avec les ressources configurées | | Vérifier la configuration HPA et les événements de mise à l'échelle | Priya Shah | Hebdomadaire | `kubectl describe hpa` et examiner les événements | | Mettre à jour les prévisions de capacité en fonction des tendances de trafic | Jamie Rodriguez, chef de produit | Mensuelle | Analyser les métriques du load balancer et de l'application | | Tester les procédures de récupération (suppression de pod, drainage de nœud) | Alex Chen | Trimestrielle | `kubectl delete pod --dry-run=client` puis exercice réel | | Examiner les coûts cloud et optimiser les ressources surprovisionnées | Jamie Rodriguez | Mensuelle | Explorateur de coûts et `kubectl describe nodes` ressources allouées | | S'assurer que les sélecteurs de service et les endpoints sont corrects | Alex Chen | Avant chaque version | `kubectl get endpoints ` | | Valider que minReplicas de HPA couvre une défaillance d'un seul nœud | Priya Shah | Trimestrielle | Calculer la répartition des pods sur les nœuds | Attribuez clairement les responsables et définissez des rappels de calendrier pour ces révisions. La documentation des décisions et des changements est essentielle ; mettez à jour les runbooks en conséquence. ## 10. Conclusion La planification de capacité des services Kubernetes est un processus continu qui combine mesure, configuration et mise à l'échelle proactive. En suivant l'approche systématique de ce guide, vous pouvez éviter les pièges courants, garantir que vos services gèrent le trafic avec élégance et récupérer rapidement des défaillances. Commencez par un inventaire complet de l'environnement, définissez des requêtes et limites de ressources réalistes, utilisez HPA et VPA de manière appropriée et examinez régulièrement les données de performance. La planification de capacité n'est pas une tâche ponctuelle mais une discipline continue qui porte ses fruits en fiabilité et en rentabilité. À mesure que vos modèles de trafic évoluent, revoyez vos hypothèses et ajustez. Avec les bonnes pratiques et les bons outils, vous pouvez maintenir vos services Kubernetes en bon état de fonctionnement à n'importe quelle échelle. ## Lectures complémentaires - Documentation Kubernetes : [Gestion des ressources pour les conteneurs](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) - Documentation Kubernetes : [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) - Documentation Kubernetes : [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) - Prometheus et Grafana pour la surveillance Kubernetes - Limites et quotas des load balancers spécifiques aux fournisseurs cloud