k8s资源限制以及探针检查

k8s资源限制以及探针检查

一、资源限制

1、资源限制的使用

当定义Pod时可以选择性地为每个容器设定所需要的资源数量。最常见的可设定资源是CPU和内存大小，以及其他类型的资源。

2、reuqest资源（请求）和limit资源（约束）

1、当为Pod中的容器指定了request资源时，调度器就使用该信息来决定将Pod调度到哪个节点上。当还为容器指定了limit资源时，kubelet就会确保运行的容器不会使用超出所设的limit资源量。kubelet还会为容器预留所设的request资源量，供该容器使用。2、如果Pod所在的节点具有足够的可用资源，容器可以使用超过所设置的request资源量。不过，容器不可以使用超出所设置的limit资源量。3、如果给容器设置了内存的limit值，但未设置内存的request值，Kubernetes会自动为其设置与内存limit相匹配的request值。类似的，如果给容器设置了CPU的limit值但未设置CPU的request值，则Kubernetes自动为其设置CPU的request值，并使之与CPU的limit值匹配。

3、Pod和容器的资源请求和限制

```html/xml定义创建容器时预分配的CPU资源spec.containers[].resources.requests.cpu定义创建容器时预分配的内存资源spec.containers[].resources.requests.memory定义创建容器时预分配的巨页资源spec.containers[].resources.requests.hugepages-定义cpu的资源上限spec.containers[].resources.limits.cpu定义内存的资源上限spec.containers[].resources.limits.memory定义巨页的资源上限spec.containers[].resources.limits.hugepages-

### 4、官方文档示例 ```html/xml apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: app image: images.my-company.example/app:v4 env: - name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

此例子中Pod有两个Container。每个Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， 每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。

5、资源限制实操

5.1 编写yaml资源配置清单

```html/xml[root@master ~]# mkdir /opt/test[root@master ~]# cd !$cd /opt/test[root@master test]# vim test1.yaml

apiVersion: v1kind: Podmetadata:name: test1spec:containers:

name: webimage: nginxenv: name: WEB_ROOT_PASSWORDvalue: "password"resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m" name: dbimage: mysqlenv: name: MYSQL_ROOT_PASSWORDvalue: "password"resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m" ### 5.2 释放内存（node节点，以node03为例） 由于mysql对于内存的使用要求比较高，因此需要先检查内存的可用空间是否能够满足mysql的正常运行，若剩余内存不够，可对其进行释放操作。 查看内存 free -mh  手动释放缓存 echo [1\2\3] > /proc/sys/vm/drop_caches ```html/xml [root@node03 ~]# free -m total used free shared buff/cache available Mem: 5442 604 4154 9 683 4505 Swap: 0 0 0 [root@node03 ~]# free -mh total used free shared buff/cache available Mem: 5.3G 604M 4.1G 9.1M 683M 4.4G Swap: 0B 0B 0B [root@node03 ~]# cat /proc/sys/vm/drop_caches 0 [root@node03 ~]# echo 3 > /proc/sys/vm/drop_caches [root@node03 ~]# free -mh total used free shared buff/cache available Mem: 5.3G 516M 4.6G 9.1M 245M 4.5G Swap: 0B 0B 0B [root@node03 ~]# cat /proc/sys/vm/drop_caches 3

 0：0是系统默认值，默认情况下表示不释放内存，由操作系统自动管理 1：释放页缓存 2：释放dentries和inodes 3：释放所有缓存 注意： 如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？所以说，既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。 一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因，如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了。 ### 5.3 创建资源 kubectl apply -f tets1.yaml [root@master02 test]# kubectl apply -f test1.yaml pod/test1 created ### 5.4 跟踪查看pod状态 kubectl get pod -o wide -w  OOM（OverOfMemory）表示服务的运行超过了我们所设定的约束值。 Ready:2/2，status:Running说明该pod已成功创建并运行，但运行过程中发生OOM问题被kubelet杀死并重新拉起新的pod。 ### 5.5 查看容器日志 ```html/xml kubectl logs test1 -c web /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2022/08/03 08:16:10 [notice] 1#1: using the "epoll" event method 2022/08/03 08:16:10 [notice] 1#1: nginx/1.23.1 2022/08/03 08:16:10 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6) 2022/08/03 08:16:10 [notice] 1#1: OS: Linux 3.10.0-693.el7.x86_64 2022/08/03 08:16:10 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 65536:65536 2022/08/03 08:16:10 [notice] 1#1: start worker processes 2022/08/03 08:16:10 [notice] 1#1: start worker process 31 2022/08/03 08:16:10 [notice] 1#1: start worker process 32

