k8s部署-32-k8s的集群资源管理cpu、memory（上）

k8s部署-32-k8s的集群资源管理cpu、memory（上）

可控资源

首先我们要知道k8s能对哪些资源进行控制，如下图：

如何来分配这些资源呢，我们需要提前规划好一个值吧，在k8s中主要关注两个值，一个是requests，一个是limit；

requests：希望被分配到的额度limits：最大被分配到的额度

大概心里有个数了，接下来实操一波。

验证资源划分

1、先查看当前集群有多少资源；

[root@node1 ~]# kubectl get nodeNAME STATUS ROLES AGE VERSIONnode2 Ready 18d v1.20.2node3 Ready 18d v1.20.2[root@node1 ~]# kubectl describe node node2# 省略部分输出# 可以看到指定节点的内存和cpu以及其他信息的使用占比Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 550m (68%) 100m (12%) memory 190Mi (15%) 390Mi (31%) ephemeral-storage 0 (0%) 0 (0%) hugepages-1Gi 0 (0%) 0 (0%) hugepages-2Mi 0 (0%) 0 (0%)Events: [root@node1 ~]#

2、创建一个限制cpu和内存的pod，我们看一下，此pod的yaml文件，基于上一篇中，我们只添加了内存和cpu的限制，在deployment模块中。

[root@node1 ~]# cd namespace/[root@node1 namespace]# mkdir requests[root@node1 namespace]# cd requests/[root@node1 requests]# vim request-web-demo.yaml #deployapiVersion: apps/v1kind: Deploymentmetadata: name: tomcat-demospec: selector: matchLabels: app: tomcat-demo replicas: 1 template: metadata: labels: app: tomcat-demo spec: containers: - name: tomcat-demo image: registry.cn-hangzhou.aliyuncs.com/liuyi01/tomcat:8.0.51-alpine ports: - containerPort: 8080 resources: requests: memory: 100Mi cpu: 100m limits: memory: 100Mi cpu: 200m---#serviceapiVersion: v1kind: Servicemetadata: name: tomcat-demospec: ports: - port: 80 protocol: TCP targetPort: 8080 selector: app: tomcat-demo---#ingressapiVersion: extensions/v1beta1kind: Ingressmetadata: name: tomcat-demospec: rules: - host: tomcat.yunweijia.com http: paths: - path: backend: serviceName: tomcat-demo servicePort: 80[root@node1 requests]# kubectl apply -f request-web-demo.yaml deployment.apps/tomcat-demo configuredservice/tomcat-demo unchangedingress.extensions/tomcat-demo configured[root@node1 requests]#

3、验证下配置是否生效

[root@node1 requests]# kubectl get pods -o wide | grep tomcattomcat-demo-577d557cb4-s8rv9         1/1     Running   3          2m     10.200.104.49   node2              [root@node1 requests]# # 从上面可以看到运行在了node2节点上，登录到node2上[root@node2 yunweijia]# crictl psCONTAINER IMAGE CREATED STATE NAME ATTEMPT POD IDb9de73c75753c 2304e340e2384 About a minute ago Running tomcat-demo 3 c0b7dd83c1639cf5d8452030ba 67da37a9a360e 6 minutes ago Running coredns 22 218c789a30d84bc99cc78dd418 2673066df2c99 6 minutes ago Running deploy-springboot 2 321a93fee22d59a1ca81b1eb60 f2f70adc5d89a 6 minutes ago Running my-nginx 23 a1ae445fa42264edbc35f14aff 7a71aca7b60fc 6 minutes ago Running calico-node 22 da37be9dbe48be8daddbca434d 90f9d984ec9a3 6 minutes ago Running node-cache 22 cda9b13a11528[root@node2 yunweijia]# crictl inspect b9de73c75753c# 忽略部分内容，然后主要关注下linux那块内容 "linux": { "resources": { "devices": [ { "allow": false, "access": "rwm" } ], "memory": { "limit": 104857600 }, "cpu": { "shares": 102, "quota": 20000, "period": 100000 } },# 可以看到内存是104857600，我们配置额是100Mi，计算方式是：# 100*1024*1024=104857600# 然后看下CPU是102，那么他的计算方式如下：# 100/1000=0.1 # 1024*0.1约等于102，他是发生资源抢占的时候一个权重，决定资源分配比例

