K8S如何限制资源使用

本文介绍几种在K8S中限制资源使用的几种方法。

资源类型

在K8S中可以对两类资源进行限制:cpu和内存。

CPU的单位有:

  • 正实数,代表分配几颗CPU,可以是小数点,比如0.5代表0.5颗CPU,意思是一 颗CPU的一半时间。2代表两颗CPU。
  • 正整数m,也代表1000m=1,所以500m等价于0.5

内存的单位:

  • 正整数,直接的数字代表Byte
  • kKKi,Kilobyte
  • mMMi,Megabyte
  • gGGi,Gigabyte
  • tTTi,Terabyte
  • pPPi,Petabyte

方法一:在Pod Container Spec中设定资源限制

在K8S中,对于资源的设定是落在Pod里的Container上的,主要有两类,limits控制上限,requests控制下限。其位置在:

  • spec.containers[].resources.limits.cpu
  • spec.containers[].resources.limits.memory
  • spec.containers[].resources.requests.cpu
  • spec.containers[].resources.requests.memory

举例:

apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: ... image: ... resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

方法二:在Namespace中限定

方法一虽然很好,但是其不是强制性的,因此很容易出现因忘记设定limits/request,导致Host资源使用过度的情形,因此我们需要一种全局性的资源限制设定,以防止这种情况发生。K8S通过在Namespace设定LimitRange来达成这一目的。

配置默认request/limit

如果配置里默认的request/limit,那么当Pod Spec没有设定request/limit的时候,会使用这个配置,有效避免无限使用资源的情况。

配置位置在:

  • spec.limits[].default.cpu,default limit
  • spec.limits[].default.memory,同上
  • spec.limits[].defaultRequest.cpu,default request
  • spec.limits[].defaultRequest.memory,同上

例子:

apiVersion: v1 kind: LimitRange metadata: name: <name> spec: limits: - default: memory: 512Mi cpu: 1 defaultRequest: memory: 256Mi cpu: 0.5 type: Container

配置request/limit的约束

我们还可以在K8S里对request/limit进行以下限定:

  • 某资源的request必须>=某值
  • 某资源的limit必须<=某值

这样的话就能有效避免Pod Spec中乱设limit导致资源耗尽的情况,或者乱设request导致Pod无法得到足够资源的情况。

配置位置在:

  • spec.limits[].max.cpulimit必须<=某值
  • spec.limits[].max.memory,同上
  • spec.limits[].min.cpurequest必须>=某值
  • spec.limits[].min.memory,同上

例子:

