运维开发网

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

运维开发网 https://www.qedev.com 2021-04-07 16:14 出处:网络 作者: DBA随笔
k8s中的最小调度单位---pod之前的文章中,我们对k8s能够解决的问题做了简单介绍,简单来说,它解决的问题是容器的编排与调度,它的核心价值在于:运行在大规模集群的任务之间,实际上存在着各种各样的关...

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

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

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

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

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

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

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

Pod和容器的关系?

   需要注意的是,Pod是一个逻辑上的概念,它的本质是一组共享了某些资源的容器。确切的说,同一个pod里面的容器,共享了相同iEgTPPk的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的使用的资料请关注我们其它相关文章!

0

精彩评论

暂无评论...
验证码 换一张
取 消