微信公众号:运维发展故事,作者:双冬

1.概述

从两个重要的 Pod 参数开始:CPU 请求和内存请求。大多数情况下,我们在定义 Pod 时并没有定义这两个参数,Kubernetes 假设 Pod 需要的资源非常少,并且可以在任何可用的 ode 上调度。这样,如果集群中的计算资源不够充足,集群中 Pod 负载的突然增加会导致 Node 的资源严重不足。

为了避免系统挂起,Node 选择“清理”一些 Pod 以释放资源,此时每个 Pod 都可能成为受害者。但是,有些 Pod 的职责比其他 Pod 更重要,例如与数据存储、登录和查询平衡相关的职责。即使系统资源严重不足,也需要保证这些 Pod 能够存活。 Kubernetes 中这种安全机制的核心如下。

  • 通过资源配额保证不同的Pod只能占用指定的资源

  • 允许集群资源过度分配,提高集群资源利用率

  • 对 Pod 进行分类,保证不同级别的 Pod 具有不同的服务质量(QoS)。资源不足时会清理低级别的 Pod,以保证较高级别的 Pod 稳定运行

Kubernetes 集群中的节点提供计算资源,计算资源是可以应用、分配和使用的可衡量的基础资源,与 Pod 和 Services 等 API 资源区别开来。目前,Kubernetes集群中的计算资源主要包括CPU、GPU和内存。大多数通用应用程序不支持 GPU。因此,本文重点讨论CPU和内存的资源管理问题。

CPU 和 Memory 都是 Pod 使用的,所以在配置 Pod 的时候,可以通过参数 CPU Request 和 Memory Request 来指定每个容器需要多少 CPU 和 Memory。 Kubernetes 根据 Request 的值寻找资源充足的 Node 来调度 Pod,如果没有,调度失败。

2.Pod资源使用规范

我们知道,一个 pod 使用的 CPU 和 Memory 是动态的量,正好是一个范围,并且与它的负载密切相关:随着负载的增加,CPU 和 Memory 的使用也会增加。因此,最准确的说法是,一个进程使用 0.1 到 1 个 CPU,其内存占用为 500 MB 到 1 GB。 Kubernetes 对应的 OD 容器对 CPU 和 Emory 有两个限制:

  • Requests 表示业务正常运行所需资源为预留资源

  • limit表示业务使用的最大资源 该值是最大资源使用值,不保证资源资源充足

其中,CPU以时间片调度可压缩资源,Memory为硬约束资源类型,limits对应资源量的上限,即允许使用该上限的最大资源量。由于 CPU 资源是可压缩的,进程永远不会突破上限,因此设置起来更容易。内存(一种不可压缩的资源)的限制设置是一个问题。如果设置为小,当一个进程在繁忙的业务期间尝试请求超过限制限制时,它将被 Kubernetes 杀死。因此,Memory的Request和Limit值需要根据流程的实际需要谨慎设置。如果不设置 CPU 或内存的限制值会怎样?在这种情况下,Pod 的资源使用具有弹性范围。我们不必对这两个 Limits 的合理值进行头脑风暴,但问题就来了。考虑以下示例:

Pod A 的 Memory Request 设置为 1GB,Node A 的空闲 Emory 为 1.2GB,满足 Pod A 的要求,因此将 Pod A 调度到 Node A。运行三天后,Pod A 的访问请求急剧增加,需要 1.5 GB 内存.节点 A 现在只剩下 200 MB 的内存。由于 Pod A 的新内存超过了系统资源,这种情况下 Pod A 会被 Kubernetes 杀死。

一个没有 Limit 或者只有一个 CPU Limit 或 Memory Limit 设置的 Pod 表面上看起来很有弹性,但实际上有四个参数的 Pod 处于相对不稳定的状态,只比没有的 Pod 稳定一点四个参数。理解这一点可以很容易地理解资源 QoS 问题。

如果我们有成百上千个不同的 Pod,为每个 Pod 手动设置这四个参数是有意义的,然后检查以确保它们已设置。比如内存超过 2GB 或者 CPU 两核的 Pod 就不能出现。最后还要手动检查 Pod 的资源使用量是否超过了不同租户(Namespace)的限制。为此,Kubernetes 提供了另外两个相关的对象,LimitRange 和 ResourceQuota,解决请求和限制参数的默认和合法范围等问题,后者解决租户资源配额的约束。

  • CPU规则如下:

单位 m,10mu003d0.01 Kernel, 1 Kernelu003d1000m

请求根据实际业务使用情况填写预估

限制 u003d 请求 * 20% + 请求

  • 内存规则如下:

单位 Mi 1024Miu003d1G 内存

请求根据实际业务使用情况填写预估

限制 u003d 请求 * 20% + 请求

3.Namespace资源管理规范

Business Actual Requests Limit 不超过总数的 80% 以防止业务翻转更新没有足够的资源来创建 Pod

3.1 多租户资源利用策略

通过 ResourceQuota 限制对应项目组的资源使用

