海德Hyde

k8s之pod

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，指定访问的资源

不正常的状态：

正常的状态：