k8s中的最小调度单位---pod
之前的文章中 ，我们对k8s能够解决的问题做了简单介绍，简单来说，它解决的问题是容器的编排与调度，它的核心价值在于：运行在大规模集群的任务之间，实际上存在着各种各样的关系，这些关系的处理，才是任务编排和系统管理最困难的地方，k8s就是为了这个问题而生的。
这句话比较难理解，我们从已有的知识入手，抽丝剥茧，慢慢理解它。我们已经知道，容器的本质是一个进程，它包含三个部分：
如果说容器是云环境的一个进程，那么你可以将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容器，将这些应用容器给关联起来的。类似于下面这样：
在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的使用的资料请关注服务器之家其它相关文章！
原文链接：https://mp.weixin.qq.com/s/ifuyvUzvpg4_vJrYRs4yyA
