【kubernetes系列】kubernetes之计算资源管理

资源类型

在 Kubernetes 中，Node 提供资源，而 Pod 使用资源。其中资源分为计算（CPU、Memory、GPU）、存储（Disk、SSD）、网络（Network Bandwidth、IP、Ports）。这些资源提供了应用运行的基础，正确理解这些资源以及集群调度如何使用这些资源，对于大规模的 Kubernetes 集群来说至关重要，不仅能保证应用的稳定性，还可以提高资源的利用率。在日常工作中，我们一般比较关心其中的计算资源，包括CPU和内存。CPU 的单位是 core，memory 的单位是 byte。

可压缩资源

目前kubernetes支持的可压缩资源是CPU。它的特点是，当可压缩资源不足时，Pod 只会饥饿少用，但不会退出。CPU 资源的限制和请求以cpu为单位。Kubernetes 中的一个 cpu 就是一个核，就是一个逻辑CPU。一个核相当于1000个微核，即1=1000m，0.5=500m。

不可压缩资源

目前kubernetes支持的不可压缩资源是内存。它的特点是，当不可压缩资源不足时，Pod 就会因为 OOM被内核杀掉。内存的限制和请求以字节为单位。可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。

POD中的资源请求和资源限制

requests 资源请求 pod最低需求（表示Pod对资源的最小需求，因此在调度的时候会如果Node剩余的资源不能满足Pod的需求，则不会调度到对应的Node上。Scheduler调度的时候并不关注在调度时具体的资源使用情况，而是根据现存Pod的资源请求情况来进行调度。调度器首先将不符合请求的Node排除在外，然后在执行优选策略最后在选定pod）

由于 Pod 可以由多个 Container 组成，所以 CPU 和内存资源的限额，是要配置在每个Container的定义上的。这样，Pod 整体的资源配置，就由这些 Container的配置值累加得到。

示例

执行下面yaml的内容：

[root@k8s-m1 k8s-resource]# cat resource-limit-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: resource-limit-podnamespace: defaultlabels:name: myapp
spec:containers:- name: myappimage: ikubernetes/stress-ngcommand: ["/usr/bin/stress-ng","-c 1","--metrics-brief"]ports:- name: httpcontainerPort: 80resources:requests:memory: "128Mi"cpu: "200m"limits:memory: "512Mi"cpu: "500m"
[root@k8s-m1 k8s-resource]# kubectl apply  -f resource-limit-pod.yaml 
pod/resource-limit-pod created

查看结果：

[root@k8s-m1 k8s-resource]# kubectl exec -it resource-limit-pod -- top
Mem: 7805096K used, 202092K free, 6444K shrd, 2104K buff, 4575292K cached
CPU:   3% usr   1% sys   0% nic  88% idle   6% io   0% irq   0% sirq
Load average: 0.14 0.55 0.71 3/1509 33PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND6     1 root     R     6892   0%  15   2% {stress-ng-cpu} /usr/bin/stress-ng -c 1 --metrics-brief1     0 root     S     6244   0%   9   0% /usr/bin/stress-ng -c 1 --metrics-brief29     0 root     R     1500   0%   9   0% top

我们看到CPU占用是3%，为什么呢？因为我的集群node都是是16个core。我们最大限制是0.5核。所以应该是0.5/16≈3.1%。

Request和Limits

基于Requests和Limits的Pod调度机制

  • 调度器在调度时，首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和，不超过该节点能提供给Pod使用的CPU和Memory的最大容量值；
  • 即使某节点上的实际资源使用量非常低，但是已运行Pod配置的Requests值的总和非常高，再加上需要调度的Pod的Requests值，会超过该节点提供给Pod的资源容量上限，这时Kubernetes仍然不会将Pod调度到该节点上。如果Kubernetes将Pod调度到该节点上，之后该节点上运行的Pod又面临服务峰值等情况，就可能导致Pod资源短缺；

Requests和Limits的背后机制

