kubernetes ResourceQuotas Limits（资源配额）

已于 2024-01-09 15:10:57 修改
阅读量895 收藏 21
点赞数 21
分类专栏： kubernetes 文章标签： kubernetes 容器 云原生 安全 运维
于 2024-01-09 15:04:15 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_48297181/article/details/135480590
版权

开头语

写在前面：如有问题，以你为准，

目前24年应届生，各位大佬轻喷，部分资料与图片来自网络

内容较长，页面右上角目录方便跳转

简介

  1. 当多个用户或团队共享具有固定节点数目的集群时，人们会担心 有人使用超过其基于公平原则所分配到的资源量 。资源配额是帮助管理员解决这一问题的工具。
  2.  资源配额，通过 ResourceQuota 对象来定义，对每个命名空间的资源消耗总量提供限制。 它可以 限制 命名空间中 某种类型的对象的总数目上限，也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。
  3.  资源配额的工作方式如下：
    1. 不同的团队可以在不同的命名空间下工作，目前这是非约束性的，在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。
    2. 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象
    3. 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况，以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
    4. 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。
    5. 如果命名空间下的计算资源 （如 cpu 和 memory）的配额被启用，则用户必须为 这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。

ResourceQuota 是一个准入控制插件，默认已启用

kubectl exec kube-apiserver-master -n kube-system -- kube-apiserver -h | grep enable-admission-plugins | grep  ResourceQuota

括号内是默认启用

yaml 介绍

官方文档

资源配额 | Kubernetes

apiVersion: v1

kind: ResourceQuota

metadata:

  name: storage

  namespace: default # 限制 default 名称空间

spec:

  hard: # 是每种指定资源所强制实施的硬性限制集合

    pods: "3" # 限制 Pod 的数量

    requests.cpu: "1" # 限制 pod cpu 数量

    requests.memory: 1Gi # 限制 内存使用量

    requests.storage: "10G" # 限制 存储使用量

  used: # 是当前命名空间中所观察到的资源总用量

RQ对pod的影响

如果对某个命名空间做出了限制，会导致在这个命名空间下创建的pod其配置里面就要对自身做出限制，不然会创建不了，导致报错

主要是满足 requests 的请求，这是请求资源的最低值

requests 和 limit 区别

在调度的时候： requests 比较重要，这可以帮助 Kubernetes 调度器决定在哪个节点上运行 Pod

在运行的时候： limits      比较重要,   这有助于确保容器不会无限制地使用资源。

当设置 limits 而没有设置 requests 时，Kubernetes 默认令 requests 等于 limits

requests（资源请求）： 定义了对应容器需要的最小资源量

  • requests定义了一个容器所需的最低资源量。它表示容器在正常运行时所需的资源最小值。Kubernetes调度器使用这个值来决定将容器调度到哪个节点上，以确保节点上的资源能够满足容器的请求。如果节点上的资源不足以满足 requests，则容器可能不会被调度到该节点。
  • requests 对于水平伸缩（Horizontal Pod Autoscaling）也非常重要，因为它帮助系统自动决定何时需要扩展Pod的数量。

 imits（资源限制）：定义了这个容器最大可以消耗的资源上限

  • limits 定义了容器能够使用的资源的上限。它表示容器在运行时不应该使用的资源量。如果容器尝试使用超过 limits 定义的资源量，Kubernetes将限制容器的资源使用，并可能终止容器。
  • limits 对于防止容器占用过多的系统资源以至于影响其他容器或节点非常重要。它可以确保一个容器不会耗尽整个节点的资源，从而维护整个集群的可靠性和稳定性

（1）对于 CPU，如果 pod 中服务使用 CPU 超过设置的limits，pod 不会被 kill 掉但会被限制。如果没有设置 limits ，pod 可以使用全部空闲的 CPU 资源。

（2）对于内存，当一个 pod 使用内存超过了设置的limits，pod 中 container 的进程会被 kernel 因 OOM kill 掉。当 container 因为 OOM 被 kill 掉时，系统倾向于在其原所在的机器上重启该 container 或本机或其他重新创建一个 pod

0 <= requests <=Node Allocatable, requests <= limits <= Infinity

k8s 中负载问题

1. 经常在 K8s 集群种部署负载的时候不设置 CPU requests 或将 CPU requests 设置得过低（这样“看上去”就可以在每个节点上容纳更多 Pod ）。在业务比较繁忙的时候，节点的 CPU 全负荷运行。业务延迟明显增加，有时甚至机器会莫名其妙地进入 CPU 软死锁等“假死”状态

