pod进阶:探针和容器钩子

发布时间:2024年01月05日

探针*

容器钩子:

poststart

prestop

pod的生命周期开始

Q:docker和k8s的重启策略对比

A:

k8s的pod重启策略:

Always:正常退出和非正常退出都重启(deployment的yaml文件只能是Always。pod的yaml文件三种模式都可以)

Never:正常退出和非正常退出都不重启

OnFailure:只有状态码非0才会重启。正常退出不重启

容器退出了,pod才会重启

pod可以有多个容器,只要有一个容器,整个pod都会重启,pod内的所有容器都会重启

docker的重启策略:

docker的默认策略是Never

on-failure:非正常退出才会重启容器

always:只要容器退出,都会重启

unless-stopped:只要容器推出就会重启,docker守护进程时已经停止的容器不再重启

单机部署:docker足够

集群化部署:K8S

如何快捷生成yaml文件

[root@master01 opt]#?kubectl create deployment nginx --image=nginx:1.22 --replicas=3 --dry-run=client

deployment.apps/nginx created (dry run)

[root@master01 opt]# kubectl get deployment.apps

NAME ????????READY ??UP-TO-DATE ??AVAILABLE ??AGE

centos1 ?????0/1 ????1 ???????????0 ??????????20h

[root@master01 opt]#?kubectl create deployment nginx --image=nginx:1.22 --replicas=3 --dry-run=client -o yaml > /opt/test1.yml

[root@master01 opt]# ls

a.yml ???cni-plugins-linux-amd64-v0.8.6.tgz ?rh

b.yml ???containerd ?????????????????????????test1.yml

[root@master01 opt]#?kubectl run nginx1 --image=nginx:1.22 --dry-run=client -o yaml > /opt/test-pod.yaml

[root@master01 opt]# vim test-pod.yaml

[root@master01 opt]#?kubectl expose deployment nginx2 --port=80 --target-port=80 --type=NodePort --dry-run=client -o yaml > /opt/testl-service.yaml

[root@master01 opt]# vim testl-service.yaml

--dry-run=client: 只是调用api的对象不执行命令

pod内的容器使用节点资源的限制:

1、request: 需要的资源

2、limit:最高能占用系统多少资源

如果只设置request,没有limit,会占用所有

工作中一般就写一个limit

limit:需要多少,最多也只能占用这么多

如果只有limit,没有request,会按照limit来

两个限制:内存 ?CPU

CPU的限制格式:

法一:

1 ???????????????????2 ????????????????0.2 ????????????????0.1 【最小单位】

可以占用1个cpu ?可以占用2个cpu ????可以占用0.2个cpu ?????可以占用0.1个cpu

要么是整数,要么就是小数点后只能跟一位,最小单位0.1

法二:

m来表示CPU

1000m表示一个cpu

CPU时间分片原理:

CPU时间分片:通过周期性的轮流分配CPU时间给各个进程。多个进程可以在CPU上交替执行

在K8S中就是表示占用的CPU的比率

m:millicores 单位

内存:Ki/Mi/Gi/Ti

#在创建pod时,一定要给容器做资源限制

k8s怎么设置拉取镜像的策略

默认策略:

lfNotPresent:如果本地镜像有,则不再拉取。本地没有才会去镜像仓库拉取

Always:不论镜像是否存在,创建/重启时都会重新拉取镜像

Never:仅仅使用本地镜像。本地没有也不会主动拉取

都是本地部署,Never

如果涉及到外部部署,默认策略 (事前要把docker的镜像导入到目标主机)

Always:一般不用

pod的容器健康检查:探针(probe)

K8S对容器执行的定期检查、诊断

探针的三种规则:

1、存活探针:livenessProbe

探测容器是否正常运行

如果发现探测失败,会杀掉容器,容器会根据重启策略决定是否重启。不是杀掉pod,只是对容器

2、流量/就绪探针

探测容器是否进入ready状态,并做好接受请求的状态

探测失败,ready ?0/1 没有进入ready状态。但是status依旧是running,实际不可用

service会把资源对象的端点从当中剔除,service也不会把请求转发到pod

3、启动探针

只是在容器启动后开始检测,容器内的应用是否启动成功。在启动探测成功之前,所有其他的探针都处于禁用状态。一旦启动探针结束,后续的操作就不再受启动探针的影响

在一个容器当中的可以有多个探针

启动探针:只在容器启动时探测

存活

就绪

probe的检查方法:

1、exec探针: 在容器内部执行命令,如果命令的返回码是0,表示成功。

适用于需要在容器内自定义命令来检查容器的健康状况

2、httpGet:

对指定ip+端口的容器发送一个httpget的请求。响应状态码大于等于200,小于400都是成功。

200<=x<400

适用于检查容器能否响应http的请求,web容器(nginx、tomcat)

3、tcpSocket

端口。对指定端口上的容器的IP地址进行tcp检查(三次握手),端口打开,认为探测成功,否则都是失败。

适用于检查特定容器的端口监听状态

类似于telnet 192.168.233.10 80

诊断结果:

1、成功

容器通过了,正常运行

2、失败

只有存活探针会重启,就绪探针会,启动探针会

3、未知

诊断失败(少见)

exec方式

successThreshold: 1

timeoutSeconds: 1

这两个可以不加,其他的三个都要加,是核心指标

总结:

探针:

存活探针: 检测失败之后,会杀死容器,然后重启

探针将伴随整个容器的生命周期

exec:相当于执行了一个shell命令: 容器里面执行

shell命令执行成功:返回码是0表示成功

成功一次即可。只要成功一次就是探测成功

httpGet:对web容器发起的一次Get请求,可以添加path,指定访问的资源。返回码在[200,400)之间都算成功

tcpSocket:相当于telnet。指定的容器的监听端口是否打开。是否能和指定的容器监听端口进行通信

文章来源:https://blog.csdn.net/a91888888/article/details/135400252
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。