kubelet在启动Pod的某个容器时，会将容器的Requests和Limits值转化为相应的容器启动参数传递给容器执行器。如果是docker 容器：

  • spec.container[].resources.requests.cpu: 转化为docker 的–cpu-share；
  • spec.container[].resources.limits.cpu: 转为docker的–cpu-quota；
  • spec.container[].resources.requests.memory: 提供给Kubernetes调度器作为调度和管理的依据，不会作为任何参数传递给Docker；
  • spec.container[].resources.limits.memory： 会转为–memory；
    在这里插入图片描述

QoS（服务质量等级）

Kubernetes是根据Pod的Requests和Limits配置来实现针对Pod的不同级别的资源服务质量控制。当 Kubernetes 创建一个 Pod 时，它就会给这个 Pod 分配一个 QoS 等级。

QoS分类

  • Guaranteed：pod里的每一个container都同时设置了CPU和内存的requests和limits 而且值必须相等。（这类的pod是最高优先级）
  • Burstable：pod至少有一个container设置了cpu或内存的requests和limits，且不满足 Guarantee 等级的要求。即内存或CPU的值设置的不同。（中等优先级）
  • BestEffort：没有任何一个容器设置了requests或limits的属性。（最低优先级）

应用场景：当宿主机资源紧张的时候，kubelet会根据服务质量等级对pod进行eviction，即驱逐pod进行资源回收。

Requests和Limits资源配置特点

  • 如果Pod配置的Requests值等于Limits值，那么该Pod可以获得的资源是完全可靠的；
  • 如果Pod的Requests值小于Limits值，那么该Pod获得的资源可分成两部分；

完全可靠的资源，资源量的大小等于Requests值；
不可靠的资源，资源量最大等于Limits与 Requests的差额，这份不可靠的资源能够申请到多少，取决于当时主机上容器可用资源的余量；通过这种机制，Kubernetes可以实现节点资源的超售（Over Subscription），超售机制能有效提高资源的利用率，同时不会影响容器申请的完全可靠资源的可靠性。

调度策略的影响

  • Kubernetes的kubelet通过计算Pod中所有容器的Requests的总和来决定对Pod的调度；
  • 不管是CPU还是内存，Kubernetes调度器和kubelet都会确保节点上所有Pod的Requests的总和不会超过在该节点上可分配给容器使用的资源容量上限；

示例

https://www.cnblogs.com/wtzbk/p/15816291.html

Guaranteed样例

[root@k8s-m1 k8s-resource]# cat   guaranteed-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: guaranteed-podlabels:name: nginx
spec:containers:- name: myappimage: nginxports:- name: httpcontainerPort: 80resources:requests:memory: "512Mi"cpu: "500m"limits:memory: "512Mi"cpu: "500m"
[root@k8s-m1 k8s-resource]# kubectl apply -f guaranteed-pod.yaml 
pod/guaranteed-pod created

结果：

[root@k8s-m1 k8s-resource]# kubectl describe po guaranteed-pod 
......
Volumes:default-token-glxls:Type:        Secret (a volume populated by a Secret)SecretName:  default-token-glxlsOptional:    false
QoS Class:       Guaranteed
Node-Selectors:  <none>
.....

更详细检查
1）查看该pod被分配到的节点

[root@k8s-m1 k8s-resource]# kubectl get pod -o wide
NAME                 READY   STATUS    RESTARTS   AGE     IP              NODE     NOMINATED NODE   READINESS GATES
guaranteed-pod       1/1     Running   0          8s      10.244.11.39    k8s-m3   <none>           <none>

2）然后到k8s-m3上去查看这个pod里面启动的容器的资源限制是否生效

[root@k8s-m3 ~]# docker ps |grep guaranteed
434a95e67849   nginx                                               "/docker-entrypoint.…"   6 minutes ago   Up 6 minutes             k8s_myapp_guaranteed-pod_default_7095c77a-7c31-4a0a-ba1c-c347c690cfe8_0
32a0053da67b   registry.aliyuncs.com/google_containers/pause:3.2   "/pause"                 6 minutes ago   Up 6 minutes             k8s_POD_guaranteed-pod_default_7095c77a-7c31-4a0a-ba1c-c347c690cfe8_0#查看主容器的信息
[root@k8s-m3 ~]# docker inspect  434|egrep -i 'cpu|mem'"CpuShares": 512,"Memory": 536870912,"NanoCpus": 0,"CpuPeriod": 100000,"CpuQuota": 50000,"CpuRealtimePeriod": 0,"CpuRealtimeRuntime": 0,"CpusetCpus": "","CpusetMems": "","KernelMemory": 0,"KernelMemoryTCP": 0,"MemoryReservation": 0,"MemorySwap": 536870912,"MemorySwappiness": null,"CpuCount": 0,"CpuPercent": 0,
关注Memory、CpuPeriod、CpuQuota这三个值

