简介
容器并不是软件开发的银弹,没有任何一种技术能解决软件开发中的所有问题
当我们采用容器化技术的时候,摒弃了传统的物理机或者虚拟机的部署方式,以一种更加轻快,便捷的方式来部署我们的应用。到容器化的进阶,再加上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保持不变,这不仅仅是节省资金成本的问题了,而是横向扩展的灵活性问题。
●程序员修神之路--kubernetes是微服务发展的必然产物
●程序员过关斩将--cookie和session的关系其实很简单