Kubernetes 3 （Pod生命周期、探针、控制器）

一、Pod生命周期

简介：
1、Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。Init 容器与普通的容器非常像，除了如下两点：
它们总是运行到完成；
Init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行。

2、如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

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

二、init初始化容器

pause镜像为pod提供了基础的初始化环境。

编写init.yaml文件；
initContainers: 优先运行init容器；
读取资源清单创建pod，查看Pod信息可以看到两个初始化容器都未成功运行，由于每个init初始化容器必须成功运行并退出后，主容器才能成功运行，因此pod一直未就绪

修改init.yaml文件，为其中一个个init初始化容器构建资源模块，此时一个初始化容器成功运行

查看默认命名空间的服务

运行一个pod， nslookup是一种网络管理命令行工具，可用于查询DNS域名和IP地址输入指令

在初始化文件中再多添加一个服务，为另一个init初始化容器构建资源模块

kubectl get pod -w 可以查看执行的动态过程

此时初始化成功

再次运行一个pod，可以看到mydb的域名解析；
删除初始化容器

三、探针

1、探针是由 kubelet 对容器执行的定期诊断:
ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

2、每次探测都将获得以下三种结果之一：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。

1.livenessProbe存活探针

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：
livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
重启策略：PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。

编辑资源清单文件，设置在生成pod时使用存活探针探测容器的8080端口是否开放，进而指示容器的运行状态

读取资源清单创建pod，可以看到pod无法成功运行，这是因为myapp容器镜像默认开放的是80端口，8080端口不处于监听状态，存活探针探测到后认为容器未在运行，Kubelet就会杀死容器

将端口修改为80之后

删除资源清单后重新创建pod，可以看到pod就绪并成功运行

查看pod的详细信息可以看到80端口开放

2.readinessProbe 就绪探针

readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

编辑资源清单文件，设置在生成pod时使用就绪探针检测容器默认发布路径下是否有test.html文件，从而指示容器是否准备好服务请求

读取资源清单创建pod，可以看到pod一直未就绪，但可以访问到容器分配到的ip，这说明容器实际上已就绪

删除已有的pod，编辑资源清单文件，设置pod的标签为myapp

编辑服务资源清单，设置创建的服务mysvc为标签为myapp的pod提供统一的对外访问接口

查看服务的详细信息发现该服务无后端pod，这是因为就绪探针持续运行，当容器没有就绪，svc不会暴露出去，没有能够提供访问的后端

连接进入pod，在容器默认发布路径下创建指定test.html文件；
就绪探针检测到后指示容器就绪，此时查看服务的详细信息发现该服务有了后端pod

访问成功

当删除容器默认发布路径下的test.html文件后，再次查看服务的详细信息发现该服务无后端pod

查看详细信息

startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

四、控制器

三种可用的控制器：
使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。

1、Pod 的分类：
自主式 Pod：Pod 退出后不会被创建；
控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

2、控制器类型：
Replication Controller和ReplicaSet；Deployment；DaemonSet；StatefulSet；Job；CronJob；
HPA全称Horizontal Pod Autoscaler

Replication Controller和ReplicaSet
ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet。

1.ReplicaSet–rs控制器

ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet 支持新的基于集合的选择器需求，ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。

编辑ReplicaSet控制器清单文件；
rs控制器：控制副本，确定任何时间都有指定数量的Pod副本在运行，根据标签匹配；
读取该文件新建pod

查看pod信息可以看到由RS控制器管理的三个pod副本成功创建

查看由rs.yaml文件创建的控制器

修改Pod 副本数量为6

可以看到由RS控制器管理的pod副本数量变为6个

更改其中任意副本的标签为myapp，可以看到由RS控制器新建了一个pod副本，但其管理的pod副本数量仍为6个

删除更改过标签的pod副本，RS控制器管理的副本仍为6个

编辑ReplicaSet控制器清单文件rs.yaml，缩小运行的Pod 副本数量为3，设定RS控制器生成的副本使用的镜像为nginx，生成pod之后，可以访问到nginx的发布页面

直接修改RS控制器生成的副本使用的镜像为myapp:v1，生成pod之后，访问到的仍然是nginx的发布页面，说明RS副本控制器只通过标签控制副本数量，不能实现pod副本镜像版本的迭代更新，除非先删除rs.yaml文件，再编辑应用

2.deployments控制器

Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法。
典型的应用场景：用来创建Pod和ReplicaSet；滚动更新和回滚；扩容和缩容；暂停与恢复。
deployments控制器：用来创建pod和ReplicaSet，依靠标签显示，相比较rs可更新容器，可扩容，可暂停和恢复

编辑deployment控制器清单文件，设定deployment控制器生成的三个副本使用nginx镜像

可以查看到deployment控制器的信息

修改yaml文件，副本数增加为6个，和前面RS控制器不同，不需要删除deployment.yaml，再次运行清单deployment.yaml就可以更新


修改镜像为myapp:v1后

由于进行了镜像版本更新，所以会有两个RS控制器，可以看到之前的nginx-deployment-6799xx仍然存在，这是为了版本的回退

此时访问到的是myapp:v1容器的发布页面

修改镜像为myapp:v2后

此时访问到的是myapp:v2容器的发布页面

3.DaemonSet控制器

1、DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

2、DaemonSet 的典型用法：
在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。
在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。
在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等

3、一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。

DaemonSet控制器示例

执行清单，创建pod

查看DaemonSet控制器详细信息

4.StatefulSet控制器

StatefulSet 是用来管理有状态应用的工作负载 API 对象。实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用”。
StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。
StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：
稳定的、唯一的网络标识符。
稳定的、持久的存储。
有序的、优雅的部署和缩放。
有序的、自动的滚动更新。

5.Job控制器

真机将per.tar包传给server1

server1导入镜像perl.tar，并上传到仓库中

执行清单job.yaml

可以看到pod节点先是运行之后又停止了

查看日志

删除清单job.yaml，写一个定时清单

执行定时清单，查看pod节点和日志

完成之后，删除cronjob.yaml清单即可