【K8S 云原生】Pod资源

一、pod概述：

1、pod概念

2、pod的分类：

二、 pause容器

一、pod概述：

1、pod概念

pod是K8S中最小的资源管理组件

pod也是最小化运行容器化的应用的资源管理对象

pod是一个抽象的概念，可以理解为一个或者多个容器化应用的集合

在一个pod中运行一个容器是最常用的方式

在一个pod当中同时运行多个容器，一个pod中可以同时封装几个需要耦合的互相协作的容器

这些多个容器时共享资源，也可以互相协作，组成一个service单位。

不论是运行一个还是多个容器，K8S管理的都是pod而不是容器

一个pod内的容器，必须都运行在同一节点。

基于现代容器技术的要求，就是一个pod运行一个容器，一个容器运行一个进程

这样做的目的：

横向扩展，方便扩缩容
解耦，一个pod内运行多个容器，耦合度太高，一旦一个进程失败，整个pod将全部失败。一个pod运行一个容器，可以实现解耦，可以创建多个副本，实现高可用和负载均衡
管理方面，简单直观

2、pod的分类：

自主式pod：pod不会自我修复，如果pod内容器的进程终止，或者被delete删除、缺少资源被驱逐，这个pod没有办法自愈（只要不是基于控制器创建的都是自主式pod）
控制器管理pod：可以滚动升级，可以自愈（自动重启），可以管理pod的数量，以及扩缩容

二、 pause容器

1、pause容器概念：

pod内的容器共享资源。

共享机制：pause底层基础容器来提供共享资源的机制

pause容器时基础容器，也可以称为父容器。作用就是管理pod内容器的共享操作

pause还可以管理容器的生命周期

K8S提供了pause容器作用：

为pod内的所有容器提供一个命名空间
启动容器的PID命名空间，每个pod中都作为PID为1的进程（init进程），回收僵尸进程
创建pod时，先创建pause容器，然后拉取镜像，生成容器，形成pod（容器不是由pod管理，而是由pause管理容器的进程）

pause相当于pod的基础容器，先有pause再有pod

kubelet 是负责管理整个 Pod 中所有容器的组件，包括pause容器。pause容器在这里充当一个辅助角色，为其他容器提供共享的运行环境。

创建一个nginx pod的过程：先拉取pause容器，在拉取nginx镜像，容器跑起来，pause管理

销毁pod：先销毁nginx，pause回收容器资源，kubelet销毁pause

pause是pod的基础，由pause管理pod内部的容器

总的来说kubelet管理节点上的pod，pause管理pod内的容器

2、创建pod的流程：

第一步：master节点发出指令，pod使用的镜像nginx，pod的副本数

第二步：scheduler来分配执行的node节点

第三步：node节点的kubelet收到master的指令，先拉pause，再拉nginx:1.22，指定副本数

第四步：pause容器先启动，提供命名空间，进程管理pid=1，来为pod内的容器提供共享服务以及容器的进程管理

3、pause容器的作用：

共享网络命名空间： 所有容器都共享同一个网络命名空间，它们可以通过 localhost 相互通信，而无需通过网络进行通信。

共享存储卷： 所有容器可以访问相同的存储卷，这使得它们之间可以共享数据。

维护 Pod 的生命周期： "pause" 容器的存在确保了 Pod 的运行。当 Pod 中的其他容器终止时，"pause" 容器依然存在，从而保持整个 Pod 的存在，直到所有容器都终止。

总体而言，pause容器在 Kubernetes 的 Pod 中扮演了一个关键的角色，为其他容器提供了网络和存储的共享环境，同时通过维护其自身的存在来维护整个 Pod 的生命周期。

pause作用：

网络命名空间共享
只要创建pod就会创建pause，维护pod内部容器的生命周期
pod可以指定多个共享的VOLUME，pod内的容器共享这些VOLUME卷，可以实现数据的持久化，防止pod重新构建之后文件丢失

4、pause总结：

pause容器共享两种资源：网络和存储资源

网络：每个pod都是被分配一个集群内部唯一的IP地址，pod内的容器共享网络，pod在集群内部的IP地址和端口

pod内部的容器可以使用localhost互相通信。pod中的容器与外部通信时，从共享的资源当中进行分配

每个pod都有一个基础容器，pause容器。

pause容器对应的镜像是属于K8S集群的一部分，创建集群的时候就会有pause这个基础镜像

pod里面包含了一个或者多个相关的容器（应用），提供服务的是容器，不是pod

endpoints给pod分配IP地址，网络插件分配网络服务

pod外面再设置一个初始镜像：

pod内部有一组容器，挂了一个，就算整个pod失效了么？引入pause机制，可以代表整个容器组的状态。可以解决对pod内部整体状态的判断
pod内的容器和pod共享ip，共享VOLUME，解决了容器内网络通信的问题，解决了容器内部文件共享的问题

三、pod的生命周期：

1、pod的状态：

1、pending挂起状态：

