Netflix打造容器管理基础架构：Titus

by Andrew Spyker等，译者 大愚若智

容器技术在Netflix基于AWS EC2虚拟机打造的全球云平台中大放异彩，并产生了深远影响。之前我们曾分享过不少有关Netflix使用容器的故事（视频、幻灯片），本文将深入讨论Netflix对容器的使用情况，以及Netflix为基于容器的应用程序打造的底层基础架构Titus。Titus为Netflix提供了可伸缩的集群和资源管理能力，增强了容器执行与Amazon EC2之间的集成度，提供了Netflix所需的通用基础架构功能。

本月，Netflix的容器技术迎来两个重大里程碑。首先，我们的平台规模更上一层楼，在一周内顺利扩展至上百万个容器。其次，Titus现已可为提供流播服务客户体验的功能提供支持。我们将深入介绍Docker容器的具体使用方法，以及使得该容器运行时显得如此独一无二的原因。

容器的发展历史

基于Amazon虚拟机（EC2）的基础架构早已成为Netflix实现各项创新的重要推动力。除了虚拟机，我们还大量使用基于容器的工作负载，这类工作负载为我们提供了独特的价值。容器技术带给我们不菲的收益，对此我们倍感激动，同时容器的用量也经历了爆发式增长，甚至我们自己的开发人员都对这些因素感到吃惊。

虽然EC2支持对服务进行高级调度，但我们的批处理用户无法从中获益。Netflix有很多用户需要同时运行多个作业，甚至要通过基于事件的触发器分析数据，执行运算，并将结果发送给其他Netflix服务、用户，以及报告。我们需要每天多次运行诸如机器学习模型训练、媒体编码、持续集成测试、大数据Notebook，以及CDN部署分析作业等工作负载。因此我们希望为基于容器的应用程序提供不依赖具体工作负载类型的通用资源调度器，通过更高级的工作流调度器对所有内容进行集中控制。Titus可同时承担通用部署单位（Docker 镜像）和通用批处理作业调度系统的任务，它的顺利上线帮助Netflix通过扩展为批处理用例提供了更好的支持。

借助Titus，我们的批处理用户只需要指定自己对资源的需求，即可快速获得成熟的基础架构环境。用户无须选择并维护在规模方面无法与自己的工作负载完美匹配的AWS EC2实例，而是可以安心地通过Titus将更大规模的实例“打包”在一起，高效运用于不同类型的工作负载。批处理用户可在本地编写代码，随后立即通过调度通过Titus进行大规模执行。在容器的帮助下，Titus可以运行任何批处理应用程序，并且可以明确指定自己需要的应用程序代码和依赖项。例如，在机器学习训练过程中，用户将能配合运行Python、R、Java和Bash脚本应用程序。

除了批处理，我们发现其他工作负载也能从更简单的资源管理和本地开发体验等方面获益。通过与Edge、UI和设备工程团队合作，我们还将这些收益扩展到了服务的使用者群体。目前，我们正在通过重建将面向具体设备的服务器端逻辑部署到API层，这样即可更充分地利用面向单内核优化的NodeJS服务器。我们的UI和设备工程团队还希望获得更好的开发体验，例如与生产环境完全一致，更简单的本地测试环境。

除了一致的环境，开发者还可以在容器技术的帮助下，通过Docker层镜像和面对容器部署进行优化的预供应虚拟机，更快速地推送新版应用程序。现在，使用Titus进行的部署可在1-2分钟内完成，而以往单纯使用虚拟机时往往需要数十分钟。

所有这些改进都源自开发者更快速的创新。现在，批处理用户和服务用户都可以更快速地在本地进行实验和测试，他们还可以更自信地将代码部署到生产环境。这样的速度也可以让Netflix客户更快获得各类新功能。可以说，容器技术对我们的业务非常重要。

深入了解Titus

上文介绍了我们构建Titus的原因。下文将深入介绍Titus到底是如何提供这些价值的。我们将简要介绍Titus的调度功能和容器的执行如何为服务和批处理作业需求提供支持，具体情况如下图所示。

在处理应用程序的调度工作时，Titus可对所需资源和可用计算资源进行匹配。Titus可支持“永久”运行的服务作业，以及“持续运行直到完成”的批处理作业。服务作业可重启动失败的实例，并通过自动伸缩与负载的变化相匹配。批处理作业可根据策略进行重试并一直运行直到完成。

Titus为资源调度提供了多种SLA。通过EC2的自动伸缩功能，Titus可根据当前需求为即席（Ad hoc）批处理和非关键内部服务提供按需获取的计算容量。它还能为用户需要执行的工作负载和更关键的批处理任务提供预配置、有保障的容量。调度器可通过集装优化（Bin packing）提高大规模虚拟机的效能，并能通过反关联性（Anti-affinity）实现跨越虚拟机和可用性集的可靠性。这种调度功能源自Netflix开发的一个名为Fenzo的开源库。

