在Almatar，与Kubernetes（k8s）进行了大规模合作，在极少数情况下，我们的某些服务遇到意外行为，导致我们提出了很少的问题，以使事情变得更加稳定和可靠。 其中之一是当一个Pod停止运行时该怎么办，因为k8无法满足特定节点上该Pod所需的资源（就内存和CPU而言），我们是否应该在这种情况下重新启动Pod？ 有没有更聪明的方法来管理资源分配？ 让我们看看我们如何遇到这种情况以及如何更好地控制它。

Kubernetes，大图景

> Image from Dzone

在容器化的世界中，Kubernetes在其控制平面中又有多个组件，即一个主节点，其中之一就是kube-scheduler。 是组件/流程，负责监视集群中的Pod，将工作负载分配给相应的节点，以及跟踪每台正在运行的主机上的资源利用率，以使工作负载与可用资源匹配。

资源限制是Kubernetes用于获取信息的信息的参数，该信息是Pod正常运行所需的资源是什么以及Pod可以利用的最大允许资源是多少。

调度程序还负责根据计算资源利用率（内存/ CPU）与可用节点匹配容器需求，即：对于需要X内存和Y CPU的新创建的Pod，调度程序将确保分配容器。 装到可以处理分配给它的工作负载的节点上，否则会发生什么？ 默认的k8s分配没有针对内存/ CPU的强制资源限制，因此，容器可以与同一个节点中的其他Pod一起使用尽可能多的资源，从而相互影响，可能会出现拥塞状态。

负载测试背景

> Photo by Thomas Kelley on Unsplash

在发布我们的航班产品之前，我们开始使用Apache JMeter进行一些负载测试，并通过Grafana收集少量指标，以确保在高流量期间一切稳定。

如果容器超出了其允许的内存限制（在我们的情况下为无限制），则kubelet（在每个节点上运行的守护程序）将开始采取措施以重启有问题的Pod（如果可能的话），否则，如果其超出了请求的内存（在我们的情况下） 它也处于打开状态），如果Pod导致节点内存不足（或基于内核发出信号的方式杀死了oom），则该Pod将被驱除，或者同一节点中的其他Pod也可能被驱逐，从而导致更多混乱和 这些服务不稳定，会间歇性停止运行。

在此阶段，一切可能仍然很好，Kubernetes将重新启动Pod，Linux内核将回收一些空间，然后调度程序将Pod重新调整到其他节点（请记住，尚无分配策略），但是我们仍然有风险 在其他节点上再次发生相同的行为。 我们需要根据每个服务的当前消耗率对Kubernetes进行检测，以便在当前基础架构下可以做出更好的分配决策。

K8中的这些请求/限制是什么？

在kube-scheduler决定在哪个节点上放置容器/容器之后，重要的是容器具有可在该节点上运行的足够资源，这是kubelet守护程序在每个负责节点运行状况的节点上运行的角色。 豆荚。 例如，如果您的应用程序需要8 GB的内存（RAM），而主机上允许的最大容量为<8 GB，则将导致该文凭节点内存不足，并且一切将停止工作。 设置这些需求很重要，这样调度程序才能在放置步骤中做出更好的决策。 但是这些指标如何设置以及设置什么？

请求（例如：8 GB内存，0.1 CPU）：告诉Kubernetes仅在具有这些资源可用的节点上分配容器。

限制（例如：10 GB内存，0.2 CPU）：告诉Kubernetes调度程序在消耗资源时不要让Pod超过这些阈值（达到这些限制然后限制它）。

spec:

containers:

- image: php

imagePullPolicy: IfNotPresent

name: flights-x-service

ports:

- containerPort: 80

protocol: TCP

resources:

limits:

cpu: 800m

memory: 2000Mi

requests:

cpu: 700m

memory: 1000Mi

简而言之，上面的示例描述了一个Pod的部署，其中包含一个正在运行的PHP映像容器，并按以下方式指定了请求：

· 要求cpu：700m（以毫米为单位）

· 请求内存：1000Mi（以兆字节为单位）

· 限制cpu：800m（最高可达800毫米）