4、模拟下在容器中占用超出限制的内存会怎样；

[root@node1 requests]# kubectl exec -it tomcat-demo-577d557cb4-s8rv9 -- bashbash-4.4# vi test.sh  # 写一个占用内存的测试脚本试试看#!/bin/bashstr="woshi yunweijia, nihaoya, nihaoya, nihaoya."while [ TRUE ]do str="$str$str" echo "++++" sleep 0.1donebash-4.4# sh test.sh ++++++++++++++++++++++++++++++++++++command terminated with exit code 137[root@node1 requests]# kubectl get podsNAME READY STATUS RESTARTS AGEdeploy-springboot-5dbfc55f78-mpg69 1/1 Running 2 2d7hnginx-ds-q2pjt 1/1 Running 18 13dnginx-ds-zc5qt 1/1 Running 23 19dtomcat-demo-577d557cb4-s8rv9 0/1 OOMKilled 5 16m[root@node1 requests]## 竟然自己退出了？说明内存被占用之后这个pod会存在异常

‍

然后稍等几分钟，不用做任何操作，会自动恢复；

[root@node1 requests]# kubectl get podsNAME READY STATUS RESTARTS AGEdeploy-springboot-5dbfc55f78-mpg69 1/1 Running 2 2d8hnginx-ds-q2pjt 1/1 Running 18 13dnginx-ds-zc5qt 1/1 Running 23 19dtomcat-demo-577d557cb4-s8rv9 1/1 Running 7 25m[root@node1 requests]#

然后我们登录系统查看下，是不是把占用内存的程序给kill掉了呢？

[root@node1 requests]# kubectl exec -it tomcat-demo-577d557cb4-s8rv9 -- bashbash-4.4# cat test.shcat: can't open 'test.sh': No such file or directorybash-4.4# # 看来不止是把程序kill了，这个文件也给删除了，貌似是新启动了一个pod？

我们再验证下，在运行test.sh文件之前，新建一个文件，看看到底是新创建了一个pod，还是把异常程序删除了，如下：

[root@node1 requests]# kubectl exec -it tomcat-demo-577d557cb4-s8rv9 -- bashbash-4.4# lsLICENSE RELEASE-NOTES bin include logs temp workNOTICE RUNNING.txt conf lib native-jni-lib webappsbash-4.4# echo "123" > a.txtbash-4.4# lsLICENSE RELEASE-NOTES a.txt conf lib native-jni-lib webappsNOTICE RUNNING.txt bin include logs temp workbash-4.4# vi test.shbash-4.4# lsLICENSE RELEASE-NOTES a.txt conf lib native-jni-lib test.sh workNOTICE RUNNING.txt bin include logs temp webappsbash-4.4# sh test.sh ++++++++++++++++++++++++++++++++++++++++++++++++++++++++command terminated with exit code 137[root@node1 requests]# [root@node1 requests]# kubectl get podsNAME READY STATUS RESTARTS AGEdeploy-springboot-5dbfc55f78-mpg69 1/1 Running 2 2d8hnginx-ds-q2pjt 1/1 Running 18 13dnginx-ds-zc5qt 1/1 Running 23 19dtomcat-demo-577d557cb4-s8rv9 0/1 OOMKilled 8 34m[root@node1 requests]#

再稍等几分钟~~~我们等他自动恢复之后，进去看下。

