在上K8s之前必须知道的Pod容器资源知识

来源：http://bjbsair.com/tech-info/79843.html

导读

当我们开始使用Kubernetes时，通常会忘记在开始时设置容器资源。我们只想确保我们的Docker映像正常工作，并且可以将其部署到Kubernetes集群。如果那里只有一个应用程序，而我们只是在做实验，那很好。但是迟早，我们希望将此应用程序与已经存在的其他应用程序一起部署到生产集群中。为了使我们的应用程序成为Kubernetes公民，我们必须分配适当数量的容器资源。我们必须确保它们足以启动，运行应用程序，并且不会对其他已经运行的应用程序造成任何问题。

定义资源非常重要，并且具有许多优点。我们可以最大程度地降低云提供商的成本，但最重要的是，它可以通过使Kubernetes处于健康状态来帮助其管理集群。

在此文章中，我们将介绍Pod的容器资源（CPU和MEM），请求和限制。我们将了解这些设置带来的优势，如果不进行设置，将会发生什么。在”问答”部分中，我们将为最常见的问题提供答案。

请求和有限的资源详细信息

Kubernetes — Docker resources contract

解释请求的资源和有限的资源是如何工作的，最好的选择是向您展示Kubernetes和Docker之间的合同。从上面的图片中，您可以注意到哪些Kubernetes字段对应于哪个docker run标志。

内存：请求和限制

containers:… resources: requests: memory: “0.5Gi” limits: memory: “1Gi”

如前所述，内存以字节为单位。基于Kubernetes文档，我们可以通过将其设置为数字（普通整数）来指定内存。2678，这意味着2678个字节。我们也可以使用后缀，例如G，Gi，但请记住，后缀是不同的。第一个是小数，第二个是二进制前缀。因此，作为k8s文档中提到的示例，128974848、129e6、129M，123Mi几乎是等效的。

Kubernetes的limit.memory对应于Docker的–memory标志。如果是request.memory，则不会提供指向Docker的箭头，因为Docker不使用此字段。您可能会问我们是否完全需要它-是的，我们需要它。正如我在上一节中提到的，该字段对Kubernetes很重要，因为kube-scheduler基于该信息来决定应在哪个Node上调度Pod。

如果我设置的内存请求不足怎么办？

如果容器到达其内存请求边界，则此Pod进入Pod集合，以防Node内存不足而将其驱逐。

如果我没有设置足够的内存限制怎么办？

如果容器超出其内存限制，则可以使用OOM-Killed原因终止该容器，并且可以（基于RestartPolicy，默认值为Always）将其重新启动。

如果我不提供任何存储请求怎么办？

Kubernetes将采用限制值并将其设置为默认请求值。

如果我不提供任何内存限制怎么办？

由于容器没有任何限制，因此可以使用所需的内存量。如果它开始使用所有Node的可用内存，则可能会被OOM杀死。然后，如果可能（基于RestartPolicy），可以将其重新启动。

如果我既不提供内存限制也不提供请求怎么办？

这是最坏的情况。调度程序不知道您的容器需要多少资源，这可能会导致Node出现严重问题。在这种情况下，最好在名称空间中使用默认限制（由LimitRange设置）。但是，如果您没有默认限制，那么Pod便会取消上限，并可以使用尽可能多的内存。

请记住，如果您定义的内存请求大于Node可以提供的内存请求，则永远不会计划您的Pod。

请勿误解requests.memory为最小范围。将其视为保证此内存量（带有一些缓冲区）足以使您的容器始终保持正常运行的保证。

通常，最佳做法是为requests.memory和limits.memory设置相同的值。因此，您可以防止Kubernetes在节点上安排Pod的情况，该Pod有足够的内存来启动它，但运行起来却没有那么多。请记住，当Kubernetes调度Pod时，仅考虑request.memory。那时还不遵守limits.memory。

CPU：请求和限制

containers:… resources: requests: cpu: 1 limits: cpu: “1200m”

CPU有点神秘。回到Kubernetes和Docker之间的合同的图像，您会注意到，requests.cpu对应于–cpu-shares，而limits.cpu对应于来自Docker标志的cpus。

