k8s之pod
pod中的容器与外部通信时,从共享的资源当中进行分配。引入pause禁止,代表整个容器的组的状态,可以解决对pod内部容器整体状态的判断。②解耦,一个pod内运行多个容器,耦合度太高,一旦一个进程失败,整个pod将全部失败。基于现代容器技术的要求,一个pod运行一个容器,一个容器只运行一个进程。第四步:pause容器先启动,提供命名空间,进程管理pid1 来为pod内的容器提供共享服务以及容器的进
pod是k8s中最小的资源管理组件
pod也是最小化运行容器化的应用的资源管理对象
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进程),回收僵尸进程
pod里面是容器,容器运行的是进程 pid
pause 父进程1 在pod内部管理容器进程
3、创建pod时,先创建pause容器,然后拉取镜像,生成容器,形成pod
第一步:master节点发出指令,pod使用的镜像nginx pod副本数
第二步:kube-scheduler来分配执行的node节点
第三步:node节点的kubelet收到master指令,拉pause,拉ngixn:1.22 pod1
第四步:pause容器先启动,提供命名空间,进程管理pid1 来为pod内的容器提供共享服务以及容器的进程管理
pause容器共享两种资源
网络:每个pod都会被分配一个集群内部的唯一ip地址。pod内的容器共享网络,pod在集群内部的IP地址和端口。pod内部的容器可以使用localhost互相通信。pod中的容器与外部通信时,从共享的资源当中进行分配。宿主机的端口映射
存储:pod可以指定多个共享的volume,pod内的容器共享这些vloume。这些volume可以实现数据的持久化。防止pod重新构建之后文件消失
总结:
每个pod都有一个基础容器pause容器
pause容器对应的镜像属于k8s集群的一部分。创建集群就会有pause这个基础镜像
pod里面包含了一个或者多个相关的容器(应用)
kube-controller-manager
pod外再设置一个基础镜像:
1、pod内部有一组容器,挂了一个,就算这个pod失效了嘛? 引入pause禁止,代表整个容器的组的状态,可以解决对pod内部容器整体状态的判断。
2、pod内的容器共享IP、共享volume挂载卷。解决了容器内网络通信的问题,解决了容器内部文件共享的问题
pod的分类:
1、自主式pod。pod不会自我修复,pod内容器的进程终止,被删除,缺少资源被驱逐,这个pod没有办法自愈
deployment daemanset
2、控制器管理pod。可以自愈(自动重启),可以管理pod的数量以及pod的扩缩容
pod的生命周期
1、Pending 挂起
pod已被创建,但是尚未被分配到运行的node节点
一直panding:①节点上资源不够;②需要等待其他pod的调度
2、Running 运行
pod已经被分配到node节点。pod内部的所有容器都已经启动,运行状态正常、稳定
3、Complete/Successed 容器内部的进程运行完毕,正常退出。没有发生错误
4、Faild pod中的容器非正常退出
发生了错误,需要通过查看详情和日志来定位问题
5、Unkown 由于某些原因,k8s集群无法获取pod状态
一般是APIserver出了问题
6、Terminating 终止中
pod正在被删除,但是里面的容器正在终止
终止过程中,资源回收、垃圾清理、终止过程中需要执行的命令(终止需要时间的原因)
创建pod的容器分类:
1、基础容器:pause
2、init容器(初始化容器):init c
1和2这个过程中,pod的状态叫做init。pod的状态:init:3/3
3、业务容器
init容器的作用:环境变量
①可以在创建的过程中为业务容器定制好相关的代码和工具
②init容器独立于业务容器,他是单独构建的一个镜像,对业务容器不产生任何安全影响
③init容器能以不同于pod内应用容器的文件系统视图运行。secrets的权限,应用容器无法访问secrets的权限
总结:init容器提供了应用容器运行之前的先决条件,提供了一种阻塞或者延迟机制来控制应用容器的启动。只有前置条件满足,才会创建pod的应用容器。(k8s的一种机制)
1、在pod的启动过程中,容器时按照初始化容器先启动,每个容器必须在下一个容器启动之前,要成功退出
2、如果运行失败,会按照容器的重启策略进行指定动作,restartPolicy(Always Never onFailure{非正常退出才会重启})
3、所有都init容器没有成功之前,pod是不会进入ready状态的
init容器与service无关,不能对外提供访问
4、如果重启pod,所有的init容器一定会重新执行
5、如果修改init容器的spe(参数),只限制于image,其他的修改字段都不生效(基于deployment)
6、每个容器的名称都要唯一,不能重复
总结:
pause容器:底层容器/基础容器
提供pod内容器的网络和存储共享,以及pod内容器退出之后的资源回收
init容器不是一定要有,是人为设定的,业务容器启动之前的必要条件
pod的生命周期:①起pause基础容器;②init容器全部成功退出,到业务容器;③poststart prestop 容器的钩子(启动时命令和退出时命令);④探针:探测容器的健康状态。伴随颇多的整个声明周期(除了启动探针)
总结:pod就是用来封装容器的,业务是容器、服务是容器、端口也是容器
更多推荐
所有评论(0)