· 限制内存：2000Mi（最多可占用2000兆字节）

调度程序将首先尝试找到一个可以处理请求阈值的节点（如果找到了该节点，则将其分配给它），但是如果找不到节点会发生什么呢？ 如果这些请求阈值太高或运行时超出了这些限制，该怎么办？

· 如果请求值设置得太高，则调度程序将无法在任何节点上调度Pod并挂起。 查看命名空间中引发的事件，我们将看到原因：

$ kubectl get events | grep flights-x-serviceWarning FailedScheduling0/x nodes are available:x Insufficient memory, y Insufficient cpu.

· 对于在运行时Pod超出其内存/ cpu限制的其他情况，kubernetes的行为会有所不同，具体取决于哪种资源类型。 CPU资源是可压缩的，这意味着kubernetes将在CPU达到其极限时对其进行压缩，但不会终止pod，从而导致应用程序性能下降。 另一方面，内存是不可压缩的（无法像cpu一样限制内存），如果内存超出了允许的配额，则pod将终止。

还有其他更深入的文章，讨论kubelet如何处理资源不足的情况

如何定义请求限制阈值（上限）？

在开始时，我们主要采用一种实验方法来在进行负载测试时跟踪资源利用率，然后，我们可以使用分析/监控工具来跟踪Pod的使用情况，并在需要时调整阈值以防止利用率过高或不足 在资源中，结果称为"上限"或简称为" Ulimits"：

· 如果我们能够在短时间窗口内模拟成千上万的用户访问平台的行为，那么我们可以对集群中的资源分配进行一些粗略的估算；如果它是一个简单的API，我们可以使用loader.io之类的东西或构建 使用Apache JMeter进行一些更复杂的流程，然后使用kubescope-cli或与Kubernetes集成的任何其他分析/监视工具（如Grafana）监视每个pod上的资源利用率。

> kubescope-cli

> grafana

2.一旦记录了已使用的内存/ CPU，就可以开始按其类型对Pod利用率进行分类，还记得我们要回答的下一个问题是：如果我们有一个新的服务部署，那么应该为其分配什么资源阈值？ ，贪婪的方法主要有以下三类：

· 高流量：在阿拉木图，这些是沿用户操作（例如搜索，产品选择等）的关键路径的请求的主要消费者。

· 中流量：可能是按概率命中的服务，即：由另一个缓存层支持的服务，该缓存层并未在每个繁忙流量的请求路径上使用。

· 低流量：可能是受到攻击的可能性很小，例如：拥有一些通过某些API为航班/酒店提供静态数据的服务，这些服务可用于将信息植入其他层，例如Elastic Search， 这些甚至在其请求期间也不需要大量消耗。

3.除了上述存储桶之外，其他Pod可以构成其他类别，例如数据库存储，例如，如果一个Pod用于mongodb，则Mongodb的u限制有一个额外的层，例如：docs.mongodb/ manual / reference / ulimit /引用了有关文件大小，内存分配，堆栈大小等的更详细的限制级别。

4.对于请求的任何新服务，默认部署文件应考虑根据服务所属的类别设置一些默认限制。 以后，可以根据需要调整这些限制，重新设计请求的关键路径，等等。

最后的想法

· 可以在名称空间级别上设置一些资源配额，它控制同一名称空间中所有Pod的聚合资源消耗。 可以创建具有不同分类的ResourceQuota Kubernetes对象（将其视为标签），为每个标签设置一些内存/ cpu阈值，然后为每个创建的Pod指定一个标签以引用ResourceQuota对象中定义的资源阈值， 例如：高流量客舱，低流量客舱，等等。

· 生产负载测试可能很棘手，我们需要在非高峰时间在生产环境中连续运行这些定期测试，同时确保不会耗尽资源，从而导致其他服务的停机，设置u-limits非常重要 在进入这个阶段之前。

· 本文介绍了对k8s Pod设置ulimit的重要性，请求和限制如何不同以及Kubernetes在这些阈值方面的行为的基本理解。 可以采用许多其他方法来完善这些阈值，更好地控制（不仅是容器）持久性卷，存储请求等。