容器并不是软件开发的银弹，没有任何一种技术能解决软件开发中的所有问题

当我们采用容器化技术的时候，摒弃了传统的物理机或者虚拟机的部署方式，以一种更加轻快，便捷的方式来部署我们的应用。到容器化的进阶，再加上kubernetes对容器的编排技术，使得容器化的利益进一步扩大。但是对于kubernetes来说，直接调度编排管理的基本单位并非容器，而是另外一种结构体。

假设容器中同时运行着多个不相关的进程，这些进程的持续运行，管理，以及输入输出日志会是容器的责任。如果这些不相关的进程同时都有标准的输出，而此时我们很难确定每个进程具体输出了什么内容。另一方面，每个容器是一个逻辑的运行单位，有着自己的命名空间，IP以及端口和其他信息，假如非一个团队开发的不同进程监听了相同的端口号，必将发生资源的争夺冲突。虽然多个进程运行在同一个容器中，无论是通过进程间通信还是通过存储文件进行共享文件都很容易，但是Docker和kubernetes还是期望每个进程都运行在自己的容器中，除非是和自己相关的子进程。如果你的多个进程有着依赖关系（例如：一个进程的启动依赖于另外一个进程），这样的多个进程推荐运行在相同的容器中。

由于不推荐将无关的进程运行在同一个容器中，但是特殊情况下还存在要求多个相关进程运行于同一个容器的需求，kubernetes提供了一种更高级的结构来把容器捆绑在一起，并将这种结构作为调度部署的基本单元，这个结构就是Pod。

Pod是一组并置的容器，是kubernetes中基本的构建模块。但是这并不意味着一个Pod总是包含多个容器，在实际应用中每个Pod只有一个容器是最常见的部署方式。这里要注意一点，虽然对于kubernetes来说，并不关心Pod位于哪个节点上，但是一个Pod的多个容器位于多个节点是不允许的，换句话说，同一个Pod的多个容器总是运行在同一个集群节点上。

kubernetes部署和操作的基本单位是Pod隔离

相同Pod下运行的容器之间可以共享一些资源，但是并非全部资源（话句话说，这些容器并非完全隔离的），kubernetes通过配置可以让同一个Pod内的容器共享相同的linux命名空间和network等资源，所以这些容器共享相同的主机名和网络接口，话句话说，这些容器在Pod中可以进行IPC通信，就像在局域网中一样。既然共享相同的IP和端口号，那么多个容器就不能绑定到相同的端口，否则会出现端口冲突，所以这也是官方推荐一个Pod只运行一个容器的原因之一。

每个Pod都有自己独立的Ip和端口空间，所以不同的Pod内的容器永远不会发生端口冲突。同一个Pod中的容器具有相同的loopback，因此可以通过localhost与同一Pod中的其他容器进行通信

Pod网络在同一个kubernetes集群中的Pod就和局域网内的每台服务器一样，他们共享一个网络地址空间，这个网络是通过软件基于真实链路来实现的。所以只要知道一个Pod的IP地址就可以进行访问，这个通信过程不通过网关，在通信上性能非常好。由于kubernetes把资源进行了抽象，所以Pod无论位于哪个服务器节点上，对于同一个集群内的Pod来说都一样。

Pod使用多个容器

在多数情况下，我还是建议每个Pod运行一个容器，但是如果你的多个容器有互相依赖关系（比如一个容器的启动依赖于另外一个容器），就需要把多个容器部署到一个Pod。一个Pod中运行一个容器更多的是基于应用分层的考虑，例如：一个应用的容器需要调用一个数据库的容器，这两个容器应该分配到不同的Pod中，不仅仅是为了提高集群机器的利用率，更是为了之后不同层次的扩容。对于kubernetes来说，操作和部署的基本单位是Pod，所以kubernetes扩容的单位是Pod并非容器，如果我们的应用层有性能瓶颈，我们就可以单独的对应用层的Pod进行单独扩容，其他层的Pod保持不变，这不仅仅是节省资金成本的问题了，而是横向扩展的灵活性问题。