apiVersion: v1 kind: LimitRange metadata: name: <name> spec: limits: - max: memory: 1Gi cpu: 800m min: memory: 500Mi cpu: 200m type: Container
本文转自中文社区- K8S如何限制资源使用
<think>嗯,用户需要计算Kubernetes集群的CPU和内存使用率,这涉及到多个层面的监控数据采集和计算逻辑。从引用内容看,用户可能已经接触过metrics-server和资源分配率的概念,但需要更系统的计算方法。 用户提供的三个引用很有价值:引用[1]解释了CPU请求值(如500m)的本质是时间片分配,这关系到如何理解底层资源计量;引用[2]提到分配率与利用率的关键差异,说明用户可能遇到资源碎片问题;引用[3]则指向具体的工具链metrics-server。这些都需要整合进回答。 深层需求可能是:用户想优化集群资源使用(如引用[2]提到的低利用率问题),需要先建立准确的监控基线。因此除了基础公式,还要强调利用率与分配率的区别——这正是集群优化的核心痛点。 计算逻辑需要分层说明: 1 节点层:直接用kubectl top node获取原始数据最直观,但要注意背后是kubelet的cAdvisor采集数据 2 Pod层:需区分容器组内各容器的指标,特别是共享pause容器的影响 3 集群层:总和计算时不能简单相加,要考虑控制平面组件和未调度资源 内存计算相对简单,但CPU要强调时间片概念(如1000m=1核秒/秒)。特别要提醒用户:HPA和VPA依赖这些指标,如果计算不准会影响自动扩缩容。 最后补充监控工具时,考虑到用户可能后续需要优化,推荐了Prometheus生态和Kube-state-metrics——后者能提供资源请求值数据,正好与引用[1]的CPU请求概念衔接。 相关问题设计成阶梯式:从基础监控(问题1)到高级优化(问题2),再到碎片问题(问题3)和自动扩缩(问题4),覆盖用户可能的后续动作。特别是问题4直接关联引用[3]的metrics-server应用场景。</think>计算 Kubernetes 集群的 CPU 和内存资源使用率需要分层进行,主要涉及节点层、Pod/容器层和集群层。以下是详细的计算方法和步骤: --- ### **一、核心概念** 1. **资源请求(Requests)** Pod 向节点申请的最小资源量(如 `resource.cpu.requests=500m` 表示申请 0.5 核 CPU)[^1]。 2. **资源限制Limits)** Pod使用资源上限(如 `resource.cpu.limits=1` 表示最多使用 1 核 CPU)。 3. **实际使用量(Usage)** 通过监控工具实时采集的 CPU/内存消耗值。 --- ### **二、计算资源使用率的步骤** #### **1. 节点层资源使用率** 需先安装 **Metrics Server** 或 **Prometheus** 获取监控数据: ```bash # 安装 Metrics Server kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml ``` - **CPU 使用率计算** $$ \text{节点 CPU 使用率} = \frac{\sum \text{节点上所有 Pod 的实际 CPU 使用量}}{\text{节点总 CPU 核数}} \times 100\% $$ - **内存使用率计算** $$ \text{节点内存使用率} = \frac{\sum \text{节点上所有 Pod 的实际内存使用量}}{\text{节点总内存容量}} \times 100\% $$ **操作示例**: ```bash kubectl top node # 查看节点实时资源使用 ``` 输出示例: ``` NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% node-1 560m 28% 5.2Gi 65% ``` --- #### **2. Pod/容器层资源使用率** - **公式** $$ \text{Pod CPU 使用率} = \frac{\text{Pod 实际 CPU 使用量}}{\text{节点总 CPU 核数}} \times 100\% $$ $$ \text{Pod 内存使用率} = \frac{\text{Pod 实际内存使用量}}{\text{节点总内存容量}} \times 100\% $$ **操作示例**: ```bash kubectl top pod -n <命名空间> ``` --- #### **3. 集群层资源使用率** - **CPU 分配率(Allocation Rate)** $$ \text{CPU 分配率} = \frac{\sum \text{所有 Pod 的 CPU 请求量}}{\sum \text{所有节点 CPU 总量}} \times 100\% $$ - **CPU 利用率(Utilization)** $$ \text{CPU 利用率} = \frac{\sum \text{所有节点实际 CPU 使用量}}{\sum \text{所有节点 CPU 总量}} \times 100\% $$ - **内存同理**。 **示例场景**: 若集群总 CPU 为 100 核,所有 Pod 的 CPU 请求总和为 80 核,实际使用量为 15 核,则: - 分配率 = $80/100 \times 100\% = 80\%$ - 利用率 = $15/100 \times 100\% = 15\%$(反映资源闲置问题)[^2] --- ### **三、关键工具与监控方案** | 工具 | 作用 | |--------------------|----------------------------------------------------------------------| | **Metrics Server** | 提供基础的 `kubectl top` 命令,收集节点/Pod 的 CPU/内存使用量 [^3] | | **Prometheus** | 存储历史数据,支持自定义查询和告警(如计算日均利用率) | | **Grafana** | 可视化监控仪表盘(如展示集群利用率趋势) | | **Kube-state-metrics** | 监控资源请求/限制等元数据(用于计算分配率) | --- ### **四、常见问题与优化建议** 1. **利用率远低于分配率** - 原因:资源请求过高或调度碎片化(如大规格 Pod 无法调度)[^2] - 优化:使用 **Vertical Pod Autoscaler (VPA)** 动态调整请求值。 2. **监控数据不准** - 确保 Metrics Server 配置正确(尤其注意 `--kubelet-insecure-tls` 参数)。 3. **资源碎片问题** - 采用 **Descheduler** 重平衡 Pod,或使用 **Bin Packing** 调度策略提高密度。 --- ### **五、高级监控指标示例(PromQL)** ```promql # 集群 CPU 利用率 sum(rate(container_cpu_usage_seconds_total{container!=""}[5m])) / sum(kube_node_status_capacity_cpu_cores) * 100 # 集群内存利用率 sum(container_memory_working_set_bytes{container!=""}) / sum(kube_node_status_capacity_memory_bytes) * 100 ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值