2. 类似地，部署负载的时候，不设置内存 requests 或者内存 requests 设置得过低，这时会发现有些 Pod 会不断地失败重启。而不断重启的这些 Pod 通常跑的是 Java 业务应用，但是这些 Java 应用本地调试运行地时候明明都是正常的。

3.在 K8s 集群中，集群负载并不是完全均匀地在节点间分配的，通常内存不均匀分配的情况较为突出，集群中某些节点的内存使用率明显高于其他节点。 K8s 作为一个众所周知的云原生分布式容器编排系统，一个所谓的事实上标准，其调度器不是应该保证资源的均匀分配吗

（1）CPU 属于可压缩资源，其中 CPU 资源的分配和管理是 Linux 内核借助于完全公平调度算法（ CFS ）和 Cgroup 机制共同完成的

简单地讲，如果 pod 中服务使用 CPU 超过设置的 CPU limits， pod 的 CPU 资源会被限流（ throttled ）。对于没有设置limit的 pod ，一旦节点的空闲 CPU 资源耗尽，之前分配的 CPU 资源会逐渐减少。不管是上面的哪种情况，最终的结果都是 Pod 已经越来越无法承载外部更多的请求，表现为应用延时增加，响应变慢，对应上面1的情形

（2）内存属于不可压缩资源， Pod 之间是无法共享的，完全独占的，这也就意味着资源一旦耗尽或者不足，分配新的资源一定是会失败的。有的 Pod 内部进程在初始化启动时会提前开辟出一段内存空间。比如 JVM 虚拟机在启动的时候会申请一段内存空间。如果内存 

requests 指定的数值小于 JVM 虚拟机向系统申请的内存，导致内存申请失败（ oom-kill ），从而 Pod 出现不断地失败重启。这种情形对应于上面的情形 2

（3）另一方面， K8s 内置的调度算法不仅仅涉及到“最小资源分配节点”，还会把其他诸如 Pod 亲和性等因素考虑在内。并且 k8s 调度基于的是资源的 requests 数值，而之所以往往观察到的是内存分布不够均衡，是因为对于应用来说，相比于其他资源，内存一般是更紧缺的一类资源这种情形对应于上面的情形 3

比如当出现新的 Pod 进行调度时，调度程序会根据其当时对 Kubernetes 集群的资源描述做出最佳调度决定。但是 Kubernetes 集群是非常动态的，由于整个集群范围内的变化，比如一个节点为了维护，我们先执行了驱逐操作，这个节点上的所有 Pod 会被驱逐到其他节点去，但是当我们维护完成后，之前的 Pod 并不会自动回到该节点上来，因为 Pod 一旦被绑定了节点是不会触发重新调度的

计算资源配额

参数

资源名称

描述

limits.cpu

所有非终止状态的 Pod，其 CPU 限额总量不能超过该值。

limits.memory

所有非终止状态的 Pod，其内存限额总量不能超过该值。

requests.cpu

所有非终止状态的 Pod，其 CPU 需求总量不能超过该值。

requests.memory

所有非终止状态的 Pod，其内存需求总量不能超过该值。

hugepages-

对于所有非终止状态的 Pod，针对指定尺寸的巨页请求总数不能超过此值。

cpu

与 requests.cpu

相同。

memory

与 requests.memory

相同。

yaml 示例

apiVersion: v1

kind: ResourceQuota

metadata:

  name: mem-cpu

  namespace: default # 限制 default 名称空间

spec:

  hard:

    requests.cpu: "1"

    requests.memory: 1Gi

    limits.cpu: "2"

    limits.memory: 2Gi

requests：这是您为 Pod 请求的资源数量，即 Pod 的最小资源需求。它用于告诉 Kubernetes 集群为您的 Pod 分配多少资源。如果您设置了 requests，Kubernetes 集群将确保为 Pod 预留这些资源。这是在调度 Pod 到节点时的关键指标，它确保了节点上有足够的资源可供 Pod 使用。如果节点上没有足够的资源来满足 requests，Pod 可能无法被调度。

 limits：这是您为 Pod 设置的资源上限，即 Pod 的资源使用的最大限制。它用于限制 Pod 的资源使用，以防止它占用过多的资源并影响其他 Pod。如果您设置了 limits，Kubernetes 集群将确保 Pod 的资源使用不会超过这些限制。如果 Pod 尝试使用超出 limits 设置的资源量，它可能会被终止或受到限制。

总结一下，requests 是资源的保底需求，确保 Pod 有足够的资源可供使用，并在调度时起作用。limits 是资源的上限，用于限制 Pod 的资源使用，以确保它不会超过限制。

