Kubernetes中的资源分配和限制策略

Posted 2023-03-30

参考技术A

Kubernetes是一个容器集群管理平台，Kubernetes需要统计整体平台的资源使用情况，合理地将资源分配给容器使用，并且要保证容器生命周期内有足够的资源来保证其运行。 同时，如果资源发放是独占的，即资源已发放给了个容器，同样的资源不会发放给另外一个容器，对于空闲的容器来说占用着没有使用的资源比如CPU是非常浪费的，Kubernetes需要考虑如何在优先度和公平性的前提下提高资源的利用率。为了实现资源被有效调度和分配同时提高资源的利用率，Kubernetes采用request和limit两种限制类型来对资源进行分配。

在中台这边的实践中，多次遇到各种场景的容器资源限制等问题。基于此，特整理相关的知识点，供大家参阅。

request 容器使用的最小资源需求，创建容器的时候，是最小的资源要求。 只有当节点上可分配资源量>=容器资源请求数时才允许将容器调度到该节点。

也就是说，创建容器时候，分配资源是按照 request 指定的值进行独占的，容器至少要保留request指定的资源。

limit 表明容器能使用资源的最大值，设置为0表示使用资源无上限。

request 能够保证Pod有足够的资源来运行，而 limit 则是防止某个Pod无限制地使用资源，导致其他Pod崩溃。

两者之间必须满足关系:

通过一个示例简述request和limit参数的使用场景。

假设PaaS的一个节点有 4U4G 可用资源。已经部署2个pod，记为pod1, pod2。每个pod的资源设置为

节点上CPU和内存的资源分配情况如下图：
[图片上传失败...(image-935055-1555552418778)]

已经分配的CPU资源为：1U(分配Pod1)+1U(分配Pod2)=2U，剩余可以分配的CPU资源为2U

已经分配的内存资源为：1G(分配Pod1)+1G(分配Pod2)=2G，剩余可以分配的内存资源为2G

所以该节点可以再部署一个(CPU Requst, Memory Requst)=(2U,2G)的Pod，或者部署2个(CPU Requst, Memory Requst)=(1U,1G)的Pod

在资源限制方面，每个Pod1和Pod2使用资源的上限为(2U,1G)，即在资源空闲的情况下，Pod使用CPU的量最大能达到2U，使用内存的最大量为1G。从CPU资源的角度，对于资源使用上线为2U的Pod，通过设置request为1U，实现了2倍数量的Pod的部署，提高了资源的使用效率。

依然假设PaaS的一个节点有 4U4G 可用资源，节点上部署了4个pod，记为pod1~4。每个Pod的资源设置为（CPU Requst,CPU limit,Memory Requst, Memory limit）= (1U, 2U, 512M,512M)。资源分配情况如下图：

[图片上传失败...(image-84aeaf-1555552418778)]

按照request的要求，那么已经没有可以分配的CPU资源了。但是，由于Pod1~4业务负载比较低，造成了CPU的利用率较低，造成资源浪费。这个时候可以通过将request的值设置为0，实现对资源的进一步利用。

在此节点上部署4个pod5~8， 资源限制为（CPU Requst,CPU limit,Memory Requst, Memory limit）= (0U, 0U, 512M,512M)。资源的使用情况如下图所示：

[图片上传失败...(image-78aeae-1555552418778)]

Pod5~8 能够在Pod(1~4)空闲时，使用节点上剩余的CPU资源，从而进一步提高资源的使用率。

Kubernetes中资源通过 request 和 limit 的设置，能够实现容器对资源的更高效的使用。在如果多个容器同时对资源进行充分利用，资源使用尽量的接近limit。 Node节点上的资源总量要小于所有Pod中limit的总和，就会发生资源抢占。

对于资源抢占的情况，Kubernetes根据资源能不能进行伸缩进行分类，分为可压缩资源和不可以压缩资源。

