pod资源(yaml)声明式

pod的相关知识

pod的基础概念

pod是k8s中最小的资源管理组件。也是最小化运行容器化的应用的资源管理对象。pod是一个抽象的概念,可以理解为是一个或者多个容器化应用的集合。
在一个pod中运行一个容器是最常用的方式,一个pod当中可以运行多个容器,在一个pod当中可以同时分装几个需要有耦合的互相协作的容器。多个容器共享资源,也可以互相协作组成一个service单位。

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

 一个pod内的容器必须都运行在同一节点。基于现代容器技术的要求,一个pod运行一个容器,一个容器只能运行一个进程。横向扩展,方便扩缩容。
 
 解耦:一个pod内运行多个容器,耦合度太高,一旦一个进程失败,整个pod将全部失败,实现解耦,基于pod可以创建多个副本,实现高可用和负载均衡。管理方便,简单直观。

pod内的容器共享资源,共享机制: pause底层基础容器来提供共享资源的机制。
pause是一个基础容器,也可以称作父容器。管理pod内容器的共享操作。
pause还可以管理容器的生命周期。
k8s提供了pause容器:
1、为pod内的所有容器提供统一的命名空间
2、启动容器的pid(进程号)命名空间,是所有pod中都pid为1的pause进程(init进程),回收僵尸进程。
3、创建pod 时,先创建pause容器,然后再拉取镜像,生成容器,形成pod(创建pause–初始化容器–(创建业务容器)拉取镜像----生成容器)(暂停容器----pause回收容器资源----kubelet回收pause资源)
pod资源(yaml)声明式_第1张图片

第一步 master节点发出指令,pod使用的镜像nginx pod的副本数
第二步 kube-scheduler来分配执行的node节点
第三步 node节点的kubelet收到master指令,拉pause,拉nginx:1.22 pod1
第四步 pause容器先启动,提供命名空间,进程管理pid1 来为pod内的容器提供共享服务以及容器的进程管理。

pause共享两种资源(存储、网络)

网络: 每个pod都会被分配一个集群内部的唯一ip地址,pod内的容器共享网络,pod在集群内部的ip地址和端口。pod内部的容器可以使用localhost互相通信。pod中的容器与外部通信时,从共享的资源当中进行分配,宿主机的端口映射。
存储: pod可以指定共享的volume,pod内的容器共享这些volume,volume可以实现持久化。防止pod重新构建之后文件消失。

总结:
每个pod都有一个基础容器,统称pause容器
pause容器对印的镜像属于k8s的一部分,创建集群都会有pause这个基础镜像。
pod里面包含了一个或者多个相关的容器(应用)

pod外设置一个基础镜像:

1、pod内部有一组容器,挂一个,就算这个pod失效吗??引入pause禁止,代表整个容器的组的状态。可以解决对pod内部容器整体状态的判断。
2、pod内的容器共享IP 共享volume,解决了容器内网络通信的问题,也解决了容器内部容器共享的问题。

pod的分类:

自主式pod:pod不会自我修复,如果进程终止或被删除,缺少资源被驱逐,这个pod无法被自愈。
控制器管理pod:滚动升级,可以自愈,可以管理pood的数量,以及扩缩容。

pod的生命周期:

  1. pending 挂起状态 : pod已被创建,但是尚未被分配到运行的node节点(原因:节点资源不够或等待其他pod节点调度)
  2. running 运行中: pod已经被分配到了node节点,pod内部的所有容器都已经启动,运行状态正常,稳定。
  3. completed 或 successded :容器内部的进程运行完毕,正常退出,没有发生错误。
  4. faild :pod中的容器非正常退出,发生了错误,需要通过查看详细和日志来定位问题。
  5. Unkown:由于某些原因,k8s集群无法获取pod的状态。APIserver出了问题
  6. terminating 在终止中:这个pod正在被删除,里面的容器正在终止。终止过程中,资源回收、垃圾清理、以及终止过程中需要执行的命令。
    pod资源(yaml)声明式_第2张图片

poststart: 表示容器运行时执行的第一个命令
prestop: 容器结束时执行的最后一个命令容器钩子

    探针:
    存活探针、流量探针 都会伴随整个pod的生命周期 如果容器出现问题,容器将不再是ready状态。
    启动探针  容器状态是否正常

创建pod的容器分类:
1、基础容器:pause
2、init(初始化状态): init c
1和2过程中,pod的状态init 1/3
3、业务容器

init容器的作用:

环境变量 检测容器的依赖环境
1、可以在创建的过程中为业务容器定制好相关的代码和工具。
2、init独立于业务容器,他是单独构建的一个镜像,对业务容器不产生任何安全影响。
init容器能不同于pod内应用容器的文件系统视图运行,secrets的权限。应用容器无法访问secerts的权限。

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

pod的状态说明

  1. 在pod启动过程中,容器时按照初始容器先启动,每个容器必须在下一个容器启动之前,要成功退出。
  2. 如果运行失败,会按照容器的重启策略经行指定动作,restartPolicy Always never onFailure(非正常退出才会重启)
  3. 所有的init容器没有成功之前,pod是不会进入ready状态的。init容器与service不能对外提供访问。
  4. 如果重启pod,所有的init容器一定会重新执行
  5. 如果修改init容器的spec(参数),只限制于image,其他的修改都不生效(基于deployment)
  6. 在init每个容器的名称都要唯一,不能重复

pod的重启策略

针对pod内的所有容器,pod的重启策略(基于容器的状态)
Always: 只要容器退出,中时重启,无论容器的状态码是否正确。默认策略,可以不加
Never: 只要容器退出,不论是否正常,都不重启
Onfailure: 只要而且的状态码非0才会重启,正常退出不重启

在deployment的yaml文件当中,重启的策略只能是Always,Always也是默认策略,所以可以不加。
apiVersion: v1
kind: Pod
metadata:
  name: nginx-init
spec:
  restartPolicy: Always Never Onfailure
#pod的重启策略(基于容器的状态)
#Always:只要容器退出,中时重启,无论容器的状态码是否正确。默认策略,可以不加
#Never: 只要容器退出,不论是否正常,都不重启
#Onfailure: 只要而且的状态码非0才会重启,正常退出不重启
#在deployment的yaml文件当中,重启的策略只能说always,可以不写
  containers:
    - name: init-centos
      image: centos:7
      command: ["echo","I am ready"]
#定义了两个init容器,创建完pause之后,分贝运行centos centos1之后,才会拉起nginx

pod资源(yaml)声明式_第3张图片

总结

pause容器: 底层容器/基容器
提供pod内容器的网络和存储共享,以及pod内容器退出之后资源回收。
init容器: 人为设定的,业务容器启动之间的必要条件。
pod的生命周期
1、pasue基础容器
2、init容器------全部成功退出---------业务容器
3、poststart prestop 容器的钩子,启动时命令和退出时的命令
4、探针: 探测容器的健康状态。伴随pod的整个生命周期(除了启动探针)
pod就是用来封装容器的,业务是容器。服务也是容器。端口也是容器。

你可能感兴趣的:(rpc,kubernetes,dubbo)