一、前言

本文主要以下几方面介绍k8s中的资源配额-ResourceQuota:

  • ResourceQuota是什么

  • ResourceQuota出现背景

  • ResourceQuota配置解析

  • ResourceQuota如何使用

本文主要以下几方面介绍k8s中的资源限制-LimitRange:

  • LimitRange是什么
  • LimitRange出现背景
  • LimitRange配置解析
  • LimitRange如何使用

本文主要以下几方面介绍k8s中的服务质量-QoS:

  • 什么是QoS
  • QoS出现背景
  • QoS分类
  • QoS如何使用

二、ResourceQuota是什么

当多个用户或团队共享具有固定节点数目的集群时，人们会担心有人使用超过其基于公平原则所分配到的资源量。

资源配额是帮助管理员解决这一问题的工具。

资源配额，通过 ResourceQuota 对象来定义，对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。

资源配额的工作方式如下：

  • 不同的团队可以在不同的命名空间下工作。这可以通过 RBAC强制执行。
  • 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
  • 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况， 以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
  • 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。
  • 如果命名空间下的计算资源 （如 cpu 和 memory）的配额被启用， 则用户必须为这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。

注意:大部分Kubernetes版本默认开启了ResourceQuota，也可以在APIServer配置文件的--enable-admission-plugins参数中添加ResourceQuota开启。

三、ResourceQuota出现背景

ResourceQuota是Kubernetes中的一种资源限制机制，它用于对命名空间内的资源使用进行限制和配额控制。它的出现背景是为了解决以下问题：

  • 多租户隔离：在Kubernetes中，多个团队或用户可以在同一个集群中共享资源。为了确保每个命名空间或用户不会无限制地使用资源，需要一种机制来实现资源的隔离和限制。ResourceQuota提供了这样的能力，可以为每个命名空间设置资源使用的上限。
  • 防止资源滥用：资源滥用可能导致整个集群的性能下降或崩溃。通过设置ResourceQuota，可以限制每个命名空间或用户可以使用的资源数量，以防止某个应用程序或用户抢占过多的资源，从而保护集群的稳定性和可靠性。
  • 预测和控制成本：在云计算环境中，资源的使用与成本直接相关。通过设置ResourceQuota，可以根据团队或用户的需求和预算来限制资源使用，从而更好地预测和控制成本。

四、ResourceQuota配置解析

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-test
  labels:
    app: resourcequota
spec:
  hard:
    pods: 2
    requests.cpu: 0.5
    requests.memory: 512Mi
    limits.cpu: 5
    limits.memory: 16Gi
    configmaps: 2
    requests.storage: 40Gi
    persistentvolumeclaims: 20
    replicationcontrollers: 20
    secrets: 20
    services: 50
    services.loadbalancers: "2"
    services.nodeports: "10"

用户可以对给定命名空间下的可被请求的 计算资源总量进行限制。其中配额机制所支持的资源类型：

资源名称 描述
limits.cpu 所有非终止状态的 Pod，其 CPU 限额总量不能超过该值。
limits.memory 所有非终止状态的 Pod，其内存限额总量不能超过该值。
requests.cpu 所有非终止状态的 Pod，其 CPU 需求总量不能超过该值。
requests.memory 所有非终止状态的 Pod，其内存需求总量不能超过该值。
hugepages-<size> 对于所有非终止状态的 Pod，针对指定尺寸的巨页请求总数不能超过此值。
cpu 与 requests.cpu 相同。
memory 与 requests.memory 相同。

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

对有限的一组资源上实施一般性的对象数量配额也是可能的。

支持以下类型：

资源名称 描述
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 总数上限。

ResourceQuota作用于Pod，并且有命名空间限制！！！