【K8S 云原生】Pod资源

目录

一、pod概述：

1、pod概念

2、pod的分类：

二、 pause容器

1、pause容器概念：

2、创建pod的流程：

3、pause容器的作用：

4、pause总结：

三、pod的生命周期：

1、pod的状态：

2、pod的生命周期过程：

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

4、init容器的作用：

5、pod的重启策略

6、总结：

一、pod概述：

1、pod概念

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

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

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

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

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

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

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

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

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

这样做的目的：

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

2、pod的分类：

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

二、 pause容器

1、pause容器概念：

pod内的容器共享资源。

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

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

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

K8S提供了pause容器作用：

1. 为pod内的所有容器提供一个命名空间
2. 启动容器的PID命名空间，每个pod中都作为PID为1的进程（init进程），回收僵尸进程
3. 创建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作用：

1. 网络命名空间共享
2. 只要创建pod就会创建pause，维护pod内部容器的生命周期
3. 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外面再设置一个初始镜像：

1. pod内部有一组容器，挂了一个，就算整个pod失效了么？ 引入pause机制，可以代表整个容器组的状态。可以解决对pod内部整体状态的判断
2. 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无关。不能对外提供访问

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

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"]

6、总结：

pause容器：底层容器/基础容器

提供pod内容器的网络和共享存储，以及pod内容器退出之后资源回收

init容器：人为设定的，业务容器启动之间的必要条件

pod的生命周期：

1. pause基础容器
2. init容器——全部成功退出——业务容器
3. poststart prestop 容器的钩子

启动时命令和退出时的命令

1. 探针：探测容器的健康状态。伴随pod的整个生命周期（除了容器探针）

总结一句话：

pod就是用来封装管理容器的，业务是容器。服务也是容器。端口也是容器

代码007普通

打赏 收藏 海报 链接