2. 接下来，我们看看Pod有哪些主要的应用场景
Pod可以用来承载垂直化的集成应用，比如LAMP，但是Pod的主要目的还是支持需要一起部署、一起管理的辅助进程，包括：
1）内容管理系统，文件和数据加载进程，本地cache管理进程等
2）日志压缩、rotation、备份、快照等
3）数据变化监听、日志和监控适配器，事件分发等
4）控制、管理、配置、升级程序
如果希望了解更多相关解释，推荐一篇关于这种容器组的设计模式的文章，也是微服务架构中很重要的思想：
http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html
下面我们来看几个实际的使用场景:
1）业务服务需要收集日志
某服务模块已经实现了一些核心的业务逻辑，并且稳定运行了一段时间，日志记录在了某个目录下，按照不同级别分别为 error.log、warning.log、info.log，现在希望收集这些日志并发送到统一的日志处理服务器上。
这时我们可以修改原来的服务模块，在其中添加日志收集、发送的服务，但这样可能会影响原来服务的配置、部署方式，从而带来不必要的问题和成本，也会增加业务逻辑和基础服务的藕合度。
如果使用Pod的方式，通过简单的编排，既可以保持原有服务逻辑、部署方式不变，又可以增加新的日志收集服务。
而且如果我们对所有服务的日志生成有一个统一的标准，或者仅对日志收集服务稍加修改，就可以将日志收集服务和其他服务进行Pod编排，提供统一、标准的日志收集方式。
这里的“核心业务服务”、“日志收集服务”分别是一个Docker镜像，运行在隔离的容器环境中。
2）提供ssh、ftp访问容器数据的能力
Docker Hub或者很多第三方的镜像并没有安装sshd的服务，不方便我们进入容器进行配置、代码的修改、调试，很多时候需要重新构建镜像、或者在镜像基础上安装sshd的服务，这都需要时间和一定的学习成本。
而通过Pod的方式，我们就可以将现有镜像和一个ssh、ftp镜像进行编排，获得操作容器内数据的能力。
3）代码自动更新
我们部署了一个node.js的应用，而且部署了几十、上百个节点，那么我希望这个应用可以定时的同步最新的代码，以便自动升级线上环境。
这时，我们当然也不希望改动原来的node.js 应用，可以开发一个Git代码仓库的自动同步服务，然后通过Pod的方式进行编排，并共享代码目录，就可以达到更新node.js应用代码的效果。
并且这个同步服务还可以同其他使用Git代码仓库的服务编排，实现同样的需求。
4）适配不同IaaS平台的环境
我们开发了一个节点管理的agent，这个agent需要读取当前部署环境的一些信息，可以通过底层平台的API实现。
但是，当部署到AWS、阿里云、青云等不同平台时，API就无法统一了。这样，我们可以实现不同平台的适配服务来获取各自的信息，并且和agent通过Pod编排部署，在不改变agent逻辑的情况下，通过服务组合来适配于不同平台。
