Pod进阶——资源限制以及探针检查

本文主要是介绍Pod进阶——资源限制以及探针检查，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目录

一、资源限制

1、资源限制定义：

2、资源限制request和limit资源约束

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

4、官方文档示例

5、CPU资源单位

6、内存资源单位

7、资源限制实例

①编写yaml资源配置清单

②释放内存（node节点，以node01为例子）

③注意：

④创建资源

⑤跟踪查看pod状态

⑥查看容器日志

⑦删除pod

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

⑨然后再次创建资源

⑩跟踪查看pod状态

11查看pod详细信息

12查看node01节点的详细信息

二、健康检查

1、健康检查的定义

2、探针的三种规则

①livenessProbe存活探针

②readinessProbe就绪探针

③startupProbe启动探针（1.17版本新增）

④注意：

3、Probe支持三种检查方法：

①exec：

②tcpSocket：

③httpGet：

4、探测结果

5、exec方式

示例2、

6、httpGet方式

示例2、

7、tcpSocket方式

三、总结

1、探针

2、检查方式

3、常用的探针可选参数

四、拓展

1、Pod的状态

2、Container生命周期

---

一、资源限制

1、资源限制定义：

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

2、资源限制request和limit资源约束

①当为 Pod 中的容器指定了 request 资源时，调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量， 供该容器使用。

②如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量。

③如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。

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

官方示例网站：Resource Management for Pods and Containers | Kubernetes

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

4、官方文档示例

apiVersion: v1
kind: Pod
metadata:name: frontend
spec:containers:- name: appimage: images.my-company.example/app:v4env:- name: MYSQL_ROOT_PASSWORDvalue: "password"resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m"- name: log-aggregatorimage: images.my-company.example/log-aggregator:v6resources: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、CPU资源单位

CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）。
Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的  、一半 CPU 资源（类似于Cgroup对CPU资源的时间分片）。表达式 0.1 等价于表达式 100m（毫核），表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。
Kubernetes 不允许设置精度小于 1m 的 CPU 资源。 

6、内存资源单位

内存的 request 和 limit 以字节为单位。可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示， 或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。
如：1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB

注意：在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以 MB、GB为单位的，1GB 就是1,000,000,000Byte，而操作系统是以2进制为处理单位的，因此检查硬盘容量时是以MiB、GiB为单位，1GiB=2^30=1,073,741,824，相比较而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以检测实际结果要比标出的少一些。

7、资源限制实例

①编写yaml资源配置清单

[root@master ~]# mkdir /opt/test
[root@master ~]# cd /opt/test
[root@master test]# vim test1.yamlapiVersion: v1
kind: Pod
metadata:name: test1
spec: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"

②释放内存（node节点，以node01为例子）

由于mysql对于内存的使用要求较高，因此需要先检查内存的可用空间是否能够满足mysql的正常运行，若剩余内存不够，可以对其进行操作释放。

查看内存
free -mh

内存总量为3.7G，实际使用1.1G，因此可有内存应该为2.6G左右。但是由于有1.4G的内存被用于缓存，free为1.2G。所以不需要释放内存。

这里可以手动释放缓存

echo [1\2\3] > /proc/sys/vm/drop_caches

0：0是系统默认值，默认情况下表示不释放内存，由操作系统自动管理
1：释放页缓存
2：释放dentries和inodes
3：释放所有缓存

③注意：

如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？所以说，既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。

一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因，如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了。

④创建资源

kubectl apply -f tets1.yaml

⑤跟踪查看pod状态

kubectl get pod -o wide -w

OOM（OverOfMemory）表示服务的运行超过了我们所设定的约束值。
Ready:2/2，status:Running说明该pod已成功创建并运行，但运行过程中发生OOM问题被kubelet杀死并重新拉起新的pod。

⑥查看容器日志

kubectl logs test1 -c web

nginx启动正常，然后查看mysql日志

kubectl logs test1 -c db

容器问题为mysql

⑦删除pod

kubectl delete -f test1.yaml

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

[root@master test]# vim test1.yaml  apiVersion: v1
kind: Pod
metadata:  name: test1
spec:  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"

⑨然后再次创建资源

kubectl apply -f test1.yaml

⑩跟踪查看pod状态

kubectl get pod -o wide -w

11查看pod详细信息

[root@k8s test]# kubectl describe pod test1

12查看node01节点的详细信息

kubectl describe  nodes node01

二、健康检查

1、健康检查的定义

健康检查：又称为探针（Probe），探针是由kubelet对容器执行的定期诊断。

2、探针的三种规则

①livenessProbe存活探针

判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针，则默认状态为Success。

②readinessProbe就绪探针

判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service 址endpoints 中剔除删除该Pod的IP地。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。

③startupProbe启动探针（1.17版本新增）

判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，在则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。 如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe， 则默认状态为 Success。

④注意：

以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。

3、Probe支持三种检查方法：

①exec：

在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。

②tcpSocket：

对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。

③httpGet：

对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的

4、探测结果

每次探测都将获得一下三种结果之一：

①成功：容器通过了诊断

②失败：容器未通过诊断

③未知：诊断失败，因此不会采取任何行动

5、exec方式