nginx启动正常，接下来查看mysql日志kubectl logs test1 -c mysql

5.6 删除pod

kubectl delete -f test1.yaml pod "test1" deleted

5.7 修改yaml配置资源清单，提高mysql资源限制

```html/xml[root@master test]# vim test1.yaml

apiVersion: v1kind: Podmetadata: name: test1spec: containers:

name: web image: nginx env: name: WEB_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" name: db image: mysql env: name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "512Mi" cpu: "0.5" limits: memory: "1024Mi" cpu: "1" ### 5.8 再次创建资源 kubectl apply -f test1.yaml ```html/xml [root@master test]# kubectl apply -f test1.yaml pod/test1 created

### 5.9 跟踪查看pod状态 kubectl get pod -o wide -w [root@master test]# kubectl get pod -o wide -w ### 5.10 查看pod详细信息 kubectl describe pod test1 [root@master test]# kubectl describe pod test1 ### 5.11 查看node资源使用 [root@master test]# kubectl describe node node01 node01的配置为2C2G。 CPU Requests分析： nginx的requests为250m，mysql的requests为500m，因此node01的CPU Requests为750m，在node01的两个核中使用占比为37%。 CPU Limits分析： nginx到的limit为500m，mysql的limit为1，因此node01到的CPU Limits为1500m，在node01的两个核中使用占比为75%。 Memory Requests分析： nginx的requests为64Mi，mysql的requests为512Mi，因此node01的内存Requests为576Mi，在node01的2G内存中使用占比为30%。 Memory Limits分析： nginx的limits为128Mi，mysql的limit为1Gi，因此node01的1152Mi，在node01的2G内存中使用占比为61%。 # 二、健康检查 ### 1、健康检查的定义  健康检查又称为探针（Probe），是由kubelet对容器执行的定期诊断。 ### 2、探针的三种规则 2.1 livenessProbe存活探针 判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据restartPolicy来设置Pod状态，如果容器不提供存活探针，则默认状态为Success。 2.2 readinessProbe就绪探针 判断容器是否准备好接受请求。如果探测失败，端点控制器将从与Pod匹配的所有service endpoints中剔除删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。 2.3 startupProbe启动探针（1.17版本新增） 判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果匹配了startupProbe探测，则在startupProbe状态为Success之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。如果startupProbe失败，kubelet将杀死容器，容器将根据restartPolicy来重启。如果容器没有配置startupProbe，则默认状态为Success。 2.4 同时定义 以上三种规则可同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的 ### 3、Probe支持的三种检测方法 .1 exec 在容器内执行执行命令，如果容器退出时返回码为0则认为诊断成功。 3.2 tcpSocket 对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。 3.3 httpGet 对指定的端口和路径上的容器的IP地址执行httpGet请求。如果响应的状态码大于等于200且小于400（2xx和3xx），则诊断被认为是成功的。 ### 4、探测结果 每次探测都将获得以下三种结果之一： ● 成功：容器通过了诊断 ● 失败：容器未通过诊断 ● 未知：诊断失败，因此不会采取任何行动 ### 5、exec方式 ```html/xml vim exec.yaml apiVersion: v1 kind: Pod metadata: labels: test: liveness #为了健康检查定义的标签 name: liveness-exec spec: #定义了Pod中containers的属性 containers: - name: liveness image: busybox args: #传入的命令 - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy;sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 #表示pod中容器启动成功后，多少秒后进行健康检查 periodSeconds: 5 #在首次健康检查后，下一次健康检查的间隔时间 5s

