pod

是k8s当中最小的资源管理组件

Pod也是最小化运行容器化的应用的资源管理对象

Pod是一个抽象化的概念，可以理解为一个或多个容器化的集合

在一个pod当中运行一个容器，是最常用的方式

在一个pod当中同时运行多个容器，在一个pod当中可以同时封装几个需要耦合（有紧密关联度的）的互相协作的容器，这些多个容器他们时共享资源，也可以互相协作为一个service单位

不论是运行一个还是多个容器，k8s管理的都是pod而不是容器

一个pod内的容器，必须都运行在同一节点上，基于现代容器技术的要求，一个pod运行一个容器，一个容器只运行一个进程，横向扩展，方便扩容缩容

解耦，一个pod内运行多个容器，耦合度太高，一旦一个进程失败，整个pod将全部失败，实现解耦，基于pod可以创建多个副本，实现高可用和负载均衡

管理方便，简单直观

Pod内的容器共享资源，

共享资源：pause底层基础来提供共享资源的机制

Pause容器是基础容器，也可以称为父容器，管理pod内容器的共享操作

Pause还可以管理容器的生命周期

k8s提拱了pause容器：

1. 为pod内的所有容器提供一个统一的命名空间
2. 启动容器的pid的命名空间，每个pod中都作为pid为一的进程（init进程），回收僵尸进程
3. 创建pod时，先创建pause容器，然后在拉取镜像，生成容器，形成pod

类似于lnmp，l是一切的基础，

Docker ps佐证：

拉起了pause，就拉齐了命名空间，节点上的容器还是kubectl管理，pause的作用就是管理kubectl的容器，pod内部要实现通信，

小结：

第一步:master节点发出指令，pod使用的镜像nginx，pod的副本数

第二步:kube-scheduler来分配执行的node节点

第三步：node节点的kubelet收到master指令，拉pause，拉nginx：1.22pod1

第四步：pause容器要先启动，提供命名空间，进程管理pid1，来为pod内的容器提供共享服务，以及容器的进行过程

再次总结pause容器，他是共享两种资源，一个是网络资源，还有个存储资源

网络：每个pod都会分配一个集群内部的唯一IP地址，pod内的容器共享网络，pod在集群内部的IP地址，pod内部的容器可以使用localhost互相通信，pod的容器与外部通信，从共享资源当做进行分配，宿主机的端口映射

Pod可以指定多个volume，pod内的容器共享这些volume.

volume可以是实现数据的持久化

防止pod重新构建之后文件消失

总结：

每个pod都有一个基础容器pause容器

Pause容器对应的镜像是属于k8s集群的一部分，创建集群就会有pause这个基础镜像

Pod里面包含了一个或多个相关的容器（应用）

Pod外再设置一个基础镜像：

1. pod内部有一组容器，挂了一个，就算整个pod失效了吗？引入pause机制，代表整个容器组的状态，可以解决对pod内部容器状态的判断
2. 共享pod内的容器共享IP，共享VOLUME挂载卷，解决了容器网络通信的问题，解决了容器内部文件共享的问题

Pause的作用：

1.只要创建pod，就会创建pause

2.提供网络资源共享和存储资源共享

Pod的分类：

自主试pod：pod是不会自我修复的，如果进程终止，被删除，缺少资源被驱逐，这个pod没有办法自愈，例如：deployment daemanset

控制器管理的pod：滚动升级，可以自愈（自动重启），可以管理pod的数量以及pod的扩缩容

Pod的生命周期（重要）：

1. Pending：挂起

Pod已被创建，但是尚未被分配到运行的node节点（节点上资源不够，需要等待其他pod的调度）

1. running：运行中

Pod已经被分配到了node节点，pod内部的所有容器都已经启动，运行状态良好正常，稳定

1. Complete/successd:表示容器内部的进程运行完毕，正常退出，没有发生错误
2. Faild:pod中的容器非正常退出，发生了错误，需要通过查看详情和日志来定位问题
3. Unknown：由于某些原因，k8s集群无法获取pod的状态，apiserver出了问题
4. Terminating:表示终止中，正在终止，pod正在被删除，里面的容器正在终止过程中，资源回收，垃圾清理，以及终止过程中需要执行的命令

核心图：

创建pod容器的分类：

1. 基础容器：pause
2. Init容器：（初始化容器）：init C

1和2这个过程中，pod的状态就是init：0/3 2/3 3/3

1. 业务容器

Init容器的作用：

环境变量

可以在创建的过程中为业务容器定制好相关的代码和工具

因为init容器独立于业务容器，那就是单独构建的镜像，对业务容器容器不产生任何安全影响

Init容器能以不同于pod内应用容器的文件系统视图运行，secrets的权限，应用容器无法访问secret权限

总结一下：init容器是提供了应用容器运行之前的先决条件，提供了一种阻塞机制，或者延迟机制来控制应用容器的启动，只有前置条件满足，才会创建pod内的应用容器

实验演示全部过程：

解释一下概念：

1. 在pod的启动过程中，容器是按照初始化容器先启动，每个容器必须在下一个容器启动之前，要成功退出
2. 如果运行失败，会按照容器的重启策略进行指定动作，restartPolicy Alawys never onFailure非正常退出才会重启
3. 所有的init容器没有成功之前，pod是不会进入ready状态的

Init容器与service无关，不能对外提供访问

1. 如果重启了pod，所有的init一定会重新执行
2. 如果修改init容器的spec（参数），只限制于image，其他的修改字段都不生效（基于deployment）
3. 每个容器的名称都要唯一，不能重复

查看日志

Pod的重启策略（针对pod内的所有容器，所有容器重启）：

总结今天的内容：

Pause容器：这是底层容器，也可以理解为基础容器

提供pod内容器的网络和存储共享，以及pod内容器退出之后，资源回收

Init容器：人为设定的，业务容器启动之前的必要条件

Pod的生命周期：

1. pause基础容器
2. Init容器---全部成功退出-----才会带业务容器
3. Poststart prestop 容器的钩子

启动时的命令和退出事的命令

4.探针，探测容器的健康状态，伴随pod的整个生命周期（除了启动探针）

大总结：pod到底是什么，就是容器的封装体，业务就是容器，服务也是容器端口也是