扩展资源

  1. 除上述资源外，在 Kubernetes 1.10 版本中，还添加了对 扩展资源 的支持。
  2. 由于扩展资源不可超量分配，因此没有必要在配额中为同一扩展资源同时指定 requests 和 limits。 对于扩展资源而言，目前仅允许使用前缀为 requests. 的配额项。
  3. 以 GPU 拓展资源为例，如果资源名称为 nvidia.com/gpu，并且要将命名空间中请求的 GPU 资源总数限制为 4，则可以如下定义配额：

requests.nvidia.com/gpu: 4

实操

apiVersion: v1

kind: Pod

metadata:

  creationTimestamp: null

  labels:

    run: web

  name: web

  namespace: test

spec:

  containers:

  - image: nginx:1.17.1

    name: web

    resources:

      requests:

        cpu: 0.5

        memory: 256Mi

      limits:

        cpu: 1

        memory: 512Mi

status: {}
[root@master cks]# kubectl create -f RQ-cpu-mem.yaml

resourcequota/mem-cpu created


[root@master cks]# kubectl get quota -n test

NAME      AGE   REQUEST                                       LIMIT

mem-cpu   13m   requests.cpu: 0/1, requests.memory: 0/512Mi   limits.cpu: 0/2, limits.memory: 0/1Gi


[root@master cks]# kubectl run -n test web --image=nginx:1.17.1

Error from server (Forbidden): pods "web" is forbidden: failed quota: mem-cpu: must specify limits.cpu for: web; limits.memory for: web; requests.cpu for: web; requests.memory for: web

kubectl run -n test web --image=nginx:1.17.1 --dry-run=client -oyaml > pod.yaml

[root@master cks]# kubectl apply -f pod.yaml

pod/web created


[root@master cks]# kubectl get quota -n test

NAME      AGE   REQUEST                                              LIMIT

mem-cpu   26m   requests.cpu: 500m/1, requests.memory: 256Mi/512Mi   limits.cpu: 1/2, limits.memory: 512Mi/1Gi

[root@master cks]# kubectl apply -f pod.yaml

pod/web2 created

[root@master cks]# kubectl get quota -n test

NAME      AGE   REQUEST                                           LIMIT

mem-cpu   26m   requests.cpu: 1/1, requests.memory: 512Mi/512Mi   limits.cpu: 2/2, limits.memory: 1Gi/1Gi

[root@master cks]# kubectl get pod -n test

NAME   READY   STATUS    RESTARTS   AGE

web    1/1     Running   0          58s

web2   1/1     Running   0          24s

存储资源配额

  1. 用户可以对给定命名空间下的 存储资源 总量进行限制。
  2. 此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗

资源名称

描述

requests.storage

所有 PVC，存储资源的需求总量不能超过该值。

persistentvolumeclaims

在该命名空间中所允许的 PVC 总量。

.storageclass.storage.k8s.io/requests.storage

在所有与 相关的持久卷申领中，存储请求的总和不能超过该值。

.storageclass.storage.k8s.io/persistentvolumeclaims

在与 storage-class-name 相关的所有持久卷申领中，命名空间中可以存在的持久卷申领总数。

  1.  例如，如果一个操作人员针对 gold 存储类型与 bronze 存储类型设置配额， 操作人员可以定义如下配额：
    1.  gold.storageclass.storage.k8s.io/requests.storage: 500Gi
    2.  bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

 在 Kubernetes 1.8 版本中，本地临时存储的配额支持已经是 Alpha 功能

资源名称

描述

requests.ephemeral-storage

在命名空间的所有 Pod 中，本地临时存储请求的总和不能超过此值。

limits.ephemeral-storage

在命名空间的所有 Pod 中，本地临时存储限制值的总和不能超过此值。

ephemeral-storage

与 requests.ephemeral-storage相同。

注意：如果所使用的是 CRI 容器运行时，容器日志会被计入临时存储配额。 这可能会导致存储配额耗尽的 Pods 被意外地驱逐出节点。 参考日志架构 了解详细信息。

yaml 示例

apiVersion: v1

kind: ResourceQuota

metadata:

  name: storage

  namespace: default # 限制 default 名称空间

spec:

  hard:

    requests.storage: "10G"

实操

apiVersion: v1

kind: ResourceQuota

metadata:

  name: storage

  namespace: test

spec:

  hard:

    requests.storage: "10G"
[root@master cks]# kubectl apply -f RQ-storage.yaml

resourcequota/storage created



[root@master cks]# kubectl get quota -n test

NAME      AGE   REQUEST                                       LIMIT

