Mesos 在爱奇艺目前管理着大约 2000 台物理机，分布在多个数据中心，单个集群最大节点数接近 600。
Mesos 平台每周启动的容器超过 500 万，峰值在线容器数近 2 万；适当的资源超卖给我们带来的是在最近一个季度中，所有集群 CPU 平均利用率超过 20%，而最繁忙的集群超过 50%，这对于一家互联网公司来说非常不易。
在这些惊讶的数字背后，Mesos 支撑着许多重要业务，包括但不限于，几乎所有视频、音频、图片转码，对服务质量和稳定性要求非常高的在线服务以及 Storm，Spark 这类实时计算分析业务等。
时光如逝，
回望 Mesos 在爱奇艺的发展历程，
也并非一番风顺。
且不论起初的时候人员不足，
借人帮助开发，
开源代码成熟度不够，
一日三坑，
不得不暂时搁置一些项目；
更别提在一家发展迅速的科技娱乐公司
去推动基础设施服务变革的乏力感。
爱奇艺从 2013 年底开始调研 Mesos，这个声称受到 Google Borg 集群管理系统启发的开源数据中心操作系统核心。
Mesos 是一个 ASF（https://www.apache.org/） 顶级开源项目，Mesos的作者也创建了 Mesosphere 公司来更好的推动 Mesos 生态的发展。
并且，基于 Mesos，Mesosphere 发布了开源的数据中心操作系统 DC/OS，这一次，暴露在你眼前的不仅是内核，而是一个完整的数据中心操作系统。
在 2014 年初，我们将 Mesos 0.16.0 部署到了生产环境，之上运行了一个自研的任务调度器，以短任务的形式运行视频转码业务。
这之后，由于人员和开发量的关系，以及到了年中的时候，我们发现 Chronos（https://mesos.github.io/chronos/）作为基于 Mesos 的短任务调度器已经变得比较完善，顺理成章的，我们尝试从自研的转码框架切换到 Chronos，由此开始了一段新的征程。
和使用 Mesos 的感觉不一样，
Chronos 并没有 Mesos 那样稳定，
以至于在后面大半年的时间里，
我们使用了一些临时手段来维持稳定，
直到后来有更多时间
彻底解决了 Chronos 的稳定性问题，
在那之后，
Chronos 几乎没有再出过问题。
我们对 Chronos 进行了大量开发，其中有超过 30 个 commit 回馈到 Chronos 社区并被接受，而大部分则是我们内部私有的改动，不够通用，所以没有提交到社区，而我们内部则为修改后的 Chronos 取名为 Sisyphus，古希腊中推着石头上山的神，这也是我们为数不多的自认为取得好的项目名字！伴随着 Chronos 稳定性的提高，转码业务量逐步切换到 Mesos 集群，直到 2015 年中转码团队不再维护任何生产集群；至此，Chronos 完全支撑了公司的转码生产业务。
在开发 Chronos 的同时，我们也上线了 Hadoop on Mesos 业务，不过由于业务量不大，以及后来 YARN/MapReduce2 的推出，我们将运行在 Mesos 上的业务全部迁移到了 YARN 集群。
另一方面，Storm 在解决了一些问题之后，能够稳定的提供服务，所以我们也将 Storm 业务接入了 Mesos 集群。对于另一个可以运行在 Mesos 之上的框架 Spark 来说，彼时的 Spark 运行在 Mesos 上还不够稳定，所以我们并没有上线 Spark on Mesos 业务。因为，2014 年底我们开始了对 Marathon（https://mesosphere.github.io/marathon/）的调研，并且在 Marathon 之上设计和开发我们自己的 PaaS 平台 QAE（iQIYI App Engine）。
QAE 是一个完全自助式的（除了配额申请）容器云平台，用户（公司内部开发者）只需要申请资源配额，就能在 QAE 上实现对 App 的全自助式管理，生命周期管理自不必说，其它的高级功能例如：
基于角色的鉴权
App 和容器的监控
非侵入式的接入自定义监控
订阅式的报警
根据任何监控指标自动伸缩
支持灰度发布、AB 测试
App 的高级分布策略
健康检查
日志管理
历史容器管理（方便排障）
在线控制台
CI/CD，自动部署
这里还想啰嗦几句，我对 IaaS 和 PaaS 的理解。
从用户角度来看，IaaS 和 PaaS 面向的用户群有所区别，前者要求用户对系统有更好的理解，更高的熟悉度，类似管理员的角色；而后者要求用户对软件开发环境有更好的熟练度，类似开发者角色。
另一方面，从用户的角度来说，IaaS 提供虚机本非用户所需，用户得到的虚机和物理机并没有本质区别，所以对用户来说，没有什么附加值；IaaS 之所以普遍存在，出发点并不是为了给用户提供更好，更高级的服务，而是节约计算成本，提高大规模计算资源的维护能力。
经过两年多的漫长发展，
QAE 羽翼渐丰，
也接入了近万的在线容器，
形成了良好的用户口碑，
已经变成了能够吸引用户主动采用的平台。
我们的下一步是乘上微服务的风口，提供更多的微服务友好的基础设施以及产品给我们的用户（公司内部开发者）。
因为微服务几乎总是和容器形影不离，可能会被人误以为实现了容器云平台，自然而然的也就实现了微服务平台。
在我看来，其实不然，容器仅仅只是一种软件分发、运行方式，和服务并不位于同一个维度；微服务之所以和容器形影不离，无非是容器相较于虚机来说更加易用，灵活，更加适合微小的服务来利用物理计算资源。
想象一下，微服务带来了什么问题？
一个单体 App，如果需要部署 100 个实例来提供服务，以前基于虚机的时候，开发者需要部署 100 台虚机，不管他用什么方式，总之需要部署；要知道，爱奇艺并没有专门的应用 SRE 帮助开发者维护运行环境；而现在，如果开发者使用 QAE 来管理他的 App，那么只需要在 QAE 上部署一次即可，100 个，1000 个实例，不过是点点按钮的事情。
所以，在这个例子中，对于开发者来说，将业务管理成本降低了 100 倍，太棒了！
但是，如果开发者决定将单体 App 拆分呢？如果拆成 100 个微服务，会变成什么情况？
在 QAE 上他得部署 100 次，即使 QAE 有 App 复制/导入的功能，也依然捉襟见肘，运维成本高企。
更难的是，这 100 个微服务的治理，100 个微服务的拓扑、依赖关系是什么样的？各个微服务之间的流量是怎样的？流量是否健康？微服务接口是否有完善的鉴权管理？是否能从各种维度对微服务之间的请求限流？服务调用跟踪排障？怎样快速发现，接入服务，跨数据中心的流量管控等等？
而这些微服务基础设施，严格来说，并非需要总是和容器联系起来，而是应该作为另一个维度的基础设施，发挥着举足轻重的作用，微服务基础设施之于微服务就像虚机和容器之于单个 App 实例一样重要。
微服务基础设施例如：
API gateway，APM，链路调用跟踪，服务中心等正在积极的开发当中，相信和 QAE 一样，两年过后，一定也会得到内部用户的认可。
两年太远，
只争朝夕；
来看看我们现在正在做哪些事情呢。
改造 QAE 的健康检查，以前是基于 Marathon 的健康检查，由于 Marathon 健康检查是集中式的，所以当容器达到数千的时候，可能会出现瓶颈；而 Mesos 的分布式健康检查则不会有这个问题，因为计算节点总是伴随着业务规模规模一起增长的。
QAE 支持托管计算资源，作为一个通用的平台，我们有一些推荐的最佳实践，比如：容器的配置有上限，因为我们不希望用户把容器当做虚机，甚至物理机来使用；
支持的网络特性，分布特性有限制，例如：共享的集群可不想让用户使用 HOST 网络模式；
出于这些考虑，有些非常想使用 QAE 的特殊业务（例如：直播转码，HCDN 等）不得不被挡在了门外。
所以，我们正在实现 QAE 支持托管的计算资源，主要需要实现：
除了 QAE 之外，对于 Mesos 和 Docker，我们也在做一些很酷的事情：
切换到 Mesos unified container，踢掉Docker daemon 这个一直不太稳定的家伙
从 Device-Mapper（https://en.wikipedia.org/wiki/Device_mapper）切换到 OverlayFS（https://en.wikipedia.org/wiki/OverlayFS），另一个在高并发新建/删除容器下不够稳定的组件
从可配置的静态资源超分迁移到动态的 Mesos Oversubscription，进一步提升资源利用率；这是一个和南京大学合作的项目，相信很快就会有结果
实现离线和在线业务的真正混布，结合 Mesos Oversubscription，进一步降低集群管理成本，提高利用率
使用 Mesos 统一管理 GPU 计算资源
引入公有云，提高 Mesos 集群扩容的速度和效率，让业务能够自由的在私有云和公有云上调度
虽然自认为我们在推动公司容器化应用的道路上取得了一些阶段性的成果，但路漫漫，其修远兮，还有更多的事情等着我们去完成！
本文转载自爱奇艺技术产品团队公众号，ID：iQIYI-TP
本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等，点击识别下方二维码加微信好友了解具体培训内容。
