容器平台选型的十大模式：Docker、DC/OS、K8S 谁与当先？

本文由  网易云 发布。

 

做者：刘超   来自：网易云 基础服务

不管是在社区，仍是在同客户交流的过程当中，总会被问到到底何时该用 Docker？何时用虚拟机？若是使用容器，应该使用哪一个容器平台？
 
显而易见，我不会直接给你们一个答案，而是但愿从技术角度进行分析具体的场景。例如客户是大公司仍是小公司，将部署小集群仍是大集群，倾向于私有云仍是公有云，已经采购了 IaaS 仍是没有 IaaS，IT 运维能力强仍是弱，是否须要物理机、虚拟机、容器的混合部署，是通常的并发系统仍是高并发，这里面所应该作的技术选型都不同。举个例子，若是你是一个初创型的主营业务非 IT 的小公司，天然不该该花大力气在数据中内心面本身搭建一套大规模、高并发、高性能的容器平台。
 
接下来，首先，咱们来谈下什么状况下应该使用 Docker 的问题。
 

 
如上图所示，左面是咱们常常挂在嘴边的所谓容器的优点，可是虚拟机都能一一怼回去。
 
若是部署的是一个传统的应用，这个应用启动速度慢，进程数量少，基本不更新，那么虚拟机彻底可以知足需求。
 
○ 应用启动慢：应用启动 15 分钟，容器自己秒级，虚拟机不少平台能优化到十几秒，二者几乎看不出差异；
○ 内存占用大：动不动 32G，64G 内存，一台机器跑不了几个；
○ 基本不更新：半年更新一次，虚拟机镜像照样可以升级和回滚；
○ 应用有状态：停机会丢数据，若是不知道丢了什么，就算秒级启动也没有用，照样恢复不了，并且还有可能由于丢数据，在没有修复的状况下，盲目重启带来数据混乱；
○ 进程数量少：两三个进程相互配置一下，不用服务发现，配置不麻烦
 
若是是一个传统应用，根本没有必要花费精力去容器化，由于白花了力气，享受不到好处。
 

 
那么什么状况下，才应该考虑作一些改变呢：
 
传统业务忽然被互联网业务冲击了，应用总是变，三天两头要更新，并且流量增大了，原来支付系统是取钱刷卡的，如今要互联网支付了，流量扩大了 N 倍。
 
这种状况下就只能：拆。
 
拆开了，每一个子模块独自变化，相互影响变少。
拆开了，原来一个进程扛流量，如今多个进程一块儿扛。
 
这被称为微服务。
 

 
微服务场景下，进程多，更新快，因而出现 100 个进程，天天一个镜像。
 
容器乐了，每一个容器镜像小，没什么问题，虚拟机哭了，由于虚拟机每一个镜像太大了。
 
因此微服务场景下，能够开始考虑用容器了。
 

 
这时虚拟机又怒了，我不用容器了，微服务拆分以后，用 Ansible 自动部署是同样的。
 
这从技术角度来说没有任何问题，问题是从组织角度出现的。通常的公司，开发会比运维多得多，开发写完代码就不用管了，环境的部署彻底是运维负责，运维为了自动化，写 Ansible 脚原本解决问题。
 
然而这么多进程，又拆又合并的，更新这么快，配置老是变，Ansible 脚本也要常改，天天都上线，不得累死运维。
 
因此在如此大的工做量状况下，运维很容易出错，哪怕经过自动化脚本。这时，容器就能够做为一个很是好的工具运用起来。
 
除了容器从技术角度，可以使得大部分的内部配置能够放在镜像里面以外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕以后，就须要考虑环境部署的问题，而不能当甩手掌柜。
 
这样作的好处就是，虽然进程多，配置变化多，更新频繁，可是对于某个模块的开发团队来说，这个量是很小的，由于 5-10 我的专门维护这个模块的配置和更新，不容易出错。
 
若是这些工做量全交给少数的运维团队，不但信息传递会使得环境配置不一致，部署量也会大很是多。
 
容器是一个很是好的工具，就是让每一个开发仅仅多作 5% 的工做，就可以节约运维 200% 的工做量，而且不容易出错。
 
然而原来运维该作的事情开发作了，开发的老大愿意么？开发的老大会投诉运维的老大么？
 