假设有pod1~4 分别占用（CPU Requst,CPU limit,Memory Requst, Memory limit）= (1U, 2U, 1G,1G)。当四个pod的负载都很高，CPU使用都超过1U的情况下，这个时候每个pod将按照request设置的CPU比例进行时间片调度。由于4个Pod设置的request都为1U，发生资源抢占时，每个Pod分到的CPU时间片为1U/(1U)*4，实际占用的CPU核数为1U。

对于不可压缩资源，如果发生资源抢占，则会按照优先级的高低进行Pod的驱逐。驱逐的策略为： 优先驱逐request=limit=0的Pod，其次驱逐 0<request<limit<Infinity (limit为0的情况也包括在内)。 0<request==limit 的Pod的会被保留，除非出现删除其他Pod后，节点上剩余资源仍然没有达到Kubernetes需要的剩余资源的需求。

由于对于不可压缩资源，发生抢占的情况会出Pod被意外Kill掉的情况，所以建议对于不可以压缩资源(Memory，Disk)的设置成 0<request==limit 。

http://www.cnblogs.com/sparkdev/p/8032330.html
https://www.cnblogs.com/sparkdev/p/8052522.html
https://cloud.tencent.com/developer/article/1004976

如何在 Kubernetes 中执行清单策略？

【中文标题】如何在 Kubernetes 中执行清单策略？

【英文标题】：How to enforce policies for manifests in Kubernetes?

【发布时间】：2020-03-07 12:40:20

【问题描述】：

我已经建立了一个基于 Kubernetes 的自助服务平台，我们为每个团队创建命名空间并允许他们“在命名空间内做任何他们想做的事情”（我们设置了资源限制，因此没有人可以杀死整个集群）。

但是，现在我想在整个组织中实施某种标准。例如，我希望每个 PodSpec 定义自己的资源限制，并且我希望每个资源都有一个标签来指定它属于哪个应用程序。

是否有一种机制允许 API 服务器根据一组规则检查正在应用的清单，如果检查失败，则清单被拒绝。

例如，以下清单将被拒绝，因为它既没有标签也没有设置资源限制。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

但以下清单会成功，因为它满足所有规则：

api版本：apps/v1 种类：部署 元数据： 名称：nginx-部署 标签： 应用程序：foobar 规格： 选择器： 匹配标签： 应用程序：nginx 复制品：2 模板： 元数据： 标签： 应用程序：nginx 规格： 容器： - 名称：nginx 图片：nginx：1.7.9 端口： - 容器端口：80 资源： 限制： CPU：“1” 请求： cpu：“0.5”

【参考方案1】：

是否有一种机制允许 API 服务器根据一组规则检查正在应用的清单，如果检查失败，则清单被拒绝。

一般来说，这可以通过custom admission controller 或自定义代理来解决。这取决于您的需求，可能并不那么容易。

命名空间的资源限制

我们为每个团队创建命名空间，并允许他们“在命名空间内为所欲为”（我们设置了资源限制，因此没有人可以杀死整个集群）。

我希望每个 PodSpec 定义自己的资源限制

您在这里寻找的可能是每个命名空间的 Limit Ranges，可能还有默认值。

使用资源配额，集群管理员可以在命名空间的基础上限制资源消耗和创建。在命名空间中，Pod 或容器可以消耗命名空间资源配额所定义的 CPU 和内存。人们担心一个 Pod 或 Container 可能会垄断所有资源。 Limit Range 是一种通过命名空间中的 Pod 或 Container 来限制资源的策略。

强制标签据我所知这不可能，yet

【参考方案2】：

您可以使用 Open Policy Agent (OPA) 和 Gatekeeper 对资源清单强制执行自定义策略。

OPA 是一个通用策略引擎，Gatekeeper 提供 CRD 和验证准入控制 webhook 以在 Kubernetes 中定义和执行 OPA 策略。

您可以从字面上描述资源清单的各个方面的政策，Gatekeeper 会拒绝任何违反政策的资源。

这是一个demo，它展示了 Gatekeeper 的工作原理。