![image.png](https://img-blog.csdnimg.cn/img_convert/474a4cb2e0e9a7f4b6ae82301a444a02.png#clientId=u36d536b9-7e10-4&from=paste&height=282&id=u1a93447b&margin=[object Object]&name=image.png&originHeight=564&originWidth=1242&originalType=binary&ratio=1&size=82895&status=done&style=none&taskId=u3e400703-5479-4048-9788-975ceb2a474&width=621)

3.2 资源消耗变化过程

![image.png](https://img-blog.csdnimg.cn/img_convert/770b4e74efd2495a7878b79bbbead74f.png#clientId=u36d536b9-7e10-4&from=paste&height=133&id=uc527a8bc&margin=[object Object]&name=image.png&originHeight=266&originWidth=1014&originalType=binary&ratio=1&size=69926&status=done&style=none&taskId=u07661404-7b56-435b-b5f4-832de2f1bc8&width=507)

4.资源监测和检查

4.1 资源使用监控

  • 命名空间请求资源使用情况

sum (kube_resourcequota{typeu003d"used",resourceu003d"requests.cpu"}) by (resource,namespace) / sum (kube_resourcequota{typeu003d"hard",resourceu003d"requests.cpu"})通过(资源,命名空间)* 100

sum (kube_resourcequota{typeu003d"used",resourceu003d"requests.memory"}) by (resource,namespace) / sum (kube_resourcequota{typeu003d"hard",resourceu003d"requests.memory"})通过(资源,命名空间)* 100

  • 命名空间限制资源使用

sum (kube_resourcequota{typeu003d"used",resourceu003d"limits.cpu"}) by (resource,namespace) / sum (kube_resourcequota{typeu003d"hard",resourceu003d"limits.cpu"})通过(资源,命名空间)* 100

sum (kube_resourcequota{typeu003d"used",resourceu003d"limits.memory"}) by (resource,namespace) / sum (kube_resourcequota{typeu003d"hard",resourceu003d"limits.memory"})通过(资源,命名空间)* 100

4.2 通过Grafana查看

![image.png](https://img-blog.csdnimg.cn/img_convert/60fc1ffab409e11bd8ff36c58d946a61.png#clientId=u36d536b9-7e10-4&from=paste&height=155&id=u09b8b5e9&margin=[object Object]&name=image.png&originHeight=310&originWidth=1558&originalType=binary&ratio=1&size=121527&status=done&style=none&taskId=u81163135-8e23-4ef8-8230-561e529246f&width=779)

  • CPU请求率

sum (kube_resourcequota{typeu003d"used",resourceu003d"requests.cpu",namespaceu003d~"$NameSpace"}) by (resource,namespace) / sum (kube_resourcequota{typeu003d"hard",resource u003d"requests.cpu",namespaceu003d~"$NameSpace"}) by (resource,namespace)

  • 内存请求率

sum (kube_resourcequota{typeu003d"used",resourceu003d"requests.memory",namespaceu003d~"$NameSpace"}) by (resource,namespace) / sum (kube_resourcequota{typeu003d"hard",resource u003d"requests.memory",namespaceu003d~"$NameSpace"}) by (resource,namespace)

  • CPU限制率

sum (kube_resourcequota{typeu003d"used",resourceu003d"limits.cpu"}) by (resource,namespace) / sum (kube_resourcequota{typeu003d"hard",resourceu003d"limits.cpu"})通过(资源,命名空间)

  • 内存限制率

sum (kube_resourcequota{typeu003d"used",resourceu003d"limits.memory"}) by (resource,namespace) / sum (kube_resourcequota{typeu003d"hard",resourceu003d"limits.memory"})通过(资源,命名空间)

4.3 查看集群内资源使用情况

  • 查看资源使用情况

[root@k8s-dev-slave04 yaml]# kubectl describe resourcequotas -n cloudchain--staging

名称:mem-cpu-demo

命名空间:cloudchain--staging

资源使用困难


limits.cpu 200m 500m

limits.memory 200Mi 500Mi

requests.cpu 150m 250m

requests.memory 150Mi 250Mi

  • 查看事件事件事件判断是否创建正确

[root@kevin ~]# kubectl 获取事件 -n 默认

最后出现的类型原因对象消息

46m 警告 FailedCreate replicaset/hpatest-57965d8c84 创建错误:pod“hpatest-57965d8c84-s78x6”被禁止:超出配额:mem-cpu-demo,请求:limits.cpuu003d400m,limits.memoryu003d400Mi,使用:限制。 cpuu003d200m,limits.memoryu003d200Mi, 受限:limits.cpuu003d500m,limits.memoryu003d500Mi

29m 警告 FailedCreate replicaset/hpatest-57965d8c84 创建错误:pod“hpatest-57965d8c84-5w6lk”被禁止:超出配额:mem-cpu-demo,请求:limits.cpuu003d400m,limits.memoryu003d400Mi,已使用:限制。 cpuu003d200m,limits.memoryu003d200Mi, 受限:limits.cpuu003d500m,limits.memoryu003d500Mi

13m 警告 FailedCreate replicaset/hpatest-57965d8c84 创建错误:pod“hpatest-57965d8c84-w2qvz”被禁止:超出配额:mem-cpu-demo,请求:limits.cpuu003d400m,limits.memoryu003d400Mi,已使用:限制。 cpuu003d200m,limits.memoryu003d200Mi, 受限:limits.cpuu003d500m,limits.memoryu003d500Mi

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