一、理解 Limits
kubernetes 调度器在执行调度的时候用的是节点上物理核的概念，但容器运行的时候，应该将 limits 配置的 CPU 转换为 CPU 时间的概念。
二、Limits 其实是时间
Resources:limits:cpu: 1000m
如果该应用需要完整的 1 秒 CPU 运行时间来服务一个 API 调用，中间不能被停止或抑制，即在容器被抑制前需要允许该应用运行 1000 毫秒 (ms) 或 1 CPU 秒。
三、Linux Accounting system
resources:limits:cpu: 500m开始时，使用 1000 milliCPU 作为一个完整的 share。当配置 500 milliCPU 时，使用了半个周期，或 500m/1000m = 50%。如果设置了 200m/1000m，则表示使用的 CPU 比率为 20%，以此类推。我们需要这些转换数字来理解一些 prometheus 的指标输出。 上面提到的记账系统是按容器计算的，下面看下指标 container_spec_cpu_period，与我们假设的实验不同，实际与容器相关的周期为 100ms。
Linux 有一个配置，称为 cpu.cfs_period_us，设置了账簿翻到下一页前的时间，该值表示下一个周期创建前的微秒时间。这些 Linux 指标会通过 cAdvisor 转换为 prometheus 指标。 撇开一些特殊场景不谈，在账簿翻页之前经过的时间并不像被限制的 CPU 时间切片那样重要。 下面看下使用 cpu.cfs_quota_us 指标设置的容器配额，这里配置为 50 毫秒，即 100ms 的一半：
四、多线程容器
容器通常具有多个处理线程，根据语言的不同，可能有数百个线程。
当这些线程 / 进程运行时，它们会调度不同的 (可用)vCPU，Linux 的记账系统需要全局跟踪谁在使用这些 vCPU，以及需要将哪些内容添加到账簿中。 先不谈周期的概念，下面我们使用 container_cpu_usage_seconds_total 来跟踪一个应用的线程在 1 秒内使用的 vCPU 数。假设线程在 4 个 vCPU 上均运行了整整一秒钟，则说明其使用了 4 个 vCPU 秒。
如果总的 vCPU 时间小于 1 个 vCPU 秒会发生什么呢？此时会在该时间帧内抑制节点上该应用的其他线程的运行。 五、Global accounting
上面讨论了如何将一个 vCPU 秒切分为多个片，然后就可以全局地在多个 vCPU 上申请时间片。让我们回到上述例子 (4 个线程运行在 4 个 vCPU 上)，进一步理解它们如何运行的。 当一个 CPU 需要运行其队列中的一个线程或进程时，它首先会确认容器的全局配额中是否有 5ms 的时间片，如果全局配额中有足够的时间片，则会启动线程，否则，该线程会被抑制并等待下一个周期。
六、真实场景
下面假设一个实验，假如有 4 个线程，每个线程需要 100ms 的 CPU 时间来完成一个任务，将所有所需的 vCPU 时间加起来，总计需要 400ms 或 4000m，因此可以以此为进程配置 limit 来避免被抑制。
不幸的是，实际的负载并不是这样的。这些函数的线程可能运行重的或轻的 API 调用。应用所需的 CPU 时间是变化的，因此不能将其认为是一个固定的值。再进一步，4 个线程可能并不会同时各需要一个 vCPU，有可能某些线程需要等待数据库锁或其他条件就绪。 正因为如此，负载往往会突然爆发，因此延迟并不总是能够成为设置 limits 的候选因素。最新的一个特性—cpu.cfs_burst_us[1]允许将部分未使用的配额由一个周期转至下一个周期。 有趣的是，这并不是让大多数客户陷入麻烦的地方。假设我们只是猜测了应用程序和测试需求，并且 1 个 CPU 秒听起来差不多是正确的。该容器的应用程序线程将分布到 4 个 vCPU 上。这样做的结果是将每个线程的全局配额分为 100ms/4 或 25ms 的运行时。
而实际的总配额为 (100ms 的配额) * (4 个线程) 或 400ms 的配额。在 100 毫秒的现实时间里，所有线程有 300 毫秒处于空闲状态。因此，这些线程总共被抑制了 300 毫秒。 Latency
下面从应用的角度看下这些影响。单线程应用需要 100ms 来完成一个任务，当设置的配额为 100ms 或 1000 m/1000 m = 100%，此时设置了一个合理的 limits，且没有抑制。
在第二个例子中，我们猜测错误，并将 limits 设置为 400m 或 400 m/1000 m = 40%，此时的配额为 100ms 周期中的 40ms。下图展示该配置了对该应用的延迟：
此时处理相同请求的时间翻倍 (220ms)。该应用在三个统计周期中的两个周期内受到了抑制。在这两个周期中，应用被抑制了 60ms。更重要的是，如果没有其他需要处理的线程，vCPU 将会被浪费，这不仅仅会降低应用的处理速度，也会降低 CPU 的利用率。 与 limits 相关的最常见的指标 container_cpu_cfs_throttled_periods_total 展示了被抑制的周期，container_cpu_cfs_periods_total 则给出了总的可用周期。上例中，三分之二 (66%) 的周期被抑制了。 那么，如何知道 limits 应该增加多少呢？ 七、Throttled seconds
幸运的是，cAdvisor 提供了一个指标 container_cpu_cfs_throttled_seconds_total，它会累加所有被抑制的 5ms 时间片，并让我们知道该进程超出配额的数量。指标的单位是秒，因此可以通过将该值除以 10 来获得 100ms(即我们设置的周期)。 通过如下表达式可以找出 CPU 使用超过 100ms 的前三个 pods。 topk(3, max by (pod, container)(rate(container_cpu_usage_seconds_total{image!="", instance="$instance"}[$__rate_interval]))) / 10下面做一个实验：使用 sysbench 启动一个现实时间 100ms 中需要 400ms CPU 时间的的 4 线程应用。 command:- sysbench- cpu- --threads=4- --time=0- run可以观测到使用了 400ms 的 vCPU：
下面对该容器添加 limits 限制：
resources:limits:cpu: 2000mmemory: 128Mi可以看到总的 CPU 使用在 100ms 的现实时间中减少了一半，这正是我们所期望的。
PromQL 给出了每秒的抑制情况，每秒有 10 个周期 (每个周期默认 100ms)。为了得到每个周期的抑制情况，需要除以 10。如果需要知道应该增加多少 limits，则可以乘以 10(如 200ms * 10 = 2000m)。
topk(3, max by (pod, container)(rate(container_cpu_cfs_throttled_seconds_total{image!="", instance="$instance"}[$__rate_interval]))) / 10八、告警设置
可以基于 CPU 抑制时间或抑制比率来编写告警表达式，其表达的也是 CPU 的饱和度信息：
# CPU抑制时间超过1s时产生告警rate(container_cpu_cfs_throttled_seconds_total{namespace=~"wordpress-.*"}[1m]) > 1# CPU抑制周期占可用周期的一半时产生告警sum(increase(container_cpu_cfs_throttled_periods_total{container!=""}[5m])) by (container, pod, namespace)/sum(increase(container_cpu_cfs_periods_total{}[5m])) by (container, pod, namespace) *100 > 50九、总结
本文介绍了 limits 是如何工作的，以及可以使用哪些指标来设置正确的值，使用哪些指标来进行抑制类型的问题定位。
本文的实验提出了一个观点，即过多地配置 limits 的 vCPU 数也可能会导致 vCPU 处于 idle 状态而造成应用响应延迟，但在现实的服务中，一般会包含语言自身 runtime 的线程 (如 go 和 java) 以及开发者自己启动的线程，一般设置较多的 vCPU 不会对应用的响应造成影响，但会造成资源浪费。
来源：https://www.cnblogs.com/charlieroro/p/17074808.html 号外号外！
第二十一届 GOPS 全球运维大会
将于2023年10月20日-21日在上海召开啦！
报名通道 ▼
早鸟票立省1260元！
近期好文：
K8s Kubectl 技巧集锦，这样轻松管理集群有多爽？
“高效运维”公众号诚邀广大技术人员投稿
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。
点个“在看”，一年不宕机
