目前我有一个传统的部署流程，其工作方式如下：
- 有许多不同的“功能”。每个功能在不同的环境上运行，但存在跨功能通信。
- 有一个“部署器”主机，它将 git 存储库拉到上面，并将代码/资产部署到不同的 ECS 机器上
- “部署者”将通过自动 Bash 脚本将不同的功能部署到不同的机器上
- “部署者” bash 脚本可以指定机器数量以及要为每个功能部署哪些机器
- 每个功能都有一个环境配置文件，实际机器上的功能代码将引用它。“Deployer”bash 脚本将相同的配置文件部署到相同功能（相同环境）的服务器中
- 对于每个功能，负载均衡器将根据平衡规则将请求分发到同一环境的各个机器上
- 每台机器都运行相同的操作系统 CentOS7，并且有一份手册文档用于为每个环境设置所需的实用程序（如 httpd、PHP、NodeJs、MySQL 及其配置文件等）。设置只需进行一次，几个小时即可完成
现在容器化部署的炒作越来越流行，我正在考虑是否应该将我的流程切换到 Kubernetes（或其他替代方案）。
根据我的理解，容器化部署的主要优势和我目前的考虑是
Ability to deploy codes on cross-vendor clouds.
我目前的想法是：既然每个云都支持 CentOS7，那么安装文档和配置文件应该适用于每个云，对吗？（我处于开发阶段，还没有在真正的云供应商中进行过测试，这可能是我误解的重点，但理论上我看不出它怎么不起作用）
Easy to scale the number of machines
我目前的想法是：“Deployer” bash 脚本可以为每个功能指定要自动部署和激活的机器数量。我想不出在使用容器时如何更轻松地进行扩展/缩小
Faster deployment
我目前的想法：我的“Deployer”脚本的主要开销是通过网络复制大型资产文件。我看不出使用容器时如何能大幅减少这一开销。
More integrated local development
我目前的想法：目前的本地开发是使用 vagrant 虚拟机（全部使用 CentOS7）而不是容器完成的，我发现这并没有什么不方便。
另一方面，我了解到，在使用容器时，错误可能很难解决，日志文件也很难管理，这些都是严重的问题。
我对容器还很陌生，我承认我是那些关注炒作并考虑从我熟悉的开发/部署流程转换的人之一。然而，我目前的考虑似乎表明我不应该听信炒作，也许是因为我缺乏知识。我是否错过了什么，如果我转而使用容器，这真的有好处吗？