Kubernetes-基于资源配额(ResourceQuota)进行资源管理

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
应用型负载均衡 ALB,每月750个小时 15LCU
简介: 1、资源配额概述 当存在多个用户或团队共享数目国定的集群时,就需要考虑如果有人使用的资源可能会超出应有的份额带来的问题,资源配额(ResourceQuota)就是用来帮助集群管理员解决上述问题的工具。

1、资源配额概述


当存在多个用户或团队共享数目国定的集群时,就需要考虑如果有人使用的资源可能会超出应有的份额带来的问题,资源配额(ResourceQuota)就是用来帮助集群管理员解决上述问题的工具。在Kubernetes集群中通过 ResourceQuota 对象定义每个命名空间(namespace)的资源配额,从而实现资源消耗总量的限制。 资源配额有两个作用:1)可以按类型限制命名空间(namespace)下所创建对象的数量;2)限制所消耗计算资源的总量。

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

  • 不同的团队在不同的命名空间下工作。 目前这是是非必须的,后续计划通过ACL (Access Control List 访问控制列表) 使其变为强制性的。
  • 集群管理员为每个命名空间创建一个或多个资源配额对象。
  • 用户在命名空间下创建资源 (pods、 services等),同时配额系统会跟踪使用情况,来确保其不超过 资源配额中定义的硬性资源限额。
  • 如果资源的创建或更新违反了配额约束,则请求会失败,并返回 HTTP状态码 403 FORBIDDEN ,以及说明违反配额 约束的信息。
  • 如果命名空间下的计算资源 (如 cpumemory)的配额被启用,则用户必须为这些资源设定请求值(request) 和约束值(limit),否则配额系统将拒绝Pod的创建。
    提示: 可使用 LimitRange 准入控制器来为没有设置计算资源需求的Pod设置默认值。 作为示例,请参考 演练 来避免这个问题。

下面是使用命名空间和配额构建策略的示例:

  • 在具有 32 GiB 内存 和 16 核CPU资源的集群中, 允许A团队使用 20 GiB 内存 和 10 核的CPU资源, 允许B团队使用 10GiB 内存和 4 核的CPU资源, 并且预留 2GiB 内存和 2 核的CPU资源供将来分配。
  • 限制 “testing” 命名空间使用 1 核CPU资源和 1GiB 内存。 允许 “production”命名空间使用任意数量。

在集群容量小于各命名空间配额总和的情况下,可能存在资源竞争。 Kubernetes采用先到先服务的方式处理这类问题。无论是资源竞争还是配额的变更都不会影响已经创建的资源。资源配额的支持在很多Kubernetes版本中是默认开启的。 当 apiserver 的 --admission-control= 参数中包含 ResourceQuota 时,资源配额会被启用。当namespace中存在一个 ResourceQuota 对象时,该namespace即开始实施资源配额管理。 一个namespace中最多只应存在一个 ResourceQuota 对象

2、资源配额所能管理的资源类型

在Kuberners中,资源配额能够对计算资源(CPU和内存)、存储资源、以及对资源对象的数量进行管理。

2.1 计算资源配额

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

资源名称 描述
cpu 所有非终止状态的Pod中,其CPU需求总量不能超过该值。
limits.cpu 所有非终止状态的Pod中,其CPU限额总量不能超过该值。
limits.memory 所有非终止状态的Pod中,其内存限额总量不能超过该值。
memory 所有非终止状态的Pod中,其内存需求总量不能超过该值。
requests.cpu 所有非终止状态的Pod中,其CPU需求总量不能超过该值。
requests.memory 所有非终止状态的Pod中,其内存需求总量不能超过该值。

2.2 存储资源配额

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

资源名称 描述
requests.storage 所有的PVC中,存储资源的需求不能超过该值。
persistentvolumeclaims namespace中所允许的 PVC 总量。
<storage-class-name>.storageclass.storage.k8s.io/requests.storage 所有该storage-class-name相关的PVC中, 存储资源的需求不能超过该值。
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims namespace中所允许的该storage-class-name相关的PVC的总量。

例如,如果一个操作人员针对 “黄金” 存储类型与 “铜” 存储类型设置配额,操作员可以 定义配额如下:

  • gold.storageclass.storage.k8s.io/requests.storage: 500Gi
  • bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

2.3 对象数量配额

给定类型的对象数量可以被限制。 支持以下类型:

资源名称 描述
configmaps namespace下允许存在的configmap的数量。
persistentvolumeclaims namespace下允许存在的PVC的数量。
pods namespace下允许存在的非终止状态的pod数量。 如果pod 的 status.phase 为 Failed 或 Succeeded , 那么其处于终止状态。
replicationcontrollers namespace下允许存在的replication controllers的数量。
resourcequotas namespace下允许存在的 resource quotas 的数量。
services namespace下允许存在的service的数量。
services.loadbalancers namespace下允许存在的load balancer类型的service的数量。
services.nodeports namespace下允许存在的node port类型的service的数量。
secrets namespace下允许存在的secret的数量。

例如 pods 配额统计并保证单个namespace下创建 pods 的最大数量。用户可能希望在namespace中为pod设置配额,来避免有用户创建很多小的pod,从而耗尽集群提供的pod IP地址。

3、配额作用域

每个配额都有一组相关的作用域(scope),配额只会对作用域内的资源生效。当一个作用域被添加到配额中后,它会对作用域相关的资源数量作限制。 如配额中指定了允许(作用域)集合之外的资源,会导致验证错误。

