首先 容器环境初始化,pod 由pod 镜像来提供

在pod 生命周期里 容器主要 分文两种：初始化容器和主容器

初始化 容器一定要成功运行并退出，当初始化容器运行退出完了之后 主容器开始和运行

主容器开始运行的时候  有两个探针 存活探针和就绪探针
Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 init 容器
Init 容器与普通的容器非常像，除了如下两点它们总是运行到完成。
Init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行。
如果 Pod 的Init 容器失败，Kubernetes 会不断地重启该 Pod，直到Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

Init 容器能做什么?
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。由于Init 容器必须在应用容器启动之前运行完成，因此 init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。

初始化容器

在集群内部 corends 提供解析服务 每当在集群内创建一个services的时候，就会创建一个解析

添加serveice 定义

没有添加service解析之前 都是就绪状态

添加了 service 解析之后

初始化容器的效果就是 在打开myapp容器之前，首先通过init容器检测集群内的解析到位没，如果没到位 后续的容器不会起来 直到环境就绪 容器在开启 svc解析成功后，init容器退出，主容器运行

=============================

探针 是由 kubelet 对容器执行的定期诊断:ExecAction:在容器内执行指定命令。如果命令退出时返回码为0 则认为诊断成功。
TCPSocketAction: 对指定端口上的容器的IP 地址进行TCP 检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction:对指定的端口和路径上的容器的IP 地址执行HTTP Get请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
每次探测都将获得以下三种结果之一:
成功:容器通过了诊断。
失败:容器未通过诊断
未知: 诊断失败，因此不会采取任何行动。

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应:

livenessProbe: 指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针则默认状态为 Success。
readinessProbe: 指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的IP地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状
startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

一旦设置启动探诊 回忽略前两个 服务的话 定义前两个就够了

============================

回收资源

创建存活探针

在存活探针检测失败导致容器不断被重启

一旦存活探针报错，这样的话 就认为这个pod 不存活，就会不断重启pod 内的容器

端口修改成80 肯定会启动成功

==============================

就绪探针

此时未就绪状态

没有定义就绪探针 就绪探针就是成功的

但是现在定义了就绪探针 就绪探针就不成功

创建测试页面

创建svc

就绪容器自动上线

删除测试页面

就绪探针失败，容器未就绪

在svc中容器自动下线

总结： 存活探针如果检测失败 会不断地重启这个容器，让它达到自愈的功能