k8s中，为什么要设计pod
平台直接管理容器不是挺好的吗
为什么要以pod为单位进行管理，
然后把容器放在pod里面
那么有pod和没pod的区别是什么
也就是pod提供了什么作用
这个可以考虑从pod生命周期管理的角度去思考
如图，pod主容器在运行之前，会有一个initcontainer，就是初始化容器。
初始化容器的作用是什么？
比如主容器运行的服务需要连接到数据库才能运行
那么在pod里面写一个initcontainer来确保数据库可以连接上，
才能启动主容器maincontainer
initcontainer里面用busybox镜像，自定义嵌入式脚本command、args、- -c、 - |
命令里面写对于数据库连接的测试，只有连接成功，初始化容器
才算running
初始化容器running
主容器才启动
这个从外观上来讲，相当于多容器pod
从逻辑上来讲，初始化容器的启动是主容器启动的必要条件
初始化容器启动了，才启动主容器。
这个对于服务的依赖的解决来讲，几乎是必要的。
还有主容器挂载pvc卷的时候，
需要指定挂载目录
而这个目录是需要创建好的
如果不用初始化容器
就需要管理员手工创建
而pod调度到哪个节点上，又是自动化调度
如果管理员需要找到对应的节点
再去创建，比较繁琐，不自动化。
把这个挂载的目录
在pod的资源文件里面
写一个initcontainer初始化容器
用busybox镜像，加自定义脚本，创建好目录
那么pod在哪个节点上，这个initcontainer作为主容器的依赖容器，会在主容器
启动之前把目录创建好，就很自动化。
另外，如果restartPolicy设置为Never，不让容器重启
那么，如果initcontainer启动失败了，整个pod也就不再重启，就报错
初始化容器可以有多个
初始化容器的镜像可以和主容器不同
初始化容器执行完自定义命令之后，会退出，不会一直运行
初始化容器退出的时候，会有个退出码，如果非零，那么意味着异常，就需要排查
如果初始化容器退出正常，主容器才会运行。
说白了，初始化容器，就是主容器运行的必要条件。
这个必要条件，可以是数据库，可以是目录创建，可以是各种自定义检测脚本
-------------------------------------------------------------------------------
什么是容器探针？
是容器的健康检查
由谁来检查？
由kubelet
检查哪几个方面？
三个
startupProbe 启动了没
livenessProbe 运行着没
readinessProbe 准备好接收服务请求了没
这个健康检测，拿汽车的年审来比喻
就像是
车能打着吗
车能跑吗
车能坐乘客吗，空调、座椅、安全带、后视镜、转向灯、雨刮器、车载wifi、音乐播放器、香氛、氛围灯，这些都准备好了没，准备好了才可以开始。
那么
startupProbe就是检查发动机能否启动
livenessProbe就是检查车能否上路跑
readinessProbe就是检查提供服务需要的方方面面都准备好了没
startupProbe从字面意思看，就是容器启动了没
那么怎么看容器启动了没，比如容器运行的服务，有端口号
那么用tcpSocket的方式访问这个端口号能不能访问到，能的话，startupProbe就是
success的，不能就是failure，不知道就是unknown
unknown的情况一般应该是网络的问题
livenessProbe从字面意思看，就是在线没，转着没，容器跑着没有
怎么看是否在线，用httpGet的方式去访问端口号加路径，如果状态码是200-400
就是success的，不是就failure，不知道就unknown
readinessProbe从字面意思看，就是准备好了没
怎么知道准备好了没？用exec自定义执行命令的方式，去检测
比如，检测某个文件的版本是否大于2，如果大于，
那就success，不是就failure，不知道就unknown
比如web服务，版本需要大于2，不大于2就不ready
那么这里面的
success
failure
unknown
就是
容器探针的三种检测结果
tcpSocket
httpGet
exec
还有一个gPRC，
就是
容器探针检测的四种方法
gRPC是谷歌远程过程调用，检测自己开发的程序和返回状态。
startupProbe
livenessProbe
readinessProbe
就是
容器探针检测的三个检测方面
可以这么理解，
容器探针，343，总共十个要素，
3个检测方面
4种检测方法
3种检测结果
------------------------------------------------------------------------
事件处理函数，也叫钩子函数
一个是postStart，就是已经开始了，但是也才刚刚开始，
就是主容器启动后干点啥，
比如要去参加聚会，要喝酒，已经坐上车了，在去参加聚合的路上了
甚至是，已经到达聚会的地方了，开始喝酒前，先喝瓶牛奶
这个叫postStart
比如主容器干活之前，先注册一下服务，告诉注册中心，说我来了，
就叫postStart
第二个钩子函数是preStop
也就是主容器结束之前干点啥
还是拿聚会举例，比如大家喝完酒了，也聊得很开心，要散场了
参加聚合的人，有的是开车来参加的，返程的时候就要叫个代驾
拿出手机，叫代驾的操作，就是preStop
也可以说是，在返程之前，跟还在聚会地方的朋友打声招呼，说一下
这个过程，也可以叫preStop
在主容器干完活了，准备休息了，会告诉注册中心，说先下线了。
这个叫preStop
---------------------------------------------------------------------
那么总的来说
如图
pod的生命周期中，除了主容器
还包括
初始化容器
容器探针
钩子函数
这三个要素
这些是可选项
运用好这些可选项，
可以让k8s集群，
更加自动化，实时监控化，可定制化。
如果没有pod，
那么可能这些功能不容易实现
因为这些都是在pod的生命周期的不同阶段进行的。
kubelet是这些行为的经理
看着这些动作
如果有问题，
就调用资源处理，
同时把情况传递给数据库。
如果运行ok，没问题，
就继续保障着这些服务
同时把运行ok的情况
也传递给数据库。
pod的生命周期，从这个角度看，作用比较大。
事件处理函数
---
kind: Pod
apiVersion: v1
metadata:
name: web5
spec:
containers:
- name: web
image: myos:httpd
lifecycle:
postStart:
exec:
command:
- sh
- -c
- |
xxxxx
preStop:
exec:
command:
- sh
- -c
- |
xxxxx
exec的探测方法用的更多一些，使用嵌入式脚本
