Pod是Kubernetes调度和管理的最小单位，每个Pod都是由若干个容器组成，容器之间共享网络、PID等命名空间，详细内容之前介绍容器原理的时候已经介绍了。

那么为啥k8s 不是直接管理容器，非要引入Pod这个概念呢？这其实和容器的设计理念相关。容器最佳实践是一个容器里面只运行一个进程，这倒并不是因为容器里面不支持多个进程，而且通过这种方式能够更加方便的管理进程。试想，如果将webserver和mysql 部署到一个容器里面，如果升级单个服务，就需要重建整个容器，导致两个服务都要重启。所以，容器的最佳实践是一个容器里面只跑一个容器。

但有些时候有些进程之间需要紧密合作，譬如采集日志的进程需要和被采集的进程在一起，但又不能在一个容器里面，下面列举三个常用的场景

sidercar

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

代理

通过这个本地代理可以分发流量或者做策略限制等，举个例子，我们可以将本地代理做成一个客户端的负载均衡器，所有的流量都可以通过这个本地代理转发，可以完成限流和动态路由等功能，还能协助容器完成redis集群分片等功能，这样可以在业务端无感知的情况下对接到redis集群，业务程序访问本地localhost：2379的地址请求redis服务，通过代理容器和业务容器共享网络命名空间获取到流量从而完成正向代理的功能。如果熟悉Service Mesh的童鞋就会发现，Envoy 代理就是这个原理。

适配器

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

总结来看就是通过Pod的设计方式可以将多个紧密关联的容器共享网络、存储等资源，通过对Pod生命周期的管理，完成对一组容器的生命周期管理，可以设想，在我们的业务主程序退出的时候，它的关联容器也是需要被回收的。