1、pod：k8s中最小的资源管理组件，最小化运行容器化应用的资源管理对象
（1）pod是一个抽象的概念，可以理解为一个或者多个容器化应用的集合
（2）一个pod中运行一个容器是最常用的方式
（3）一个pod中同时运行多个容器，在一个pod中可以同时封装多个需要耦合的互相协作的容器，这些多个容器共享资源，互相协作组成一个service单位
（4）一个pod内的容器，必须都运行在一个node节点上，基于现代容器技术的要求，就是一个pod运行一个容器，一个容器只运行一个进程
①横向扩展，方便扩缩容
②解耦，一个pod内运行多个容器耦合度太高，一旦一个进程失败，整个pod将全部失败，实现解耦，基于pod可以创建多个副本，实现高可用和负载均衡
③管理方便，简单直观
（5）不论运行一个或者多个容器，k8s管理的都是pod而不是容器
2、pod内的容器共享资源（共享机制）
（1）共享机制：pause底层基础容器来提供共享资源的机制
①pause是基础容器，也可以称为父容器，管理pod内容器的共享操作
②pause还可以管理容器的生命周期
（2）k8s提供了pause容器（pause的作用）
①为pod内的所有容器提供了统一的命名空间
②启动容器的pid命名空间（进程号），每个pod中，pause都作为pid为1的进程（init进程），可回收僵尸进程（pause作为所有容器进程的父进程，管理pod内部的容器进程）
③创建pod时，先创建pause容器，然后再拉取镜像生成容器，最后形成pod（pause来分配和回收容器的资源）
（3）kubelet和pause
①kubelet管理node节点上的容器的生命周期，pause管理pod中的容器
（4）设置基础镜像pause的作用
①引入pause机制，代表整个容器组的状态，可以解决对pod内部容器整体状态的判断
②pod内的容器共享ip、volume挂载卷，解决了容器内网络通信的问题，解决了容器内部文件共享的问题
（5）pause容器共享两种资源
| 网络资源 | • 每个pod都会被分配一个集群内部的唯一的IP地址，pod内部的容器共享网络，pod在集群内部的IP地址和端口。 • pod内部的容器可以使用localhost互相通信，pod中的容器与外部通信时，从共享的资源当中进行分配，宿主机的端口映射 |
| 存储资源 | • pod可以指定多个共享的volume，pod内的容器共享这些volume • volume可以实现数据的持久化 • 防止pod重新构建之后文件消失 |
3、总结
（1）每个pod都有一个基础容器，pause容器
（2）pause容器对应的镜像属于k8s集群的一部分，创建集群就会有pause这个基础镜像
（3）pod里面包含了一个或者多个相关的容器（应用）
4、pod的分类
| 自主式pod | 此类pod不会自我修复，若pod内容器的进程终止或被删除、缺少资源被驱逐，这种pod没有办法自愈 |
| 控制器管理pod | 能滚动升级、自愈（自动重启）、管理pod的数量以及pod的扩缩容 |
5、pod的生命周期（重点）
| pod生命周期的状态： | |
| pending | 挂起，pod已被创建，尚未被分配到运行的node节点（原因：节点上资源不够、需要等待其他pod的调度） |
| running | 运行中，pod已经被分配到了node节点，pod内部的所有容器都已经启动，运行状态正常，稳定 |
| complete/ successded | 容器内部的进程运行完毕，正常退出，没有发生错误 |
| failed | pod中的容器非正常退出，发生了错误，需要通过查看详情和日志来定位问题 |
| unknow | 由于某些原因，k8s集群无法获取pod的状态，一般是APIserver出现问题 |
| terminating | 终止中，pod正在被删除，里面的容器正在终止，还要进行资源回收、垃圾清理、以及终止过程中需要执行的命令 |
| crashloopbackoff | pod当中的容器退出，kubelet正在重启 |
| imagepullbackoff | 正在重试拉取镜像（网络问题/镜像仓库挂了） |
| errimagepull | 拉取镜像出错（网速太慢/镜像名称写错/镜像仓库挂了） |
| Evicte | pod被驱赶（node节点的资源不够部署pod，或者是资源不足，kubelet自动选择一个pod驱逐） |
6、创建pod的容器分类
（1）基础容器：pause container
（2）init容器（初始化容器）：init container（init容器运行完即被终止）
①前两个过程中，pod的状态是init:3/3，才会进入业务容器
| init容器的作用 |
| • 环境变量，可以在创建的过程中为业务容器定制好相关的代码和工具 • 检测依赖环境 |
| • init容器独立于业务容器，是单独构建的一个镜像，对业务容器不产生任何安全影响 |
| • init容器能以不同于pod内业务容器的文件系统试图运行，secrets的权限，业务容器无法访问secrets的权限 |
| 总结：init容器提供了业务容器运行之前的先决条件，提供了一种阻塞或者延迟机制来控制业务容器的启动，只有前置条件满足，才会创建pod的业务容器 |
（3）业务容器：main container
7、pod容器创建的过程（实例）
（1）pod创建过程的总结
①在pod的启动过程中，容器按照：初始化容器先启动，每个容器必须在下一个容器启动之前成功退出
②如果运行失败，会按照容器的重启策略进行指定动作，restartPolicy（always、never、onfailure—非正常退出才会重启）
③所有的init容器没有成功之前，pod是不会进入ready状态的，init容器与service无关，不能对外提供访问
④如果重启pod，所有的init容器一定会重新执行
⑤如果修改init容器的spec（参数），只限制于image，其他的修改字段都不生效（基于deployment）
⑥每个容器的名称都要唯一，不能重复
8、k8s的pod的重启策略（基于容器的状态，针对pod内的所有容器）
（1）三种重启策略（docker的重启策略和pod的重启策略的对比）
| k8s的pod的重启策略（重）： | |
| Always | deployment的yaml文件只能是Always，pod的yaml三种模式都可以。不论正常退出还是非正常退出都重启 |
| On Failure | 只有状态码非0才会重启，正常退出是不重启的 |
| Never | 正常退出和非正常退出都不重启 |
| 容器退出了，pod才会重启，pod可以有多个容器，只要有一个容器退出，整个pod都会重启，pod内的所有容器都会重启 | |
| docker的重启策略（重）： | |
| Never | docker的默认策略 |
| On-failure | 非正常退出，才会重启容器 |
| unless-stopped | 只要容器退出就会重启，docker的守护进程启动时，已经停止的容器不再重启 |
| always | 只要容器退出就会重启 |
| 单机部署；docker 集群化部署容器：k8s（至少3个节点） | |
（2）On Failure策略
①状态码正常
②状态码不正常
9、总结
（1）pause容器：底层容器/基础容器
①pause提供pod内容器的网络和存储共享，以及pod内容器退出之后的资源回收
（2）init容器：人为设定的，业务容器启动之前的必要条件
（3）pod的生命周期
①第一步：起pause基础容器
②第二步：init容器全部成功退出，才起业务容器
③poststart、prestop：容器的钩子
④探针：探测容器的健康状态，伴随pod的整个生命周期（除了启动探针）
（4）pod就是用来封装容器的，业务是容器，服务也是容器，端口也是容器
10、yaml文件快速生成（生成特定的模版）
（1）生成deployment的模版：kubectl create deployment nginx1 --image=nginx:1.22 --replicas=3 --dry-run=client -o yaml > /opt/test1.yaml
| --dry-run=client | 只是调用api的对象不执行命令 |
（2）生成pod的模版：kubectl run nginx1 --image=nginx:1.22 --dry-run=client -o yaml > /opt/test1-pod.yaml
（3）生成service的模版：kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort --dry-run=client -o yaml > /opt/test1-service.yaml
11、pod内的容器使用节点资源的限制
（1）request：需要的资源
（2）limit：最高能占用系统多少资源（限制）
①生产中设置limit，需要多少，最多也只能占用多少
（3）k8s中pod的资源限制（两个限制）：CPU、内存
| 创建pod时，一定要给容器设置资源限制 | |
| CPU限制： | |
| CPU的限制格式：1、2、0.5、0.2、0.3（要么是整数，要么是小数点后只能跟一位） ①单位：m（millicores）来表示CPU，CPU的时间分片原理 ②CPU时间分片：通过周期性的轮流分配CPU时间给各个进程，多个进程可以在CPU上交替执行，在k8s中就是表示占用CPU的比率 ③1000m：表示一个CPU ④100m就是最小单位：0.1 | |
| 1 | 可占用1个CPU |
| 0.5 | 可占用半个CPU |
| 0.2 | 可占用一个CPU的五分之一 |
| 0.1 | 是最小单位 |
| 内存限制：单位Ki、Mi、Gi、Ti | |
（4）实例
（5）问题：centos7默认没有持久化命令，默认运行一次即退出，要加command
（6）测试
12、镜像的拉取策略
| IfNotPresent | 默认策略，如果本地镜像已经存在，就不再拉取，本地没有才回去镜像仓库拉取——适用于外部部署，事前要把docker的镜像导入到目标主机 |
| Always | 不论镜像是否存在，创建时（重启）都会重新拉取镜像——一般不用 |
| Never | 仅仅使用本地镜像，本地没有也不会主动拉取——适用于本地部署 |
（1）设置镜像拉取策略
13、pod的容器健康检查（探针probe—重点）
（1）探针：k8s对容器执行的定期检查、诊断，探针将伴随整个容器的生命周期
（2）探针的三种规则（三种方式）
| ①存活探针（livenessProbe）：探测容器是否正常运行 |
| • 如果发现探测失败会杀掉容器，容器会根据重启策略来决定是否重启，不是杀掉pod • 检测失败后，会杀死容器，然后重启 |
| ②就绪探针：探测容器是否进入ready状态，并做好接受请求的准备 |
| • 探测失败，ready 0/1，没有进入ready状态。service会把这个资源对象的端点从当中剔除，service也不会把请求转发到这个pod |
| ③启动探针：只在容器启动时探测 |
| • 只是在容器的启动后开始检测，容器内的应用是否启动成功。在启动探测成功之间，所有的其他探针都会处于禁用状态，但是一旦启动探针结束，后续的操作不再受启动探针的影响。在一个容器当中可以有一个或者多个探针。 |
| 所有探针策略，伴随整个pod的生命周期，除了启动探针 |
（3）probe的检测方法
| probe的检测方法（适用于上述三种探针） | |
| exec | 在容器内部执行命令，如果命令的返回码是0，表示成功 |
| 适用于需要在容器内自定义命令来检查容器的健康状态 | |
| httpGet | 对外部容器发起了一次get请求，可以添加path，指定访问的资源，返回码在200<=x<400之间（200<=x<400），都表示成功 |
| 适用于检查容器能否响应http的请求，web容器（Tomcat、nginx等等） | |
| tcpSocket | 端口，对指定端口上的容器的IP地址进行tcp检查（三次握手） 相当于telnet，检测指定容器的监听端口是否打开，能否和指定的容器监听端口进行通信，端口打开就认为探测成功 |
| 适用于检查特定容器的端口监听状态 | |
| 诊断结果 | 成功，容器通过了，正常运行 |
| 失败，存活探针会重启 | |
| 未知状态，诊断失败 | |
（4）exec检测（以存活探针为例）
①检测正常
②检测不正常
删除文件：kubectl exec -it centos-6d4764b9df-mpzmf -- rm -rf /opt/1.txt
（4 ）以存活探针为例：检测失败后，会杀死容器，然后重启
①exec检测
• 检测正常
• 检测不正常
删除文件：kubectl exec -it centos-6d4764b9df-mpzmf -- rm -rf /opt/1.txt
②httpGet检测（以存活探针为例）
• 检测正常
• 检测不正常
• 指定path，指定访问的资源
不正常的状态：
正常的状态：
③tcpSocket检测（以存活探针为例）
• 正常状态
• 不正常状态
（5）就绪探针（readinessProbe）
①exec检测
• 正常状态
• 不正常状态：kubectl exec -it nginx1 -- rm -rf /etc/passwd
②httpGet检测
• 正常状态
• 不正常状态：
③tcpSocket检测
• 正常状态
• 不正常状态：
（6）启动探针：startupProbe
①启动探针：如果探测失败，pod的状态是not ready，启动探针探测容器失败会重启容器
（7）三种方式结合
①启动探针探测失败
测试：删除/etc/passwd：kubectl exec -it nginx1 -- rm -rf /etc/passwd
启动探针如果没有成功之前，后续的探针都不会执行
②启动探针探测成功
测试：删除/etc/passwd文件：kubectl exec -it nginx2 -- rm -rf /etc/passwd
启动探针成功之后，在pod的生命周期内不会再检测启动探针
重启了pod之后，相当于重新部署了一个初始版的新的容器
测试：删除index.jsp
（8）总结
①在一个yaml文件中可以有多个探针（启动、存活、就绪都针对一个容器）
②启动探针的优先级最高，只有启动探针“成功”，后续的探针才会执行
③启动探针成功之后，后续除非重启pod，否则不会再触发启动探针
④在pod的生命周期当中，一直存在，一致探测的是存活探针和就绪探针
⑤在pod的生命周期当中，后续的条件是满足哪个探针的条件，触发哪个探诊的条件
⑥就绪探针，如果不影响容器运行，status:running，这个时候不会重启，但是，容器退出的话，就绪探针也会重启
14、容器启动和退出时的动作：postStart、preStop
| postStart | 容器启动钩子，容器启动之后触发的条件 |
| preStop | 容器退出钩子，容器退出之后触发的条件 |
| 启动和退回动作的作用： ①启动可以自定义配置容器内的环境变量 ②通知机制，告诉用户容器启动完毕 ③退出时，可以执行自定义命令，删除或者生成一些必要的程序，自定义销毁方式、自定义资源回收的方式以及容器的退出等待时间 | |
（1）实例
①退出容器