这就不是技术问题了，其实这就是 DevOps，DevOps 不是不区分开发和运维，而是公司从组织到流程可以打通，看如何合做，边界如何划分，对系统的稳定性更有好处。
 
因此微服务、DevOps、容器是相辅相成，不可分割的。不是微服务，根本不须要容器，虚拟机就能搞定，不须要 DevOps，一年部署一次，开发和运维沟通再慢都能搞定。
 
因此，容器的本质是基于镜像的跨环境迁移。
 
镜像是容器的根本性发明，是封装和运行的标准，其它什么 namespace，cgroup，早就有了，这是技术方面。
 
在流程方面，镜像是 DevOps 的良好工具。
 
容器是为了跨环境迁移的，第一种迁移的场景是开发、测试、生产环境之间的迁移。若是不须要迁移，或者迁移不频繁，虚拟机镜像也行，但老是要迁移，带着几百 G 的虚拟机镜像，太大了。
 
第二种迁移的场景是跨云迁移，跨公有云，跨 Region，跨两个 OpenStack 的虚拟机迁移都是很是麻烦，甚至不可能的，由于公有云不提供虚拟机镜像的下载和上传功能，并且虚拟机镜像太大了，一传传一天。
 
因此跨云场景下，混合云场景下，容器也是很好的使用场景。这也同时解决了仅仅私有云资源不足，扛不住流量的问题。
 
因此这是我认为的容器的本质，是最终应该使用容器的正确姿式，固然一开始你不必定彻底按照这个来。
 

模式一：公有云虚拟机

 
适合场景：初创公司，无信息安全担心
 
若是您是一家初创公司，人员少，IT 运维能力不足，要部署的系统不多，可以花在 IT 系统上的资金有限，固然应该选择公有云的虚拟机部署，它可以解决您的以下问题：
 
○ 基层 IT 资源的管理交给公有云平台，公司自身运维人员仅须要基本的 Linux 能力；
○ 少许的部署系统，例如 10 台如下的虚拟机，每每替换一个 war，重启 Tomcat 就能解决，若是稍微虚拟机多一点 10 到 20 台，Ansible 脚本能够很好地解决这个问题；
○ 公有云按量按时收费，能够在花费不多的状况下启动，而且在业务飞速扩展的时候，迅速申请大量虚拟机；
 
这里所说的信息安全担心，真的仅仅是心理的担心，公有云每每有大量的安全机制来保证每一个租户的安全隔离，只要用好了这些机制，公有云的安全性绝对大于通常公司本身搭建的数据中心，当客户在说要安全的时候，客户在想什么？ 这篇文章讲到了绝对的端到端解决方案。
 
这里贴张图说明公有云的安全性：
 

 

公有云为支撑自身高并发业务积累了更强的安全防御能力和更多的安全防御经验：

 
○ 多线 BGP，外网线路冗余
○ 高吞吐量的 DDoS 外网防御
○ 更完善的防火墙，入侵检测，WAF
○ 更完善的流量清洗规则
 

公有云为支撑自身高并发业务推出了更安全、更高可靠、更高可用的 PaaS 服务：

 
数据库：
○ 高可用：主备切换数据零丢失
○ 高可靠：同城双活，异地备份
○ 安全性：访问控制，IP 白名单
 
对象存储：
○ 高可靠：超大容量，三份备份，异地同步
○ 安全性：访问控制，防盗链
 

公有云为支撑自身高并发业务推出更完善的监控运维的系统，流程，经验：

 
完善的监控系统，保障大促期间系统故障的快速定位和排障
保障大促可以极大的提高和训练一支有经验的运维团队
大促的业务层面的数据对运维也是机密的，须要流程保障

 

道高一尺魔高一丈，公有云为保证自身业务的安全性对云平台不断升级：

 
○ 愈来愈强的 DDoS 防御
○ 愈来愈完善的防火墙规则
○ 最新的云平台安全功能和机制
○ 不断更新的虚拟机和容器镜像建设漏洞
○ 不断更新的病毒库
 

模式二：无 IaaS，裸用容器

 
适用场景：初创公司无 IaaS，有信息安全担心
 
可是即使如此，仍是有初创公司或者初创项目，也许由于心理方面，也许由于合规方面，很是担忧信息安全问题，仍是但愿采起部署在本身机房的方式。
 