mem-cpu   51m   requests.cpu: 0/1, requests.memory: 0/512Mi   limits.cpu: 0/2, limits.memory: 0/1Gi

storage   31s   requests.storage: 0/10G
apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: pvc

  namespace: test

spec:

  accessModes: # 访客模式

    - ReadWriteMany

  resources: # 请求空间

    requests:

      storage: 5Gi

[

root@master cks]# kubectl apply -f RQ-pvc.yaml

persistentvolumeclaim/pvc-rq created

[root@master cks]# kubectl get pvc -n test

NAME     STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE

pvc-rq   Pending                                                     10s

# pending 代表没匹配大小一样的pv

[root@master cks]# kubectl get quota -n test

NAME      AGE     REQUEST                                       LIMIT

mem-cpu   56m     requests.cpu: 0/1, requests.memory: 0/512Mi   limits.cpu: 0/2, limits.memory: 0/1Gi

storage   5m28s   requests.storage: 5Gi/10G

[root@master cks]# kubectl apply -f RQ-pvc.yaml

Error from server (Forbidden): error when creating "RQ-pvc.yaml": persistentvolumeclaims "pvc-rq-2" is forbidden: exceeded quota: storage, requested: requests.storage=5Gi, used: requests.storage=5Gi, limited: requests.storage=10G

# 因为重新创建会导致存储使用 >= 10G ,k8s 认为会超过限制

# 改成 4G 即可创建成功

[root@master cks]# kubectl apply -f RQ-pvc.yaml

persistentvolumeclaim/pvc-rq-2 unchanged

[root@master cks]# kubectl get pvc -n test

NAME       STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE

pvc-rq     Pending                                                     5m14s

pvc-rq-2   Pending                                                     94s



[root@master cks]# kubectl get quota -n test

NAME      AGE     REQUEST                                       LIMIT

mem-cpu   58m     requests.cpu: 0/1, requests.memory: 0/512Mi   limits.cpu: 0/2, limits.memory: 0/1Gi

storage   7m40s   requests.storage: 9Gi/10G

对象数量配额

  1. 你可以使用以下语法对所有标准的、命名空间域的资源类型进行配额设置：

count/<resource>.<group>

：用于非核心（core）组的资源。

count/<resource>

：用于核心组的资源。

  1.  这是用户可能希望利用对象计数配额来管理的一组资源示例。
    1. count/persistentvolumeclaims
    2. count/services
    3. count/secrets
    4. count/configmaps
    5. count/replicationcontrollers
    6. count/deployments.apps
    7. count/replicasets.apps
    8. count/statefulsets.apps
    9. count/jobs.batch
    10. count/cronjobs.batch
  2.  相同语法也可用于自定义资源。 例如，要对 example.com API 组中的自定义资源

