理解k8s资源限制(2):cpu time

在关于kubernetes资源限制的这个由两部分组成的系列文章的第一篇文章中，我讨论了如何使用ResourceRequirements对象来设置容器中容器的内存限制，以及容器运行时和linux控制组如何实现这些限制。我还谈到了请求之间的区别，用于在调度时通知调度程序pod的需求，以及限制，用于在主机系统处于内存压力时帮助内核强制执行使用限制。在这篇文章中，我想继续详细查看cpu时间请求和限制。阅读完第一篇文章并不是从这篇文章中获取价值的先决条件，但我建议你在某些时候阅读它们，以便全面了解工程师和集群管理员可以使用的控件。

CPU限制

正如我在第一篇文章中提到的，cpu限制比内存限制更复杂，原因将在下面说明。好消息是cpu限制是由我们刚才看到的相同cgroups机制控制的，所以所有相同的内省思想和工具都适用，我们可以只关注差异。让我们首先将cpu限制添加回上次查看的示例资源对象：

单位后缀m代表“千分之一核心”，因此该资源对象指定容器进程需要50/1000的核心（5％）并且允许最多使用100/1000核心（10％）。同样，2000m将是两个完整核心，也可以指定为2或2.0。让我们创建一个只有cpu请求的pod，看看它是如何在docker和cgroup级别配置的：

我们可以看到kubernetes配置了50m cpu请求：

我们还可以看到docker配置了具有相同限制的容器：

为什么51，而不是50？cpu控制组和docker都将核划分为1024个共享，而kubernetes将其划分为1000. docker如何将此请求应用于容器进程？与设置内存限制导致docker配置进程的内存cgroup的方式相同，设置cpu限制会导致它配置cpu，cpuacct cgroup：

Docker的HostConfig.CpuShares容器属性映射到cgroup的cpu.shares属性，所以让我们看一下：

你可能会惊讶地发现设置cpu请求会将值传播到cgroup，因为在上一篇文章中我们看到设置内存请求没有。底线是关于内存软限制的内核行为对kubernetes不是很有用，因为设置cpu.shares很有用。我将在下面详细讨论为什么。那么当我们设置cpu限制时会发生什么？我们来看看：

现在我们还可以在kubernetes pod资源对象中看到限制：

并在docker容器配置中：

如上所述，cpu请求存储在HostConfig.CpuShares属性中。但是，cpu限制不太明显。它由两个值表示：HostConfig.CpuPeriod和HostConfig.CpuQuota。这些docker容器配置属性映射到进程的cpu、cpuacct cgroup的两个附加属性：cpu.cfs_period_us和cpu.cfs_quota_us。我们来看看那些：

正如预期的那样，这些值设置为与docker容器配置中指定的值相同。但是这两个属性的值是如何从我们的pod中的100m cpu限制设置得出的，它们如何实现该限制？答案在于cpu请求和cpu限制是使用两个独立的控制系统实现的。请求使用cpu共享系统，两者中较早的一个。Cpu共享将每个核划分为1024个切片，并保证每个进程将获得这些切片的比例份额。如果有1024个切片，并且两个进程中的每一个都将cpu.shares设置为512，那么它们将分别获得大约一半的可用时间。但是，cpu共享系统无法强制执行上限。如果一个进程不使用其共享，则另一个进程可以自由使用。

大约在2010年，谷歌和其他人注意到这可能会导致问题。作为回应，增加了第二个功能更强大的系统：cpu带宽控制。带宽控制系统定义一个周期，通常为1/10秒，或100000微秒，以及一个配额，表示允许进程在cpu上运行的那个周期内的最大切片数。在这个例子中，我们要求我们的pod上的cpu限制为100m。这是100/1000的核，或100000微秒的CPU时间中的10000。因此，我们的限制请求转换为在进程的cpu，cpuacct cgroup上设置cpu.cfs_period_us = 100000和cpu.cfs_quota_us = 10000。顺便说一下，这些名称中的cfs代表Completely Fair Scheduler，它是默认的linux cpu调度程序。还有一个实时调度程序，它有自己相应的配额值。

所以我们已经看到在kubernetes中设置cpu请求最终会设置cpu.shares cgroup属性，并且通过设置cpu.cfs_period_us和cpu.cfs_quota_us来设置cpu限制可以使用不同的系统。与内存限制一样，请求主要对调度程序有用，调度程序使用它来查找至少具有多个可用cpu共享的节点。与内存请求不同，设置cpu请求还会在cgroup上设置一个属性，以帮助内核实际将该数量的共享分配给进程。限制也与内存区别对待。超出内存限制使你的容器进程成为oom-killing的候选者，而你的进程基本上不能超过设置的cpu配额，并且永远不会因为尝试使用比分配的更多的CPU时间而被驱逐。系统会在调度程序中强制执行配额，以便进程在限制时受到限制。

如果你未在容器上设置这些属性，或将它们设置为不准确的值，会发生什么？与内存一样，如果设置限制但不设置请求，kubernetes会将请求默认为限制。如果你非常了解工作负载所需的CPU时间，那么这可能会很好。设置一个没有限制的请求怎么样？在这种情况下，kubernetes能够准确地安排你的pod，并且内核将确保它至少获得所请求的共享数量，但是你的进程将不会被阻止使用超过所请求的cpu数量，这将被盗来自其他进程的cpu共享（如果可用）。既不设置请求也不设置限制是最糟糕的情况：调度程序不知道容器需要什么，并且进程对cpu共享的使用是无限的，这可能会对节点产生负面影响。这是我想要谈论的最后一件事的好消息：确保命名空间中的默认限制。

默认限制

鉴于我们刚刚讨论过关于忽略资源限制对pod容器的负面影响的所有内容，你可能认为能够设置默认值会很好，因此允许进入群集的每个pod都至少设置了一些限制。Kubernetes允许我们使用LimitRange v1 api对象在每个命名空间的基础上执行此操作。要建立默认限制，请在要将其应用于的命名空间中创建LimitRange对象。这是一个例子：

这里的命名可能有点令人困惑，所以让我们简单地把它拆掉。default key低于限制表示每个资源的默认限制。在这种情况下，任何允许没有内存限制的命名空间的pod都将被分配100Mi的限制。任何没有cpu限制的pod都将被分配100m的限制。defaultRequest键用于资源请求。如果在没有内存请求的情况下创建pod，则会为其分配默认请求50Mi，如果没有cpu请求，则默认值为50m。max和min键有点不同：基本上如果设置了pod，如果设置了违反这些边界的请求或限制，则不会允许pod进入命名空间。我没有找到这些的用途，但也许你有，如果是这样发表评论，让我们知道你对他们做了什么。

LimitRange中规定的默认值由LimitRanger插件应用于pod，这是一个kubernetes许可控制器。入场控制器是插件，在api接受对象之后但在创建pod之前有机会修改podSpecs。对于LimitRanger，它会查看每个pod，如果它没有指定命名空间中存在默认设置的给定请求或限制，则它将应用该默认值。通过检查pod元数据中的注释，你可以看到LimitRanger已在你的pod上设置了默认值。这是LimitRanger应用100m的默认cpu请求的示例：

这包含了对kubernetes资源限制的看法。我希望这个信息对你有所帮助。如果你有兴趣阅读有关使用资源限制和默认值，linux cgroups或内存管理的更多信息，我已经提供了一些指向下面这些主题的更详细信息的链接。