在配置文件中，可以看到Pod具有单个Container。该perioSeconds字段指定kubelet应该每5秒执行一次活动性探测。该initiaDelaySeconds字段告诉kubelet在执行第一个探测之前应该等待5秒。为了执行探测，kubelet cat /tmp/healthy在容器中执行命令。如果命令成功执行，则返回0，并且kubelet认为Container仍然重要。如果命令返回非0值，则kubelet将杀死Container并重启它。

在这个配置文件中，可以看到Pod只有一个容器。容器中的command字段表示创建一个/tmp/live文件后休眠30秒，休眠结束后删除该文件，并休眠10分钟。仅使用livenessProbe存活探针，并使用exec检查方式，对/tmp/live文件进行存活检测。initialDelaySeconds字段表示kubelet在执行第一次探测前应该等待5秒。periodSeconds字段表示kubelet每隔5秒执行一次存活探测。

6、v1kind: Podmetadata:labels:test: livenessname: liveness-livenessimage: k8s.gcr.io/livenessargs: /serverlivenessProbe:/healthzport: 8080httpHeaders: name: Custom-Headervalue: AwesomeinitialDelaySeconds: 3periodSeconds: 3 在配置文件中，可以看到Pod具有单个Container。该periodSeconds字段指定kubectl应该每3秒执行一次活动性探测。该initiaDelaySeconds字段告诉kubelet在执行第一个探测之前应等待3秒。为了执行探测，kubectl将HTTP GET请求发送到Container中运行并在端口8080上侦听的服务器。如果服务器/healthz路径的处理程序返回成功代码，则kubectl会认为在200-400的代码均表示成功，其他代码都表示失败。

7、tcpSocket方式

定义TCP活动度探针

第三种类型的活动性探针使用TCP套接字，使用此配置，kubelet将尝试在指定端口上打开容器的套接字。如果可以建立连接，则认为该让其运行状况良好，如果不能，则认为该容器是故障容器```html/xmlapiVersion: v1kind: Podmetadata:name: goproxylabels:app: goproxyspec:containers:

name: goproxyimage: k8s.gcr.io/goproxy:0.1ports: containerPort: 8080readinessProbe:tcpSocket:port: 8080initialDelaySeconds: 5periodSeconds: 10livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 20

三、总结

1. 探针

探针分为3种

livenessProbe（存活探针）∶判断容器是否正常运行，如果失败则杀掉容器（不是pod），再根据重启策略是否重启容器readinessProbe（就绪探针）∶判断容器是否能够进入ready状态，探针失败则进入noready状态，并从service的endpoints中剔除此容器startupProbe∶判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态

2. 检查方式

检查方式分为3种

exec∶使用 command 字段设置命令，在容器中执行此命令，如果命令返回状态码为0，则认为探测成功get访问。如果返回的常用的探针可选参数

常用的探针可选参数有4个

initialDelaySeconds∶ 容器启动多少秒后开始执行探测periodSeconds∶探测的周期频率，每多少秒执行一次探测failureThreshold∶探测失败后，允许再试几次timeoutSeconds ∶ 探测等待超时的时间

4、重启策略

Pod在遇到故障之后“重启”的动作Pod在遇到故障之后“重启”的动作

Always：当容器终止退出后，总是“重启”容器，默认策略

OnFailure：当容器异常退出（退出状态码非0）时，重启容器

Never：当容器终止退出，从不“重启”容器。

（注意：k8s中不支持重启Pod资源，只有删除重建，重建）

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。