集美网“服务上云” 一直是一个进行时，在 2010 年 – 2017 年期间，发力点重心都在「自有物理建设」到「IAAS 基础设施即服务」，各个云厂商都在此基础上推出网络产品、数据库产品、存储产品，提供「PAAS」层面的产品来促进上云的过程，我们称为 “服务上云 1.0”
“服务上云 1.0” 本质上就是将自建的物理服务设施迁移到云厂商提供的服务设施，并配备了一大批专业的工具。但在这一过程中，内在的关于开发者所选的服务技术架构，却很少干预触及；目前大部分流通的都是传统服务架构模式。
传统服务架构模式是什么，有什么特点？这里举几个例子大家感受一下：
a. 使用本地文件系统来持久化存储，数据文件和应用的文件混合在一起。
b. 在同一个服务器上运行很多服务，比如 MySQL、Redis 、Nginx 以及一大堆定时任务。
c. 使用大杂烩式的脚本和手工流程进行安装和升级。
d. 配置是存储在文件里的，通常散落在多个位置，并与应用的文件混在一起。
e. 进程间的通信是借助本地文件系统进行的（比如在磁盘上放一个文件，另一个进程来读取），而不是 TCP/IP。
f. 按照单个服务器上只运行一个应用的实例的方式来设计的。
这些特点会在执行维护的过程中暴露出很多问题，比如：
a. 自动化部署很困难，虽然可以通过各种工具来实现，但仍有很大的水分空间存在。
b. 如果需要运行应用的多个不同的实例，很难让多个实例在同一个服务器上同时存在。
c. 如果服务器停机，由于需要手工流程所以需要较长的时间来恢复。
d. 部署新版本的过程基本是手动的，或者大部分是手动的，难以回滚。
e. 很有可能测试环境与生产环境有较大差异，导致一些生产环境问题不能在测试期间发现。
f. 很难通过增加新的实例来进行横向扩展。
这些问题会随着业务的发展日益突出，最终极大的消耗人力成本，也累积了很多风险因素，即使服务设施上云，有强大的环境，内部系统的维护问题始终阻碍和影响高质量的服务。
容器技术，规避了传统服务架构模式所带来的问题，作为一种新的架构模式开始在近几年兴起。
容器服务，就是通过标准化方式，将业务代码和其所依赖的环境资源一起打包成为镜像，然后在服务器中启动一个实例运行这个镜像，就可以提供服务了。
比如你去网吧工作，使用网吧的纯净系统，需要安装自己所需要的办公软件才能够开始正式工作，这里就类比你在传统模式下需要根据服务设施的不同来进行针对性运维，才能够把自己的业务项目运行起来。容器服务在这个例子中就是，你带了一块硬盘（或者一个 U 盘），将你的办公系统存储在其中，到网吧里直接插入你的硬盘，就可以立刻使用熟悉的系统了。
我们总结容器技术的几个特点：
a. 部署容易，可以使用新的容器镜像直接替换整个老版本。
b. 自动化部署也相对容易，可以完全由 CI 来驱动。
c. 部署失败时的回滚只要切换到之前的镜像就行，非常方便。
d. 应用升级不需要去考虑复杂的升级配置流程，不必执行繁琐的步骤。
e. 相同的容器镜像可以在不同的环境中充分测试，再直接部署到生产环境，确保测试环境与生产环境完全一致。
f. 系统更容易从宕机中恢复，因为可以迅速在新硬件资源上启动装有这个应用镜像的新容器，并附加到同一数据源上。
g. 开发人员能在本地以容器的形式，在更逼真的环境里测试新功能。
h. 硬件资源的利用更高效，在单一主机上可以运行多个容器应用。
i. 容器化是支持零停机升级、金丝雀部署、高可用和横向扩展的坚实基础。
容器技术和 Docker 到底是什么关系？Docker 是构建容器的技术工具，是目前流行的。就好比安卓和 IOS（Docker）是手机终端操作系统（容器技术）中比较流行的，因为流行，所以各个厂商都会适配，使得技术方案可以畅行无阻没有门槛。当我们构建的服务越来越多，同一个服务因为并发可能包含多个容器实例，那么如何有效的管理协调多个容器的位置资源？如何处理容器与容器之间的通信？这就需要容器编排技术。
Kubernetes 是目前最流通的容器编排技术，提供 API 来控制容器的执行方式和位置，操作执行 Docker 容器和调节工作负载，解决在调整跨多部伺服器部署多个容器规模时的一些复杂作业。
我们来看一下标准的容器服务需要的配置，其适用于对容器编排非常熟悉的团队使用，可以灵活配置，按照自己的需求来调整
