{"id":77693,"date":"2020-04-13T01:42:39","date_gmt":"2020-04-12T23:42:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes"},"modified":"2020-04-13T01:42:39","modified_gmt":"2020-04-12T23:42:39","slug":"cpu-limity-i-agressivnyj-trottling-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","title":{"rendered":"Limites CPU et throttling agressif dans Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Note de traduction.<\/b>: cette histoire instructive d'Omio \u2014 un agr\u00e9gateur de voyages europ\u00e9en \u2014 guide les lecteurs de la th\u00e9orie de base aux aspects pratiques captivants de la configuration de Kubernetes. D\u00e9couvrir de tels cas aide non seulement \u00e0 \u00e9largir ses horizons, mais aussi \u00e0 pr\u00e9venir des probl\u00e8mes non triviaux.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Limites CPU et throttling agressif dans Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/1175c9df746e43b5a7d81476164929db.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAvez-vous d\u00e9j\u00e0 \u00e9t\u00e9 confront\u00e9 \u00e0 une application qui \u00ab stagnait \u00bb, cessait de r\u00e9pondre aux requ\u00eates de v\u00e9rification d'\u00e9tat (health checks) et vous ne pouviez pas comprendre la raison d'un tel comportement ? Une des explications possibles est li\u00e9e \u00e0 la limite de quota sur les ressources CPU. C'est ce sujet que nous aborderons dans cet article.<\/p>\n<p><b>TL;DR :<br \/>\nNous vous recommandons vivement d'abandonner les limites de CPU dans Kubernetes (ou de d\u00e9sactiver les quotas CFS dans Kubelet), si vous utilisez une version du noyau Linux avec un bogue de quotas CFS. Dans le noyau. <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">un support pour XWayland;<\/a><\/noindex> il existe un bogue s\u00e9rieux et <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/67577\">bien connu<\/a><\/noindex> qui entra\u00eene un throttling excessif et des retards<\/b>.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Chez Omio <b>toute notre infrastructure est g\u00e9r\u00e9e par Kubernetes<\/b>. Tous nos workloads stateful et stateless fonctionnent exclusivement sur Kubernetes (nous utilisons Google Kubernetes Engine). Au cours des six derniers mois, nous avons constat\u00e9 des ralentissements al\u00e9atoires. Les applications se bloquent ou cessent de r\u00e9pondre aux health checks, perdent la connexion au r\u00e9seau, etc. Ce comportement nous a longtemps laiss\u00e9 perplexes et nous avons finalement d\u00e9cid\u00e9 de nous pencher s\u00e9rieusement sur le probl\u00e8me.<\/p>\n<p>R\u00e9sum\u00e9 de l'article :<\/p>\n<ul>\n<li> Quelques mots sur les conteneurs et Kubernetes ;<\/li>\n<li> Comment sont impl\u00e9ment\u00e9s les requ\u00eates et limites CPU ;<\/li>\n<li> Comment la limite de CPU fonctionne dans les environnements \u00e0 plusieurs c\u0153urs ;<\/li>\n<li> Comment surveiller le throttling de CPU ;<\/li>\n<li> Solution du probl\u00e8me et nuances.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Quelques mots sur les conteneurs et Kubernetes<\/h2>\n<p>\nKubernetes est essentiellement la norme moderne dans le monde de l'infrastructure. Sa t\u00e2che principale est l'orchestration des conteneurs.<\/p>\n<h3>Conteneurs<\/h3>\n<p>\nDans le pass\u00e9, nous devions cr\u00e9er des artefacts comme des fichiers Java JAR\/WAR, des Eggs Python ou des ex\u00e9cutables pour leur ex\u00e9cution ult\u00e9rieure sur des serveurs. Cependant, pour les faire fonctionner, il fallait effectuer un travail suppl\u00e9mentaire : installer l'environnement d'ex\u00e9cution (Java\/Python), placer les fichiers n\u00e9cessaires aux bons endroits, assurer la compatibilit\u00e9 avec une version sp\u00e9cifique du syst\u00e8me d'exploitation, etc. En d'autres termes, il fallait pr\u00eater une attention particuli\u00e8re \u00e0 la gestion des configurations (ce qui \u00e9tait souvent la source de tensions entre d\u00e9veloppeurs et administrateurs syst\u00e8me).<\/p>\n<p><b>Les conteneurs ont tout chang\u00e9.<\/b> Maintenant, un artefact prend la forme d'une image de conteneur. On peut le consid\u00e9rer comme un fichier ex\u00e9cutable \u00e9tendu, contenant non seulement le programme mais \u00e9galement un environnement d'ex\u00e9cution complet (Java\/Python\/etc.), ainsi que les fichiers\/packages n\u00e9cessaires, pr\u00e9install\u00e9s et pr\u00eats \u00e0 \u00eatre lanc\u00e9s. Les conteneurs peuvent \u00eatre d\u00e9ploy\u00e9s et ex\u00e9cut\u00e9s sur diff\u00e9rents serveurs sans aucune action suppl\u00e9mentaire.<\/p>\n<p>De plus, les conteneurs fonctionnent dans leur propre environnement isol\u00e9. Ils disposent de leur propre adaptateur r\u00e9seau virtuel, d'un syst\u00e8me de fichiers avec un acc\u00e8s restreint, d'une hi\u00e9rarchie de processus, de limitations sur le CPU et la m\u00e9moire, etc. Tout cela est r\u00e9alis\u00e9 gr\u00e2ce \u00e0 une sous-syst\u00e8me particulier du noyau Linux \u2014 les namespaces.<\/p>\n<h3>Kubernetes<\/h3>\n<p>\nComme mentionn\u00e9 pr\u00e9c\u00e9demment, Kubernetes est un orchestrateur de conteneurs. Son fonctionnement est le suivant : vous lui fournissez un pool de machines, puis vous dites : \u00ab H\u00e9, Kubernetes, lance dix instances de mon conteneur avec 2 processeurs et 3 Go de m\u00e9moire chacune, et maintiens-les en \u00e9tat de marche ! \u00bb. Kubernetes s'occupe de tout le reste. Il trouvera les ressources disponibles, lancera les conteneurs et les red\u00e9marrera si n\u00e9cessaire, appliquera des mises \u00e0 jour lors des changements de version, etc. En gros, Kubernetes permet d'abstraire le mat\u00e9riel et rend la diversit\u00e9 des syst\u00e8mes utilisable pour le d\u00e9ploiement et le fonctionnement des applications.<\/p>\n<p><img decoding=\"async\" alt=\"Limites CPU et throttling agressif dans Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/6509bb1b66a4a0f5e9a479d0bd6ececb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kubernetes du point de vue d'un simple citoyen<\/i><\/p>\n<h2>Qu'est-ce que les requ\u00eates et les limites dans Kubernetes<\/h2>\n<p>\nD'accord, nous avons compris les conteneurs et Kubernetes. Nous savons \u00e9galement que plusieurs conteneurs peuvent se trouver sur une seule machine.<\/p>\n<p>On peut faire une analogie avec un appartement communautaire. On prend un grand espace (machines\/n\u0153uds) et on le loue \u00e0 plusieurs locataires (conteneurs). Kubernetes joue le r\u00f4le d'agent immobilier. La question se pose : comment emp\u00eacher les locataires de se disputer ? Que se passe-t-il si l'un d'eux, disons, d\u00e9cide d'occuper la salle de bains pendant une demi-journ\u00e9e ?<\/p>\n<p>C'est ici que les requ\u00eates et les limites entrent en jeu. CPU <b>Request<\/b> Le CPU est uniquement utilis\u00e9 pour la planification. C'est un peu comme une \u00ab liste de souhaits \u00bb du conteneur, utilis\u00e9e pour s\u00e9lectionner le n\u0153ud le plus adapt\u00e9. En m\u00eame temps, le CPU <b>Limite<\/b> peut \u00eatre compar\u00e9 \u00e0 un contrat de location \u2014 une fois que nous avons trouv\u00e9 un n\u0153ud pour le conteneur, celui-ci <b>ne pourra pas<\/b> d\u00e9passer les limites \u00e9tablies. Et c'est l\u00e0 que le probl\u00e8me se pose...<\/p>\n<h3>Comment sont impl\u00e9ment\u00e9es les requ\u00eates et les limites dans Kubernetes<\/h3>\n<p>\nKubernetes utilise un m\u00e9canisme de throttling (ralentissement) int\u00e9gr\u00e9 au noyau pour mettre en \u0153uvre les limites CPU. Si une application d\u00e9passe la limite, le throttling s'active (c'est-\u00e0-dire qu'elle re\u00e7oit moins de cycles CPU). Les requ\u00eates et limites pour la m\u00e9moire sont organis\u00e9es diff\u00e9remment, ce qui les rend plus faciles \u00e0 d\u00e9tecter. Il suffit de v\u00e9rifier le dernier statut de red\u00e9marrage du pod : n'est-il pas \u00ab OOMKilled \u00bb. Avec le throttling CPU, ce n'est pas si simple, car K8s ne rend disponibles que des m\u00e9triques d'utilisation, et non des m\u00e9triques par cgroups.<\/p>\n<h4>Demande de CPU<\/h4>\n<p>\n<img decoding=\"async\" alt=\"Limites CPU et throttling agressif dans Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/fbc8bf3f775ffd9513374ce94b20535d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Comment est mise en \u0153uvre la demande CPU<\/i><\/p>\n<p>Pour simplifier, prenons un exemple avec une machine \u00e0 CPU 4 c\u0153urs.<\/p>\n<p>K8s utilise un m\u00e9canisme de groupes de contr\u00f4le (cgroups) pour g\u00e9rer la distribution des ressources (m\u00e9moire et processeur). Un mod\u00e8le hi\u00e9rarchique est disponible : un enfant h\u00e9rite des limites du groupe parent. Les d\u00e9tails de la distribution sont stock\u00e9s dans le syst\u00e8me de fichiers virtuel (<code>\/sys\/fs\/cgroup<\/code>). Dans le cas du processeur, cela <code>\/sys\/fs\/cgroup\/cpu,cpuacct\/*<\/code>.<\/p>\n<p>K8s utilise le fichier <code>cpu.share<\/code> pour distribuer les ressources processeur. Dans notre cas, le groupe de contr\u00f4le racine re\u00e7oit 4096 parts de ressources CPU \u2014 100% de la puissance CPU disponible (1 c\u0153ur = 1024 ; c'est une valeur fixe). Le groupe racine distribue les ressources de mani\u00e8re proportionnelle en fonction des parts des enfants, inscrites dans <code>cpu.share<\/code>, et ceux-ci, \u00e0 leur tour, agissent de m\u00eame avec leurs enfants, etc. Dans un n\u0153ud Kubernetes typique, le groupe de contr\u00f4le racine a trois enfants : <code>system.slice<\/code>, <code>user.slice<\/code> et <code>kubepods<\/code>. Les deux premiers sous-groupes sont utilis\u00e9s pour distribuer les ressources entre les charges syst\u00e8me critiques et les programmes utilisateur en dehors de K8s. Le dernier \u2014 <code>kubepods<\/code> \u2014 cr\u00e9\u00e9 par Kubernetes pour distribuer les ressources entre les pod.<\/p>\n<p>Dans le sch\u00e9ma ci-dessus, on peut voir que le premier et le deuxi\u00e8me sous-groupe ont re\u00e7u chacun <b>1024<\/b> parts, tandis que le sous-groupe kubepod a \u00e9t\u00e9 allou\u00e9 <b>4096<\/b> parts. Comment cela est-il possible ? Apr\u00e8s tout, le groupe racine a acc\u00e8s \u00e0 un total de <b>4096<\/b> parts, et la somme des parts de ses enfants d\u00e9passe consid\u00e9rablement ce chiffre (<b>6144<\/b>) ? La raison en est que la valeur a un sens logique, et le planificateur Linux (CFS) l'utilise pour la distribution proportionnelle des ressources CPU. Dans notre cas, les deux premiers groupes re\u00e7oivent chacun <b>680<\/b> parts r\u00e9els (16,6% de 4096), tandis que kubepod re\u00e7oit les parts restantes. <b>2736<\/b> En cas d'inactivit\u00e9, les deux premiers groupes n'utiliseront pas les ressources allou\u00e9es.<\/p>\n<p>Heureusement, le planificateur dispose d'un m\u00e9canisme permettant d'\u00e9viter la perte de ressources CPU inutilis\u00e9es. Il transf\u00e8re les capacit\u00e9s \u00ab inactives \u00bb dans un pool global, \u00e0 partir duquel elles sont r\u00e9parties aux groupes n\u00e9cessitant des ressources suppl\u00e9mentaires du processeur (le transfert se fait par lots pour \u00e9viter des pertes dues \u00e0 l'arrondi). Une m\u00e9thode similaire est appliqu\u00e9e \u00e0 tous les descendants des descendants.<\/p>\n<p>Ce m\u00e9canisme assure une r\u00e9partition \u00e9quitable des capacit\u00e9s du processeur et veille \u00e0 ce qu'aucun processus ne \u00ab vole \u00bb de ressources aux autres.<\/p>\n<h4>Limite CPU<\/h4>\n<p>\nBien que les configurations de limites et de demandes dans K8s se ressemblent, leur mise en \u0153uvre est fondamentalement diff\u00e9rente : c'est <b>la partie la plus trompeuse<\/b> et la moins document\u00e9e.<\/p>\n<p>K8s utilise <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-design-CFS.txt\">un m\u00e9canisme de quotas CFS<\/a><\/noindex> pour mettre en \u0153uvre les limites. Leurs param\u00e8tres sont d\u00e9finis dans les fichiers <code>cfs_period_us<\/code> et <code>cfs_quota_us<\/code> dans le r\u00e9pertoire cgroup (le fichier se trouve \u00e9galement l\u00e0) <code>cpu.share<\/code>).<\/p>\n<p>Contrairement \u00e0 <code>cpu.share<\/code>, la quota est bas\u00e9e sur <b>une p\u00e9riode de temps<\/b>, et non sur la puissance du processeur disponible. <code>cfs_period_us<\/code> d\u00e9finit la dur\u00e9e de la p\u00e9riode (\u00e9poque) \u2014 c\u2019est toujours 100000 \u03bcs (100 ms). Dans K8s, il est possible de changer cette valeur, mais cette option est encore disponible uniquement en version alpha. Le planificateur utilise l'\u00e9poque pour red\u00e9marrer les quotas utilis\u00e9s. Le deuxi\u00e8me fichier, <code>cfs_quota_us<\/code>, d\u00e9finit le temps disponible (quota) \u00e0 chaque \u00e9poque. Notez qu'il est \u00e9galement indiqu\u00e9 en microsecondes. La quota peut d\u00e9passer la dur\u00e9e de l'\u00e9poque ; en d'autres termes, elle peut \u00eatre sup\u00e9rieure \u00e0 100 ms.<\/p>\n<p>Examinons deux sc\u00e9narios sur des machines \u00e0 16 c\u0153urs (le type d'ordinateur le plus courant chez nous chez Omio) :<\/p>\n<p><img decoding=\"async\" alt=\"Limites CPU et throttling agressif dans Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/61c6105320af3a92a91cec1007da0d45.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sc\u00e9nario 1 : 2 flux et une limite de 200 ms. Sans throttling<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Limites CPU et throttling agressif dans Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/c33993341d5395bb73dda1f4c8482a11.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sc\u00e9nario 2 : 10 flux et une limite de 200 ms. Le throttling commence apr\u00e8s 20 ms, l'acc\u00e8s aux ressources du processeur est r\u00e9tabli encore apr\u00e8s 80 ms.<\/i><\/p>\n<p>Supposons que vous ayez fix\u00e9 une limite CPU \u00e0 <b>2<\/b> c\u0153urs ; Kubernetes convertira cette valeur en 200 ms. Cela signifie que le conteneur peut utiliser au maximum 200 ms de temps processeur sans throttling.<\/p>\n<p>Et c'est l\u00e0 que \u00e7a devient int\u00e9ressant. Comme mentionn\u00e9 ci-dessus, le quota disponible est de 200 ms. Si vous avez dix <b>flux en parall\u00e8le sur une machine \u00e0 12 c\u0153urs (voir l'illustration du sc\u00e9nario 2), tant que tous les autres pods sont inactifs, le quota sera \u00e9puis\u00e9 en seulement 20 ms (puisque 10 * 20 ms = 200 ms), et tous les flux de ce pod seront \u00ab throttl\u00e9s \u00bb<\/b> des flux sur une machine \u00e0 12 c\u0153urs (voir l'illustration du sc\u00e9nario 2), pendant que tous les autres pod restent inactifs, le quota sera \u00e9puis\u00e9 en seulement 20 ms (puisque 10 * 20 ms = 200 ms), et tous les flux de ce pod seront \u00ab bloqu\u00e9s \u00bb <i>(limiter)<\/i> sur les 80 ms suivants. La situation est aggrav\u00e9e par le d\u00e9j\u00e0 mentionn\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">bug du planificateur<\/a><\/noindex>, qui provoque un throttling excessif et rend le conteneur incapable de consommer m\u00eame sa propre quota.<\/p>\n<h2>Comment \u00e9valuer le throttling dans les pod ?<\/h2>\n<p>\nIl suffit d'entrer dans le pod et d'ex\u00e9cuter <code>cat \/sys\/fs\/cgroup\/cpu\/cpu.stat<\/code>.<\/p>\n<ul>\n<li> <code>nr_periods<\/code> \u2014 le nombre total de p\u00e9riodes du planificateur ;<\/li>\n<li> <code>nr_throttled<\/code> \u2014 le nombre de p\u00e9riodes throttl\u00e9es parmi <code>nr_periods<\/code>;<\/li>\n<li> <code>throttled_time<\/code> \u2014 le temps total throttl\u00e9 en nanosecondes.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Limites CPU et throttling agressif dans Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/a1818614914a8c31f7f7f1331cc02e8b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Que se passe-t-il r\u00e9ellement ?<\/h3>\n<p>\nEn fin de compte, nous avons un haut niveau de throttling dans toutes les applications. Parfois, il est <b>une fois et demie<\/b> plus fort que pr\u00e9vu !<\/p>\n<p>Cela entra\u00eene diverses erreurs \u2014 des \u00e9checs de v\u00e9rification de disponibilit\u00e9 (readiness), des blocages de conteneurs, des interruptions de connexions r\u00e9seau, des d\u00e9lais d'attente dans les appels de services. Au final, cela se traduit par une augmentation de la latence et du nombre d'erreurs.<\/p>\n<h2>Solutions et cons\u00e9quences<\/h2>\n<p>\nC'est assez simple. Nous avons abandonn\u00e9 les limites de CPU et avons mis \u00e0 jour le noyau du syst\u00e8me d'exploitation dans les clusters vers la derni\u00e8re version o\u00f9 le bug a \u00e9t\u00e9 corrig\u00e9. Le nombre d'erreurs (HTTP 5xx) dans nos services a imm\u00e9diatement consid\u00e9rablement diminu\u00e9 :<\/p>\n<h3>Erreurs HTTP 5xx<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Limites CPU et throttling agressif dans Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/86ab1694b952b5451a4ae075cbda2788.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Erreurs HTTP 5xx d'un service critique<\/i><\/p>\n<h3>Temps de r\u00e9ponse p95<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Limites CPU et throttling agressif dans Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/63922c8eb468366a7d05154a3adf40e6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Latence des requ\u00eates d'un service critique, 95e percentile<\/i><\/p>\n<h3>Co\u00fbts d'exploitation<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Limites CPU et throttling agressif dans Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/8405c26fcbd82853e296fa7e3bcba131.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Nombre d'heures d'instance d\u00e9pens\u00e9es<\/i><\/p>\n<h2>O\u00f9 est le pi\u00e8ge ?<\/h2>\n<p>\nComme mentionn\u00e9 au d\u00e9but de l'article :<\/p>\n<blockquote><p>On peut faire une analogie avec un appartement en colocation\u2026 Kubernetes joue le r\u00f4le de l'agent immobilier. Mais comment emp\u00eacher les colocataires de se disputer ? Que se passe-t-il si l'un d'eux d\u00e9cide, disons, d'occuper la salle de bain pendant une demi-journ\u00e9e ?<\/p><\/blockquote>\n<p>\nVoil\u00e0 le pi\u00e8ge. Un conteneur malveillant peut consommer toutes les ressources CPU disponibles sur la machine. Si vous avez une architecture applicative bien con\u00e7ue (par exemple, avec des JVM, Go, Node VM correctement configur\u00e9s), alors ce n'est pas un probl\u00e8me : on peut travailler dans ces conditions pendant une longue p\u00e9riode. Mais si les applications sont mal optimis\u00e9es ou pas du tout optimis\u00e9es (<code>FROM java:latest<\/code>), la situation peut \u00e9chapper \u00e0 tout contr\u00f4le. Chez Omio, nous avons des Dockerfiles de base automatis\u00e9s avec des configurations raisonnables par d\u00e9faut pour les principaux langages, donc ce probl\u00e8me n'existait pas.<\/p>\n<p>Nous recommandons de surveiller les m\u00e9triques <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/usemethod.html\">Golden Signals<\/a><\/noindex> (utilisation, saturation et erreurs), d\u00e9lais API et fr\u00e9quence des erreurs. Assurez-vous que les r\u00e9sultats correspondent \u00e0 vos attentes.<\/p>\n<h2>Liens<\/h2>\n<p>\nVoici notre histoire. Les documents suivants ont grandement aid\u00e9 \u00e0 comprendre ce qui se passe :<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-design-CFS.txt\">kernel.org \u2192 Planificateur CFS<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-bwc.txt\">kernel.org \u2192 Contr\u00f4le de bande passante CFS<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/engineering.squarespace.com\/blog\/2017\/understanding-linux-container-scheduling\">Comprendre la planification des conteneurs Linux<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.linuxjournal.com\/content\/everything-you-need-know-about-linux-containers-part-i-linux-control-groups-and-process\">Tout ce que vous devez savoir sur les conteneurs Linux, Partie I : Groupes de contr\u00f4le Linux et isolation des processus<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/k8s.af\/\">Histoires d'\u00e9chec de Kubernetes<\/a><\/noindex> \u2014 recherchez \u00ab cpu throttling \u00bb.<\/li>\n<\/ul>\n<p>\nRapports d'erreurs Kubernetes :<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/51135#issuecomment-373454012\">#51135: Avoid setting CPU limits for Guaranteed pods<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/67577\">#67577: CFS quotas can lead to unnecessary throttling<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gist.github.com\/bobrik\/2030ff040fad360327a5fab7a09c4ff1\">CFS trop agressif<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nAvez-vous rencontr\u00e9 des probl\u00e8mes similaires dans votre pratique ou avez-vous de l'exp\u00e9rience li\u00e9e au throttling dans des environnements de production conteneuris\u00e9s ? Partagez votre histoire dans les commentaires !<\/p>\n<h2>P.S. de l'auteur<\/h2>\n<p>\nLisez aussi dans notre blog :<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/459326\/\">Autoscaling et gestion des ressources dans Kubernetes (aper\u00e7u et vid\u00e9o de la pr\u00e9sentation)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/418269\/\">Comment fonctionne le gestionnaire CPU dans Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/342822\/\">Que se passe-t-il dans Kubernetes lors de l'ex\u00e9cution de kubectl run ? Partie 2<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/489668\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes. \u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 \u0442\u0430\u043a\u0438\u043c\u0438 \u0441\u043b\u0443\u0447\u0430\u044f\u043c\u0438 \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0440\u0430\u0441\u0448\u0438\u0440\u044f\u0442\u044c \u043a\u0440\u0443\u0433\u043e\u0437\u043e\u0440, \u043d\u043e \u0438 \u043f\u0440\u0435\u0434\u043e\u0442\u0432\u0440\u0430\u0449\u0430\u0442\u044c \u043d\u0435\u0442\u0440\u0438\u0432\u0438\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b. \u0414\u043e\u0432\u043e\u0434\u0438\u043b\u043e\u0441\u044c \u043b\u0438 \u0432\u0430\u043c \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0441 \u0442\u0435\u043c, \u0447\u0442\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u00ab\u0437\u0430\u0441\u0442\u0440\u0435\u0432\u0430\u043b\u043e\u00bb \u043d\u0430 \u043c\u0435\u0441\u0442\u0435, \u043f\u0435\u0440\u0435\u0441\u0442\u0430\u0432\u0430\u043b\u043e \u043e\u0442\u0432\u0435\u0447\u0430\u0442\u044c \u043d\u0430 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u043e \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0435 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77694,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77693","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47CPU-\u043b\u0438\u043c\u0438\u0442\u044b \u0438 \u0430\u0433\u0440\u0435\u0441\u0441\u0438\u0432\u043d\u044b\u0439 \u0442\u0440\u043e\u0442\u0442\u043b\u0438\u043d\u0433 \u0432 Kubernetes | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-04-12T23:42:39+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-12T23:42:39+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Limites CPU et throttling agressif dans Kubernetes | ProHoster","description":"Note du traducteur : cette histoire illustrative d'Omio \u2014 un agr\u00e9gateur de voyages europ\u00e9en \u2014 guide les lecteurs de la th\u00e9orie de base aux fascinantes subtilit\u00e9s pratiques de la configuration Kubernetes.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47CPU-\u043b\u0438\u043c\u0438\u0442\u044b \u0438 \u0430\u0433\u0440\u0435\u0441\u0441\u0438\u0432\u043d\u044b\u0439 \u0442\u0440\u043e\u0442\u0442\u043b\u0438\u043d\u0433 \u0432 Kubernetes | ProHoster","og:description":"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u044d\u0442\u0430 \u043f\u043e\u0443\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u0430\u044f \u0438\u0441\u0442\u043e\u0440\u0438\u044f Omio \u2014 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u043e\u0433\u043e \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440\u0430 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u0439 \u2014 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u0442 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043e\u0442 \u0431\u0430\u0437\u043e\u0432\u043e\u0439 \u0442\u0435\u043e\u0440\u0438\u0438 \u0434\u043e \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0445 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u0435\u0439 \u0432 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 Kubernetes.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-12T23:42:39+00:00","article:modified_time":"2020-04-12T23:42:39+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"77693","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:13:23","updated":"2022-09-29 12:06:45","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/77693","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=77693"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/77693\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/77694"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=77693"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=77693"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=77693"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}