但因为是初创公司，在机房里面通常是不能部署 IaaS，由于 IaaS 平台的运维难度，优化难度更大，没有一个 50 人的团队根本玩不起来，因此通常在使用容器以前，采用的是物理机部署的方式，当物理机数目很是小，好比部署 5 到 10 个应用的时候手动部署或者简单脚本部署就能够，可是一旦到了 20 个应用，手动部署和简单脚本就很是麻烦了：
 
○ 运维人员比例低，而应用相对较多
○ 部署在同一个物理机上的应用多，配置冲突，端口冲突，互相链接，运维须要一个 excel 去管理，还容易出错
○ 物理机容器被脚本和 Ansible 改的乱七八糟，难以保证环境一致性，重装物理机更加麻烦
○ 不一样的应用依赖不一样的操做系统和底层包，千差万别
 
这个时候，能够试一下裸用容器，即在原来的脚本，或者 Ansible 里面，将启动进程，改成使用 Docker run，能够有如下的做用：
 
○ 配置，端口隔离，冲突减小
○ 基于容器部署，使得环境一致性，安装和删除干干净净
○ 不一样的操做系统和底层包，均可以用容器镜像搞定
 
在这个阶段，最简单的方式就是把容器当作虚拟机来使用，也即先启动容器，而后在里面下载 war 包等，固然也能够更进一步，将 war 包和配置直接打在容器镜像里面，这样须要一个持续集成的流程了，不只仅是运维的事情，开发也要参与其中。
 
在这个阶段，网络的模式可使用桥接打平的方式。
 

 
这种方式好处是访问 Docker 和访问物理机同样，可很方便地实现 Docker 里面和物理机里面的互通，兼容原来部署在物理机上的应用。
 
固然 Bridge 的性能通常，若是性能要求比较高，可以使用 SR-IOV 网卡嵌入容器内。
 

 

模式三：有 IaaS，裸用容器

 
适用场景：创新项目，引入 DevOps 流程
 
有一些公司规模大一些，已经采购了 IaaS，只不过有一些创新的项目须要部署，这种状态下，基本虚拟机已经可以知足需求，并且因为可以运维 IaaS，IT 能力比较强，通常也采用了 Ansible 等部署工具。
 
这种状况下，使用容器的动力相对比较少，然而容器也是可以带来必定好处的，就是 DevOps。
 
创新项目迭代速度比较快，若是有比较多的创新项目，对运维的压力也是很是大的，这里的裸用容器和模式二的裸用容器不一样的是，不是拿容器当作虚拟机来用，而是将容器当作交付物来用。
 
虽然容器化对于运维的整个过程来说改进有限，可是关键就是要开发写一个 Dockerfile，这一点很是重要，意味着运行环境的配置提早到开发，而非直接交到运维，也即上面说的，开发 5% 的工做量增长减小大量运维工做，容器环境原子性升级回滚使得停服时间变短，能够保持开发、测试、运维环境的一致性。
 

 

模式四：使用 Docker Swarm Mode

 
适用场景：发展中公司，中等规模集群
 
当集群规模超过 50 台时，裸用容器已经很是难受了，由于网络、存储、编排、服务发现等所有要靠本身的脚本或 Ansible 来搞定，是时候引入容器平台了。
 
当容器平台规模不是很大时，Docker Swarm Mode 仍是比较好用的：
 
○ 集群的维护不须要 Zookeeper，不须要 Etcd，本身内置
○ 命令行和 Docker 是同样的，用起来顺手
○ 服务发现和 DNS 是内置的
○ Docker Overlay 网络是内置的
 
总之 docker 帮你料理好了一切，你不用太关心细节，很容易就可以将集群运行起来。
 
并且能够经过 docker 命令，像在一台机器上使用容器同样使用集群上的容器，能够随时将容器当虚拟机来使用，这样对于中等规模集群，以及运维人员仍是比较友好的。
 
固然内置的太多了也有缺点，就是很差定制化，很差 Debug，很差干预。当你发现有一部分性能不行时，你须要改整个代码，所有从新编译，当社区更新了，合并分支是很头疼的事情。当出现问题时，因为 Manager 大包大揽干了不少活，不知道哪一步出错了，反正就是没有返回，停在那里，若是重启整个 Manager，影响面又很大。
 

 

模式五：使用 Marathon 和 Mesos

 
使用场景：万节点集群，多定制
 
