pod进阶

发布时间:2024年01月16日

pod进阶?

探针

poststart

prestop

pod的生命周期开始:

k8s的pod重启策略:

always ?deployment的yaml文件只能是always ?pod的yaml三种模式都可以。不论正常退出还是非正常退出都重启

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

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

容器退出了,pod才会重启

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

docker的重启策略:

docker的默认策略是nerver

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

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

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

kubectl create deployment nginx1 --image=nginx:1.22 --replicas=3 --dry-run=client:只是调用api的对象不执行命令

快速生成yaml文件的方法

crashloopbackoff:pod当中的容器退出,kubelet正在重启

imagepullbackoff:正在重试拉取镜像

errimagepull:拉取镜像出错(1、网速太慢。2、镜像名字写错了。3、镜像仓库挂了)

Evicte:pod被驱赶(node节点的资源不够部署pod,或是资源不足,kubelet自动选择一个pod驱逐)

CrashLoopBackOff: ???容器退出,kubelet正在将它重启

InvalidImageName: ???无法解析镜像名称

ImageInspectError: ??无法校验镜像

ErrImageNeverPull: ??策略禁止拉取镜像

ImagePullBackOff: ???正在重试拉取

RegistryUnavailable: 连接不到镜像中心

ErrImagePull: ???????通用的拉取镜像出错

CreateContainerConfigError: 不能创建kubelet使用的容器配置

CreateContainerError: 创建容器失败

m.internalLifecycle.PreStartContainer 执行hook报错

RunContainerError: ??启动容器失败

PostStartHookError: ??执行hook报错

ContainersNotInitialized: 容器没有初始化完毕

ContainersNotReady: ??容器没有准备完毕

ContainerCreating: ???容器创建中

PodInitializing:pod ??初始化中

DockerDaemonNotReady: ?docker还没有完全启动

NetworkPluginNotReady: 网络插件还没有完全启动

Evicte: ????pod被驱赶

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

1、request:需要的资源

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

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

两个限制:

cpu

cpu的限制格式

1 ?2 ?0.5 ?0.2 ?0.3

1可以占用1个cpu

2可以占用两个

0.5可以占用半个

0.2一个cpu的五分之一

0.1是最小单位

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

m来表示cpu

cpu时间分片原理

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

在k8s中就算表示占用的cpu的比率

m:millicores单位

1

1000m就是一个cpu

500m就是半个cpu

2000m

100m就是最小单位

memory内存:

Ki

Mi

Gi

Ti

中间加了一行

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

默认策略:

IfNotPresent:如果本地镜像有,就不再拉取,本地没有才会去镜像仓库拉取

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

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

都是本地部署:Never

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

always:一般不用

pod的容器健康检查:
探针

probe

k8s对容器执行的定期检查,诊断

探针有三种规则:

1、存活探针:

livenessProbe,探测容器是否正常运行,如果发现探测失败,会杀掉容器,容器会根据重启策略来决定是否重启。不是杀掉pod

2、就绪探针:

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

探测失败 READY 0/1 没有进入ready状态。service会把这个资源对象的端点从当中剔除,service也不会把请求转发到pod

3、启动探针:

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

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

第一个肯定是启动探针:只在容器启动时探测

存活

就绪

probe的检查方法:

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

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

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

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

3、tcpSocket:端口,对指定端口上的容器的ip地址进行tcp检查(三次握手),端口打开,认为探测成功

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

诊断结果:

1、成功 ?容器通过了,正常运行

2、失败,存活探针会重启

3、未知状态,诊断失败

存活探针exec的方式:

initialDelaySeconds:容器启动后要等待多少秒后就探针开始工作,单位“秒”,默认是 0s,最小值是 0s;

periodSeconds:执行探测的时间间隔(单位是秒),默认为 10s,最小值是 1s

failureThreshold:探测失败的重试次数,重试一定次数后将认为失败,默认为 3,最小值为 1

timeoutSeconds:探针执行检测请求后,等待响应的超时时间,默认为 1s,最小值是 1s,

successThreshold:探针检测失败后认为成功的最小连接成功次数,默认为 1,在 Liveness和startup探针中必须为 1,最小值为 1。

存活探针HttpGet的方式:(liveness是存活,probe是探针)

存活探针tcpSocket的方式:

总结:

探针:

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

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

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

shell命令执行成功

返回码:0表示成功

成功一次就是探测成功

hettpGet:对web容器发起了一次get请求,可以添加path,指定访问的资源。返回码在大于等于200,小于400的范围之内都算成功

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

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