存活探针和就绪探针,会伴随整个pod的生命周期
就绪探针的特点:pod的状态是running,ready状态是notready,容器不可以提供正常的业务访问,就绪探针不会重启容器
就绪探针exec的方式:(readiness是就绪,probe是探针)
就绪探针httpGet的方式:(readiness是就绪,probe是探针)
就绪探针tcpSocket的方式:(readiness是就绪,probe是探针)
tcpSocket只是监听容器上的业务端口能否正常通信。8081没有,8080还在,也就是正常的端口还是可以访问
如果更改了容器的启动端口
startupProbe:启动探针
如果探测失败,pod的状态是notready
启动探针:tcpSocket的方式:(startup是就绪,probe是探针)
将启动、就绪和存活探针写在一个脚本:
(启动探针没有成功之前,后续的探针都不会执行)
启动探针成功之后,在pod的生命周期内不会再检测启动探针
重启了pod之后,相当于重新部署了一个初始版的新的容器
总结:
1、一个yaml当中可以有多个探针。启动 存活 就绪都针对一个容器
2、启动探针的优先级最高,只有启动探针“成功”后续的探针才会执行
3、启动探针成功之后,后续除非重启pod,否则不会再触发启动探针
4、在pod的生命周期当中,一直存在,一直探测的是存活探针和就绪探针
5、在pod的生命周期当中,后续的条件是满足哪个探针的条件,触发哪个探针的条件
6、就绪探针,如果不影响容器运行,status:running,这个时候不会重启,但是,容器退出的话,就绪探针也会重启
postStart:容器启动钩子,容器启动之后触发的条件
preStop:容器退出钩子,容器退出之后触发的条件
apiVersion: v1
kind: Pod
metadata:
??name: nginx2
spec:
??containers:
????- name: nginx2
??????image: centos:7
??????command: ["/bin/bash","-c","sleep 3600"]
??????volumeMounts:
??????- name: test1
????????mountPath: /opt
????????readOnly: false
??????lifecycle:
????????postStart:
??????????exec:
????????????command: ["/bin/bash","-c","echo hello from start >> /opt/123.txt;sleep 10"]
????????preStop:
??????????exec:
????????????command: ["/bin/bash","-c","echo hello from stop >> /opt/123.txt"]
??volumes:
??- name: test1
????hostPath:
??????path: /opt/test
??????type: DirectoryOrCreate
??????volumeMounts:
??????- name: test1
????????mountPath: /opt
????????readOnly: false
声明容器内部的挂载目录
要给这个挂载卷取名字,不同的挂载卷的名字不能重复
readonly:false:可读写
??volumes:
??- name: test1
????hostPath:
??????path: /opt/test
??????type: DirectoryOrCreate
声明的是node节点上和容器内的/opt的挂载目录
挂载卷的名称和要挂载的容器内挂载卷名称要一一对应
hostPath:指定和容器的挂载目录
type: DirectoryOrCreate:如果节点上的目录不存在,自动创建该目录
#pod会经常呗重启,销毁,一旦容器和node节点做了挂载卷,数据不会丢失
启动和退出的作用:
1、启动可以自定义配置容器的内的环境变量
2、通知机制,告诉用户容器启动完毕
3、退出时,可以执行自定义命令,删除或者生成一些必要的程序,自定义销毁方式以及自定义资源回收方式以及容器的退出和等待时间
pod重启策略:
在k8s当中都是重启pod
Always:默认策略------->当pod内的容器退出,不论是一个还是两个容器退出,整个pod都会重启
Never:当pod内的容器退出时,不管是退出一个还是N个,pod都不重启
onFailure:当pod内的容器退出时,整个pod都不会重启,只有一个或者N个容器非正常退出,状态码非0,整个pod才会重启
k8s就是集群化管理容器