k8s——4、pod生命周期、控制器

---

使用阿里云主机ECS，
四台主机信息如下：
server1 — 私网IP:10.0.0.2 ----公网IP: 47.108.54.185 ---- 搭建docker仓库harbor
server2 — 私网IP:10.0.0.3 ----公网IP: 47.108.144.231 ---- k8s集群主节点
server3 — 私网IP:10.0.0.4 ----公网IP: 47.108.115.206 ---- k8s集群节点
server4 — 私网IP:10.0.0.5 ----公网IP: 47.108.28.42 ---- k8s集群节点

参考：
https://kubernetes.io/zh/docs/reference/kubectl/cheatsheet/
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands官网文档

pod生命周期

pod的生命周期，，，，，创建pod的时候，首先使用pause镜像（只有几百kb，且永远处于暂停状态）为容器创建基础的运行环境， 例如存储和网络。pause镜像启动之后就可以开始创建容器了。容器的类型有多种。主要分为两种类型：初始化容器（init c）和主容器(main c)。初始化容器的特性是必须按照顺序执行，一个执行完之后才能执行第二个。而且只有容器执行完成之后才能退出。初始化容器是可选的，也可以不创建。初始化容器完成之后执行主容器。主容器指在pod内运行的应用。主容器存在开始和停止两种状态。另外存在存活探针liveness监控容器的完整生命周期，比如检测容器是否存活。还存在就绪探针readiness，检测容器内服务的状态。

• Pod可以包含多个容器，应用运行在这些容器里面，同时Pod也可以有一个或多个先与应用容器启动的Init容器
• Init容器与普通容器非常像，除以下两点：
  – 它们总是运行到完成（运行到完毕）
  – Init容器不支持Readliness，因为他们必须在Pod就绪之前就运行完成，每个Init容器必须运行成功，下一个才能够运行。
• 如果Pod的Init容器失败，k8s会不断的重启该Pod，知道Init容器成功为止。然而，如果Pod对应的restartPolicy值为never，它不会重新启动

Init容器能做什么？

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

重启策略：

** Pod 的Spec中有一个restartPolicy字段，可能的值为Always，OnFailure和Never。默认为Always **

Pod的生命周期：

• 一般Pod不会消失，直到人为的销毁
• 建议创建适当的控制器来创建Pod，而不是直接自己创建Pod。因为单独的Pod在机器故障的情况下没有办法自动复原，而控制器可以

初始化容器Init

探针

参考官方文档：

控制器

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

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

控制器类型：
Replication Controller(RC)和ReplicaSet(RS) RS是下一代的RC，官方推荐使用RS
Deployment 最常用
DaemonSet
StatefulSet
Job
CronJob
HPA全称Horizontal Pod Autoscaler

RS和RC

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

Deployment

Deployment为Pod和RS提供了一个申明式的定义方法
典型的应用场景
– 用来创建Pod和PS
– 滚动更新和回滚
– 扩容和缩容
– 暂停和恢复

直接修改镜像：

DaemonSet

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

• 在每个节点上运行集群储存DaemonSet,将被作为每种类型的daemon使用
• 一个稍微复杂的用法是单独对每种daemon类型使用多个DaemonSet，但具体不同的标志，并且对不同硬件类型具有不同的内存，CPU要求。

StatefulSet

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

Job

执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束

查看官方文档，job控制器还有很多应用

CronJob

CronJob创建基于时间调度的Jobs
一个Cronob对象就像crontab（cron table）文件中的一行，他用cron格式进行编写，并周期性的在给定的调度时间执行Job

HPA

根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放