k8s---Pod的生命周期

Pod是什么?

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

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

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

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

在一个pod当中可以同时运行多个容器,一个pod当中可以同时封装几个需要耦合的互相协作的容器。这些容器是共享资源的,也可以互相协作组成一个service单位。

不论运行一个容器还是多个容器,k8s管理的都是pod而不是容器。

一个pod内的多个容器必须都运行在同一个node节点上

基于现代容器技术的要求。最常用的就是1个pod运行1个容器,1个容器只运行一个进程目的是为了横向扩展方便扩缩容和解耦这样管理方便,简单直观。

1个pod内运行多个容器,耦合度太高。一旦一个进程失败,整个pod将全部失败。实现解耦,基于pod可以创建多个副本,实现高可用和负载均衡

pause容器

pod内的容器共享资源。

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

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

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

k8s提供了pause容器两大核心功能:

  1. 为pod内的所有容器提供一个的命名空间。只有都在同一个命名空间内才可以共享资源。

  2. 启动容器的pid(进程号)命名空间,每个pod中都作为pid为1的进程(init进程),回收僵尸进程。

  3. 当创建pod时会先创建1个pause容器,然后再拉取镜像生成容器

    pause会在每个pod中创建一个pid为1的进程来管理pod中的进程。包括回收僵尸进程。

kubelet管理node节点

pause管理pod内的容器

1、 master节点发出指令,pod使用的镜像nginx,pod的副本数

2、 kube-scheduler来分配执行的node节点

3、 node节点的kubelet收到master指令,先拉pause再拉nginx镜像

4、 pause容器先启动,提供命名空间,进程管理pid1。来为pod内的容器提供共享服务以及容器的进程管理。

pause容器共享两种资源:网络资源、存储资源

网络资源:每个pod都会被分配一个集群内部的唯一IP地址。pod内的容器共享网络。pod在集群内部的IP地址和端口。

pod内部的容器可以使用localhost互相通信。pod中的容器与外部通信时,从共享的资源当中进行分配,宿主机的端口映射。

pod可以指定多个共享的volume。pod内的容器共享这些vloume。volume可以实现数据的持久化。可以防止pod重新构建后文件丢失。

总结

每个pod都有1个pause基础容器

pause容器对应的镜像属于k8s集群的一部分。创建集群就会有pause这个基础镜像。

pod里面包含了一个或者多个相关的容器(应用)

pod外设置一个基础镜像:

1、 pod内部有一组容器挂了一个,就算pod失效了吗?

引入pause禁止,代表整个容器的组状态。可以解决对pod内部容器整体状态的判断

2、 pod内容器共享IP共享volume挂在卷,解决了容器内网络通信的问题。解决了容器内文件共享的问题。

pod的分类

自主式pod:这个pod不会自我修复。如果pod内容器的进程终止或者被删除或者缺少资源被驱逐。这个pod没有办法自愈。

只要不是基于deployment、daemanset资源控制器创建的都是自主式pod

控制器管理pod:滚动升级,可以自愈(可以自动重启)可以管理pod的数量,以及pod的扩缩容

pod的生命周期状态

1、 pending---挂起:表示pod已被创建,但是尚未被分配到运行的node节点。

可能有几种情况导致:

  1. 节点上资源不够

  2. 需要等待其他pod的调度等

2、 running---运行中:pod已经被分配到了node节点。pod内部的所有容器都已经启动。运行状态良好正常稳定。

3、 complete/successded:表示容器内部的进程运行完毕后正常退出。没有发生错误。

4、 faild:表示pod中的容器非正常退出。发生了错误。需要通过查看详情和日志来定位问题。

5、 UNknown:表示由于某些原因,k8s集群无法获取pod的状态。一般是APIserver出现问题

6、 terminating:表示终止中。表示pod正在被删除,内部容器正在终止。终止过程中涉及到资源回收,垃圾清理以及终止过程中需要执行的命令。所以需要时间终止。

Pod生命周期图:

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

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

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

3、 容器钩子:

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

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

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

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

livenessProbe:存活探针

readinessProbe:流量探针

启动探针

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

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

但是启动探针除外

创建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容器

init容器的作用

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

2、 init容器独立于业务容器。是单独构建的镜像。对业务容器不产生任何安全影响。

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

总结

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

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

2、 如果运行失败会按照容器的重启策略进行指定动作。restartPolicy:Always/Never/onFailure(非正常退出才会重启)

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

init容器与service无关,不能对外提供访问,也不会在service暴露端口。

4、 如果重启pod,所有init容器一定会重新执行。

5、 如果修改init容器的spec(参数)只限制于image。修改的修改字段都不生效。前提基于deployment

6、 每个容器的名称都要唯一且不能重复。

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: apps/v1
kind: Deployment
metadata:
  name: centos2
  labels:
    zyg: test
spec:
  replicas: 1
  selector:
    matchLabels:
      zyg: test
  template:
    metadata:
      labels:
        zyg: test
    spec:
      restartPolicy: Never
      containers:
      - name: centos2
        image: centos:7
        command: ["echo", "123"]

总结

pause容器:是底层容器/基础容器。提供pod内容器的网络和存储共享以及pod内容器退出之后的资源回收。

init容器:不是不一定要存在的。是人为设定的。是业务容器启动之前的必要条件。

pod的生命周期

  1. pause基础容器

  2. init容器-----全部成功退出----才会到主业务容器

  3. 容器钩子:poststart启动时第一条命令、prestop推出时第一条命令

  4. 探针:探测容器的健康状态,伴随pod的整个生命周期。除了启动探针。

总的来说:

pod就是用来封装容器的。业务时容器,服务也是容器,端口也是容器。

  • 26
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
Kubernetes(简称为k8s)中的Pod是最小的可部署单元,用于运行容器化应用程序。Pod生命周期可以分为以下几个阶段: 1. Pending(等待):Pod被创建后,处于Pending状态表示Kubernetes正在为Pod分配资源(如CPU、内存等)。在这个阶段,Pod可能会处于排队等待状态。 2. Running(运行中):一旦Pod获得了所需的资源,它将进入Running状态。在这个阶段,容器正在运行,并且可以被其他组件访问。 3. Succeeded(成功):如果Pod中的所有容器成功完成了它们的任务,那么Pod将进入Succeeded状态。通常情况下,这意味着所有容器都已经退出,并且不会再重新启动。 4. Failed(失败):如果Pod中的任何一个容器退出并返回错误代码,那么Pod将进入Failed状态。通常情况下,这意味着容器无法完成其任务。 5. Unknown(未知):如果无法获取关于Pod当前状态的信息,那么Pod将进入Unknown状态。这可能是由于与集群通信故障或其他未知错误导致的。 除了上述状态之外,Pod还可以通过以下方式进行调整: 1. 创建(Create):通过创建Pod规范文件或使用Kubernetes API来创建Pod。 2. 更新(Update):可以通过更新Pod规范文件或使用Kubernetes API来更新Pod的配置(如镜像版本、资源请求等),这将触发Pod的重新调度。 3. 删除(Delete):可以通过删除Pod规范文件或使用Kubernetes API来删除Pod。一旦Pod被删除,它将不再存在于集群中。 需要注意的是,Kubernetes会根据集群的状态和配置自动处理Pod生命周期,例如自动重新调度失败的Pod或替换不健康的Pod

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值