Titus容器运行在EC2虚拟机基础上，并能与AWS和Netflix基础架构进行集成。我们预测到用户会在很长一段时间内同时使用虚拟机和容器，因此决定尽可能让云平台和运维体验保持简单。使用AWS的过程中，我们选择尽可能利用现有的EC2服务。例如，我们会使用Virtual Private Cloud（VPC）获得可路由的IP，而没有使用单独的网络覆盖（Network overlay）。我们使用Elastic Network Interface（ENI）以确保所有容器都包含特定应用程序所需的安全组。Titus提供的元数据代理使得容器可以了解自己运行环境特定的容器视图以及IAM凭据。容器无法看到宿主机的元数据（例如IP、主机名、实例ID）。我们还配合使用Linux、Docker，以及自有的隔离技术实施了多租户隔离（CPU、内存、磁盘、网络、安全）。

为了成功地在Netflix的环境中应用容器技术，我们还要将其与现有开发工具和运维基础架构无缝集成。例如，Netflix已经具备持续交付解决方案Spinnaker。虽然也可以通过调度器进行滚动更新并实现其他CI/CD概念，但通过Spinnaker提供这样的功能使得我们的用户可以跨越虚拟机和容器使用一套一致的部署工具。另外还有个例子：服务之间的通信。我们会尽可能避免重新实现服务发现和服务负载均衡工作，取而代之的是提供一个完整的IP栈，借此容器将能与现有的Netflix服务发现和基于DNS（Route 53）的负载均衡机制配合使用。在这些例子中，Titus成功与否的一个关键原因在于：需要确定那些事情不该通过Titus来做，而是应该利用其他基础架构团队所提供的相关功能来实现。

继续使用现有系统的代价是：我们需要对这些系统进行扩充，以便能与虚拟机和容器技术配合使用。除了上文列举的例子，我们还需要对遥测、性能自动调优、健康度检查系统、混沌自动化（Chaos automation）、流量控制、区域性故障转移支持、密文管理，以及交互式系统访问等机制进行扩充。另一个代价是：由于需要与Netflix的这些系统进行深入绑定，这使得我们很难利用其他开源容器解决方案提供容器运行时平台之外的其他功能。

以我们的规模（以及工作负载密度）来说，容器平台的运行还需要密切关注可靠性，并且我们还会在系统的所有层面上遭遇不小的挑战。我们已经顺利解决了Titus软件，以及所依赖的其他开源软件（Docker Engine、Docker Distribution、Apache Mesos、Snap和Linux）相关的伸缩性和可靠性问题。我们针对整个系统的所有层面设计了失败处理机制，包括通过协调促进资源管理层和容器运行时之间分布式状态的一致性。通过清晰衡量的服务级别目标（容器发布启动延迟、由于Titus中问题导致容器崩溃的百分率，以及系统API整体可用性），我们可以更好地对可靠性和功能进行权衡。

容器技术帮助工程师提高效率的一个关键原因在于开发工具。开发者生产力工具团队构建了一个名为Newt（Netflix Workflow Toolkit）的本地开发工具。通过本地迭代并借助Titus进行部署，Newt可简化容器开发工作。通过在Newt和Titus之间实现一致的容器环境，也可以帮助开发者更自信地编写代码。

目前Titus的使用情况

为了驱动Netflix的服务，我们通过三个Amazon区域，用多个测试和生产账户运行了多个Titus栈。

2015年12月发布Titus后，当时我们每周需要启动数千个容器，用来处理少量工作负载。上周，我们启动了上百万个容器，这些容器中运行了数百个工作负载。一年多时间里，容器的用量增加了1000倍，而增长势头依然没有任何放缓的迹象。

为了向批处理用户提供支持，我们在峰值时段运行了500个r3.8xl实例，这意味着16,000个处理器内核，以及120TB内存的规模。我们还通过p2.8xl实例获得了所需的GPU资源，借此支撑基于神经网络和微批（Mini-batch）的深度学习功能。

2017年上半年，流处理即服务团队决定通过Titus为自己基于Flink的系统提供更简单快速的集群管理能力。这一决定导致新增了超过10,000个长期运行的服务作业容器，并且随着流处理作业的变化，这些容器都需要重新部署。各种服务共使用了数千个m4.4xl实例。虽然上述用例对我们的业务很重要，但这些用例都不会对Netflix的客户产生直接影响。不过这种情况最近有了些变化，最近我们开始通过Titus容器运行某些直接面向Netflix客户的服务。

用于支撑直接面向客户的服务，这个决定必须慎重。过去六个月来，我们一直在对虚拟机和容器之间的实时通信进行复制，并使用复制的流量了解如何更好地运维容器，以验证该平台是否已经面向生产环境做好了准备。通过大量的前期工作，我们已经可以自信地在基础架构中推行如此重大的变动。

Titus团队

Netflix得以成功运用Titus的原因之一在于，Titus开发团队所积累的宝贵经验和不断的成长。我们的容器用户坚信不疑地认为，Titus团队可以通过Titus的运维和创新满足自己的需求。

这个团队的后续成长还有很长的路要走，我们也希望能将这个容器运行时和开发者体验扩展到更多领域。

Andrew Spyker、Andrew Leung和Tim Bozarth代表整个Titus开发团队撰文并发布。

阅读英文原文：The Evolution of Container Usage at Netflix

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ, @丁晓昀），微信（微信号：InfoQChina）关注我们。