pod已被创建，但是尚未分配到运行他的node节点

出现原因：

节点上资源不够

需要等待其他pod资源的调度完成

2、Running运行中：

pod已经被分配到了node节点，pod内部的所用容器都已经启动，运行状态正常

3、competed/successded：容器内部的进程运行完毕正常退出，没有发生错误

4、failed：pod中的容器非正常退出。发生了错误，需要通过查看详情或者日志定位问题

5、UNkown：由于某些原因，K8S集群无法获取pod的状态。apiserver出了问题

6、terminating：终止中，pod正在被删除，里面的容器正在终止。终止过程中，涉及资源回收、垃圾清理、终止过程中需要执行的命令

2、pod的生命周期过程：

1、先有pause基础容器才会创建初始化init容器

2、初始化容器运行完毕而且是成功运行完毕后才会创建pod的主业务容器

在容器的生命周期中还伴随着2个容器钩子：

3、容器钩子：

poststart：表示容器运行时执行的第一个命令

prestop：容器结束时执行的最后一个命令

容器生命周期中还有2个探针：

探针：用于检测容器状态是否正常。

livenessProbe：存活探针

readinessProbe：流量探针

启动探针

存活探针和流量探针会伴随整个pod的生命周期

会不停的检测内部主业务容器的情况。只要主业务容器出现问题，整个pod将不再式ready状态。

但是启动探针除外

3、创建一个pod容器过程：

1、基础容器：pause

2、 init容器(初始化容器)：init c

3、业务容器：主服务容器

先启动pause基础容器 > init初始化容器 > pod业务主容器

在pause基础容器和init初始化容器的过程中。pod状态：init 1/3---2/3---3/3

当所有init初始化都启动完毕才会创建业务容器

实验验证：

vim init.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-init
spec:
  containers:
  - name: nginx1
    image: nginx:1.22
#定义的业务容器
  initContainers:
  - name: init-centos1
    image: centos:7
    command: ["echo", "hello,world"]
  - name: init-contos2
    image: centos:7
    command: ["echo", "I am ready"]
#这里定义业务容器和两个init初始化容器
#会先创建完pause初始化容器后
#才会先执行init-centos1输出hello，world。
#再执行init-centos2输出I am ready
#最后才会拉起nginx容器

4、init容器的作用：

环境变量，可以在创建的过程中为业务容器定制好相关的代码和工具。

init容器独立于业务容器，他是单独构建的一个镜像，对业务容器不产生任何安全影响

init容器能以不同于pod内应用容器的文件系统视图运行。secrets的权限。应用容器无法访问secrets的权限

总结：

init容器提供了应用容器运行之前的先决条件，提供了一种阻塞或者延迟机制来控制应用容器的启动。只有前置条件满足，才会创建pod内的应用容器

1、在pod的启动过程中，容器是按照初始化容器先启动，每个容器都必须下一个容器启动之前，要成功退出

2、如果有运行失败，会按照容器的重启策略进行指定动作，restartPolicy：Alawys Never Onfailure（非正常退出才会重启）

3、所有的init容器没有成功之前，pod是不会进入ready状态的

init容器与service无关。不能对外提供访问

如果重启pod，所有的init容器一定会重新执行
如果修改init容器的spec（参数），只限制于image，修其他修改字段都不生效（基于deployment创建的pod）
每个容器的名称都要唯一，不能重复

5、pod的重启策略

实验举例：

apiVersion: v1
kind: Pod
metadata:
  name: centos
spec:
  restartPolicy: OnFailure
#k8s中pod的重启策略，基于容器的状态进行pod的重启
#Always：总是重启。只要容器退出，无论容器的状态码是正常还是不正常。默认策略可以不加
#Never：永不重启。只要容器退出，无论容器是否正常都不重启
#OnFailure：只有容器的状态码非0时候才会重启。正常退出不会重启。
#一般情况下都使用默认Always，只有特殊情况下会使用Never
#在deployment的yaml文件当中，重启的策略只能是Always也是默认策略。所以可以不加。
  containers:
  - name: centos
    image: centos:7
    command: ["echo", "I am ready"]

在deployment的yaml文件当中，重启的策略只能是Always也是默认策略。所以可以不加

实验举例：

apiVersion: v1
kind: Pod
metadata:
  name: centos
spec:
  restartPolicy: OnFailure
#k8s中pod的重启策略，基于容器的状态进行pod的重启
#Always：总是重启。只要容器退出，无论容器的状态码是正常还是不正常。默认策略可以不加
#Never：永不重启。只要容器退出，无论容器是否正常都不重启
#OnFailure：只有容器的状态码非0时候才会重启。正常退出不会重启。
#一般情况下都使用默认Always，只有特殊情况下会使用Never
#在deployment的yaml文件当中，重启的策略只能是Always也是默认策略。所以可以不加。
  containers:
  - name: centos
    image: centos:7
    command: ["echo", "I am ready"]