Les performances et la disponibilité d'un cluster Container Service for Kubernetes (ACK) dépendent du nombre de resources du cluster, de la fréquence d'accès à ces resources et des modèles d'accès. Les différentes combinaisons de ces variables exercent une pression variable sur l'API Server et entraînent des niveaux de performance distincts. Dans un cluster ACK Pro à grande échelle (généralement un cluster comptant plus de 500 nœuds ou 10 000 pods), les administrateurs doivent planifier et utiliser le cluster de manière appropriée en fonction des besoins métier réels, tout en surveillant étroitement les métriques afin de garantir la stabilité et la disponibilité du cluster.
Guide de lecture
Cette rubrique s'adresse aux développeurs et administrateurs de clusters ACK Pro. Elle fournit des recommandations générales pour la planification et l'utilisation de clusters à grande échelle. Adaptez-les selon votre environnement de cluster réel et vos exigences métier.
Dans le cadre du modèle de responsabilité partagée , ACK gère la sécurité des composants du plan de contrôle du cluster — y compris les composants du plan de contrôle Kubernetes et etcd — ainsi que l'infrastructure sous-jacente d'Alibaba Cloud. Vous êtes responsable de la sécurisation de vos applications métier et de la configuration de vos resources cloud. Pour plus de détails, consultez Modèle de responsabilité partagée .
Phase de planification
Cluster unique ou clusters multiples
Un cluster unique à grande échelle réduit la charge de gestion et améliore l'utilisation des resources. Toutefois, dans certains scénarios métier, il est plus judicieux de répartir les services sur plusieurs clusters.
Envisagez l'utilisation de plusieurs clusters dans les cas suivants :
| Critère | Quand séparer les clusters |
|---|---|
| Isolation | Empêchez les problèmes survenant dans un environnement (par exemple, test) d'affecter la production. La séparation des clusters réduit le périmètre d'impact des défaillances. |
| Distribution géographique | Déployez des clusters dans des régions spécifiques pour répondre aux exigences de disponibilité et de latence des utilisateurs finaux. |
| Limites de taille d'un cluster unique | Le plan de contrôle managé ACK s'adapte aux clusters de différentes tailles grâce à la mise à l'échelle automatique et à l'optimisation des performances des composants du cluster. Cependant, l'architecture Kubernetes comporte des limites de performance inhérentes, et un cluster surdimensionné peut nuire à la disponibilité et aux performances. Avant de planifier un cluster à grande échelle, examinez les limites de capacité et les SLOs définis par la communauté, puis vérifiez votre quota dans le Quota Center. Si vos besoins dépassent les limites communautaires ou celles d'ACK, optez pour une architecture multi-clusters. |
Pour gérer plusieurs clusters dans le cadre de tâches telles que le déploiement d'applications, la gestion du trafic, la distribution des jobs et la surveillance, activez la gestion de flotte.
Maintenez les clusters à jour
Les versions récentes de Kubernetes intègrent des améliorations de stabilité, de performance et de scalabilité qui profitent directement aux clusters à grande échelle. Voici quelques exemples notables :
v1.31 : kube-apiserver assure des lectures cohérentes pour les requêtes List depuis son cache, ce qui réduit les accès directs à etcd et allège sa charge. Consultez Lectures cohérentes depuis le cache.
v1.33 : kube-apiserver utilise un encodage en streaming (StreamingCollectionEncodingToJSON et StreamingCollectionEncodingToProtobuf) pour les opérations List, réduisant ainsi l'utilisation de la mémoire par kube-apiserver à grande échelle. Consultez Réponses List en streaming.
v1.34 : kube-apiserver prend en charge la mise en cache par snapshot des versions historiques des resources, améliorant ainsi les performances en lecture et en écriture. Consultez Cache API server avec snapshot.
ACK publie les versions Kubernetes prises en charge en synchronisation avec la communauté et cesse de supporter les versions expirées — ce qui inclut l'arrêt des nouvelles fonctionnalités, des corrections de bugs et des correctifs de sécurité — tout en fournissant uniquement un support technique limité pour ces versions obsolètes. Surveillez les annonces de publication via divers canaux tels que la documentation, les notifications de la console et les messages internes, et procédez rapidement aux mises à niveau pour éviter d'éventuels problèmes de sécurité et de stabilité du cluster.
Versions prises en charge : Guide des versions
Considérations et procédures de mise à niveau : Mettre à niveau les clusters
Mise à niveau manuelle : Mettre à niveau manuellement un cluster ACK
Mise à niveau automatique : Mettre à niveau automatiquement un cluster
Utilisez le plan de contrôle prédéfini ACK Pro
Le plan de contrôle d'un cluster ACK Pro repose sur une architecture à mise à l'échelle automatique. Dans les clusters de très grande taille ou lors de pics soudains de concurrence élevée, le délai de réponse lié à l'extension élastique peut impacter la continuité de service. Le plan de contrôle prédéfini ACK Pro préalloue et fixe les resources du plan de contrôle, maintenant ainsi la concurrence API et la capacité d'ordonnancement des pods à un niveau élevé garanti. Cette solution convient parfaitement à l'entraînement et à l'inférence IA, aux clusters ultra-dimensionnés et aux charges de travail critiques.
En fixant les resources du plan de contrôle et les configurations de base de l'API Server, le plan de contrôle prédéfini ACK Pro élimine à la source l'incertitude liée à la mise à l'échelle élastique, au lieu de dépendre de mécanismes élastiques pour rattraper la charge après coup. Cela garantit des performances prévisibles du plan de contrôle en toutes circonstances.
Pour plus d'informations, consultez Plan de contrôle prédéfini ACK Pro.
Surveillez les limites des resources du cluster
Respectez les limites suivantes pour maintenir la disponibilité et les performances des clusters à grande échelle.
| Ressource | Limite | Action |
|---|---|---|
| Taille de la base de données etcd (DB Size) | Maintenez-la sous 8 Go. Une base de données etcd surdimensionnée dégrade les performances, notamment la latence de lecture/écriture des données, la consommation des ressources système et la latence d'élection. Elle rend également la récupération des services et des données plus difficile et longue. | Gardez la taille totale de la base de données etcd inférieure à 8 Go :
|
| Données totales par type de ressource dans etcd | Ne dépassez pas 800 Mo par type. Si le volume total d'un type de ressource est trop important, les clients qui listent toutes les resources de ce type consomment beaucoup de resources système. Dans les cas graves, l'API server ou les contrôleurs personnalisés peuvent échouer lors de leur initialisation. | Lors de la définition d'une nouvelle CustomResourceDefinition (CRD), estimez à l'avance le nombre final de custom resources (CRs). Lors du déploiement de charts avec Helm, notez que Helm crée des releases pour suivre l'état du déploiement. Par défaut, Helm stocke les informations de release dans des Secrets. Dans les clusters à grande échelle, le stockage d'un grand volume d'informations de release dans des Secrets peut dépasser la limite Kubernetes sur la taille totale des Secrets. Privilégiez plutôt le backend de stockage SQL de Helm. |
| Connexions et bande passante du CLB de l'API Server | Bande passante maximale : 5 120 Mbit/s ; consultez Instances CLB pour les limites de connexions. Le dépassement de la limite de connexions ou de bande passante du CLB peut faire passer les nœuds à l'état Not Ready. | Pour les clusters comportant 1 000 nœuds ou plus, utilisez des instances Classic Load Balancer (CLB) facturées à l'utilisation. Adoptez le mode de connexion directe ENI (Elastic Network Interface) lorsque les clusters à grande échelle accèdent au service Kubernetes dans le namespace Default. Les clusters créés après février 2023 avec Kubernetes 1.20 ou version ultérieure utilisent la connexion directe ENI par défaut. Consultez Accéder à l'API server via un endpoint interne. |
| Services par namespace | Restez sous 5 000 | Le kubelet injecte les informations de service sous forme de variables d'environnement dans les pods. Un nombre excessif de services par namespace ralentit le démarrage des pods ou provoque des échecs. Définissez enableServiceLinks: false dans le podSpec pour désactiver cette injection. Consultez Accéder au service. |
| Total des services dans le cluster | Maximum 10 000 au total ; 500 pour les services de type LoadBalancer | Un excès de services augmente le nombre de règles réseau traitées par kube-proxy, ce qui dégrade ses performances. Pour les services de type LoadBalancer, le délai de synchronisation vers le CLB peut atteindre plusieurs minutes lorsque leur nombre est élevé. |
| Pods backend par endpoint de service | Limitez-vous à 3 000 | Sur chaque nœud, kube-proxy surveille les mises à jour des Services pour actualiser les règles réseau locales. Lorsqu'un service possède de nombreux endpoints, son objet Endpoints devient volumineux, et chaque mise à jour de cet objet génère un trafic important entre l'API server et kube-proxy. Plus le cluster est grand, plus cet effet boule de neige est prononcé. Pour y remédier, kube-proxy utilise EndpointSlices par défaut dans les clusters v1.19 et ultérieurs. Préférez EndpointSlices aux Endpoints dans les clusters à grande échelle : EndpointSlices fragmentent les endpoints en blocs plus petits, réduisant ainsi le volume de données transmis à chaque modification. Si vous utilisez un contrôleur personnalisé qui lit directement les Endpoints, maintenez le compte sous 1 000 par objet Endpoints ; au-delà, l'objet est automatiquement tronqué. Consultez Endpoints en surcapacité. |
| Total des endpoints pour tous les services | Ne dépassez pas 64 000 | Un nombre excessif d'endpoints surcharge l'API Server et dégrade les performances réseau. |
| Pods en attente (Pending) | Maintenez le seuil sous 10 000 | Un nombre élevé de pods en attente amène le scheduler à générer des événements répétés, susceptibles de déclencher des tempêtes d'événements. |
| Secrets dans les clusters avec chiffrement KMS V1 | Maximum 2 000 | Avec KMS V1, chaque opération de chiffrement génère une nouvelle clé de chiffrement des données (DEK). Au démarrage ou lors de la mise à niveau du cluster, tous les secrets sont déchiffrés séquentiellement. Un trop grand nombre de secrets ralentit considérablement le démarrage. Consultez Chiffrement au repos des secrets avec KMS. |
Phase de configuration
Configurer les paramètres des composants du plan de contrôle
kube-apiserver
kube-apiserver limite le traitement des requêtes simultanées afin de protéger le plan de contrôle. Lorsque cette limite est dépassée, il renvoie une réponse HTTP 429 (Too Many Requests) et demande aux clients de réessayer. En l'absence de limitation côté serveur, un volume excessif de requêtes peut provoquer la défaillance du plan de contrôle.
Mécanismes de limitation
Deux mécanismes de limitation existent selon la version de Kubernetes :
Antérieur à la v1.18 : Limitation par concurrence maximale uniquement. Les paramètres de démarrage
--max-requests-inflightet--max-mutating-requests-inflightplafonnent respectivement la concurrence des requêtes en lecture et en écriture. Aucune différenciation de priorité n'est appliquée : des requêtes lentes et peu prioritaires peuvent bloquer des requêtes urgentes. Les clusters ACK Pro permettent de personnaliser ces paramètres. Consultez Personnaliser les paramètres des composants du plan de contrôle.-
v1.18 et versions ultérieures : API Priority and Fairness (APF) offre une gestion fine du trafic. APF classe et isole les requêtes par priorité, garantissant le traitement prioritaire des requêtes critiques tout en maintenant l'équité. Passé en phase bêta avec la v1.20, ce mécanisme est activé par défaut. Dans les clusters exécutant la v1.20 ou une version ultérieure, la capacité totale de requêtes simultanées correspond à la somme de
--max-requests-inflightet--max-mutating-requests-inflight. APF utilise deux types de CRD pour allouer cette capacité.PriorityLevelConfiguration : Définit les niveaux de priorité ainsi que la proportion de concurrence totale attribuée à chaque niveau.
FlowSchema : Associe les requêtes entrantes à une PriorityLevelConfiguration.
kube-apiserver assure automatiquement la maintenance de ces objets. Pour consulter la configuration actuelle, affichez les PriorityLevelConfiguration :
ACK ajoute
ack-system-leader-electionetack-defaultau FlowSchema destiné aux composants principaux d'ACK. Les autres entrées correspondent aux valeurs par défaut de la communauté Kubernetes.kubectl get PriorityLevelConfiguration # Expected output NAME TYPE ASSUREDCONCURRENCYSHARES QUEUES HANDSIZE QUEUELENGTHLIMIT AGE catch-all Limited 5 <none> <none> <none> 4m20s exempt Exempt <none> <none> <none> <none> 4m20s global-default Limited 20 128 6 50 4m20s leader-election Limited 10 16 4 50 4m20s node-high Limited 40 64 6 50 4m20s system Limited 30 64 6 50 4m20s workload-high Limited 40 128 6 50 4m20s workload-low Limited 100 128 6 50 4m20sConsulter les FlowSchema :
kubectl get flowschemas # Expected output NAME PRIORITYLEVEL MATCHINGPRECEDENCE DISTINGUISHERMETHOD AGE MISSINGPL exempt exempt 1 <none> 4d18h False probes exempt 2 <none> 4d18h False system-leader-election leader-election 100 ByUser 4d18h False endpoint-controller workload-high 150 ByUser 4d18h False workload-leader-election leader-election 200 ByUser 4d18h False system-node-high node-high 400 ByUser 4d18h False system-nodes system 500 ByUser 4d18h False ack-system-leader-election leader-election 700 ByNamespace 4d18h False ack-default workload-high 800 ByNamespace 4d18h False kube-controller-manager workload-high 800 ByNamespace 4d18h False kube-scheduler workload-high 800 ByNamespace 4d18h False kube-system-service-accounts workload-high 900 ByNamespace 4d18h False service-accounts workload-low 9000 ByUser 4d18h False global-default global-default 9900 ByUser 4d18h False catch-all catch-all 10000 ByUser 4d18h False
Réagir à la limitation
Détectez la limitation en surveillant les réponses HTTP 429 ou la métrique apiserver_flowcontrol_rejected_requests_total. Lorsqu'une limitation survient :
Adoptez le plan de contrôle prédéfini ACK Pro : Ce plan de contrôle réserve les ressources de base de l'API Server et fournit directement une capacité de traitement garantie pour les fortes concurrences. Pour plus d'informations, consultez Plan de contrôle prédéfini ACK Pro.
-
Ajustez la PriorityLevelConfiguration :
Pour les requêtes qui ne doivent subir aucune limitation, créez un nouveau FlowSchema et associez-le à un niveau de priorité élevé tel que
workload-highouexempt. Utilisezexemptavec prudence, car les requêtes exemptées échappent totalement à la limitation APF. Vous avez également la possibilité de créer une nouvelle PriorityLevelConfiguration offrant une concurrence supérieure pour les requêtes prioritaires.Si des clients lents surchargent l'API Server, créez un FlowSchema dirigeant ces requêtes vers une PriorityLevelConfiguration à faible concurrence.
kube-controller-manager et kube-scheduler
Après la mise à niveau vers le plan de contrôle prédéfini ACK Pro, les paramètres liés au QPS utilisés par kube-controller-manager et kube-scheduler pour communiquer avec l'API Server s'ajustent automatiquement en fonction du niveau sélectionné.
kubelet
La valeur par défaut de kube-api-qps est 5 et celle de kube-api-burst est 10, ce qui suffit à la plupart des clusters. Si vous constatez des mises à jour lentes de l'état des pods, des retards d'ordonnancement ou des montages de volumes persistants tardifs, augmentez ces valeurs. Consultez Personnaliser les configurations kubelet pour un pool de nœuds.
L'augmentation du QPS de kubelet accélère la fréquence de communication entre chaque nœud et l'API Server. Augmentez cette valeur progressivement et surveillez les performances de l'API Server pour éviter de surcharger le plan de contrôle.
Pour préserver la stabilité du plan de contrôle lors des déploiements, ACK limite les mises à jour parallèles de kubelet à 10 nœuds maximum par lot au sein de chaque pool de nœuds.
Planifier les charges de travail à grande échelle
Désactiver le montage automatique des tokens ServiceAccount pour les pods sans accès API
Le kubelet établit une connexion Watch persistante pour chaque secret monté dans un pod. Un grand nombre de connexions Watch dégrade les performances du plan de contrôle.
Avant Kubernetes v1.22 : En l'absence de ServiceAccount spécifié, Kubernetes monte automatiquement un secret pour le ServiceAccount par défaut. Pour les tâches par lots et les pods d'application n'accédant pas à l'API Server, définissez
automountServiceAccountToken: falseafin d'éviter ce montage. Cela empêche la création inutile de secrets et de connexions Watch. Consultez Opt out of API credential automounting.Kubernetes v1.22 et versions ultérieures : Exploitez l'API TokenRequest pour obtenir des tokens éphémères à rotation automatique, montés sous forme de volume projeté. Cette approche renforce la sécurité et réduit le nombre de connexions Watch gérées par le kubelet. Consultez Utiliser la projection de volume de token ServiceAccount.
Maîtriser le nombre et la taille des objets Kubernetes
Supprimez rapidement les ressources inutilisées (ConfigMaps, Secrets, PVC) pour réduire la charge système et maintenir etcd allégé.
Limitez l'historique des déploiements : Définissez
revisionHistoryLimitsur une valeur basse pour restreindre le nombre d'anciens ReplicaSets conservés par Kubernetes. La valeur par défaut est 10. Dans les clusters comportant de nombreux déploiements fréquemment mis à jour, un historique trop long alourdit la charge de gestion de kube-controller-manager. Consultez revisionHistoryLimit.Nettoyez automatiquement les jobs terminés : Utilisez
ttlSecondsAfterFinishedpour supprimer les jobs terminés et leurs pods après un délai défini. Cela évite l'accumulation d'objets job dans les clusters exécutant de nombreux CronJobs. Consultez TTL controller for finished resources.
Définir des limites de ressources adaptées pour les composants basés sur Informer
Les composants reposant sur Informer (tels que les contrôleurs et kube-scheduler) maintiennent un cache local des ressources qu'ils surveillent. Leur consommation mémoire évolue proportionnellement au nombre et à la taille de ces ressources.
Dans les clusters à grande échelle, surveillez attentivement la consommation mémoire de ces composants pour prévenir les erreurs de mémoire insuffisante (OOM). Lorsqu'un composant manque de mémoire, il est arrêté puis redémarré. Chaque redémarrage déclenche un nouveau cycle List-Watch, exerçant une pression supplémentaire sur l'API Server. Des redémarrages fréquents créent une boucle nuisible au plan de contrôle.
Augmentez les limites mémoire des composants basés sur Informer afin qu'elles correspondent à l'échelle réelle des ressources qu'ils gèrent.
Configurer correctement les webhooks et les services API
Si des webhooks ou des services API sont configurés sur le cluster, les requêtes ciblant certaines ressources transitent par les serveurs webhook et de service API. Des réponses lentes provenant de serveurs webhook ou de service API personnalisés entraînent l'accumulation de requêtes dans l'API Server, ralentissant ainsi les temps de réponse. Surveillez l'utilisation des ressources des serveurs webhook et de service API, et procédez à leur mise à l'échelle horizontale en temps voulu.
Phase d'exécution
Planifier les taux de mise à l'échelle
En fonctionnement stable, le plan de contrôle subit généralement une faible charge, même au sein de grands clusters. Le risque provient plutôt de modifications rapides et massives, telles que la création ou la suppression simultanée de nombreuses ressources, ou encore la mise à l'échelle concurrente d'un grand nombre de nœuds.
Par exemple, un cluster de 5 000 nœuds exécutant des charges de travail stables peut présenter une pression minime sur le plan de contrôle. En revanche, un cluster de 1 000 nœuds qui crée 10 000 tâches éphémères en une minute, ou qui ajoute horizontalement 2 000 nœuds simultanément, peut pousser le plan de contrôle à ses limites.
Les valeurs indiquées ci-dessous constituent des directives de référence et non des limites strictes. La capacité du plan de contrôle dépend de nombreux facteurs. Procédez toujours à une mise à l'échelle progressive : n'augmentez le taux qu'après avoir confirmé que le plan de contrôle répond normalement.
Mise à l'échelle des nœuds :
Pour les clusters comptant plus de 2 000 nœuds, lors d'une mise à l'échelle manuelle via des pools de nœuds :
Pool de nœuds unique, opération unique : pas plus de 100 nœuds
Plusieurs pools de nœuds simultanément : pas plus de 300 nœuds au total
Mise à l'échelle des pods :
Lorsqu'un pod est associé à un service, chaque événement de mise à l'échelle met à jour les Endpoints ou EndpointSlice et propage cette mise à jour à tous les nœuds, ce qui génère un événement de propagation des données à l'échelle du cluster. Cet effet s'amplifie dans les grands clusters.
Pour les clusters comptant plus de 5 000 nœuds :
Pods non associés à un endpoint de service : QPS de mise à jour ≤ 300/s
Pods associés à un endpoint de service : QPS de mise à jour ≤ 10/s
Pour les déploiements utilisant une stratégie Rolling Update, définissez des valeurs réduites pour maxUnavailable et maxSurge afin de diminuer le taux de remplacement des pods.
Optimiser les modèles d'accès client
À mesure que le nombre de ressources du cluster augmente, des requêtes fréquentes vers l'API Server amplifient la charge du plan de contrôle et peuvent provoquer des défaillances en cascade. Respectez les directives suivantes lors du développement de contrôleurs ou d'outils accédant à l'API Server.
Utiliser des informers pour l'accès aux données mises en cache :
Recourez aux informers client-go pour lire les ressources depuis un cache local plutôt que d'émettre des requêtes List directes vers l'API Server.
Les informers maintiennent une seule connexion Watch et traitent les requêtes de lecture localement, ce qui réduit considérablement la charge de l'API Server.
Optimiser les requêtes directes vers l'API Server :
-
**Définissez
resourceVersion=0dans les requêtes List** pour lire depuis le cache de l'API Server plutôt que d'interroger etcd. Cela réduit les allers-retours entre l'API Server et etcd, tout en accélérant les réponses :k8sClient.CoreV1().Pods("").List(context.Background(), metav1.ListOptions{ResourceVersion: "0"}) Utilisez des sélecteurs de libellés et des sélecteurs de champs pour restreindre la portée des requêtes List et réduire la taille des payloads de réponse. Remarque : etcd étant un magasin clé-valeur, il ne peut pas filtrer par libellé ou par champ ; c'est l'API Server qui effectue ce filtrage depuis son cache. Combinez toujours les sélecteurs avec
resourceVersion=0pour éviter d'interroger etcd directement.-
Privilégiez protobuf pour les ressources non-CRD. Protobuf consomme moins de mémoire et de bande passante que JSON. Spécifiez plusieurs types de contenu dans l'en-tête
Acceptafin de revenir à JSON lorsque protobuf n'est pas disponible :Accept: application/vnd.kubernetes.protobuf, application/jsonConsultez Représentations alternatives des ressources.
Adopter une architecture de contrôleur centralisé :
Évitez de déployer des contrôleurs indépendants sur chaque nœud, chacun surveillant l'intégralité de l'état du cluster. Au démarrage, tous ces contrôleurs émettent simultanément des requêtes List pour synchroniser l'état, ce qui peut saturer le plan de contrôle.
Exécutez plutôt une ou quelques instances de contrôleurs gérées de manière centralisée pour l'ensemble du cluster. Un contrôleur centralisé n'émet qu'une seule requête List au démarrage et maintient un nombre minimal de connexions Watch, ce qui réduit drastiquement la pression sur l'API Server.
Phase d'observabilité : surveiller les métriques du plan de contrôle
Utilisez le tableau de bord de surveillance des composants du plan de contrôle pour suivre les métriques essentielles et détecter précocement les problèmes. Consultez Surveillance des composants du plan de contrôle.
Utilisation des ressources du plan de contrôle
Vous pouvez consulter l'utilisation des ressources de tous les composants du plan de contrôle. Les métriques associées sont décrites dans le tableau suivant.
| Métrique | PromQL | Description |
|---|---|---|
| Utilisation de la mémoire | memory_utilization_byte{container="kube-apiserver"} |
Utilisation de la mémoire par l'API Server, en octets |
| Utilisation du CPU | cpu_utilization_core{container="kube-apiserver"}*1000 |
Utilisation du CPU par l'API Server, en millicores |
| Concurrence des requêtes API | sum(apiserver_flowcontrol_current_executing_seats) |
Concurrence de l'API Server, en seats |
| Taux de planification des pods | rate(scheduler_schedule_attempts_total{result="scheduled"}[2m]) |
Taux de planification des pods, en pods/s |
| Taille de la base de données etcd | max(etcd_mvcc_db_total_size_in_use_in_bytes) |
Taille de la base de données etcd, en octets |
kube-apiserver
Pour la liste complète des métriques et les instructions de consultation, reportez-vous à Métriques de surveillance du composant kube-apiserver.
Nombre d'objets ressources :
| Métrique | PromQL | Notes |
|---|---|---|
| Nombre d'objets ressources | max by(resource)(apiserver_storage_objects) |
Kubernetes 1.22 et versions ultérieures |
max by(resource)(etcd_object_counts) |
Kubernetes 1.22 et versions antérieures ; les deux métriques coexistent dans la v1.22 pour assurer la compatibilité |
Latence des requêtes :
| Métrique | PromQL | Description | |||
|---|---|---|---|---|---|
| Latence des requêtes GET | |
proxy"}[$interval])) by (pod, verb, resource, subresource, scope, le))` |
Temps de réponse GET par pod API Server, ressource et scope |
||
| Latence des requêtes LIST | histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="LIST"}[$interval])) by (pod_name, verb, resource, scope, le)) |
Temps de réponse LIST par pod API Server, ressource et scope | |||
| Latence des requêtes d'écriture | |
WATCH |
LIST |
CONNECT"}[$interval])) by (cluster, pod_name, verb, resource, scope, le))` |
Temps de réponse des requêtes mutatives par verbe, ressource et scope |
Limitation des requêtes :
| Métrique | PromQL | Description |
|---|---|---|
| Taux de limitation des requêtes | sum(irate(apiserver_dropped_requests_total{request_kind="readOnly"}[$interval])) by (name) |
Taux de limitation pour les requêtes en lecture ; No data ou 0 indique l'absence de limitation |
sum(irate(apiserver_dropped_requests_total{request_kind="mutating"}[$interval])) by (name) |
Taux de limitation pour les requêtes mutatives |
kube-scheduler
Pour la liste complète des métriques et les instructions de consultation, reportez-vous à Métriques de surveillance du composant kube-scheduler.
Pods en attente :
| Métrique | PromQL | Description |
|---|---|---|
| Pods en attente du scheduler | scheduler_pending_pods{job="ack-scheduler"} |
Répartition par type : unschedulable (impossible à planifier), backoff (échec, en attente de nouvelle tentative), active (prêt à être planifié) |
Latence des requêtes :
| Métrique | PromQL | Description |
|---|---|---|
| Latence des requêtes kube-apiserver | histogram_quantile($quantile, sum(rate(rest_client_request_duration_seconds_bucket{job="ack-scheduler"}[$interval])) by (verb,url,le)) |
Délai entre l'envoi d'une requête par kube-scheduler et la réception de la réponse de kube-apiserver, par verbe et URL |
kube-controller-manager
Pour la liste complète des métriques et les instructions de consultation, reportez-vous à Métriques de surveillance du composant kube-controller-manager.
File d'attente de travail :
| Métrique | PromQL | Description |
|---|---|---|
| Profondeur de la file d'attente | sum(rate(workqueue_depth{job="ack-kube-controller-manager"}[$interval])) by (name) |
Taux de variation de la longueur de la file d'attente sur l'intervalle spécifié |
| Délai de traitement de la file d'attente | histogram_quantile($quantile, sum(rate(workqueue_queue_duration_seconds_bucket{job="ack-kube-controller-manager"}[5m])) by (name, le)) |
Temps d'attente des événements dans la file d'attente de travail |
etcd
Pour la liste complète des métriques et les instructions de consultation, reportez-vous à Métriques de surveillance du composant etcd.
Nombre de clés-valeurs :
| Métrique | PromQL | Description |
|---|---|---|
| Nombre total de KV | etcd_debugging_mvcc_keys_total |
Nombre total de paires clé-valeur dans le cluster etcd |
Taille de la base de données :
| Métrique | PromQL | Description |
|---|---|---|
| Taille sur disque | etcd_mvcc_db_total_size_in_bytes |
Taille totale de la base de données backend etcd |
| Utilisation de la base de données | etcd_mvcc_db_total_size_in_use_in_bytes |
Taille réellement utilisée de la base de données backend etcd |
Documentation connexe
Quotas et limites du cluster : Quotas et limites
Planification réseau : Planifier les blocs CIDR pour un cluster géré ACK
Configurations de charges de travail haute fiabilité : Configurations de charges de travail recommandées
Capacité du plan de contrôle pour les clusters à très grande échelle : le plan de contrôle prédéfini ACK Pro préalloue et réserve les ressources du plan de contrôle afin de garantir une concurrence API et une capacité de planification des pods déterministes.
Dépannage du cluster : Dépannage et FAQ sur la gestion des clusters