当集群规模大一些，几百个节点时，不少人就不肯意使用 Docker Swarm Mode 了，不少的选择是既没有用 DC/OS，也没有用 Kubernetes，而是仅仅用了 Marathon 和 Mesos。
 
由于 Mesos 是一个很是优秀的调度器，它的双层调度机制可使得集群规模大不少。
 
Mesos 的调度过程如图所示：
 

 
Mesos 有 Framework、Master、Agent、Executor、Task 几部分组成。这里面有两层的 Scheduler，一层在 Master 里面，allocator 会将资源公平的分给每个 Framework，二层在 Framework 里面，Framework 的 scheduler 将资源按规则分配给 Task。
 
其它框架的调度器是直接面对整个集群，Mesos 的优点在于，第一层调度先将整个 Node 分配给一个 Framework，而后 Framework 的调度器面对的集群规模小不少，而后在里面进行二次调度，并且若是有多个 Framework，例若有多个 Marathon，则能够并行调度不冲突。
 
详细的调度机制很是复杂，能够看 号称了解 mesos 双层调度的你，先来回答下面这五个问题！这篇文章。
 
并且 Mesos 的架构相对松耦合，有不少能够定制化的地方，从而运维人员能够根据本身的须要开发本身的模块。详细的定制方式看文章 定制化 Mesos 任务运行的几种方法。
 
这也是不少优秀的公司使用 Marathon 和 Mesos 的缘由。
 
例如爱奇艺、去哪儿、携程、当当等都选择了使用 Mesos，须要提一下的是，你们若是参加社区，能发现裸用 Marathon 和 Mesos 的不少，可是整个 DC/OS 都用得比较少，而用 Marathon 和 Mesos 每每不能解决一些问题，于是这些 IT 能力很是强的互联网公司作了大量的本身的定制化，增长了 Marathon 和 Mesos 的外围模块。
 

模式六：使用开源 Kubernetes

 
使用场景：千节点集群，少定制
 
Kubernetes 模块划分得更细，模块比较多，比起裸 Marathon 和 Mesos 来说功能丰富，并且模块之间彻底的松耦合，能够很是方便地进行定制化。
 

 
并且 Kubernetes 的数据结构的设计层次比较细，很是符合微服务的设计思想。例如从容器->Pods->Deployment->Service，原本简单运行一个容器，被封装为这么多的层次，每一个层次有本身的做用，每一层均可以拆分和组合，这样带来一个很大的缺点，就是学习门槛高，为了简单运行一个容器，须要先学习一大堆的概念和编排规则。
 
可是当须要部署的业务愈来愈复杂时，场景愈来愈多时，你会发现 Kubernetes 这种细粒度设计的优雅，使得你可以根据本身的须要灵活的组合，而不会由于某个组件被封装好了，从而致使很难定制。例如对于 Service 来说，除了提供内部服务之间的发现和相互访问外，还灵活设计了 headless service，这使得不少游戏须要有状态的保持长链接有了很好的方式，另外访问外部服务时，例如数据库、缓存、headless service 至关于一个 DNS，使得配置外部服务简单不少。不少配置复杂的大型应用，更复杂的不在于服务之间的相互配置，能够有 Spring Cloud 或者 Dubbo 去解决，复杂的反而是外部服务的配置，不一样的环境依赖不一样的外部应用，External Name 这个提供了很好的机制。
 
包括统一的监控 cadvisor，统一的配置 confgMap，都是构建一个微服务所必须的。
 
然而 Kubernetes 当前也有一个瓶颈——集群规模还不是多么大，官方说法是几千个节点，因此超大规模的集群，仍是须要有很强的 IT 能力进行定制化，这个在模式七中会说一下咱们在网易云上作的事情。可是对于中等规模的集群也足够了。
 
并且 Kubernetes 社区的热度，可使得使用开源 Kubernetes 的公司可以很快地找到帮助，等待到新功能的开发和 Bug 的解决。
 

模式七：深刻掌握使用 Kubernetes

 
使用场景：万节点集群，IT 能力强
 
随着 Kubernetes 使用规模的愈来愈大，大型的公司能够对 Kubernetes 进行必定的定制化，从而能够实现万节点甚至更大规模的支撑，固然须要 IT 能力比较强，网易在这方面有不少的实践。
 

从 APIServer 看集群的规模问题

 
随着集群规模的扩大，apiserver 的压力愈来愈大。
 

 
由于全部的其余组件，例如 Controller、Scheduler、客户端、Kubelet 等都须要监听apiserver，来查看 etcd 里面的变化，从而执行必定的操做。
 