vim exec.yamlapiVersion: v1
kind: Pod
metadata:labels:test: liveness				#为了健康检查定义的标签name: liveness-exec
spec:						#定义了Pod中containers的属性containers:- name: livenessimage: busyboxargs:						#传入的命令- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy;sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 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秒执行一次存活探测。

示例2、

vim exec.yaml
apiVersion: v1
kind: Pod
metadata:name: liveness-execnamespace: default
spec:containers:- name: liveness-exec-containerimage: busyboximagePullPolicy: IfNotPresentcommand: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]livenessProbe:exec:command: ["test","-e","/tmp/live"]initialDelaySeconds: 1periodSeconds: 3kubectl create -f exec.yamlkubectl describe pods liveness-exec

6、httpGet方式

vim httpGet.yaml
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-http
spec:containers:- name: livenessimage: k8s.gcr.io/livenessargs:- /serverlivenessProbe:httpGet:path: /healthzport: 8080httpHeaders:- name: Custom-Headervalue: AwesomeinitialDelaySeconds: 3periodSeconds: 3

在配置文件中，可以看到Pod具有单个Container。该periodSeconds字段指定kubectl应该每3秒执行一次活动性探测。该initiaDelaySeconds字段告诉kubelet在执行第一个探测之前应等待3秒。为了执行探测，kubectl将HTTP GET请求发送到Container中运行并在端口8080上侦听的服务器。如果服务器/healthz路径的处理程序返回成功代码，则kubectl会认为任何大于或等于400的代码均表示成功，其他代码都表示失败。

示例2、

apiVersion: v1
kind: Pod
metadata:name: liveness-httpgetnamespace: default
spec:containers:- name: liveness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10
kubectl create -f httpget.yamlkubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.htmlkubectl get pods

httpget http://IP:80/index.html  delay 延迟 =3  tomout=10s    period（频率）=3s   succes(成功)=1  faulure(失败)=3 机会      杀死容器

7、tcpSocket方式

定义TCP活动度探针

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

apiVersion: v1
kind: Pod
metadata:name: goproxylabels:app: goproxy
spec:containers:- name: goproxyimage: k8s.gcr.io/goproxy:0.1ports:- containerPort: 8080readinessProbe:tcpSocket:port: 8080initialDelaySeconds: 5periodSeconds: 10livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 20

如图所示，TCP检查的配置与HTTP检查非常相似，此示例同时使用就绪和活跃度探针，容器启动5秒后，kubelet将发送第一个就绪探测器。这些尝试连接到goproxy端口8080上的容器。如果探测成功，则容器将标记为就绪，kubelet将继续每10秒运行一次检查。

除了就绪探针之外，此配置还包括活动探针。容器启动后15秒钟，kubelet将运行第一个活动谈着，就像就绪探针一样，这些尝试goproxy在端口8080上连接到容器。如果活动探针失败，则容器将重新启动。

三、总结

1、探针

①livenessProbe（存活探针）∶判断容器是否正常运行，如果失败则杀掉容器（不是pod），再根据重启策略是否重启容器

②readinessProbe（就绪探针）∶判断容器是否能够进入ready状态，探针失败则进入noready状态，并从service的endpoints中剔除此容器

③startupProbe∶判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态

2、检查方式

①exec∶使用 command 字段设置命令，在容器中执行此命令，如果命令返回状态码为0，则认为探测成功

②httpget∶通过访问指定端口和url路径执行http get访问。如果返回的http状态码为大于等于200且小于400则认为成功

③tcpsocket∶通过tcp连接pod（IP）和指定端口，如果端口无误且tcp连接成功，则认为探测成功

3、常用的探针可选参数

①initialDelaySeconds∶ 容器启动多少秒后开始执行探测

②periodSeconds∶探测的周期频率，每多少秒执行一次探测

③failureThreshold∶探测失败后，允许再试几次

④timeoutSeconds ∶ 探测等待超时的时间

四、拓展

1、Pod的状态

①pending：

pod已经被系统认可了，但是内部的container还没有创建出来。这里包含调度到node上的时间以及下载镜像的时间，会持续一小段时间。

②Running：

pod已经与node绑定了（调度成功），而且pod中所有的container已经创建出来，至少有一个容器在运行中，或者容器的进程正在启动或者重启状态。--这里需要注意pod虽然已经Running了，但是内部的container不一定完全可用。因此需要进一步检测container的状态。

③Succeeded：

这个状态很少出现，表明pod中的所有container已经成功的terminated了，而且不会再被拉起了。

④Failed：

pod中的所有容器都被terminated，至少一个container是非正常终止的。（退出的时候返回了一个非0的值或者是被系统直接终止）

⑤unknown：

由于某些原因pod的状态获取不到，有可能是由于通信问题。 一般情况下pod最常见的就是前两种状态。而且当Running的时候，需要进一步关注container的状态

2、Container生命周期

①Waiting：启动到运行中间的一个等待状态。

②Running：运行状态。

③Terminated：终止状态。 如果没有任何异常的情况下，container应该会从Waiting状态变为Running状态，这时容器可用。

但如果长时间处于Waiting状态，container会有一个字段reason表明它所处的状态和原因，如果这个原因很容易能标识这个容器再也无法启动起来时，例如ContainerCannotRun，整个服务启动就会迅速返回。（这里是一个失败状态返回的特性，不详细阐述）

这篇关于Pod进阶——资源限制以及探针检查的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---