探针
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:一般不用
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,指定的容器监听端口是否打开,是否能和指定的容器监听端口进行通信