网页文章采集器(为啥k8s不是直接管理容器，非要引入Pod概念呢？)

　　网页文章采集器(为啥k8s不是直接管理容器，非要引入Pod概念呢？)

　　Pod 是 Kubernetes 调度和管理的最小单位。每个 Pod 由多个容器组成。容器共享命名空间，例如网络和 PID。细节在前面介绍容器原理的时候已经介绍过了。

　　那么为什么k8s不直接管理容器，而必须引入Pod的概念呢？这其实和容器的设计理念有关。容器的最佳实践是在一个容器中只运行一个进程。这不是因为容器不支持多进程，这样管理进程更方便。试想一下，如果你将webserver和mysql部署到一个容器中，如果你升级单个服务，你需要重建整个容器，导致两个服务都被重启。因此，容器的最佳实践是在一个容器中只运行一个容器。

　　但有时有些流程需要密切配合。比如采集log的进程需要和采集的进程一起，但是不能在容器中。下面列出了三种常见的情况。

　　边车

　　这个场景是扩展和增强主容器。比如一个nodejs主程序需要定期和代码仓库同步，​​所以需要一个sidecar容器来辅助。这个sidecar容器也可以做成一个具有通用功能的组件（定时同步代码仓库到本地）来完成nginx或者tomcat中html页面的同步，所以sidecar本身可以并且需要独立运行。那么如何让sidecar容器和我们的业务容器共享文件系统，这就需要通过Pod将两个容器挂载到同一个存储（目录）上，并共享这个存储，虽然这个存储可能挂载在两个容器中是不同的路径，但它们的后端本质上是相同的，从而达到数据共享的目的。

　　演戏

　　通过此本地代理，您可以分配流量或进行策略限制。比如我们可以把本地代理做一个客户端负载均衡器，所有流量都可以通过这个本地代理转发，可以完成限流、动态路由等，还可以辅助容器完成redis集群分片等功能，这样它就可以在业务端不知道的情况下连接到redis集群。业务程序访问本地localhost:2379地址请求redis服务，通过代理容器共享网络，业务容器命名空间获取流量完成转发代理功能。如果你熟悉 Service Mesh 的童鞋，你会发现 Envoy 代理就是这个原理。

　　适配器

　　这也是比较常见的功能需求。比如我们在做各种系统监控的时候，需要适配各种监控方式，比如JAVA的JMX，Go的pprof或者网络SNMP等等，我们的采集器会变得很麻烦。如果监控数据可以通过适配同时过滤和整合，可以返回标准定义的数据，这样就可以在不侵入监控对象的情况下完成标准化指标。采集，这个适配器就是也是被监控对象的指标，可以通过访问本地localhost获取。Prometheus设计大量使用这种方法，通过为每类监控对象采集开发相应的导出来完成数据的标准化。

　　综上所述，通过 Pod 的设计，多个密切相关的容器可以共享网络、存储等资源。通过对Pod生命周期的管理，可以完成对一组容器的生命周期管理。可以想象，在我们的业务 main 程序退出的时候，其关联的容器也需要被回收。