[root@node1 requests]# kubectl exec -it tomcat-demo-577d557cb4-s8rv9 -- bashbash-4.4# lsLICENSE RELEASE-NOTES bin include logs temp workNOTICE RUNNING.txt conf lib native-jni-lib webappsbash-4.4# [root@node1 requests]#

可以看到新建的文件也没了，所以这个后面还是要注意下，但是镜像本身的肯定不受影响。

5、然后我们验证下如何limit设置的非常大，会怎样呢？

# 和上面文件内容一致，我们只改动下面的信息 resources: requests: memory: 100Mi cpu: 100m limits: memory: 100Gi cpu: 20000m# 可以看到我把limit的内存和cpu都调整的非常高，我的服务器本身是没有这么大内存的哈# 看下情况[root@node1 requests]# kubectl apply -f request-web-demo.yaml [root@node1 requests]# kubectl get pod | grep tomcattomcat-demo-78787c7885-hxcm7 1/1 Running 0 71s[root@node1 requests]#

新的pod也调度起来了，说明什么呢？说明我们pod的启动，并不依赖于limit参数；

6、我们验证下requests的内存调大，会怎样呢？

# 和上面文件内容一致，我们只改动下面的信息 resources: requests: memory: 10000Mi cpu: 100m limits: memory: 100Gi cpu: 20000m# 我服务器本身没有10G的内存，看看情况如何[root@node1 requests]# kubectl get pod | grep tomcattomcat-demo-685d47f966-kjcfg 0/1 Pending 0 13stomcat-demo-78787c7885-hxcm7 1/1 Running 0 3m43s[root@node1 requests]#

上面的信息可以看到，老的pod在正常运行，新的pod处于pending状态，并没有启动，说明在requests超出服务器实际剩余空间时，是无法启动的。

7、验证下requests的cpu过大呢？

# 和上面文件内容一致，我们只改动下面的信息 resources: requests: memory: 100Mi cpu: 10000m limits: memory: 100Gi cpu: 20000m# 我服务器本身没有10核的cpu，看看情况如何[root@node1 requests]# kubectl apply -f request-web-demo.yaml[root@node1 requests]# kubectl get pod | grep tomcattomcat-demo-78787c7885-hxcm7 1/1 Running 0 10mtomcat-demo-868c45f468-7mvqt 0/1 Pending 0 45s[root@node1 requests]#

和内存过大的结果一样，无法启动，说明我们在request的cpu超出服务器剩余空间时，是无法启动的。

8、验证下request的参数是否会保存指定内存，这里我写下验证方式和结果，就不验证了，服务器性能太差。

# 和上面文件内容一致，我们只改动下面的信息  replicas: 3 # 副本集数量配置成3，其他的如下，正常 resources: requests:            memory: 2000Mi cpu: 100m limits: memory: 100Mi cpu: 200m# 我服务器本身没有6G的内存，看看情况如何# 会出现在node2和node3上各启动一个pod，剩余一个pod

会出现在node2和node3上各启动一个pod，剩余一个pod会处于pending状态，但是实际上我node2和node3本身并没有占用2G的空间，说明只要你requests配置了参数，就算你没有实际没有使用那么多，系统也会为你保留你配置的参数信息。

9、验证下CPU使用超限的情况，老样子，我只简单的说下验证方式，并不实际验证，服务器性能跟不上。

# 和上面文件内容一致，我们只改动下面的信息 replicas: 1 resources: requests: memory: 100Mi cpu: 100m limits: memory: 100Mi cpu: 6000m# 我服务器本身没有6核的CPU，看看情况如何# 会出现CPU一直达到我们设置的峰值，6核，且不会kill程序或者pod重启

说明CPU超限，一直在峰值，并不会kill程序或者pod重启。

总结下验证结果吧。

至此，本文结束。

往期推荐k8s部署-21-ingress-nginx实现原理和部署，并简单使用k8s系列-08-kubespray的安装配置三分钟解决centos8停止维护，我们如何下载软件这个问题