欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  网络运营

云原生技术kubernetes调度单位pod的使用详解

程序员文章站 2023-03-23 22:05:53
k8s中的最小调度单位---pod,我们对k8s能够解决的问题做了简单介绍,简单来说,它解决的问题是容器的编排与调度,它的核心价值在于:运行在大规模集群的任务之间,实际上存在着各种各样的关系,这些关系...

k8s中的最小调度单位---pod

     ,我们对k8s能够解决的问题做了简单介绍,简单来说,它解决的问题是容器的编排与调度,它的核心价值在于:运行在大规模集群的任务之间,实际上存在着各种各样的关系,这些关系的处理,才是任务编排和系统管理最困难的地方,k8s就是为了这个问题而生的。

      这句话比较难理解,我们从已有的知识入手,抽丝剥茧,慢慢理解它。我们已经知道,容器的本质是一个进程,它包含三个部分:

云原生技术kubernetes调度单位pod的使用详解

如果说容器是云环境的一个进程,那么你可以将k8s理解成云环境中的一个操作系统。

    在一个操作系统当中,进程并不总是孤立运行的,往往是通过一个进程组的方式运行的。实际部署应用的时候,我们的应用往往不是以孤立的形式跑在docker容器中的,应用之间存在这样那样的关系,有的时候,他们必须跑在同一台机器上,并且相互访问,类似于捆绑式的,例如:如果两个容器之间要发生之间的文件交换、需要共享某些linux namespace等场景。这种关系我们称之为"超亲密关系"。

     基于上面的这个前提,k8s在设计之初,就考虑了这一点,所以它在设计的时候,并不是以容器为最小的调度单位的,而是以pod这个新的概念作为k8s的最小调度单位,而每一个pod中可以包含多个容器,这样,就实现了部署在容器中的应用程序之间就实现了捆绑,也就是他们永远只能被部署在一台机器上,要么部署成功,要么失败,不可能出现一种中间状态。

pod和容器的关系?

   需要注意的是,pod是一个逻辑上的概念,它的本质是一组共享了某些资源的容器。确切的说,同一个pod里面的容器,共享了相同的network namespace,当然,还可以共享挂载卷等资源。

    所谓的共享,并不是依赖,而是对等。

    假如我们有a、b两个容器,如果a依赖b,那么a的启动顺序一定在b之后。如果a、b的地位对等,那么a、b的启动顺序将没有严格要求,这才是真正的共享。那么谁来预先创建被共享的network资源呢?

   在pod中,如果包含了多个应用容器,是需要一个infra容器,将这些应用容器给关联起来的。类似于下面这样:

云原生技术kubernetes调度单位pod的使用详解

在k8s中,infra容器占用了极少的资源,它只运行了一个叫pause的镜像,所以也被称为pause容器,它占用的磁盘大小在100~200kb之间。infra的存在是为了创建network namespace,然后应用容器a和应用容器b就可以加入到这个   network namespace中了。

对于 pod 里的容器 a 和容器 b 来说:
1、它们可以直接使用 localhost 进行通信;
2、它们看到的网络设备跟 infra 容器看到的完全一样;
3、一个 pod 只有一个 ip 地址,也就是这个 pod 的 network namespace 对应的 ip 地址;
4、当然,其他的所有网络资源,都是一个 pod 一份,并且被该 pod 中的所有容器共享;
5、pod 的生命周期只跟 infra 容器一致,而与容器 a 和 b 无关
6、对于同一个 pod 里面的所有用户容器来说,它们的进出流量,也可以认为都是通过 infra 容器完成的

    在这种设计模式下,挂载相同的volume卷就很容易了,只需要在pod的初始化yaml文件中配置volume参数即可,具体内容后续会专门分享。

     对于容器来说,一个容器只能管理一个进程,而不是一个应用。我们在进行应用上云迁移的时候,需要将应用若干个进程,然后去考虑应用模块之间是否具有"超亲密关系",拥有超亲密关系的进程可以部署在一个pod中,其他的进程部署在另外的pod中,用这个思路去拆分应用,才符合容器设计的初衷。

以上就是云原生技术kubernetes调度单位pod的使用详解的详细内容,更多关于kubernetes调度单位pod的使用的资料请关注其它相关文章!