kubernetes 4（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初始化容器
每次启动之前，直到域名解析成功时，才继续
查看日志
前面pod名字，后面容器名字
一直处于无法解析
目前被分配在server3上操作
刚刚的初始化的日志
是链接形式
初始化容器正式被启动
探针
spec:
containers:
- name: xxx
# startupProbe 健康检测
startupProbe:
failureThreshold: 3 # 检测失败3次表示未就绪
httpGet: # 请求方式
path: /ready # 请求路径
port: 8182 # 请求端口
scheme: HTTP # 请求协议
periodSeconds: 10 # 检测间隔时间
successThreshold: 1 # 检测成功1次表示就绪
timeoutSeconds: 1 # 检测超时时间
# livenessProbe 健康检测
livenessProbe:
httpGet:
path: /index.html
port: 80
initialDelaySeconds: 30 # 初始化时间，此时间内不开始检测
periodSeconds: 10 # 检测间隔时间
successThreshold: 1 # 检查成功1次表示就绪
failureThreshold: 3 # 检查失败3次表示未就绪
timeoutSeconds: 1 # 超时时间
# readinessProbe 健康检测
readinessProbe:
httpGet:
path: /index.html
port: 80
initialDelaySeconds: 30 ##容器启动30秒后才做检查
periodSeconds: 10 每隔10秒检查一次
successThreshold: 1
failureThreshold: 3
timeoutSeconds: 1
1、探针是由 kubelet 对容器执行的定期诊断:
ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
2、每次探测都将获得以下三种结果之一：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。
1.存活探针
livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
重启策略：PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。
休眠30秒
重启
2.就绪探针
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
编辑资源清单文件，设置在生成pod时使用就绪探针检测容器默认发布路径下是否有test.html文件，从而指示容器是否准备好服务请求
存活，但是没就绪
创建此页面之后，就满足条件了，已经就绪。
控制器
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。
因为控制器没有被删除，所有pod重建了
1.ReplicaSet–rs控制器
ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet 支持新的基于集合的选择器需求，ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。
编辑ReplicaSet控制器清单文件；
rs控制器：控制副本，确定任何时间都有指定数量的Pod副本在运行，根据标签匹配；
读取该文件新建pod
replicas:3 副本数为3
删除deployment标签，剩余都是rs
修改标签为myapp，rs以为没有这个副本了，就新生成一个
查看期望状态
改回来之后，又恢复原来的
删除之后会新建，除非修改标签后，再删除
2.deployment 控制器
Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法。
典型的应用场景：用来创建Pod和ReplicaSet；滚动更新和回滚；扩容和缩容；暂停与恢复。
deployments控制器：用来创建pod和ReplicaSet，依靠标签显示，相比较rs可更新容器，可扩容，可暂停和恢复
演示，新版本发布
滚动更新
显示已经更新完成
新的旧的rs都存在，方便回滚
修改回来之后快速回滚
deployment功能：控制版本
可以看出pod属于哪个rs
rs是属于哪个deployment
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 要求。
在私有仓库上传镜像
4.StatefulSet控制器
StatefulSet 是用来管理有状态应用的工作负载 API 对象。实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用”。
StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。
StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：
稳定的、唯一的网络标识符。
稳定的、持久的存储。
有序的、优雅的部署和缩放。
有序的、自动的滚动更新。
5.Job控制器
执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束
可以看到pod节点先是运行（running）之后又停止了（completed）
查看日志
查看详细信息
6.CronJob
Cron Job 创建基于时间调度的 Jobs。
一个 CronJob 对象就像 crontab (cron table) 文件中的一行，它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。
每隔一分钟创建一个
