Hulu是美国领先的互联网专业视频服务平台，目前在美国拥有超过2000万付费用户。Hulu总部位于美国洛杉矶，北京办公室是仅次于总部的第二大研发中心，也是从Hulu成立伊始就具有重要战略地位的分支办公室，独立负责播放器开发，搜索和推荐，广告精准投放，大规模用户数据处理，视频内容基因分析，人脸识别，视频编解码等核心项目。
在视频领域我们有大量的视频转码任务；在广告领域当我们需要验证一个投放算法的效果时，我们需要为每种新的算法运行一个模拟的广告系统来产出投放效果对比验证；在AI领域我们需要对视频提取帧，利用一些训练框架产出模型用于线上服务。这一切都需要运行在一个计算平台上，Capos是Hulu内部的一个大规模分布式任务调度和运行平台。
Capos是一个容器运行平台，包含镜像构建，任务提交管理，任务调度运行，日志收集查看，metrics收集，监控报警，垃圾清理各个组件。整个平台包含的各个模块，如下图所示：
用户可以在界面上创建镜像描述符，绑定github的repo，生成镜像。之后在界面上创建作业描述符，填上镜像地址，启动参数，资源需求，选择资源池，就可以运行作业，看作业运行日志等。这些所有操作也可以通过restapi来调用，对于一些高级的需求，capos提供golang和python的sdk，可以让用户申请资源，然后启动作业，广告系统就是利用sdk，在capos上面申请多个资源，灵活的控制这些资源的生命周期，一键启动一个分布式的广告系统来做模拟测试。
Capos大部分组件都是用Golang实现的，Capos的核心组件，任务调度运行CapScheduler是今天主要和大家分享和探讨的模块。CapScheduler是一个基于mesos的scheduler，负责任务的接收，元数据的管理，任务调度。CapExecutor是mesos的一个customized executor，实现Pod-like的逻辑，以及pure container resource的功能，在设计上允许Capos用户利用capos sdk复用计算资源做自定义调度。
Capos Scheduler的架构图如下所示：
上图浅蓝色部分是mesos的组件，包括mesos master，mesos agent，mesos zookeeper。mesos作用是把所有单体的主机的资源管理起来，抽象成一个cpu，memory，port，gpu等的资源池，供之上的capos scheduler使用。
其中capos scheduler是一个active-standy的HA模型，在scheduler中我们实现了一个raft based的k-v用来存储metadata，active的scheduler注册成为mesos之上的一个framework，可以收到资源，根据调度策略来启动作业。
Capbox是一个定制实现的mesos的executor，作为mesos agent的资源的占位符，接收请求与mesos agent上的docker daemon通信启动容器。其中也实现了POD-like的功能，同时可以启动多个容器共享network，磁盘等。
Capos scheduler提供两类作业运行，一个是简单作业直接在Capbox运行，另一个是复杂带有编程语义的作业，我们称之为appmaster，其本身运行占用一个capbox，然后通过编程语义二次申请capbox运行作业。
首先说明下简单作业运行流程，这里的简单作业，提交的作业通过json描述，可以包含多个container，然后scheduler收到请求之后，命中某个offer，向mesos发送offer启动请求，在请求中同时夹带着作业json信息，把作业启动起来，scheduler根据mesos状态同步信息来控制作业的生命周期。
如果是appmaster programmatically二次调度的作业，首先需要把appmaster启动，这部分和简单作业运行是一致的，然后appmaster再申请一个到多个资源来启动capbox，运行作业。此时appmaster申请的capbox的生命周期完全由appmaster决定，所以这里appmaster可以复用capbox，或者批量申请capbox完成自己特定的调度效果。多说一句，appmaster可以支持client-mode和cluster-mode，client-mode是指appmaster运行在集群之外，这种情况适用于把appmaster嵌入在用户原先的程序之中，在某些场景更符合用户的使用习惯。
说完capos的使用方式后，我们可以聊下在capos系统中一些设计的思考：
1 Scheduler的调度job和offer match策略，如下图所示：
1.1 缓存offer。当scheduler从mesos中获取offer时候，capos scheduler会把offer放入到cache，offer在TTL后，offer会被launch或者归还给mesos，这样可以和作业和offer的置放策略解耦。