Kubernetes请求的CPU乘以1024。1024是CPU周期的比例。因此，如果要请求1个完整内核，则必须像上面的代码片段一样添加cpu：1。但是，请求全内核（比例= 1024）并不意味着您的容器将获得全部。如果您的主机只有一个内核，并且您正在运行多个容器，那么所有容器都必须在它们之间共享可用的CPU。怎么样？让我们看一下下面的图片：

Requesting CPU — 1 core system

假设您有1个CPU内核可用于您的容器。母亲（Kubernetes）烤了一个蛋糕（一个CPU），想在她的孩子们（容器）之间摊开。她的三个孩子想要一个完整的蛋糕（比例= 1024），一个只想要一半的蛋糕（512）。母亲希望公平起见，并”平均”散布这块蛋糕。她所做的是简单的数学运算：

# How many cakes the children really want?  # 3 kids want the whole cake, and one only a halfcakes  NumberKidsWant=(3*1)+(1*0.5)=3.5
# The above expression comes from:  3(kids/containers)*1(whole cake/full core)+1(kid/container)*0.5(half of the cake/half core)
# How many available cakes we have?
availableCakesNumber =1
# How much cake (max number) can kids REALLY request?
newMaxRequest =1/3.5=~28%

按照上述计算，三个孩子将获得可用核心的28％，而不是他们要求的一个完整核心。另一方面，青少年将获得28％的一半，即14％，而不是一半的核心。

但是，如果我们有多个可用的CPU，则外观会有所不同：

Requesting CPU — multi-core (4) system

从上面的图像中，您可以注意到三个孩子想要整个蛋糕，而一个孩子想要一半。由于妈妈烤了四个蛋糕，她的每个孩子都会得到他们想要的东西。在多核系统上，CPU份额分布在所有可用的CPU核上。这意味着，如果将一个容器限制为少于一个完整的CPU内核，则仍可以使用其中的100％。

请记住，简化了上面的计算，以了解如何在所有容器之间共享CPU。当然，除了容器本身之外，还有其他进程也使用CPU资源。

当一个容器中的进程处于空闲状态时，其他容器可以使用未使用的CPU。

cpu：” 200m” 对应于cpu：0.2，这意味着大约一个内核的20％。

展望未来，我们来谈谈limits.cpu。受Kubernetes限制的CPU乘以100。结果是容器每100毫秒可以使用的时间量（cpu周期）。limits.cpu对应于Docker –cpus标志，这是旧的–cpu-period和–cpu-quota的新组合。通过设置它，我们指定在容器开始受到限制之前，容器可以最大程度地使用多少可用CPU资源。

cpus-cpu-period和cpu-quota的组合。cpus = 1.5等效于设置cpu-period = 100000和cpu-quota = 150000。

cpu-period-CPU CFS调度程序周期，默认为100微秒。

cpu-quota-容器限制的每个cpu周期的微秒数。

如果我设置的CPU请求不足怎么办？

很好，如果容器需要更多资源，它将从其他进程中”窃取” CPU。

如果我设置的CPU限制不足怎么办？

如前所述，由于CPU是可压缩的，因此可以对其进行限制。

如果我不提供任何CPU请求怎么办？

就像内存一样，CPU请求的值与CPU限制的值相同。

如果我不提供任何CPU限制怎么办？

容器可以使用尽可能多的CPU。如果名称空间定义了默认的CPU限制（LimitRange），则将相同的限制分配给容器。

如果我既不提供CPU限制也不提供请求怎么办？

与内存一样，这是最坏的情况。调度程序不知道您的容器需要多少资源，这可能会导致Node出现严重问题。最好在您的名称空间中使用默认限制（由LimitRange设置）。

请记住，如果您定义的CPU请求大于Node可以提供的请求，则永远不会计划您的Pod。

请勿误解request.cpu为最小范围。像保证它那样使用一定数量的CPU（带有一些缓冲区）足以使您的容器始终处于正常运行状态。

如果您的应用程序不进行大量计算，通常最好的做法是将它的request.cpu <= 1，并在需要时运行更多副本。