不少人都将容器和微服务联系起来，从 Kubernetes 的设计能够看出，Kubernetes 的模块设计时很是的微服务化，每一个进程都仅仅干本身的事情，而经过 apiserver 的松耦合关联起来。
 
而 apiserver 则很像微服务中的 api 网关，是一个无状态的服务，能够很好地弹性伸缩。
 
为了应对 listwatch，apiserver 用了 watchcache 来缓解压力，然而最终的瓶颈仍是在 etcd 上。
 
最初用的是 etcd2，这时候 listwatch 每次只能接受一个事件，因此压力很大。为了继续使用 etcd2，则须要使用多个 etcd2 的集群来解决这个问题，经过不一样的租户分配到不一样的 etcd2 集群来分担压力。
 
未来会迁移到 etcd3 有了事件的批量推送，可是从 etcd2 到 etcd3 须要必定的迁移工做。
 

经过优化 Scheduler 解决并行调度的问题

 
大的资源池的调度也是一个很大的问题，由于一样一个资源只能被一个任务使用，若是并行调度，则存在两个并行的调度器同时认为某个资源空闲，因而同时将两个任务调度到同一台机器，结果出现竞争的状况。
 
为了租户隔离，不一样的租户是不共享虚拟机的，这样不一样的租户是能够参考 Mesos 机制进行并行调度的。由于不一样的租户即使进行并行调度，也不会出现冲突的现象，每一个租户不是在几万个节点中进行调度，而仅仅在属于这个租户的有限的节点中进行调度，大大提升了调度策略。
 

 
而且经过预过滤无空闲资源的 Node，调整 predicate 算法进行预过滤，进一步减小调度规模。
 

经过优化 Controller 加快新任务的调度速度
 

 
Kubernetes 采用的是微服务常使用的基于事件的编程模型。
 
当有增量事件产生时，则 controller 根据事件进行添加、删除、更新等操做。
 
但基于事件模型的一个缺点是，老是经过 delta 进行事件触发，过了一段时间，就不知道是否同步了，于是须要周期性地 Resync 一下，保证全量的同步以后，而后再进行增量的事件处理。
 
然而问题来了，当 Resync 时，正好遇到一个新容器的建立，则全部的事件在一个队列里面，拖慢了新建立容器的速度。
 
经过保持多个队列，而且队列的优先级 ADD 优于 Update 优于 Delete 优于 Sync，保证相应的实时性。
 

模式八：深刻掌握使用 DC/OS

 
使用场景：万节点集群，IT 能力强
 
前面说过 Mesos 因为自己独特的调度机制，从而支撑的集群规模比较大，可是大多数使用 Mesos 的公司都没有使用 DC/OS，而是裸使用 Marathon 和 Mesos 外加本身定制开发的一些组件。
 
Mesos 能够支持当集群规模很是大，单个 Marathon 的性能不足以支撑时，可使用本身的 Framework 机制，使得不一样的租户使用单独的 Marathon 来解决问题。
 

 
后来 DC/OS 在最基础的 Marathon 和 Mesos 之上添加了不少的组件，如图所示，如今已经很是丰富，例如 DCOS 的客户端 (kubectl)、API 网关 admin router (相似 apiserver)、服务发现 minuteman(相似 kube-proxy)、Pod 的支持、CNI 插件的支持、存储插件的支持等，和 Kubernetes 已经很是像了。
 
不少公司裸用 Marathon 和 Mesos 而没有进一步使用 DC/OS，多是由于和核心组件 Mesos 已经通过大规模生产性支撑不一样，这些外围的组件也是新的，对其稳定性也是有必定的顾虑，因此须要比较长的学习曲线，而且对于这些新的组件有很是好的把控，才敢上生产。
 
因此从这个角度来说，虽然 Mesos 的稳定性和大规模无容置疑，但就整个 DC/OS 来说，和 Kubernetes 从功能和稳定性来说，在伯仲之间，都须要使用者有强大的 IT 能力，对于开源软件的各个模块很是熟悉，甚至可以作必定的代码修改和 Bug fix，才敢在大规模集群中使用。

 

