一身转战三千里,一剑曾当百万师。这篇文章主要讲述K8S中Pod的进阶(资源限制和探针)相关的知识,希望能为你提供帮助。
K8S中Pod的进阶(资源限制和探针)
资源限制概念
- 当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。最常见可设定资源是 CPU 和内存大小,以及其他类型的资源
- 当为 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 值匹配
- 官网示例:https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
request 和 limit
request
- 容器使用的最小资源需求, 作为容器调度时资源分配的判断依赖。
- 只有当前节点上可分配的资源量 > = request 时才允许将容器调度到该节点。
- request参数不限制容器的最大可使用资源
- 容器能使用资源的最大值
- 设置为0表示对使用的资源不做限制, 可无限的使用
0 &
lt;
= request &
lt;
= limit
如果limit=0表示不对资源进行限制, 这时可以小于request。
目前CPU支持设置request和limit,memory只支持设置request, limit必须强制等于request, 这样确保容器不会因为内存的使用量超过request但是没有超过limit的情况下被意外kill掉。
Pod和容器的资源请求和限制
spec.containers[].resources. requests.cpu#定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory #定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu#定义 cpu 的资源上限
spec.containers[].resources.limits.memory#定义内存的资源上限
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 毫秒
1KB=103=1000,1MB=106=1000000=1000KB,1GB=10^9=1000000000=1000MB
1KiB=2^10=1024,1MiB=2^20=1048576=1024KiB
【K8S中Pod的进阶(资源限制和探针)】注意∶在买硬盘的时候,操作系统报的数量要比产品标出或商家号称的小一些,主要原因是标出的是以 MB、GB为单位的,1GB
就是1,000,000,000Byte,而操作系统是以2进制为处理单位的,,因此检查硬盘容量时是以MiB、GiB为单位,1GB=2^30=1,073,741,824,相比较而言,1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte,所以检测实际结果要比标出的少—些
示例1:
kubectl run nginx1 --image=nginx --port=80 --replicas=2 --dry-run -o yaml >
demo1.yaml
#直接导出一个yaml模板进行修改,对cpu和内存进行预设和限制
vim demo1.yaml
==========================================================
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: nginx1
name: nginx1
spec:
replicas: 2
selector:
matchLabels:
run: nginx1
template:
metadata:
labels:
run: nginx1
spec:
containers:
- image: nginx
name: nginx1
ports:
- containerPort: 80
resources:
requests:
memory: "100Mi"
cpu: "250m"
limits:
memory: "200Mi"
cpu: "500m"
此例子中的 Pod 有两个容器。每个容器的 request 值为 0.25 cpu 和 100MiB 预设内存,每个容器的 limit 值为 0.5 cpu 和 200MiB 内存。那么可以认为该 Pod 的总的资源 request 为 0.5 cpu 和 200 MiB 内存,总的资源 limit 为 1 cpu 和 400MiB 内存。
kubectl apply -f demo1.yaml kubectl describe podskubectl describe node node01
kubectl describe node node02
示例2:
vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
name: frontend
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: wp
image: wordpress
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"kubectl apply -f pod2.yaml
kubectl describe pod frontendkubectl get pods -o widekubectl describe nodes node02
#由于当前虚拟机有2个CPU,所以Pod的CPU Limits一共占用了50%
重启策略
Pod 在遇到故障之后重启的动作
- Always:当容器终止退出后,总是重启容器,默认策略
- OnFailure:当容器异常退出(退出状态码非0)时,重启容器;正常退出则不重启容器
- Never:当容器终止退出,从不重启容器
示例
vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 30;
exit 3kubectl apply -f pod3.yaml
查看Pod状态,等容器启动后30秒后执行exit退出进程进入error状态,就会重启次数加1
kubectl get podskubectl delete -f pod3.yamlvim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 30;
exit 3
restartPolicy: Never
#注意:跟container同一个级别kubectl apply -f pod3.yaml#容器进入error状态不会进行重启
kubectl get pods -w
探针(健康检查,钩子)作用:kubelet对pod中的容器进行定期的健康检测
- livenessProbe(存活探针):
判断容器中的程序是否在正常运行,如果探测失败,kubelet就会杀掉容器(POD),容器(POD)再根据重启策略是否重启 - readinessProbe(就绪探针):
1.判断这个pod是否能够进入ready状态并提供接收服务的请求
2.探测失败的话,就会进入no ready(0/1)状态,并从service的endpoints中剔除这个pod,service将不会再把请求发给这个pod - startupProbe(启动探针):
判断容器内的应用是否启动用的,在状态为success前,其他探针都会处于无效状态(不会启动)
- exec:配合command或args字段在容器中执行Linux命令探测,如果命令的返回码为0,则认为探测成功
- httpget:通过对指定的端口使用url路径发起一次httpget请求,如果返回的合同谈判状态码为2XX或3XX则认为探测成功
- tcpsocket:通过使用对pod IP和指定的端口进行TCP连接(三次握手),如果对端口TCP连接成功,则认为探测成功
- 成功:容器通过了诊断
- 失败:容器未通过诊断
- 未知:诊断失败,因此不会采取任何行动
示例1∶exec方式
vim demo2.yamlapiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy;
sleep 30;
rm -rf /tmp/healthy;
sleep 60
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
failureThreshold: 1
initialDelaySeconds: 5
periodSeconds: 5kubectl apply -f demo2.yaml#查看在探测失败后重新拉取容器
kubectl describe pod liveness-exec
- initialDelaySeconds∶指定 kubelet 在执行第一次探测前应该等待5秒,即第一次探测是在容器启动后的第6秒才开始执行。默认是 0 秒,最小值是 0。
- periodSeconds∶指定了 kubelet 应该每 5 秒执行一次存活探测。默认是 10 秒。最小值是 1。
- failureThreshold∶当探测失败时,Kubernetes 将在放弃之前重试的次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
- timeoutSeconds∶探测超时后等待多少秒。默认值是 1 秒。最小值是 1。(在 Kubernetes 1.20 版本之前,exec 探针会忽略timeoutSeconds 探针会无限期地持续运行,甚至可能超过所配置的限期,直到返回结果为止)
示例2∶httpGet方式
vim demo3.yamlapiVersion: v1
kind: Pod
metadata:
name: liveness-httpget
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: nginx
containerPort: 80
livenessProbe:
httpGet:
port: nginx#指定端口,这里使用的是之前的ports里的name,也可以直接写端口
path: /index.html#指定路径
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 10#加载yaml文件
kubectl create -f demo3.yaml#进入容器删除网页文件进行测试
kubectl exec -it liveness-httpget -- rm -rf /usr/share/
nginx/html/index.html#查看pod的详细参数
kubectl get pod
kubectl describe pod liveness-httpget
在这个配置文件中, 可以看到 Pod 也只有一个容器。initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3秒。periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。 timeoutSeconds字段指定了超时等待时间为10S,kubelet 会向容器内运行的服务(服务会监听 80端口)发送一个HTTP GET 请求来执行探测。如果服务器上/index.html路径下的处理程序返回成功代码,则 kubelet 认为容器是健康存活的。如果处理程序返回失败代码,则 kubelet 会杀死这个容器并且重新启动它。
任何大于或等于 200 并且小于 400 的返回代码标示成功,其它返回代码都标示失败。
示例3∶tcpSocket方式
vim demo4.yamlapiVersion: v1
kind: Pod
metadata:
name: probe-tcp
spec:
containers:
- name: tcpnginx
image: nginx
ports:
- containerPort: 80
readinessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 15
periodSeconds: 20#加载yaml文件
kubectl create -f demo4.yaml #查看pod的信息
kubectl get pod
kubectl describe pod probe-tcp
容器启动、退出动作
vim demo1.yamlapiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: soscscs/myapp:v1
lifecycle:#此为关键字段
postStart:
exec:
command: ["/bin/sh", "-c", " echo 333333 >
>
/var/log/nginx/message"]
preStop:
exec:
command: ["/bin/sh", "-c", " echo 222222>
>
/var/log/nginx/message"]
volumeMounts:
- name: message-log
mountPath: /var/log/nginx/
readOnly: false
initContainers:
- name: init-myservice
image: soscscs/myapp:v1
command: ["/bin/sh", "-c", "echo 111111>
>
/var/log/nginx/message"]
volumeMounts:
- name: message-log
mountPath: /var/log/nginx/
readOnly: false
volumes:
- name: message-log
hostPath:
path: /data/volumes/nginx/log/
type: DirectoryOrCreatekubectl apply -f demo1.yamlkubectl get pods -o wide#在node01上节点上查看
cat /data/volumes/nginx/log/message
总结 k8s重启策略Pod 在遇到故障之后重启的动作
- Always:当容器终止退出后,总是重启容器,默认策略
- OnFailure:当容器异常退出(退出状态码非0)时,重启容器;正常退出则不重启容器
- Never:当容器终止退出,从不重启容器
k8s探针(3 种)
- livenessProbe(存活探针)∶判断容器是否正常运行,如果失败则杀掉容器(不是pod),再根据重启策略是否重启容器
- readinessProbe(就绪探针)∶判断容器是否能够进入ready状态,探针失败则进入noready状态,并从service的endpoints中剔除此容器
- startupProbe(启动探针)∶判断容器内的应用是否启动成功,在success状态前,其它探针都处于无效状态
- exec∶使用 command 字段设置命令,在容器中执行此命令,如果命令返回状态码为0,则认为探测成功
- httpget∶通过访问指定端口和url路径执行http get访问。如果返回的http状态码为大于等于200且小于400则认为成功
- tcpsocket∶通过tcp连接pod(IP)和指定端口,如果端口无误且tcp连接成功,则认为探测成功
- initialDelaySeconds∶ 容器启动多少秒后开始执行探测
- periodSeconds∶探测的周期频率,每多少秒执行一次探测
- failureThreshold∶探测失败后,允许再试几次
- timeoutSeconds ∶ 探测等待超时的时间
spec.containers.resources. requests.cpu#定义创建容器时预分配的CPU资源
spec.containers.resources.requests.memory#定义创建容器时预分配的内存资源
spec.containers.resources.limits.cpu#定义 cpu 的资源上限
spec.containers.resources.limits.memory#定义内存的资源上限
k8s Pod中应用容器的启动、退出动作spec.containers.lifecycle.postStart配合 exec.command
spec.containers.lifecycle.preStop配合 exec.command
其他小结
Pod两大类
自由式Pod
控制器管理PodPod里的容器,三大类
基础容器(pause容器)
初始化容器(init容器)
应用容器(main容器)镜像拉取策略imagePullPolicy
Always
Never
IfNotPresent重启策略restarPolicy
Always
Never
OnFailure资源限制 spec.containers.requests spec.containers.resources.limits
requests.cpumemory
limit.cpumemory
推荐阅读
- Redis(开发与运维):15---集合对象
- i.MX6ULL驱动开发 | 10 - 修改LCD驱动点亮LCD显示小企鹅logo
- jupyter重置密码
- paramiko库实现远程登录主机上传下载
- Shell 编程之正则表达式与文件处理器
- Shell 编程实战
- Shell编程之expect免交互
- K8S部署Prometheus+Grafana监控集群
- 掌握linux文件系统inode与bloke &日志管理