{"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\/en\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","title":{"rendered":"CPU limits and aggressive throttling in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Note: translation.<\/b>: This instructive story from Omio, a European travel aggregator, takes readers from basic theory to fascinating practical nuances in Kubernetes configuration. Familiarity with such cases helps not only broaden horizons but also prevent non-trivial issues.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"CPU limits and aggressive throttling in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/1175c9df746e43b5a7d81476164929db.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHave you ever encountered a situation where an application got 'stuck', stopped responding to health checks, and you couldn't understand the reason for such behavior? One possible explanation is related to the CPU resource quota limits. This article will discuss that.<\/p>\n<p><b>TL;DR:<br \/>\nWe strongly recommend avoiding CPU limits in Kubernetes (or disabling CFS quotas in Kubelet) if you are using a Linux kernel version with a bug in CFS quotas. In the kernel <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">we have<\/a><\/noindex> there is a serious and <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/67577\">well-known<\/a><\/noindex> bug that leads to excessive throttling and delays.<\/b>.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>At Omio, <b>the entire infrastructure is managed by Kubernetes.<\/b>. All our stateful and stateless workloads run exclusively on Kubernetes (we use Google Kubernetes Engine). Over the past six months, we have noticed random slowdowns. Applications freeze or stop responding to health checks, lose network connectivity, etc. This behavior has puzzled us for a long time, and we finally decided to tackle the issue head-on.<\/p>\n<p>Summary of the article:<\/p>\n<ul>\n<li> A few words about containers and Kubernetes;<\/li>\n<li> How CPU requests and limits are implemented;<\/li>\n<li> How CPU limits work in multi-core environments;<\/li>\n<li> How to monitor CPU throttling;<\/li>\n<li> Problem-solving and nuances.<\/li>\n<\/ul>\n<p><\/p>\n<h2>A few words about containers and Kubernetes.<\/h2>\n<p>\nKubernetes is essentially the modern standard in the infrastructure world. Its main task is container orchestration.<\/p>\n<h3>Containers<\/h3>\n<p>\nIn the past, we had to create artifacts like Java JARs\/WARs, Python Eggs, or executable files to run on servers later. However, to make them function, additional work had to be done: setting up the runtime environment (Java\/Python), placing the necessary files in the correct locations, ensuring compatibility with a specific operating system version, etc. In other words, we had to pay close attention to configuration management (which often caused disagreements between developers and system administrators).<\/p>\n<p><b>Containers changed everything.<\/b> Now the artifact is a container image. It can be thought of as an extended executable file that contains not only the program but also a complete runtime environment (Java\/Python\/...), along with the necessary files\/packages that are pre-installed and ready to run. Containers can be deployed and run on various servers without any additional actions.<\/p>\n<p>Moreover, containers operate in their own sandboxed environment. They have their own virtual network adapter, their own filesystem with restricted access, their own process hierarchy, CPU and memory limits, etc. All of this is implemented through a special subsystem of the Linux kernel \u2014 namespaces.<\/p>\n<h3>Kubernetes<\/h3>\n<p>\nAs mentioned earlier, Kubernetes is a container orchestrator. It works like this: you provide it with a pool of machines, and then you say, 'Hey, Kubernetes, run ten instances of my container with 2 CPUs and 3 GB of memory each, and keep them running!' Kubernetes will take care of everything else. It will find available resources, launch the containers, and restart them if necessary, roll out updates when versions change, and so on. Essentially, Kubernetes allows you to abstract away from the hardware component and makes diverse systems suitable for deploying and running applications.<\/p>\n<p><img decoding=\"async\" alt=\"CPU limits and aggressive throttling in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/6509bb1b66a4a0f5e9a479d0bd6ececb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kubernetes from the perspective of an average user<\/i><\/p>\n<h2>What are requests and limits in Kubernetes<\/h2>\n<p>\nOkay, we have understood containers and Kubernetes. We also know that several containers can be on one machine.<\/p>\n<p>You can draw an analogy with a shared apartment. A spacious room (machines\/nodes) is taken and rented out to several tenants (containers). Kubernetes acts as the realtor. The question arises: how do we keep tenants from conflicting with each other? What if one of them decides to occupy the bathroom for half a day?<\/p>\n<p>This is where requests and limits come into play. CPU <b>Request<\/b> is needed solely for scheduling. It's somewhat like a 'wish list' for the container, used to match it with the most suitable node. Simultaneously, CPU <b>Limit<\/b> can be compared to a lease agreement \u2014 once we find a node for the container, it <b>cannot<\/b> exceed the established limits. And that\u2019s where the problem arises...<\/p>\n<h3>How requests and limits are implemented in Kubernetes<\/h3>\n<p>\nKubernetes uses a built-in kernel mechanism for throttling to enforce CPU limits. If an application exceeds the limit, throttling kicks in (i.e., it receives fewer CPU cycles). Memory requests and limits are organized differently, making them easier to detect. You just need to check the last restart status of the pod: whether it was 'OOMKilled'. With CPU throttling, it's more complicated, as K8s only provides metrics on usage, not on cgroups.<\/p>\n<h4>CPU Request<\/h4>\n<p>\n<img decoding=\"async\" alt=\"CPU limits and aggressive throttling in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/fbc8bf3f775ffd9513374ce94b20535d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>How CPU request is implemented<\/i><\/p>\n<p>For simplicity, let's consider the process using a machine with a 4-core CPU as an example.<\/p>\n<p>K8s uses the control groups (cgroups) mechanism to manage resource allocation (memory and CPU). It has a hierarchical model: a child inherits the limits of its parent group. Details of the allocation are stored in a virtual file system (<code>\/sys\/fs\/cgroup<\/code>). In the case of CPU, this is <code>\/sys\/fs\/cgroup\/cpu,cpuacct\/*<\/code>.<\/p>\n<p>K8s uses the file <code>cpu.share<\/code> to allocate CPU resources. In our case, the root control group receives 4096 CPU shares \u2014 100% of the available CPU power (1 core = 1024; this is a fixed value). The root group distributes resources proportionally based on the shares of the child groups specified in <code>cpu.share<\/code>, and they, in turn, do the same with their children, and so on. In a typical Kubernetes node, the root control group has three children: <code>system.slice<\/code>, <code>user.slice<\/code> and <code>kubepods<\/code>. The first two subgroups are used to distribute resources among critical system workloads and user programs outside of K8s. The last one \u2014 <code>kubepods<\/code> \u2014 created by Kubernetes for distributing resources among pods.<\/p>\n<p>In the diagram above, it can be seen that the first and second subgroups received shares of <b>1024<\/b> , while the kubepod subgroup has been allocated <b>4096<\/b> shares. How is this possible: after all, the root group has only <b>4096<\/b> shares available, whereas the total shares of its children significantly exceed this number (<b>6144<\/b>)? The matter is that the value has logical meaning, so the Linux scheduler (CFS) uses it for proportional allocation of CPU resources. In our case, the first two groups get real shares of <b>680<\/b> (16.6% of 4096), while kubepod gets the remaining <b>2736<\/b> shares. In case of idle time, the first two groups will not use the allocated resources.<\/p>\n<p>Fortunately, the scheduler has a mechanism that prevents the loss of unused CPU resources. It transfers \"idle\" power to a global pool from which it is distributed to groups that need additional CPU power (the transfer occurs in batches to avoid losses from rounding). A similar method is applied to all descendants.<\/p>\n<p>This mechanism ensures fair distribution of CPU power and prevents any process from \"stealing\" resources from others.<\/p>\n<h4>CPU Limit<\/h4>\n<p>\nAlthough the configurations of limits and requests in K8s look similar, their implementation is fundamentally different: this <b>the most misleading<\/b> and least documented part.<\/p>\n<p>K8s employs <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-design-CFS.txt\">the CFS quota mechanism<\/a><\/noindex> to implement limits. Their settings are defined in the files <code>cfs_period_us<\/code> and <code>cfs_quota_us<\/code> in the cgroup directory (where the file is located as well). <code>cpu.share<\/code>).<\/p>\n<p>Unlike <code>cpu.share<\/code>, the quota is based on <b>time period<\/b>, not on available CPU power. <code>cfs_period_us<\/code> defines the duration of the period (epoch) \u2014 it's always 100000 \u00b5s (100 ms). K8s has the option to change this value, but it is currently available only in alpha version. The scheduler uses the epoch to restart the consumed quotas. The second file, <code>cfs_quota_us<\/code>, defines the available time (quota) in each epoch. Note that it is also specified in microseconds. The quota can exceed the duration of the epoch; in other words, it can be greater than 100 ms.<\/p>\n<p>Let's consider two scenarios on 16-core machines (the most common type of computers we have at Omio):<\/p>\n<p><img decoding=\"async\" alt=\"CPU limits and aggressive throttling in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/61c6105320af3a92a91cec1007da0d45.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Scenario 1: 2 threads and a limit of 200 ms. Without throttling.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"CPU limits and aggressive throttling in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/c33993341d5395bb73dda1f4c8482a11.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Scenario 2: 10 threads and a limit of 200 ms. Throttling begins after 20 ms; access to CPU resources resumes after another 80 ms.<\/i><\/p>\n<p>Suppose you set the CPU limit to <b>2<\/b> cores; Kubernetes will convert this value to 200 ms. This means that the container can use a maximum of 200 ms of CPU time without throttling.<\/p>\n<p>And here comes the interesting part. As stated above, the available quota is 200 ms. If you have, in parallel, <b>ten<\/b> streams on a 12-core machine (see the illustration for scenario 2), while all other pods are idle, the quota will be exhausted in just 20 ms (as 10 * 20 ms = 200 ms), and all streams of this pod will 'hang' <i>(throttle)<\/i> for the next 80 ms. The issue is exacerbated by the previously mentioned <noindex><a rel=\"nofollow\" href=\"https:\/\/bugzilla.kernel.org\/show_bug.cgi?id=198197\">scheduler bug<\/a><\/noindex>, which causes excessive throttling and the container can't even utilize its existing quota.<\/p>\n<h2>How to assess throttling in pods?<\/h2>\n<p>\nSimply enter the pod and execute <code>cat \/sys\/fs\/cgroup\/cpu\/cpu.stat<\/code>.<\/p>\n<ul>\n<li> <code>nr_periods<\/code> \u2014 total number of scheduler periods;<\/li>\n<li> <code>nr_throttled<\/code> \u2014 number of throttled periods included in <code>nr_periods<\/code>;<\/li>\n<li> <code>throttled_time<\/code> \u2014 total throttled time in nanoseconds.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"CPU limits and aggressive throttling in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/a1818614914a8c31f7f7f1331cc02e8b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>What is actually happening?<\/h3>\n<p>\nAs a result, we experience high throttling across all applications. Sometimes it is <b>one and a half times<\/b> stronger than expected!<\/p>\n<p>This leads to various errors \u2014 readiness check failures, container hangs, network connection drops, timeouts in service calls. Ultimately, this manifests as increased latency and a rise in error rates.<\/p>\n<h2>Solution and consequences<\/h2>\n<p>\nIt's quite simple. We removed the CPU limits and focused on upgrading the OS kernel in the clusters to the latest version, where the bug was fixed. The number of errors (HTTP 5xx) in our services immediately dropped significantly:<\/p>\n<h3>HTTP 5xx errors<\/h3>\n<p>\n<img decoding=\"async\" alt=\"CPU limits and aggressive throttling in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/86ab1694b952b5451a4ae075cbda2788.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>HTTP 5xx errors of a critical service<\/i><\/p>\n<h3>Response time p95<\/h3>\n<p>\n<img decoding=\"async\" alt=\"CPU limits and aggressive throttling in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/63922c8eb468366a7d05154a3adf40e6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Latency of requests to a critical service, 95th percentile<\/i><\/p>\n<h3>Operating expenses<\/h3>\n<p>\n<img decoding=\"async\" alt=\"CPU limits and aggressive throttling in Kubernetes\" src=\"\/wp-content\/uploads\/2020\/04\/8405c26fcbd82853e296fa7e3bcba131.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Number of consumed instance hours<\/i><\/p>\n<h2>What's the catch?<\/h2>\n<p>\nAs mentioned at the beginning of the article:<\/p>\n<blockquote><p>One can draw an analogy with a shared apartment... Kubernetes acts as the realtor. But how do you keep tenants from conflicting with each other? What if one decides to hog the bathroom for half a day?<\/p><\/blockquote>\n<p>\nThat's the catch. One negligent container can consume all available CPU resources on the machine. If you have a solid application stack (for example, properly configured JVMs, Go, Node VMs), then this is not an issue: you can operate under such conditions for a long time. But if the applications are poorly optimized or not optimized at all (<code>FROM java:latest<\/code>), the situation can spiral out of control. At Omio, we have automated base Dockerfiles with adequate default settings for the main programming stacks, so this problem did not exist.<\/p>\n<p>We recommend monitoring metrics. <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/usemethod.html\">Golden Signals<\/a><\/noindex> (usage, saturation, and errors), API delays, and error occurrences. Ensure that the results meet expectations.<\/p>\n<h2>Links<\/h2>\n<p>\nThis is our story. The following materials helped greatly in understanding what is happening:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-design-CFS.txt\">kernel.org \u2192 CFS Scheduler<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.kernel.org\/doc\/Documentation\/scheduler\/sched-bwc.txt\">kernel.org \u2192 CFS Bandwidth Control<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/engineering.squarespace.com\/blog\/2017\/understanding-linux-container-scheduling\">Understanding Linux Container Scheduling<\/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\">Everything You Need to Know about Linux Containers, Part I: Linux Control Groups and Process Isolation<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/k8s.af\/\">Kubernetes Failure Stories<\/a><\/noindex> \u2014 look for 'cpu throttling'.<\/li>\n<\/ul>\n<p>\nKubernetes Error Reports:<\/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\">Overly aggressive CFS<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nHave you encountered similar issues in your practice or have experience related to throttling in containerized production environments? Share your story in the comments!<\/p>\n<h2>P.S. from the translator<\/h2>\n<p>\nAlso read in our blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/459326\/\">Dailymotion\u2019s Kubernetes Adventure: Building Infrastructure in Clouds + On-Premises<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/418269\/\">How CPU Manager Works in Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/342822\/\">What Happens in Kubernetes When You Run kubectl run? Part 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\/en\/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=\"en_US\" \/>\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\/en\/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\udd47CPU limits and aggressive throttling in Kubernetes | ProHoster","description":"Note: this instructive story from Omio \u2014 a European travel aggregator \u2014 takes readers from basic theory to fascinating practical nuances in configuring Kubernetes.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/cpu-limity-i-agressivnyj-trottling-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","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\/en\/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\/en\/wp-json\/wp\/v2\/posts\/77693","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=77693"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/77693\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/77694"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=77693"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=77693"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=77693"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}