模式九：部署大数据，Kubernetes vs. Mesos

 
Mesos 还有一个优点，就是 Mesos 能够经过开发 Framework，构建大数据平台，例如 Spark 就有基于 Mesos 的部署方式。
 

 
基于 Mesos 的 Spark 有两种方式，粗粒度和细粒度。
 
粗粒度模式（Coarse-grained Mode）：应用程序的各个任务正式运行以前，须要将运行环境中的资源所有申请好，且运行过程当中要一直占用这些资源，即便不用，最后程序运行结束后，回收这些资源。组粒度的方式浪费资源。
 
细粒度模式（Fine-grained Mode）：按需分配，应用程序启动时，先会启动 executor，但每一个 executor 占用资源仅仅是本身运行所需的资源，不须要考虑未来要运行的任务，以后，mesos 会为每一个 executor 动态分配资源，每分配一些，即可以运行一个新任务，单个 Task 运行完以后能够立刻释放对应的资源。细粒度的缺点是性能有问题。
 
其实细粒度模式才是真正可以发挥 Mesos 动态资源调度最有效的方式，可是考虑到有大幅度的性能下降，https://issues.apache.org/jira/browse/SPARK-11857，很惋惜这种方式在 Spark 2.0.0 被 deprecated 掉了。
 
若是使用 kubernetes 部署大数据，其实和部署一个普通的应用思路差很少，和 Mesos 不一样，kubernetes 不会干预到大数据运行的上下文中，Kubernetes 启动的容器仅仅做为资源预留方式存在，容器内的资源分配则大数据平台本身解决。这样的利用率就下降了，至关于粗粒度模式。
 
基于容器部署大数据平台，也是建议部署计算部分，例如 Map-Reduce，或者 Spark，对于数据部分 HDFS，应当另行部署。
 

 

模式十：容器和虚拟化混合部署

 
使用场景：大型公司，逐步容器化
 
对于不少大公司可是非互联网公司，使用容器仍是须要当心对待的，于是须要逐步容器化，因此存在有 IaaS 平台，而且虚拟机和容器混合使用的状态，这种状态可能会持续至关长的时间。
 
在这种状况下，建议容器套在虚拟机里面使用。
 
使用 Flannel 和 Calico 都仅仅适用于裸机容器，并且仅仅用于容器之间的互通。
 

 
一旦有 IaaS 层，就会存在网络二次虚拟化的问题。
 
虚拟机之间的互联是须要经过一个虚拟网络的，例如 vxlan 的实现，而使用 Flannel 或者 Calico 至关于在虚拟机网络虚拟化的上面再作一次虚拟化，使得网络性能大幅度下降。
 
并且若是使用 Flannel 或者 Calico，那容器内的应用和虚拟机上的应用相互通讯时，则须要出容器平台，多使用 node port，经过 NAT 的方式访问，或者经过外部负载均衡器的方式进行访问。在现实应用中，不可能一会儿将全部的应用所有容器化，只是部分应用容器化，部分应用部署在虚拟机里面是常有的现象。然而经过 NAT 或者外部负载均衡器的方式，对应用的相互调用有侵入，使得应用不能像原来同样相互调用，尤为是当应用之间使用 Dubbo 或者 SpringCloud 这种服务发现机制时，尤为如此。
 

 
网易云开发了本身的 NeteaseController，在监听到有新的 Pod 建立时，调用 IaaS 的 API 建立 IaaS 层的虚拟网卡，而后在虚拟机内部，经过调用 Netease CNI 插件将虚拟网卡添加到容器里面。添加技术用的就是上一节提到的 setns 命令。
 

 
经过这个图咱们能够看出，容器的网卡是直接链接到虚拟私有网络的 OVS 上的，和虚拟机是一个平的二层网络，在 OVS 来看，容器和虚拟机是在同一个网络里面的。
 
这样一方面没有了二次虚拟化，只有 OVS 一层虚拟化。另外容器和虚拟机网络打平的好处是，当部分应用部署容器、虚拟机时，对应用没有侵入，应用原来如何相互访问，如今仍是如何访问，有利于应用逐步容器化。
 

 
OpenStack 里面有一个项目 Kuryr 能够很好地去作这件事情，彻底使用开源的 OpenStack 和 Kubernetes 能够尝试集成一下。

 

了解 网易云 ：
网易云官网：https://www.163yun.com/
新用户大礼包：https://www.163yun.com/gift
网易云社区：https://sq.163yun.com/