3）通过cgroup的相关信息查看
从上面的结果实际上我们就可以看到这个容器的一些资源情况，Pod 上的资源配置最终也还是通过底层的容器运行时去控制 CGroup 来实现的，我们可以进入如下目录查看 CGroup 的配置，该目录就是 CGroup 父级目录，而 CGroup 是通过文件系统来进行资源限制的，所以我们上面限制容器的资源就可以在该目录下面反映出来：
##查看CPU的限制##

[root@k8s-m3 ~]# docker exec -it 434 /bin/bash
root@guaranteed-pod:/# cd /sys/fs/cgroup/cpu/
root@guaranteed-pod:/sys/fs/cgroup/cpu# cat cpu.cfs_period_us 
100000
root@guaranteed-pod:/sys/fs/cgroup/cpu# cat cpu.cfs_quota_us  
50000
root@guaranteed-pod:/sys/fs/cgroup/cpu# 
#反向计算出--cpus参数
#cpu.cfs_quota_us / cpu.cfs_period_us = cpu的限制
50000/100000=0.5核（也就是500m）##查看内存的限制##
root@guaranteed-pod:/sys/fs/cgroup/cpu# cd /sys/fs/cgroup/memory/
root@guaranteed-pod:/sys/fs/cgroup/memory# cat memory.limit_in_bytes 
536870912
root@guaranteed-pod:/sys/fs/cgroup/memory# 内存的计算方法为：536870912÷1024÷1024÷1024 = 0.5（G）

Burstable样例

[root@k8s-m1 k8s-resource]# cat  burstable-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: burstable-podlabels:name: nginx
spec:containers:- name: myappimage: nginxports:- name: httpcontainerPort: 80resources:requests:memory: "256Mi"cpu: "200m"limits:memory: "512Mi"cpu: "500m"[root@k8s-m1 k8s-resource]# kubectl apply  -f burstable-pod.yaml 
pod/burstable-pod created

结果：

[root@k8s-m1 k8s-resource]# kubectl describe po burstable-pod 
......
Volumes:default-token-glxls:Type:        Secret (a volume populated by a Secret)SecretName:  default-token-glxlsOptional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
......

上面Burstable的示例中，可以看到limit和Request都设置了的，且limit大于Request。大家可以自行测试只设置其中一个的Qos等级。当只设置Request时，系统是不会补全limit的相关配置，也是Burstable。而当只设置limit时，系统会自动补全Request的相关配置和limit一样，Qos是Guaranteed类型。

BestEffort样例

[root@k8s-m1 k8s-resource]# cat  besteffort-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: besteffort-podlabels:name: myapptier: appfront
spec:containers:- name: httpimage: nginxports:- name: httpcontainerPort: 80[root@k8s-m1 k8s-resource]# kubectl apply -f besteffort-pod.yaml 
kupod/besteffort-pod created

结果：

[root@k8s-m1 k8s-resource]# kubectl describe po besteffort-pod 
......
Volumes:default-token-glxls:Type:        Secret (a volume populated by a Secret)SecretName:  default-token-glxlsOptional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
.....

总结：
CPU是可以压缩资源，所以在CPU不够的时候会压缩限流。而内存是不可压缩资源，所以QoS主要用于内存限制。

  • BestEffort Pod的优先级最低，在这类Pod中运行的进程会在系统内存紧缺时被第一优先杀掉。当然，从另外一个角度来看，BestEffort Pod由于没有设置资源Limits，所以在资源充足时，它们可以充分使用所有的闲置资源;
  • Burstable Pod的优先级居中，这类Pod初始时会分配较少的可靠资源，但可以按需申请更多的资源。当然，如果整个系统内存紧缺，又没有BestEffort容器可以被杀掉以释放资源，那么这类Pod中的进程可能会被杀掉;
  • Guaranteed Pod的优先级最高，而且一般情况下这类Pod只要不超过其资源Limits的限制就不会被杀掉。当然，如果整个系统内存紧缺，又没有其他更低优先级的容器可以被杀掉以释放资源，那么这类Pod中的进程也可能会被杀掉;

