关于分布式:有了容器为什么kubernetes还需要Pod

12次阅读

共计 1669 个字符，预计需要花费 5 分钟才能阅读完成。

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

当咱们采纳容器化技术的时候，摒弃了传统的物理机或者虚拟机的部署形式，以一种更加轻快，便捷的形式来部署咱们的利用。到容器化的进阶，再加上 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 中的其余容器进行通信

在同一个 kubernetes 集群中的 Pod 就和局域网内的每台服务器一样，他们共享一个网络地址空间，这个网络是通过软件基于实在链路来实现的。所以只有晓得一个 Pod 的 IP 地址就能够进行拜访，这个通信过程不通过网关，在通信上性能十分好。因为 kubernetes 把资源进行了形象，所以 Pod 无论位于哪个服务器节点上，对于同一个集群内的 Pod 来说都一样。

在少数状况下，我还是倡议每个 Pod 运行一个容器，然而如果你的多个容器有相互依赖关系（比方一个容器的启动依赖于另外一个容器），就须要把多个容器部署到一个 Pod。一个 Pod 中运行一个容器更多的是基于利用分层的思考，例如：一个利用的容器须要调用一个数据库的容器，这两个容器应该调配到不同的 Pod 中，不仅仅是为了进步集群机器的利用率，更是为了之后不同档次的扩容。对于 kubernetes 来说，操作和部署的根本单位是 Pod，所以 kubernetes 扩容的单位是 Pod 并非容器，如果咱们的应用层有性能瓶颈，咱们就能够独自的对应用层的 Pod 进行独自扩容，其余层的 Pod 放弃不变，这不仅仅是节俭资金老本的问题了，而是横向扩大的灵活性问题。