pod的相关知识
pod是k8s中最小的资源管理组件
pod也是最小化运行容器化的应用的资源管理对象
pod是一个抽象的概念，可以理解为一个或者多个容器化应用的集合。
k8s中pod的两种使用方式
（1）一个pod中运行一个容器。"每个po中一个容器"的模式是最常见的用法:在这种使用方式中，你可以把pod想象成是单个容器的封装，kterentes管理的是Pod而不是直接管理容器。
（2）**在一个Pod中同时运行多个容器。**一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个servie单位。
这些多个容器共享资源，也可以互相协作组成一个service单位。
不论运行一个容器还是多个容器，k8s管理的都是pod不是容器。
一个pod内的多个容器，必须都运行在一个节点上。基于现在容器技术的要求，一个pod运行一个容器，一个容器只运行一个进程。这样做是为了：横向扩展，方便扩缩容。解耦。一个pod内会运行多个容器，耦合度太高，导致整个集群全部失败。实现解耦，基于pod可以创建多个副本，实现高可用和负载均衡。
管理方便，简单直观。
pod内的容器共享资源，共享机制：pause
pause容器是基础容器，也可以称为父容器。管理pod内容器的共享操作。
pause还可以管理容器的生命周期。
k8s提供了pause容器
pause作用
1.为pod内的所有容器提供一个命名空间
2.启动容器的pid命名空间，每个pod中都作为pid为1的进程（init进程），回收僵尸进程。
3.创建pod时，先创建pause容器，然后再拉取镜像，生成容器，形成pod
pid为1，是所有进程的父进程。
每创建好一个pod就会自动生成一个pause。
k8s创建pod的工作流程
- 第一步：master节点发出指令，pod使用的镜像nginx，pod的副本数。
- 第二步：kube-scheduler来分配执行的node节点。
- 第三步：node节点的kubelet收到master，拉pause，拉nginx：1.22 pod1
- 第四步：pause容器先启动，提供命名空间，进程管理管理pid1，来为pod内的容器提供共享服务以及容器的进程管理
pause容器共享两种资源
1.网络资源：
每个pod都会分配一个集群内部的唯一IP地址，pod内的容器共享。pod在集群内部的IP地址和端口。
pod内部的容器可以使用localhost互相通信。pod的中容器与外部同学时，从共享的资源当中进行分配。宿主机的端口映射。
2.存储资源
pod可以指定多个共享的volume，pod内的容器共享这些volume。
volume可以实现数据的持久化。
防止pod重新构建之后文件消失。
pause总结：
每个pod都有一个基础容器--pause。
pause对应的镜像属于k8s集群的一部分。创建集群就会有pause基础镜像。
pod里面包含了一个或者多个相关的容器（应用）
pod外再设置一个初始镜像：
1.pod内部都有一组容器，挂了一个，就算pod失效了吗？引入pause机制，代表整个容器组的状态。
可以解决pod内部容器整体的状态判断。
2.pod内的容器共享IP 共享volume挂载卷。解决了容器内网络通信的问题，解决了容器内部文件共享的问题。
举个不太恰当的例子：kubelect相当于市长，pause相当于区长。kubelect发布指令创建pod，创建pod的具体操作通过pause来完成。pause管理pod内部一系列组件
pod的分类：
自主式pod：
不会自我修复，pod内容器的进程终止，被删除，缺少资源被驱逐，这个pod没有办法自愈。
deployment daemanset
控制器管理pod：
可以滚动升级，可以自愈（自动重启），可以管理pod的数量以及pod的扩缩容。
pod的生命周期
- 1.pending 挂起
pod已被创建，但是尚未被分配到运行的node节点。
原因：节点的资源不够，需要等待其他pod的调度。
- 2.running 运行中
pod已经被分配到了node节点，pod内部的所有容器都已经启动，运行状态正常，稳定。
- 3.complete / successded
表示容器内部的进程运行完毕，正常退出，没有发生错误。
- 4.failed：
pod中的容器非正常退出。发生了错误，需要通过查看详情和日志来定位问题。
- 5.UNknow：
因为某些原因，k8s集群无法获取pod的状态。APIserver出了问题。
- 6.terminating ：
终止中，pod正在被删除，里面的容器正在终止。种植过程中，资源回收，垃圾清理，以及终止过程中需要执行的命令。
创建pod的容器分类
1.基础容器：pause
2.init容器（初始化容器）：init c
1和2这个过程中，pod的状态就算init:0/3
3.业务容器
（绿---》蓝---》黄）
init容器的作用：环境变量
1.可以在创建的过程中为业务容器定制好相关的代码和工具。
2.init容器独立于业务容器，他是单独构建的一个镜像，对业务容器就不产生任何安全影响。
3.init容器能以不同于pod内应用容器的文件系统视图运行。secrets的权限。应用容器无法访问secerts的权限。
总结init：
init容器提供了应用容器运行之前的先决条件，提供了一种阻塞机制或者延迟机制来控制应用容器的启动。
只有前置条件满足，才会创建Pod内的应用容器。
1.在pod的启动过程中，容器是按照初始化容器先启动，每个容器必须在下一个容器启动之前，要成功退出。
2.如果运行失败，会按照容器的重启策略进行指定动作，restartPolicy Always Never onFailure（非正常退出才会重启）
3.所有的init容器没有成功之前，pod是不会进入ready状态。
init容器与server无关，不能对外提供访问。
4.如果重启pod，所有的init容器一定会重新执行。
5.如果修改init容器的spec（参数），只限制于image，其他的修改字段都不生效
6.每个容器的名称都要唯一，不能重复。
实验模拟
cd /opt
vim init.yaml
aplVersion: v1
kind: Pod
metadata:
name: nginx-init
spec:
containrts:
- name: nginx
image: nginx:1.22
#定义的业务容器
#定义了两个init容器，创建完pause之后，分别运行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"]
wq
kubectl apply -f init.yaml
kubectl describe pod nginx-init
kubectl get pod -o wide
aplVersion: v1
kind: Pod
metadata:
name: centos
spec:
restartPolicy: onFailure
#k8s的pod的重启策略
#always:只要容器退出总是重启，无论容器的状态码是否正常。默认策略，可以不加（默认）
#never:只要容器退出，不论是否正常，都不重启
#onFailure:只有状态码非0，才会重启
#在deployment的yaml文件当中，退出策略只能是always
containers:
- name: centos
image: centos:7
command: ["echo","I am ready"]
wq
pod的重启策略
- always:只要容器退出总是重启，无论容器的状态码是否正常。默认策略，可以不加（默认）
- never:只要容器退出，不论是否正常，都不重启
- onFailure:只有状态码非0，才会重启
pod的重启策略的对象是整个pod集群！
总结：
pause容器：底层容器/基础容器
提供pod内容器的网络和存储共享，以及pod内容器退出之后资源回收。
init容器：人为设定的，业务容器启动之间的必要条件。
pod的生命周期：
1.pause基础容器
2.init容器----全部成功退出----业务容器
3.portstart prestop 容器的钩子
启动时命令 和 退出时命令
4.探针：探测容器的健康状态。伴随pod的生命周期（除了启动探针）
容器重启策略
pod用来封装容器，业务是容器，服务也是容器，端口也是容器。
k8s每日检查
kubectl get cs
kubectl get node
kubectl get pod -n kube-system