OOM计分系统

在这里插入图片描述
如果kubelet无法在系统OOM之前回收足够的内存，则oom_killer 会根据内存使用比率来计算oom._score, 将得出的结果和oom_score_adj相加，最后得分最高的Pod会被首先驱逐。这个策略的思路是，QoS最低且相对于调度的Request来说消耗最多内存的Pod会被首先清除，来保障内存的回收。这意味着与Burstable或Guaranteed QoS类别的容器相比，BestEffort这种类别的容器被杀死的可能性更高。
与Pod驱逐不同，如果一个Pod的容器被oom杀掉，是可能被 kubelet根据restartpolicy重启的。

容器中的JVM资源限制

在Kubernetes环境中部署Java程序不一会就重启了，这意味着你的pod是不健康的。然后我们可以通过describe去查看一下重启的原因。发现是因为Pod超出了资源限制被kill掉，在日志最后一行会出现一个kill的字段。为什么Kubernetes会kill掉，因为它超出了Kubernetes对Pod的资源限制。默认情况下Docker容器会使用宿主机所有的资源，但如果不做资源限制，会影响整个宿主机。然后整个宿主机资源不够会实现飘移，会转移到其他主机上，然后再异常，可能会起到一种雪崩的效应，所以一般我们都是要做Pod资源限制。如果Java容器中未设置JVM的-Xmx（最大的堆内存使用）参数，一旦这个Pod的使用内存超出Kubernetes的limits限制，Kubernetes就会把它杀掉并重启一个新的Pod。所以在实际使用中，JVM中的这个值建议要比limits要小一点，小个10%左右，因为超过这个limits限制就可能会被杀死掉再重新起一个Pod。

更多关于kubernetes的知识分享，请前往博客主页。编写过程中，难免出现差错，敬请指出

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/29502.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

EasyCVR告警类型设置后首页需要刷新才能更新的问题优化

EasyCVR告警类型设置后首页需要刷新才能更新的问题优化

EasyCVR视频融合平台基于云边端一体化架构&#xff0c;可支持多协议、多类型设备接入&#xff0c;包括&#xff1a;NVR、IPC、视频编码器、无人机、车载设备、智能手持终端、移动执法仪等。平台具有强大的数据接入、处理及分发能力&#xff0c;可在复杂的网络环境中&#xff0c…
阅读更多...
Appium-Python-Client 源码剖析 (一) driver 的元素查找方法

Appium-Python-Client 源码剖析 (一) driver 的元素查找方法

目录 前言 源码版本:0.9 结构图&#xff1a; mobileby.py appium 的 webdriver.py selenium 的 webdriver.py seleniumdriver appiumdriver 前言 Appium-Python-Client是一个用于Python语言的Appium客户端库&#xff0c;它提供了丰富的API和功能&#xff0c;用于编写和…
阅读更多...
cocosCreator 3.6以上接入腾迅Bugly 捕捉JS错误 Android

cocosCreator 3.6以上接入腾迅Bugly 捕捉JS错误 Android

cocosCreator3.6以上接入Bugly上报其实很简单&#xff0c;不需要网上那么多弯弯绕&#xff0c;三须三步走。 1. 按照官网方式接入android的bugly 2. android端写一个Bugly上报管理类 3. 修改你工程目录下native\engine\common\Classes\目录下的Game.h, Game.cpp两个文件&…
阅读更多...
字符串编程练习（C++）

字符串编程练习（C++）

ex1 字符串变形 描述 对于一个长度为 n 字符串&#xff0c;我们需要对它做一些变形。 首先这个字符串中包含着一些空格&#xff0c;就像"Hello World"一样&#xff0c;然后我们要做的是把这个字符串中由空格隔开的单词反序&#xff0c;同时反转每个字符的大小写。…
阅读更多...
JS-27 前端数据请求方式；HTTP协议的解析；JavaScript XHR、Fetch的数据请求与响应函数；前端文件上传XHR、Fetch

