pod篇:

2024-01-03 14:33:33

pod环节:

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

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

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

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

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

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

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

一个pod内的容器,必须都运行在同一节点。基于现代容器技术的要求,一个pod运行一个容器,一个容器只运行一个进程,横向扩展,方便扩缩容。

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

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

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

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

k8s提供了pause容器

1、为pod内的所有容器提供一个统一的命名空间

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

3、创建pod时先创建pause父进程,然后再拉取镜像生成容器,形成pod,pause来管理这些容器进程c'd

pause是pod内所有的父进程。pod里面是容器,容器运行的是进程,pid是从pause来的 pause为1 ,会在pod内部管理这些容器的进程。

kubelet来管理生命周期,kubelet先创建pause,kubelet才会拉去镜像,形成容器,容器形成pod,pause来给容器进程形成pod,

pause来回收pod进程,kubelet来杀死pause,pod的内部由pause管理

1、master节点发出指令,pod使用的镜像nginx,pod的副本数,2、kube-scheduler来分配执行的node节点 3、node节点的kubelet收到master的指令,先拉pause,在拉nginx的镜像,指定创建几个副本,4、pause容器先启动,提供命名空间,进程管理pid1,为pod内容器提供共享服务以及容器的进程管理 (pause就是初始化容器)

pause总结

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

网络:每一个pod都会被配分配一个集群内部的唯一ip地址,pod内的容器共享网络,就是pod再集群内部的ip地址和他的端口

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

pod和容器共享一个ip地址。

存储

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

总结

每个pod都有一个基础pause容器,pause容器对应的镜像属于k8s集群的一部分,创建集群就会有pause基础镜像,每个pod包含了一个或者多个紧密相关容器(应用)

kube-controller-manager来给pod分配ip地址

1、pod内部有一组容器,挂了一个,整个pod失效了吗?引入pause机制,代表整个容器的组的状态

可以解决对pod内部容器整体进行状态的一个判断

2、核心作用 pod内的容器共享ip,共享volume挂载卷,解决了容器内网络通信的问题,也解决了容器内部文件共享的问题。

pod的分类

自主式pod:这个pod不会自我修复,如果pod内容器的进程终止或者删除或者因为缺少资源被驱逐,这个pod没有办法自愈,不是基于deployment daomanset控制器创建都是自主式pod。

基于控制器创建的就是控制器管理pod:滚动升级、可以自愈,可以管理pod的数量以及pod的扩缩容。

**pod的生命周期**

**pod的状态:**

**1、pending 挂起状态, pod已被创建,但是尚未被分配到运行的node节点 (可能式节点上资源不够,需要等待其他pode的调度)**

**2、running:运行状态,pod已经被分配到节点,而且正在运行,pod内所有容器都已经启动,运行状态正常、稳定**

**3、complete:容器内部的进程运行完毕正常退出,没有发生错误**

**successded:容器内部的进程运行完毕正常退出,没有发生错误**

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

**5、unkown:由于某些原因,k8s集群无法获取pod的状态,APIserver出了问题**

**6、terminating:表示终止中,pod正在被删除,里面的容器正在终止,终止过程中。资源回收,垃圾清理,以及终止过程中需要执行的命令。**

**pod的生命周期**

创建pod的容器分类:

1、基础容器:pause

2、init容器(初始化容器):

3、业务容器(应用容器)

只有再基础容器和init容器过程中,pod状态就是init:0/?,基础容器和init容器都启动之后,才会到业务容器。

init容器的作用:环境变量

1、可以在创建的过程中为业务容器定制好相关的代码和工具,

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

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

总结:init容器提供课应用容器运行之前的先决条件,提供了一种阻塞(延迟)机制来控制应用容器的启动,只有前置条件满足,才会创建pod内的应用容器

这是k8s的一种机制

实验

deployment的重启策略

apiVersion: apps/v1
kind: Deployment
metadata:
  name: centos1
  labels:
    wqb: test
spec:
  replicas: 1
  selector:
    matchLabels:
      wqb: test
  template:
    metadata:
      labels:
        wqb: test
    spec:
      containers:

   - name: centos1
     image: centos:7
     command: ["echo", "123"]



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

2、如果运行失败,会按照容器重启策略进行指定动作,restartPolicy Always、Never、onFailure(非正常退出非0,才会重启)默认是Always

3、所有init容器没有成功之前,pod是不会进入ready状态的,init端口跟service无关,不能对外提供访问

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

5、如果修改init容器的spec(参数),只限制于他的镜像image,其他的修改字段都不生效(基于deployment)

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

pod的重启策略

apiVersion: v1
kind: Pod
metadata:
  name: centos
spec:
  restartPolicy: OnFailure
#k8s的pod的重启策略(基于容器的状态)
#Always只要容器退出,总是重启,无论容器的状态码是否正常这是默认策略可以
不加,Never:只要容器退出,不论是否正常都不重启,OnFailure:只有状态码非0时候才会重启,正常退出是不重启。
  containers:
#定义的业务容器
#定义了两个init容器,创建完pause之后分别运行centos和centos1之后才会拉起nginx

  - name: centos
    image: centos:7
    command: ["echi", "I am ready"]

总结:

1、pause容器:底层容器/基础容器

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

2、init容器:是认为设定的,业务容器(应用容器),启动之前的必要条件

3、pod的生命周期

pause基础容器>init容器(全部成功退出)>业务容器

poststart prestop 容器的钩子

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

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

总结:pod就是封装容器的,业务是容器服务也是容器端口也是容器

文章来源:https://blog.csdn.net/m0_52416577/article/details/135361864
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。