简介

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

当咱们采纳容器化技术的时候，摒弃了传统的物理机或者虚拟机的部署形式，以一种更加轻快，便捷的形式来部署咱们的利用。到容器化的进阶，再加上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放弃不变，这不仅仅是节俭资金老本的问题了，而是横向扩大的灵活性问题。

更多精彩文章

  • 分布式大并发系列
  • 架构设计系列
  • 趣学算法和数据结构系列
  • 设计模式系列