目录
Pod容器的3种镜像拉取策略：imagePullPolicy（与image字段同一层级）
Pod容器的3种重启策略：restartPolicy（与containers字段同一层级）
Pod容器的资源限制：resources.requests|limits（resources与image字段同一层级）
一.Pod的定义？
Pod：是K8S中创建和管理的最小单位
一个Pod至少包含多少容器？
1个pause容器（基础容器/父容器/根容器）
1个或者多个应用容器（业务容器）
通常一个Pod最好只包含一个应用容器，一个应用容器最好也只运行一个应用进程
同一个Pod里的容器都是运行在同一个node节点上的，并且共享 net mnt uts pid ipc 命名空间
pause容器的作用？（给Pod容器组做环境初始化）
作为linux命名空间共享的基础，为Pod里的其它容器提供网络、存储资源的共享
作为pid=1的init管控类进程管理整个Pod容器组的生命周期
Pod的3种类型：
控制器管理的Pod：由scheduler调度到node节点运行的；被控制器管理的；有自愈能力，一旦Pod挂掉了，会被控制器重新拉起；有副本管理、滚动更新等功能
创建命令：kubectl create deployment .... 控制器有 deployment statefulset deamonset
自主独立的Pod：由scheduler调度到node节点运行的；不被控制器管理的；没有自愈能力，一旦Pod挂掉了，不会被重新拉起；没有副本管理、滚动更新等功能
创建：kubectl run
静态Pod：不由scheduler调度到node节点运行的，而是由kubelet自行管理的；始终与kubelet运行在同一个node节点上；通过向apiserver发送请求无法直接删除的
在node节点的/etc/kubernetes/manifests目录中放置Pod的yaml配置文件，kubelet就会自动根据yaml配置文件创建静态Pod
Pod的3种容器：
pause容器（基础容器/父容器/根容器）：给Pod容器组做环境初始化，功能具体见上
pause容器是Pod最先启动的容器
init容器（初始化容器/init container）：可以在应用容器启动前，为应用容器提供运行依赖环境或工具包；还可以阻塞或延迟应用容器的启动
init容器是在pause容器之后启动的；如果Pod定义了多个init容器，它们是串行启动的，即要在上一个init容器成功的完成启动退出后才会启动下一个init容器
应用容器（业务容器/main container）：提供应用程序业务
应用容器是在所有init容器都成功的完成启动退出后才会启动；如果Pod定义了多个应用容器，它们是并行启动的
Pod容器的3种镜像拉取策略：imagePullPolicy（与image字段同一层级）
IfNotPresent：优先使用node节点本地已存在的镜像，如果本地没有则从仓库拉取镜像。是标签为非latest的镜像的默认拉取策略
Always：总是从仓库拉取镜像，无论node节点本地是否已存在镜像。是标签为latest或无标签的镜像的默认拉取策略
Never：仅使用node节点本地镜像，总是不从仓库拉取镜像。
Pod容器的3种重启策略：restartPolicy（与containers字段同一层级）
Always：当Pod容器退出时，总是重启容器，无论容器退出状态码如何。是默认的容器重启策略
OnFailure：当Pod容器异常退出时（容器退出状态码为非0），才会重启容器；正常退出的容器（容器退出状态码为0）不重启
Never：当Pod容器退出时，总是不重启容器，无论容器退出状态码如何
注意：
deamonset statefulset控制器的Pod容器重启策略只能设置为 Always，自主类型的Pod容器重启策略可选择 Always OnFailure Never
Pod容器的资源限制：resources.requests|limits（resources与image字段同一层级）
resources.requests.cpu|memory|hugepages-<size>|ephemeral-storage|nvidia.com/gpu(需要第三方插件支持) 设置Pod容器创建时需要预留的资源量
resources.limits.cpu|memory|hugepages-<size>|ephemeral-storage|nvidia.com/gpu(需要第三方插件支持) 设置Pod容器能够使用的资源量上限
如果Pod容器的进程使用的内存资源量超过limits.memory设置的值则会引发内存不足OOM错误
QOS服务质量：确定Pod的调度和驱逐优先级
Guaranteed：Pod 中的每个容器，包含初始化容器，必须指定内存、CPU 的 requests 和 limits，并且 requests 和 limits 要相等
Burstable：Pod 中至少一个容器具有内存 或 CPU requests
BestEffort：Pod 中的所有容器都没有指定内存 或 CPU 的 requests和 limits
优先级：Guaranteed > Burstable > BestEffort
Guaranteed (QoS) 的 Pod，其优先级最高，在其资源使用量不超过其 limits 的情况下，可以确保不被杀死
在系统内存资源紧张，且集群中没有 QoS 为 Best-Effort 级别的其它 Pod 时，一旦 Burstable (QoS) 的Pod 使用的资源量超过了其 requests，这些 Pod 就容易被杀死
BestEffort (QoS) 的 Pod，其优先级最低，当系统内存资源紧张时，这些 Pod 底层容器中的进程是最先会被杀死的
kubectl describe -n <命名空间> pods <资源名称> 查看Pod中的每个容器的资源限制的配置
kubectl describe node <node节点名称> 查看node节点的资源总量、每个Pod的资源限制和节点的资源限制总量及比例
Pod容器的3种探针（健康检查）：
存活探针（livenessProbe）：探测Pod容器是否在正常运行。如果探测失败则kubelet杀掉容器，并根据容器重启策略决定是否重启容器
就绪探针（readinessProbe）：探测Pod是否进入就绪状态(ready状态栏是否100%比例)，并做好接收service转发来的请求准备。
如果探测失败则Pod变成未就绪状态(0/1 1/2)，service就会删除相关联的Pod端点，并不再转发请求给处于未就绪状态的Pod
启动探针（startupProbe）：探测Pod容器内的应用进程是否启动成功。在启动探针探测成功之前，存活探针和就绪探针都会处于暂停状态，直到启动探针探测成功为止
如果探测失败则kubelet杀掉容器，并根据容器重启策略决定是否重启容器
探针的3种探测方式：
exec：在容器里执行linux命令，如果命令返回码为0则认为探测成功，如果命令返回码为非0值则认为探测失败
httpGet：向PodIP和指定的端口及URL路径发送HTTP GET请求，如果HTTP响应状态码为2XX 3XX则认为探测成功，如果HTTP响应状态码为4XX 5XX则认为探测失败
tcpSocket：向PodIP和指定的端口发送TCP连接请求（三次握手），如果端口正确且TCP连接成功则认为探测成功，如果TCP连接失败则认为探测失败