k8s之Pod的基础（上）
什么是pod？
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为1的进程（init进程），回收僵尸进程（pause是pod的父进程）
pod里面是容器，容器运行的是进程 pid
pause 父进程 1 在pod内部管理容器进程3、创建pod时，先创建pause容器，然后拉去镜像，生成容器，形成pod
第一步：master节点发乎指令，pod使用的镜像nginx pod的副本数
第二步：kube-scheduler来分配执行的node节点
第三步：node节点的kubelet收到master指令，拉pause，拉nginx镜像 pod1
第四步：pause容器先启动，提供命名空间，进程管理pid1 来为pod内的容器提供共享服务以及容器的进程管理pause容器共享两种资源
1、网络 每个pod都会被分配一个集群内部的唯一IP地址，pod内的容器共享网络，pod在集群内部的IP地址和端口 pod内部的容器可以使用localhost互相通信，pod的中容器与外部通信时，从共享的资源当中进行分配，宿主机的端口映射
2、存储 pod可以指定多个共享的volume，pod内的容器共享这些volume，volume可以是实现数据持久化，防止pod重新构建之后文件消失
总结
每个pod都有一个基础容器（pause容器）
pause容器对应的镜像属于k8s集群的一部分，创建集群就会有pause这个基础镜像
pod里面包含一个或者多个相关的容器（应用）
pod外在设置初始镜像（原因）
1、pod内部有一组容器，挂了一个，就算这个pod失效了吗？引入pause机制，代表整个容器组的状态，可以解决对pod内部容器整体状态的判断
2、pod内的容器共享ip 共享volume，解决了容器内网络通信的问题，解决容器内部文件共享的问题
pod的分类
1、自主式pod pod不会自我修复的，pod内容器的进程终止，被删除，缺少资源被驱逐，这个pod没有办法自愈 （deployment daemonset）
2、控制器管理pod 滚动升级，可以自愈（自动重启），可以管理pod的数量以及pod的扩缩容
pod的生命周期
1、pending 挂起状态 pod已被创建，但是尚未被分配到运行的node节点
出现pending原因
节点上资源不够，需要等待其他pod的调度2、running 运行中，pod已经被分配到了node节点，pod内部的所有容器都已经启动，运行状态正常，稳定
3、Complete（successed） 容器内部的进程运行完毕之后，正常退出，没有发生错误
4、faild pod中的容器非正常退出，发生了错误，需要通过查看详情和日志来定位问题
5、UNkown 由于某些原因，k8s集群无法获取pod 的状态，APIserver出了问题
6、terminating 终止中，pod正在被删除，里面的容器正在终止，终止过程中（资源回收，垃圾清理，以及终止过程中需要执行的命令）
初始化容器 pause
初始化容器运行完，而且时成功运行完成之后才会创建pod的业务容器
poststart和prestop（容器钩子）
poststart 表示容器运行时执行的第一个命令
prestop 容器结束时执行的最后一个命令
探针
存活探针 livnessProbe
流量探针 readnessProbe
启动探针
容器状态是否正常
存活探针和流量探针会伴随整个pod的生命周期，如果容器出了问题，pod将不在时ready状态
先有pause在创建初始化容器，初始化创建完毕之后才创建pod的业务容器创建pod的容器分类
1、基础容器 pause
2、init容器（初始化容器） init c
3、业务容器
在master节点
创建基于
vim /opt/init.yml
apiVersion: v1
kind: Pod
metadata:
name: nginx-init
spec:
containers:
- name: nginx
image: nginx:1.22
#定义的业务容器
#定义了两个init容器，分别运行centos centos1之后，才会拉起nginx
initContainers:
- name: init-centos
image: centos:7
command: ["echo","hello,world"]
- name: init-centos1
image: centos:7
command: ["echo","I am ready"]init容器的作用
环境变量
1、可以在创建的过程中为业务容器定制好相关的代码和工具
2、init容器独立于业务容器，它是单独构建的一个镜像，对业务容器不产生任何安全影响
3、init容器能以不同于pod内应用容器的文件系统视图运行，secrets的权限，应用容器无法访问secret的权限
总结
init容器提供了应用容器运行之前的先决条件，提供了一种阻塞或者延迟机制来控制应用容器的启动，只有前置条件满足，才会创建pod的应用容器
1、在pod的启动过程中，容器时按照初始化容器先启动，每个容器必须在下一个容器启动之前，要成功退出
2、如果运行失败，会按照容器的重启策略济宁指定动作，restartPolicy Always never onFailure（非正常退出才会重启）
3、所有的init容器没有成功之前，pod不会进入ready状态的，init容器与service无法，不能对外提供访问
4、如果重启pod，所有的init容器一定会重新执行
5、如果修改init容器的spec（参数），只限制于image，其他的修改字段都不生效（基于deployment）
6、每个容器的名称都要唯一，不能重复
重启策略
apiVersion: v1
kind: Pod
metadata:
name: centos
spec:
restartPolicy: OnFailure
containers:
- name: centos
image: centos:7
command: ["echo","I am ready"]k8s的pod的重启策略（基于容器的状态）
Always 只要容器退出，总是重启，无论容器的状态码是否正常，默认策略，可以不加
Never 只要容器退出，不论是否正常，都不重启
Onfalure 只有容器的状态码非0 才会重启，正常退出不重启
#在deployment的yaml文件当中，重启的策略只能是Always，可以不写总结
pause容器：底层容器（基础容器），提供pod内的网络和存储共享号，以及pod内容器退出之后资源回收
init容器：人为设定的，业务容器启动之间的必要条件
pod的生命周期：
1、pause基础容器
2、init容器----全部成功退出----业务容器
3、poststart prestop 容器的钩子
启动时命令和退出时的命令
4、探针：探测容器的健康状态，伴随pod的整个生命周期（除了启动探针）
pod就是用来封装容器的，业务是容器，服务也是容器，端口也是容器