widgets 设置配额，请使用 count/widgets.example.com。

  1.  当使用 count/* 资源配额时，如果对象存在于服务器存储中，则会根据配额管理资源。 这些类型的配额有助于防止存储资源耗尽。例如，用户可能想根据服务器的存储能力来对服务器中 Secret 的数量进行配额限制。 集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动。 用户可以选择对 Job 进行配额管理，以防止配置不当的 CronJob 在某命名空间中创建太多 Job 而导致集群拒绝服务。
  2.  对有限的一组资源上实施一般性的对象数量配额也是可能的。 此外，还可以进一步按资源的类型设置其配额。

资源名称

描述

configmaps

在该命名空间中允许存在的 ConfigMap 总数上限。

persistentvolumeclaims

在该命名空间中允许存在的 PVC的总数上限。

pods

在该命名空间中允许存在的非终止状态的 Pod 总数上限。Pod 终止状态等价于 Pod 的 .status.phase in (Failed,Succeeded)为真。

replicationcontrollers

在该命名空间中允许存在的ReplicationController 总数上限。

resourcequotas

在该命名空间中允许存在的 ResourceQuota 总数上限。

services

在该命名空间中允许存在的 Service 总数上限。

services.loadbalancers

在该命名空间中允许存在的 LoadBalancer 类型的 Service 总数上限。

services.nodeports

在该命名空间中允许存在的 NodePort 类型的 Service 总数上限。

secrets

在该命名空间中允许存在的 Secret 总数上限。

例如，pods 配额统计某个命名空间中所创建的、非终止状态的 Pod 个数并确保其不超过某上限值。 用户可能希望在某命名空间中设置 pods 配额，以避免有用户创建很多小的 Pod， 从而耗尽集群所能提供的 Pod IP 地址。

yaml 示例

apiVersion: v1

kind: ResourceQuota

metadata:

  name: pods-rq

  namespace: default # 限制 default 名称空间

spec:

  hard:

    pods: "3" # 限制 Pod 的数量

    count/deployments.apps:"3"  # 限制 deployment 的数量

    count/services:"3" # 限制 services 的数量

注意：已经创建的资源不会计入其中

实操

apiVersion: v1

kind: ResourceQuota

metadata:

  name: object-rq

  namespace: test # 限制 default 名称空间

spec:

  hard:

    pods: "3" # 限制 Pod 的数量

[root@master cks]# kubectl apply -f RQ-object.yaml

resourcequota/object-rq created

[root@master cks]# kubectl get quota -n test

NAME        AGE   REQUEST                                       LIMIT

mem-cpu     63m   requests.cpu: 0/1, requests.memory: 0/512Mi   limits.cpu: 0/2, limits.memory: 0/1Gi

object-rq   6s    pods: 0/3

storage     12m   requests.storage: 0/10G
---

apiVersion: apps/v1 # 版本号

kind: Deployment # 类型

metadata: # 元数据

  name: rq-deployment # deployment的名称

  namespace: test # 命名类型

spec: # 详细描述

  replicas: 2 # 副本数量

  selector: # 选择器，通过它指定该控制器可以管理哪些Pod

    matchLabels: # Labels匹配规则

      app: nginx-pod

  template: # 模块 当副本数据不足的时候，会根据下面的模板创建Pod副本

    metadata:

      labels:

        app: nginx-pod

    spec:

      containers:

        - name: nginx # 容器名称

          image: nginx:1.17.1 # 容器需要的镜像地址

          ports:

            - containerPort: 80 # 容器所监听的端口

          resources:

            requests:

              cpu: 0.5

              memory: 256Mi

            limits:

              cpu: 1

              memory: 512Mi
[root@master cks]# kubectl apply -f RQ-deploy.yaml

deployment.apps/rq-deployment created



[root@master cks]# kubectl get deploy -n test

NAME            READY   UP-TO-DATE   AVAILABLE   AGE

rq-deployment   2/2     2            2           6s

[root@master cks]# vim RQ-deploy.yaml

[root@master cks]# kubectl get pod -n test

NAME                             READY   STATUS    RESTARTS   AGE

rq-deployment-69f7bd5dd9-gcrdc   1/1     Running   0          46s

rq-deployment-69f7bd5dd9-h48bw   1/1     Running   0          46s

[root@master cks]# kubectl get quota -n test

NAME        AGE     REQUEST                                           LIMIT

mem-cpu     68m     requests.cpu: 1/1, requests.memory: 512Mi/512Mi   limits.cpu: 2/2, limits.memory: 1Gi/1Gi

object-rq   5m15s   pods: 2/3

storage     18m     requests.storage: 0/10G

# 因为 mem-cpu 的限制，所有只设置2个副本

基于优先级类（PriorityClass）来设置资源配额

  1.  Pod 可以创建为特定的优先级。 通过使用配额规约中的 scopeSelector 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。
  2.  仅当配额规范中的 scopeSelector 字段选择到某 Pod 时，配额机制才会匹配和计量 Pod 的资源消耗。
  3.  如果配额对象通过 scopeSelector 字段设置其作用域为优先级类，则配额对象只能 跟踪以下资源：
    1.  pods
    2.  cpu
    3.  memory
    4.  ephemeral-storage
    5.  limits.cpu
    6.  limits.memory
    7.  limits.ephemeral-storage
    8.  requests.cpu
    9.  requests.memory
    10.  requests.ephemeral-storage

yaml 示例

示例：创建一个配额对象，并将其与具有特定优先级的 Pod 进行匹配

# 集群中的 Pod 可取三个优先级类之一，即 "low"、"medium"、"high"

# 为每个优先级创建一个配额对象

apiVersion: v1

kind: List

items:

- apiVersion: v1

  kind: ResourceQuota

  metadata:

    name: pods-high

  spec:

    hard:

      cpu: "1000"

      memory: 200Gi

      pods: "10"

    scopeSelector:

      matchExpressions:

      - operator : In

        scopeName: PriorityClass

        values: ["high"]

- apiVersion: v1

  kind: ResourceQuota

  metadata:

    name: pods-medium

  spec:

    hard:

      cpu: "10"

      memory: 20Gi

      pods: "10"

    scopeSelector:

      matchExpressions:

      - operator : In

        scopeName: PriorityClass

        values: ["medium"]

- apiVersion: v1

  kind: ResourceQuota

  metadata:

    name: pods-low

  spec:

    hard:

      cpu: "5"

      memory: 10Gi

      pods: "10"

    scopeSelector:

      matchExpressions:

      - operator : In

        scopeName: PriorityClass

        values: ["low"]


apiVersion: v1

kind: Pod

metadata:

  name: high-priority

spec:

  containers:

  - name: high-priority

    image: ubuntu

    command: ["/bin/sh"]

    args: ["-c", "while true; do echo hello; sleep 10;done"]

    resources:

      requests:

        memory: "10Gi"

        cpu: "500m"

      limits:

        memory: "10Gi"

        cpu: "500m"

  priorityClassName: high # priorityClassName 指的是什么，就优先使用这个优先级的配额约束。

LimitRange（限制范围）

  1. 默认情况下， Kubernetes 集群上的容器运行使用的计算资源没有限制。
  2.  使用资源配额，集群管理员可以以名字空间为单位，限制其资源的使用与创建。
  3.  在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。
  4.  有人担心，一个 Pod 或 Container 会垄断所有可用的资源。 LimitRange 是在命名空间内限制资源分配（给多个 Pod 或 Container）的策略对象，例如：资源额度 ResourceQuotas 设置为 requests.cpu 为 1 ，requests.memory 为 1Gi ，但是有人的 Pod 直接设置为 requests.cpu 为 1，requests.memory 为 1Gi，那么其他人就不能再创建 Pod 了，所以需要使用 LimitRange 对资源配额设置区间（最小和最大）。
  5.  一个 LimitRange（限制范围） 对象提供的限制能够做到：
    1. 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
    2. 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
    3. 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
    4. 设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。

其中 max 对应 limits

其中 mini 对应 request

示例

为命名空间配置 CPU 最小和最大约束

apiVersion: v1

kind: LimitRange

metadata:

  name: cpu-min-max-demo-lr

  namespace: default # 限制 default 命名空间

spec:

  limits:

  - max:  # 对应limits的最大值

      cpu: "800m"

      memory: 1Gi

    min: # 对应request的最小值

      cpu: "200m"

      memory: 200Mi

    type: Container

# Pod 中的容器的 cpu 的范围是 200m~800m

# Pod 中的容器的 memory 的范围是 200mi~1Gi

配置命名空间的最小和最大内存约束

apiVersion: v1

kind: LimitRange

metadata:

  name: mem-min-max-demo-lr

  namespace: default # 限制 default 命名空间 

spec:

  limits:

  - max:

      memory: 1Gi

    min:

      memory: 500Mi # Pod 中的容器的 memory 的范围是 500Mi~1Gi

    type: Container

为命名空间配置默认的内存请求和限制

apiVersion: v1

kind: LimitRange

metadata:

  name: mem-limit-range

  namespace: default # 限制 default 命名空间    

spec:

  limits:

  - default:

      memory: 512Mi

    defaultRequest:

      memory: 256Mi # 为命名空间配置默认的内存请求和限制

    type: Container

限制存储消耗

apiVersion: v1

kind: LimitRange

metadata:

  name: storagelimits

spec:

  limits:

  - type: PersistentVolumeClaim

    max:

      storage: 2Gi

    min:

      storage: 1Gi

 

​apiVersion: v1

kind: ResourceQuota

metadata:

  name: storagequota

spec:

  hard:

    persistentvolumeclaims: "5" # 限制 PVC 数目和累计存储容量

    requests.storage: "5Gi"

​

默认的 CPU 请求和限制

当您创建一个新的 Pod 并没有显式指定资源请求时，Kubernetes会使用

Default Request作为默认值。这可以帮助 Kubernetes 调度器决定在哪个节点上运行 Pod

如果您没有显式指定资源限制，Kubernetes会使用Default Limit作为默认值。这有助于确保容器不会无限制地使用资源

apiVersion: v1

kind: LimitRange

metadata:

  name: cpu-limit-range

  namespace: default # 限制 default 命名空间   

spec:

  limits:

  - default: # 可以与 max 一起设置

      cpu: 1

    defaultRequest:

      cpu: 500m # 声明了一个默认的 CPU 请求和一个默认的 CPU 限制

    type: Container

 实操

apiVersion: v1

kind: LimitRange

metadata:

  name: cpu-min-max-demo-lr

  namespace: test # 限制 default 命名空间

spec:

  limits:

  - max:  # 对应limits的最大值

      cpu: "800m"

      memory: 1Gi

    min: # 对应request的最小值

      cpu: "200m"

      memory: 200Mi

    type: Container

# Pod 中的容器的 cpu 的范围是 200m~800m

# Pod 中的容器的 memory 的范围是 200mi~1Gi

其中 Default 参考的是 min 和 max ，因为没有对 default 单独设置

[root@master cks]# kubectl get limits -n test

NAME                  CREATED AT

cpu-min-max-demo-lr   2023-11-06T11:42:17Z

[root@master cks]# kubectl describe limits -n test

Name:       cpu-min-max-demo-lr

Namespace:  test

Type        Resource  Min    Max   Default Request  Default Limit  Max Limit/Request Ratio

----        --------  ---    ---   ---------------  -------------  -----------------------

Container   cpu       200m   800m  800m             800m           -

Container   memory    200Mi  1Gi   1Gi              1Gi            -

sxpnp
关注
  • 21
    点赞
  • 踩
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Kubernetes中的资源限制
wanger5354的博客
12-23 1466
作者：乔克公众号：乔边故事原文链接：https://mp.weixin.qq.com/s/3FTq6UbgXZm7qDNGfKS7NQlimitRangeLimitRange有个好听的中文名字，叫"资源配置访问管理"。用过K8S的都知道，在默认情况下，K8S不会对Pod进行CPU和内存限制，这就意味着这个未被限制的Pod可以随心所欲的使用节点上的CPU和内存，如果某个Pod发生内存泄漏那么将是一个非常糟糕的事情。所以正常情况下，我们在部署Pod的时候都会把Requests和Limits加上，如下：apiVe
容器资源限制
qq_41296573的博客
05-10 962
1、资源限制 容器资源限制： resources.limits.cpu resources.limits.memory 容器使用的最小资源需求，作为容器调度时资源分配的依据： resources.requests.cpu resources.requests.memory CPU单位：可以写m也可以写浮点数，例：0.5=500m，1=1000m 资源限制案例： apiVersion: v1 kind: Pod metadata: labels: run: shenhua app
当 resources.limits.cpu 遇到 livenessProbe，进而导致 Pod 不断重启
cab5的博客
09-22 1176
K8资源管理，resources.limits.cpu，livenessProbe，Pod不断重启
EOS用户资源管理resource_limits深入解析
yhc166188的博客
12-06 677
简介 eos中用户资源分3类，1）ram，2）cpu，3）net，其中ram资源的获取主要通过变种的Bancor算法实现ram的自动定价，去中心化交易，具体的实现可以查看eosio.system合约中的exchange_state.cpp，用户的cpu跟net资源通过抵押eos来获取，抵押eos形成抵押权重相应为cpu_weight，net_weight，抵押的越多可以获取的资源越多，这跟ram...
profile的resource limits和资源计划resource_manager_plan的limit
cjh81378066的博客
06-19 636
profile 使用参数RESOURCE_LIMIT RESOURCE_LIMIT determines whether resource limits are enforced in database profiles ...
40 _ Kubernetes的资源模型与资源管理1
08-04
在Kubernetes中，资源模型和资源管理是其核心功能之一，它允许用户有效地调度和管理容器化的应用程序。Kubernetes作为一个强大的容器编排平台，提供了一套完善的机制来确保应用在集群中的高效运行。本文将深入探讨...
C语言头文件 LIMITS.H
06-12
C语言头文件 LIMITS.HC语言头文件 LIMITS.HC语言头文件 LIMITS.HC语言头文件 LIMITS.HC语言头文件 LIMITS.HC语言头文件 LIMITS.HC语言头文件 LIMITS.HC语言头文件 LIMITS.HC语言头文件 LIMITS.HC语言头文件 LIMITS....
kubernetes常用命令表
最新发布
02-19
`kubectl create` 命令用于创建各种 Kubernetes 资源。 ##### 6.1 语法： ```shell $ kubectl create (-f FILENAME | TYPE NAME) [--dry-run=bool] ... ``` #### 七、kubectl create clusterrole 创建 ClusterRole...
40 Kubernetes的资源模型与资源管理.pdf
09-18
Kubernetes作为当前最流行的容器编排平台，其核心功能之一就是对容器应用进行资源管理和调度。在Kubernetes系统中，资源模型定义了如何使用和分配资源，以及如何在集群的多个Pod之间实现资源的平衡。一个关键点是，...
kubectl-resources:用于访问Kubernetes资源请求，限制和使用的插件
05-10
Kubectl资源插件 用于访问Kubernetes资源请求，限制和使用情况的插件。安装go get github.com/howardjohn/kubectl-resources 用法Plugin to access Kubernetes resource requests, limits, and usage.Usage: kubectl...
11. K8S资源限制，多账户管理及网络实现
xiaoyizi311的博客
11-14 3160
1. Kubernetes pod、container与namespace资源限制 CPU 以核心（毫核，1核=1000毫核，500m=0.5核）为单位。 memory 以字节为单位。 requests 为kubernetes scheduler执行pod调度时node节点至少需要拥有的资源。 limits 为pod运行成功后最多可以使用的资源上限。 1.1 对单个容器的CPU及memory实现资源限制 https://kubernetes.io/zh/docs/tasks/co
Kubernetes 准入控制插件 资源配额 ResourceQuota
小楼一夜听春雨，深巷明朝卖杏花
07-01 3730
资源配额 ResourceQuota 当多个团队、多个用户共享使用K8s集群时，会出现不均匀资源使用，默认情况下先到先得，这时可以通过ResourceQuota来对命名空间资源使用总量做限制，从而解决这个问题。 使用流程：k8s管理员为每个命名空间创建一个或多个ResourceQuota对象，定义资源使用总量，K8s会跟踪命名空间资源使用情况，当超过定义的资源配额会返回拒绝。 ResourceQuota功能是一个准入控制插件，默认已经启用。 还可以基于存储类来控制PVC请求的总量。 计算资源配
【k8s】——资源限制
汤庆
05-06 2057
一、前言 kubernetes最大的优势之一：它能够有效地利用计算资源。对于资源的使用，k8s本身支持资源的配置。在K8s中定义Pod中运行容器有两个维度的限制： 　1. 资源需求：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。 　　　如： Pod运行至少需要2G内存，1核CPU 2. 资源限额：即运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，...
kubernetes CKS 2.3 资源配额 ResourceQuota
cloud_engineer的博客
07-01 251
kubernetes 资源配额 ResourceQuota
k8s开发基础-Container的resources limit和request
longway111的博客
03-11 1889
记录一下： request请求 的值 小于limits限制值，对象有cpu和memory， 比较简单没什么好说的。至于分配到哪个节点，这个可以看container的元数据。 'resources': {'limits': {'cpu': '0.5', 'memory': '500Mi'}, ...
深入理解Kubernetes资源限制：内存
cxu123321的博客
09-11 942
深入理解Kubernetes资源限制：内存 写在前面 当我开始大范围使用Kubernetes的时候，我开始考虑一个我做实验时没有遇到的问题：当集群里的节点没有足够资源的时候，Pod会卡在Pending状态。你是没有办法给节点增加CPU或者内存的，那么你该怎么做才能将这个Pod从这个节点拿走？最简单的办法是添加另一个节点，我承认我总是这么干。最终这个策略无法发挥出Kubernetes最重要的一个能力：即它优化计算资源使用的能力。这些场景里面实际的问题并不是节点太小，而是我们没有仔细为Pod计算过资源限制。
K8S（五）—命名空间与资源配额
qq_51010919的博客
12-13 1667
Kubernetes（K8s）的命名空间（Namespace）是用于在集群中对资源进行逻辑隔离和分类的一种机制。它可以将集群内的资源划分为不同的组，并且每个命名空间内的资源都有一个唯一的名称。命名空间可以帮助团队将不同的项目、环境或应用程序从彼此中隔离开来，以及更好地管理资源。命名空间允许将集群内的资源进行逻辑隔离和资源分组。每个命名空间内部的资源（例如Pod、Service、ReplicaSet等）都具有唯一的名称，但在不同的命名空间中可以有相同名称的资源。
Kubernetes—资源配额
xiayping的博客
07-24 189
Kubernetes的资源配额相关介绍与使用
K8S资源配额概念和操作详解
bajiucoding
04-21 2161
多用户或者多团队共享集群时，管理员可以通过资源配额的方式来管理各个团队或者用户可使用资源的额度。 ResourceQuota对象用于定义资源配额。可以限制对象数量，也可以限制计算资源。 资源配额有如下工作方式： ​ 1、不同团队在各自命名空间下工作。软性约束 ​ 2、每个命名空间都可以有自己的一个或多个ResourceQuota对象，由集群管理员创建。 ​ 3、在命名空间中创建资源如Pod、Service时，如果超过配额，请求会报错 ​ 4、命名空间下计算资源被启用时，cpu memeory ，必须同时有
Kubernetes QoS：配置与测试Pod资源限制
"Kubernetes服务质量试验手册1主要涵盖了配置Pod的资源配额、测试内存限制以及测试节点资源限额的内容。在Kubernetes集群中，服务质量（QoS，Quality of Service）是确保应用性能的关键因素，它通过设定Pod的资源...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值