范围 描述
Terminating 匹配 spec.activeDeadlineSeconds >= 0 的pod。
NotTerminating 匹配 spec.activeDeadlineSeconds is nil 的pod。
BestEffort 匹配”尽力而为(best effort)“服务类型的pod。
NotBestEffort 匹配非”尽力而为(best effort)“服务类型的pod。

BestEffort 作用域限制配额跟踪以下资源: pods

TerminatingNotTerminatingNotBestEffort 限制配额跟踪以下资源:

  • cpu
  • limits.cpu
  • limits.memory
  • memory
  • pods
  • requests.cpu
  • requests.memory

4、设置和查看资源配额示例

由于在资源配额是基于命名空间进行设置的,因此,在此示例中先创建一个名称为myspace的命名空间:

$ kubectl create namespace myspace

4.1 计算资源管理

下面是定义管理计算资源配额的YAML文件,在此文件中,资源配额管理的名称为computer-resources,pod的数量为4,cpu的需求数量为1核,cpu的限制数量为2核;内存的需求大小为1Gi,内存的限制大小为2Gi。

apiVersion: v1 
kind: ResourceQuota 
metadata: 
 name: compute-resources 
spec: 
 hard: 
 pods: "4" 
 requests.cpu: "1" 
 requests.memory: 1Gi 
 limits.cpu: "2" 
 limits.memory: 2Gi

通过下面的kubectl命令在myspaces命名空间下创建资源配额:

$ kubectl create -f ./compute-resources.yaml --namespace=myspace

在创建完资源配额后,通过执行下面的命令查看资源配额的详细信息:

$ kubectl describe quota compute-resources --namespace=myspace

Name: compute-resources 
Namespace: myspace 
Resource Used Hard -------- ---- ---- 
limits.cpu 0 2 
limits.memory 0 2Gi 
pods 0 4 
requests.cpu 0 1 
requests.memory 0 1Gi

4.1 资源对象数量管理

下面是定义管理资源对象数量配额的YAML文件,在此文件中,资源配额管理的名称为object-counts:

apiVersion: v1
kind: ResourceQuota
metadata:
 name: object-counts
spec:
 hard:
 configmaps: "10"
 persistentvolumeclaims: "4"
 replicationcontrollers: "20"
 secrets: "10"
 services: "10"
 services.loadbalancers: "2"

通过下面的kubectl命令在myspaces命名空间下创建资源配额:

$ kubectl create -f ./object-counts.yaml --namespace=myspace

在创建完资源配额后,通过执行下面的命令查看资源配额的详细信息:

$ kubectl describe quota object-counts --namespace=myspace 

Name: object-counts 
Namespace: myspace 
Resource Used Hard -------- ---- ---- 
configmaps 0 10 
persistentvolumeclaims 0 4
replicationcontrollers 0 20 
secrets 1 10 services 0 10 
services.loadbalancers 0 2

参考资料:

1.《资源配额》地址:https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/

本文转自中文社区-Kubernetes-基于资源配额(ResourceQuota)进行资源管理

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
6天前
|
JSON 运维 Kubernetes
|
2月前
|
存储 Kubernetes 数据中心
在K8S中,同⼀个Pod内不同容器哪些资源是共用的,哪些资源是隔离的?
在K8S中,同⼀个Pod内不同容器哪些资源是共用的,哪些资源是隔离的?
|
2月前
|
资源调度 Kubernetes 调度
Flink 细粒度资源管理问题之细粒度资源请求满足问题如何解决
Flink 细粒度资源管理问题之细粒度资源请求满足问题如何解决
|
2月前
|
资源调度 调度 流计算
Flink 细粒度资源管理问题之为不同的SSG配置资源如何解决
Flink 细粒度资源管理问题之为不同的SSG配置资源如何解决
|
2月前
|
存储 NoSQL 分布式数据库
Flink 细粒度资源管理问题之调整 slot 配置来提高资源利用效率如何解决
Flink 细粒度资源管理问题之调整 slot 配置来提高资源利用效率如何解决
|
2月前
|
边缘计算 人工智能 Kubernetes
边缘计算问题之理解 Kubernetes 节点资源的四层分配结构如何解决
边缘计算问题之理解 Kubernetes 节点资源的四层分配结构如何解决
23 1
|
2月前
|
存储 Kubernetes API
|
2月前
|
Kubernetes 监控 开发者
|
2月前
|
Kubernetes jenkins 持续交付
Jenkins 与 Kubernetes 的集成:实现高效的资源管理和自动化部署
【8月更文第31天】随着微服务架构的普及,Kubernetes 已经成为了容器编排的事实标准。Kubernetes 提供了一种强大的方式来管理容器化的应用程序,而 Jenkins 则是持续集成与持续部署(CI/CD)领域的一个重要工具。将 Jenkins 与 Kubernetes 集成,不仅可以充分利用 Kubernetes 的资源管理能力,还能通过 Jenkins 实现自动化构建、测试和部署,从而提高开发效率和部署速度。本文将详细介绍如何将 Jenkins 集成到 Kubernetes 环境中,并提供具体的代码示例。
233 0
|
2月前
|
Kubernetes Cloud Native 应用服务中间件
Kubernetes 自动伸缩策略:优化资源利用率
【8月更文第29天】在现代云原生环境中,应用的流量往往具有不可预测性。为了应对这种变化,Kubernetes 提供了多种自动伸缩机制来动态调整应用实例的数量和每个实例分配的资源。本文将深入探讨两种主要的自动伸缩工具:水平 Pod 自动伸缩器 (HPA) 和垂直 Pod 伸缩器 (VPA),并提供实际的应用示例。
72 0

热门文章

最新文章