01
k8s中的最小调度单位---pod
之前的文章中，我们对k8s能够解决的问题做了简单介绍，简单来说，它解决的问题是容器的编排与调度，它的核心价值在于：运行在大规模集群的任务之间，实际上存在着各种各样的关系，这些关系的处理，才是任务编排和系统管理最困难的地方，k8s就是为了这个问题而生的。
这句话比较难理解，我们从已有的知识入手，抽丝剥茧，慢慢理解它。我们已经知道，容器的本质是一个进程，它包含三个部分：
如果说容器是云环境的一个进程，那么你可以将k8s理解成云环境中的一个操作系统。
在一个操作系统当中，进程并不总是孤立运行的，往往是通过一个进程组的方式运行的。实际部署应用的时候，我们的应用往往不是以孤立的形式跑在docker容器中的，应用之间存在这样那样的关系，有的时候，他们必须跑在同一台机器上，并且相互访问，类似于捆绑式的，例如：如果两个容器之间要发生之间的文件交换、需要共享某些Linux Namespace等场景。这种关系我们称之为"超亲密关系"。
基于上面的这个前提，k8s在设计之初，就考虑了这一点，所以它在设计的时候，并不是以容器为最小的调度单位的，而是以pod这个新的概念作为k8s的最小调度单位，而每一个pod中可以包含多个容器，这样，就实现了部署在容器中的应用程序之间就实现了捆绑，也就是他们永远只能被部署在一台机器上，要么部署成功，要么失败，不可能出现一种中间状态。
02
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中，用这个思路去拆分应用，才符合容器设计的初衷。