JS-27 前端数据请求方式；HTTP协议的解析；JavaScript XHR、Fetch的数据请求与响应函数；前端文件上传XHR、Fetch

目录 1_前端数据请求方式1.1_前后端分离的优势1.2_网页的渲染过程 – 服务器端渲染1.3_网页的渲染过程 – 前后端分离 2_HTTP协议的解析2.1_HTTP概念2.2_网页中资源的获取2.3_HTTP的组成2.4_HTTP的版本2.5_HTTP的请求方式2.6_HTTP Request Header2.7_HTTP Response响应状态码 3…
阅读更多...
多媒体开发之cgo

多媒体开发之cgo

go语言作为近十年来优秀的现代开发语言的代表&#xff0c;由于继承了c语言的简洁和很多现代语言的表达方式&#xff0c;在广泛的应用场景中得到众多爱好者的喜爱&#xff0c;如何将go和c、c进行联合开发&#xff0c;拓展整个开发生态&#xff0c;不用重复造轮子&#xff0c;掌握…
阅读更多...
P1403 [AHOI2005] 约数研究

P1403 [AHOI2005] 约数研究

题目描述 科学家们在 Samuel 星球上的探险得到了丰富的能源储备&#xff0c;这使得空间站中大型计算机 Samuel II 的长时间运算成为了可能。由于在去年一年的辛苦工作取得了不错的成绩&#xff0c;小联被允许用 Samuel II 进行数学研究。 小联最近在研究和约数有关的问题&…
阅读更多...
【redis】redis管道简述

【redis】redis管道简述

redis管道可以一次性发送多条命令。 命令示例如下&#xff1a; [xxxlocalhost ~]$ echo -e "set k4 99\nincr k4\nget k4" | nc localhost 6379 \OK :100 $3 100下面先简述一下这条命令的组成&#xff0c;再简述一下管道的常用场景和注意事项。 首先&#xff0c;|是…
阅读更多...
IDEA 搭建Android 开发环境

IDEA 搭建Android 开发环境

项目实战 废话不多说开始创建先第一个 Android 项目 步骤一 FILE → New → Project 步骤二-选择 Android 项目模板 选那个安卓机器人，如果没有这个选项，需要升级IDEA版本或者安装安卓插件 选择*Basic Activity* Next-下一步 步骤三-项目初始化 名称、包名、安装位置自行调整…
阅读更多...
双电源并用问题与解决方案

双电源并用问题与解决方案

双电源并用问题 曾经有客户在电源模块应用过程中出现过这样的应用场景&#xff0c;如下图1所示。客户使用两路电源给后端电路进行供电&#xff0c;要求在不断电的情况下切换输入电源&#xff0c;此过程中发现后端电路会出现损坏。对各个节点波形进行分析后发现&#xff0c;在给…
阅读更多...
【C++】STL之list容器的模拟实现

【C++】STL之list容器的模拟实现

个人主页&#xff1a;&#x1f35d;在肯德基吃麻辣烫 分享一句喜欢的话&#xff1a;热烈的火焰&#xff0c;冰封在最沉默的火山深处。 文章目录 前言一、list的三个类的关系分析图vector和list的区别1.节点的成员变量以及构造函数2.list的迭代器 二、list的增删查改工作2.1inse…
阅读更多...
MFC第十六天 CFileDialog、CEdit简介、（线程）进程的启动，以及Notepad的开发(托盘技术--＞菜单功能)

MFC第十六天 CFileDialog、CEdit简介、（线程）进程的启动，以及Notepad的开发(托盘技术--＞菜单功能)

文章目录 CCommonDialogCFileDialogCEdit托盘技术进程的启动附录1:启动线程方式附录2:MFC对话框的退出过程 CCommonDialog 通用对话框 CCommonDialog 这些对话框类封装 Windows 公共对话框。 它们提供了易于使用的复杂对话框实现。 CFileDialog 提供用于打开或保存文件的标准对…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023