计算资源

我们有两种类型的资源，具有以下单元：

· 中央处理器（CPU）：核心

· 内存（MEM）：字节

可以为每个容器指定资源。在以下Pod yaml文件中，您可以注意到资源部分，其中可以包含请求的资源和有限的资源。

Pod的请求资源=所有容器的请求资源总和，Pod的有限资源=所有容器的有限资源的总和。

如果您不熟悉Pod yamls或Pod本身，请阅读我以前的博客文章。

Pod规范中的resources.requested字段是元素之一，用于查找可以在其中安排Pod的正确Node。

精细。那么，这种”查找”过程是怎样的呢？

好吧，Kubernetes由多个组件组成，其中一个是主节点（Kubernetes控制平面）。Master包含一些进程：kube-apiserver，kube-controller-manager和kube-scheduler。kube-scheduler是一个负责人，负责监视新创建的Pod并找到可行的Worker Node，它可以满足Pod的所有期望（连同其请求的资源）。对由kube-scheduler找到的节点列表进行排序，并选择得分最高的节点作为Pod的调度节点。

Where the violet Pod will be scheduled?

在上图中，kube-scheduler必须安排新的（紫色）Pod。Kubernetes集群有两个节点A和B。您会注意到，kube-scheduler无法在Node A上调度应用程序，因为可用（未请求）资源无法满足紫Pod的期望。要求的1 Gi紫罗兰色Pod内存无法容纳在（可用）0.5 Gi内存的节点A上，但另一方面，节点B具有足够的资源。紫罗兰色Pod的1个CPU内核和1 Gi内存可以安装在具有3个内核和1.5 Gi可用内存的Node A上。根据紫罗兰色Pod资源的请求以及节点上的可用资源，kube-scheduler决定将节点B作为紫罗兰色Pod的目的地。

酷。我们知道，在节点上调度Pod时会考虑请求的资源。那有限的资源呢？

有限的资源是CPU / MEM无法到达的边界。但是，CPU是可压缩的，因此达到限制值的容器不会导致Pod终止，而是可以对其进行限制。与不可压缩的MEM相比，达到其限制的容器将以OOM-Killed原因终止，并根据RestartPolicy（默认情况下始终为默认）重新启动。

理想的请求/有限资源数量

我们了解了计算资源。现在是时候回答这个问题了：”我的Pod需要多少资源来为应用程序提供服务而不会出现任何问题？完美的金额是多少？”

不幸的是，对这些问题没有简单的答案。如果您不知道应用程序的性能如何，需要多少CPU或内存，那么您最好的办法就是为CPU和内存添加大缓冲区，然后对应用程序进行性能测试。

除性能测试外，在监视工具中观察下一周的行为。如果从图中注意到您的应用程序消耗的资源少于我们请求的资源，那么您可以进行调整，并减少CPU /内存，无论被超额使用/限制了多少。

作为启发，请查看Grafana仪表板，该仪表板介绍了请求/受限资源与当前使用之间的区别。

结论

设置请求的资源和有限的资源有助于我们保持Kubernetes集群的健康。拥有适当的数量可以最大程度地降低成本，并使我们的应用程序始终保持正常运行。

简要总结一下，有几件事要牢记：

• 所请求的资源是在”启动时间”（当Kubernetes计划安排应用程序时）考虑的配置，而有限的资源在”运行时”（当我们的应用程序已经在Node上运行）时很重要。
• 与内存相比，CPU是一种可压缩的资源。这意味着在缺乏CPU的情况下，您的Pod不会终止，但会受到限制
• 请求的资源有限，范围不大！通过定义请求的资源，可以确保您的应用程序可以正常运行并没有任何问题。
• 要求和限制的内存相等是一件好事。
• 除非您的应用进行大量计算，否则CPU最好少于或等于1个内核。
• 如果您指定的请求资源大于Node的资源，则永远不会安排Pod。
• 要找到理想数量的请求/有限资源，请针对您的应用运行性能测试并对其进行监控。

希望这篇文章可以帮助您理解它的基本概念，将学到知识应用到工作中。