详解kubernetes pod的编排和生命周期

详解kubernetes pod的编排和生命周期,第1张

详解kubernetes pod的编排和生命周期 目录
  • K8S Master基本架构
  • Pod的编排思想
  • Pod对象的属性和容器的属性?
  • Pod的生命周期

K8S Master基本架构

      K8S的集群运行依赖Master节点和Node节点的通信,为了更好的理解第4部分的Pod生命周期,我们这里先给出K8S Master的简单架构图,后续的文章中,我们会分析Master、Node和Pod之间的关系。

Master的架构图:

其中:

API Server提供了HTTP Rest接口,它是k8s中的所有资源增删改查的唯一入口,也是集群控制的入口;

Scheduler是负责资源调度的进程;

Controller Manager是所有资源对象的自动化控制中心;

Etcd提供资源对象的数据保存服务

其中每个组件都有很多知识点,这里我们只要有个宏观的印象就可以了,后续的文章中,我们会逐一分析。

Pod的编排思想

     上一篇文章末尾,我们提到了应用程序往k8s搬迁过程中的注意事项。这里重申一下,当我们想要把虚拟机上的应用程序搬迁到k8s中时,我们需要用Pod来构建我们应用程序模块。这个时候,比较重要的一点是划分我们应用程序模块,因为容器和虚拟机的设计模式不同,但是为了更好的理解和对比这二者的关系,我们可以设想下面的对应关系:

k8s----- *** 作系统

Pod----虚拟机

容器----进程

1、k8s相当于物理机的 *** 作系统,k8s管理Pod相当于物理机的 *** 作系统管理虚拟机

2、Pod相当于虚拟机,Pod里面可能包含多个容器,对应于虚拟机中的很多进程

3、容器相当于进程,容器的本质,其实就是一个进程。

    有了这样的概念,去理解Pod可能会更加形象。再说回我们的应用程序迁移,假设我们的应用程序存在:

web服务、日志分析、MySQL数据库

三个关键的模块,其中:

web服务和日志分析存在"超亲密关系",因为日志分析模块要消费web服务模块产生的日志,所以他们必须部署在同一个服务器上。反之、web服务和MySQL数据库之间完全可以通过TCP-IP的方式来访问,就没有必要部署在同一台机器上。如果我们用容器运行这个应用,那么web服务需要和日志分析模块打包在同一个Pod中,而MySQL数据库服务单独部署在一个Pod中即可,我们的应用程序迁移到k8s中,可能就是下面的结构:

将不同的进程或者任务,编排在同一个Pod中,这本质上,就是Pod的一种编排思想

Pod对象的属性和容器的属性?

     从上面的分析中不难看出,容器是隶属于Pod中的一个元素,从yaml文件上看,容器就是Pod的整个yaml文件中的一个字段。现在我们看看Pod和容器有哪些重要属性。

先看Pod的属性:

1、凡是调度、网络、存储、安全相关的属性,基本都是Pod相关的。

    调度,自然不用说,Pod是k8s的最小调度单元;网络,同一个Pod中的容器共享Pod的网络;存储,可以通过Pod挂载卷的方式让不同的容器共享Pod的存储;安全,也是以Pod为维度来控制的。

2、凡是跟容器的Linux Namespace相关的属性,也是Pod级别的。

    Pod的设计初衷,就是要容器之间共享Namespace。

3、凡是Pod中的容器要共享宿主机的Namespace,也一定是Pod级别的。

  这个更加容易理解,因为Pod要共享主机的Namespace,那么Pod中的容器必然是要共享相同的Namespace,所以这个设置一定是Pod级别的。

再看Container的2个重要属性:

1、ImagePullPolicy:这个属性定义了镜像拉取的策略,它的默认值是always,也就是每次创建Pod都拉取一次镜像,它还有2个其他的取值,分别是never和ifnotpresent,这两个比较容易理解,一种是从来不拉取镜像,一种是只有在不存在镜像的时候才拉取镜像。这里需要注意一点,如果我们的版本号配置的是latest这种的,那么ImagePullPolicy会被默认值always。

2、Lifecycle:顾名思义,它是在容器的生命周期中执行某些动作,它有两个常见的参数,分别是postStart和preStop,就是在容器开始后或者容器结束前执行的一个特定 *** 作。

Pod的生命周期

Pod的生命周期,主要体现在Pod的API的status部分,Pod的生命周期从开始到结束包含下面的几个过程:

1、Pending,表示Pod的yaml文件已经交给k8s,并且保存在etcd(etcd是k8s中的元信息库)中了。但是它由于调度不成功等原因没有被创建。

2、Running,这个词语具有迷惑性,它表示Pod已经调度成功,跟一台具体的节点服务器绑定,Pod中的容器不一定全部都正常运行了,但是至少有一个在运行。

3、Succeeded,这个状态意味着所有的容器都启动完毕,并且已经退出。

4、Failed,这个很好理解,就是Pod中的容器至少有一个以非0状态退出,也就是异常退出了。

5、Unknow。这是一个异常状态,表示当前Pod的状态不能正常的汇报给kube-apiserver了,这可能是主从节点之间的通信有问题。

如下所示为一个状态为running的Pod

[root@VM-16-13-centos ~]# kubectl get pod
NAME                                READY     STATUS             RESTARTS   AGE
mysql-pd7jr                         1/1       Running            0          118d
myweb-60r22                         1/1       Running            0          80d

[root@VM-16-13-centos ~]# 
[root@VM-16-13-centos ~]# kubectl get pod mysql-pd7jr -o yaml
apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  ...
status:
  ...
  hostIP: 127.0.0.1
  phase: Running
  podIP: 172.17.0.2
  startTime: 2020-11-20T09:01:39Z

以上就是详解kubernetes pod的编排和生命周期的详细内容,更多关于kubernetes pod的编排和生命周期的资料请关注脚本之家其它相关文章!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/897886.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-15
下一篇 2022-05-15

发表评论

登录后才能评论

评论列表(0条)

保存