ACM通信

实践

Titus:向Netflix Cloud介绍容器

作者:Andrew Leung, Andrew Spyker, Tim Bozarth
ACM通讯，2018年2月，第61卷第2期，第38-45页
10.1145 / 3152529
评论

2008年，Netflix将全部精力投入到云迁移上，并开始将其整个内部托管基础设施转移到亚马逊网络服务(AWS)上。如今，几乎所有的Netflix都运行在AWS的虚拟机上。客户的目录浏览体验、内容推荐计算和付款都由AWS提供。

多年来，Netflix已经帮助打造了许多云原生模式，比如松散耦合的微服务和不可变的基础设施，它们已经成为行业最佳实践。Netflix向云平台的全面迁移取得了巨大成功。尽管已经有了一个成功的云原生架构，Netflix仍在投资于容器技术。

容器技术使Netflix能够以更简单、更灵活、更有效的方式遵循VMs已经采用的许多相同模式。推动这一投资的一些因素包括:

端到端应用程序包装。用于本地开发的容器映像与在生产环境中运行的容器映像相同(或至少非常相似)。这种打包允许开发人员在类似产品的环境中更容易地构建和测试应用程序，这提高了可靠性并减少了开发开销。

灵活的包装。Netflix过去提供了面向Java虚拟机(JVM)的开发和部署环境，使用了应用程序配置“烘烤”到的通用VM映像。对于非jvm应用程序，正确配置这个映像可能很困难。容器映像提供了一种简单的方法来构建特定于应用程序的映像，这些映像只包含应用程序所需的内容。

更简单的云抽象。将Netflix应用程序部署到虚拟机需要选择一个大小合适的VM实例类型，并配置它来运行和管理应用程序。许多因素会影响哪种实例类型是最好的，包括硬件(例如CPU、内存、磁盘)尺寸、价格、区域可用性和高级特性支持(例如专门的网络或存储特性)。对于许多开发人员来说，这是一个令人困惑的、以机器为中心的步骤，它会留下出错的机会。容器通过提供更以应用程序为中心的部署(只需要声明应用程序的需求)使这个过程变得更容易。

更快、更高效的云资源。容器是轻量级的，这使得构建和部署它们比使用VM基础设施更快。此外，由于容器只包含单个应用程序所需的内容，因此它们更小，可以更密集地打包到vm上，这减少了总体基础设施占用空间。

这些因素不会改变Netflix现有的云原生基础设施的模式或方法。相反，容器提高了开发人员的生产力，允许他们更快地开发、部署和创新。在整个行业中，容器作为部署和运行云本地应用程序的事实上的技术正在出现。投资集装箱可以确保Netflix的基础设施与关键的行业趋势保持一致。

虽然对开发人员生产力的价值驱动了公司的大部分战略投资，但投资集装箱的一个重要的现实原因是Netflix的团队已经开始使用它们。这些团队不仅提供了如何从集装箱中获益的切实证据，而且还突显了集装箱内部缺乏支持的问题。

独特的Netflix容器挑战。在许多公司中，容器采用发生在构建新的新应用程序或作为大型基础设施重构的一部分时，例如移动到云或将单个应用程序分解为微服务。Netflix采用的容器之所以不同，是因为它是由已经运行在云本机基础设施上的应用程序驱动的。这种独特的环境从以下几个方面影响了我们处理技术和管理内部采用的方式:

• 由于应用程序还没有被重构，所以重要的是它们可以在不进行任何重大更改的情况下迁移到容器。
• 由于Netflix的文化提倡自下而上的决策，所以没有要求团队采用容器。因此，我们最初只关注少数内部用户和用例，他们希望尝试容器，并将从采用中看到主要好处。
• 我们希望一些应用程序继续在vm中运行，而另一些应用程序则在容器中运行，因此确保它们之间的无缝连接非常重要。
• 早期的容器采用用例包括传统的微服务和各种各样的批处理作业。因此，我们的目标是支持这两种工作负载。
• 由于应用程序将从稳定的AWS EC2(弹性计算云)基板转移到运行在EC2之上的新的容器管理层，因此提供适当级别的可靠性至关重要。

回到顶部

现有云基础设施中的容器

Netflix的独特需求促使我们开发了Titus，这是一个针对Netflix云基础设施的容器管理系统。提图斯的设计集中在几个关键领域:

• 允许现有的Netflix应用程序在容器中不加修改地运行，
• 使这些应用程序能够轻松使用现有的Netflix和AWS云基础设施和服务，
• 在同一资源池上调度批处理和服务作业，以及
• 有效管理云容量和可靠性。

Titus是建立在Apache Mesos之上的一个框架，⁸跨一系列机器代理可用资源的集群管理系统。Mesos使我们能够控制我们认为重要的方面，例如调度和容器执行，同时处理诸如哪些机器存在和哪些资源可用等细节。此外，Mesos已经在其他几家大公司大规模运行。^7，12，14其他开源容器管理系统，如Kubernetes¹⁰码头工人群,⁶在Titus被开发出来的时候就推出了，提供了自己的调度和执行容器的方式。考虑到这里所提到的特定需求，我们觉得我们最终会很快地背离它们的共同能力，从而限制它们的好处。

Titus由一个复制的、由领导选出的调度程序Titus Master组成，它负责将容器放置到一个名为Titus Agents的EC2虚拟机池中，这些虚拟机管理每个容器的生命周期。动物园管理员⁹管理领导人选举，还有卡桑德拉¹¹持久化主数据。Titus架构如图1所示。

图1。提多架构组件。

Titus中的工作由作业规范描述，该规范详细说明了要运行什么(例如，容器映像和入口点)、元数据(例如，作业的目的和谁拥有它)，以及运行它需要什么资源，例如CPU、内存或调度约束(例如，可用性区域平衡或主机关联)。作业规范提交给主程序，由许多任务组成，这些任务表示正在运行的应用程序的单个实例。主程序将任务安排到Titus代理程序上，Titus代理程序根据任务的工作规范启动容器。

为易于采用容器而设计。大多数Netflix微服务和批处理应用都是围绕Netflix的部分云基础设施，AWS服务，或两者兼而有。Netflix云基础设施由各种系统组成，这些系统为在云中运行的Netflix应用程序提供核心功能。例如,尤里卡,¹⁸服务发现系统，Ribbon，²¹一个IPC库，提供连接服务的机制。阿特拉斯,¹⁶时间序列遥测系统，还有Edda，¹⁷云资源索引服务，提供监控和分析服务的工具。

这些系统中的许多都可以作为开源软件使用。^20.类似地，许多Netflix应用程序使用AWS服务，如S3(简单存储服务)或SQS(简单队列服务)。

为了避免使用这些服务的应用程序为了采用容器而改变，Titus集成了许多Netflix云服务和AWS服务，允许容器化应用程序轻松地访问和使用它们。使用这种方法，应用程序开发人员可以继续依赖这些现有的系统，而不需要采用替代的、但类似的基础设施。这与其他容器管理系统不同，其他容器管理系统要么提供自己的服务，要么使用新的特定于容器的基础设施服务。⁵

与现有云集成。在某些情况下，通过Titus访问Netflix云基础设施系统非常简单。例如，许多基于java的平台服务客户机只需要Titus在容器中设置特定的环境变量。这样做会自动启用分布式配置服务的使用，¹⁵实时数据管道系统，²⁷和其他人。

其他集成需要对基础设施服务本身进行更改，以便能够与Titus控制平面通信(通常除了EC2之外)或理解容器级数据。例如，更新了Eureka客户端以理解从EC2 VM和Titus容器注册的服务。类似地，健康检查轮询系统被更改为查询Titus，并为容器(除vm外)提供健康检查轮询。实例上的Atlas遥测代理被更改为从Titus代理收集和发出容器级系统指标(例如，CPU和内存使用量)。以前，它只收集整个主机的指标。

除了允许Netflix应用程序更容易地在容器中运行之外，这些集成降低了在Netflix中采用容器所需的学习曲线。用户和团队可以使用他们已经知道的工具和进程，无论他们使用的是vm还是容器。例如，拥有Atlas遥测仪表板和警报的团队可以将其应用程序从vm迁移到容器，同时保持遥测和操作系统不变。

与Netflix云基础设施的集成也允许Titus开发团队不专注于重建现有的内部云组件。在几乎所有情况下，与现有的Netflix服务集成要比实现或引入该服务的特定于容器的新版本容易得多。

在Titus中，我们没有采用各种部署策略，比如红/黑或滚动升级，而是选择了三角帆，²²Netflix的持续交付工具。三角帆提供了一个概念云提供商，这使得它能够协调跨Titus和EC2的应用程序部署。除了在Titus上提供一个熟悉的部署工具，三角帆的使用允许三角帆团队，这是专业的连续交付，实现如何编排部署的逻辑，而Titus开发团队能够专注于集装箱调度和执行。

---

Netflix采用的容器之所以不同，是因为它是由已经运行在云本机基础设施上的应用程序驱动的。

---

可以肯定的是，Netflix云服务的某些方面要么与Titus的工作方式不同，要么与Titus的工作方式不同。通过与现有的Netflix组件集成，Titus提供的每一个集成都可以降低一些团队和用户的采用曲线，而不是要求使用新的组件。

使AWS集成。使容器易于采用的另一个关键方面是支持使用AWS服务。许多Netflix应用程序都是围绕各种AWS服务(如S3或SQS)构建的。使用AWS服务需要正确的IAM(身份和访问管理)^3.授权服务调用的凭据。

对于运行在EC2虚拟机中的应用程序，身份和凭证信息由元数据服务通过实例元数据提供⁴在一个众所周知的IP地址上可用。这个元数据服务提供了EC2 VM粒度的凭证，这意味着同一个VM上的容器化应用程序必须共享主机的IAM凭证(这违反了最小特权原则)，或者不使用AWS服务。

Titus使用一个运行在每个代理VM上的元数据服务代理，为容器提供特定的IAM凭证。Titus jobs声明了需要的IAM角色。当容器化的应用程序向元数据服务IP发出IAM请求时，代理通过主机路由规则(将这些请求重定向到它)拦截这些请求。

代理从Titus提供的任务配置信息中提取容器的IAM角色，然后使用主机的IAM假设的作用获取特定IAM凭证并将它们返回到容器的能力。IAM假设角色允许一个主体的IAM角色(在本例中是主机的角色)临时承担另一个主体(在本例中是容器的角色)的标识能力。这种方法只提供具有的容器他们的与EC2虚拟机使用的IAM角色相同的IAM凭证。除了IAM角色外，代理还为容器提供Titus实例身份信息，而不是EC2身份信息。Eureka客户机等客户机库使用此信息。

一个共同的网络是关键。对于许多集成来说，一个重要的推动因素是公共网络基础设施。容器化应用程序和现有基础设施之间的无缝网络通信消除了许多集成和采用的障碍。

容器网络的一个常见解决方案是提供一个覆盖网络，在现有网络的基础上创建一个单独的网络。这种方法很有吸引力，因为它将两个网络解耦，而且不需要更改底层网络。然而，覆盖将容器的网络空间与现有网络隔离开来，并需要网关或代理来连接它们。

另一种常见的方法是从主机的IP分配到容器的特定端口。虽然这允许容器的IP成为现有网络IP空间的一部分，但它允许容器只使用它们必须预先知道的特定端口，限制使用相同端口的容器的重新定位，并向容器公开主机的网络策略。此外，应用程序和基础设施处理容器网络(端口)的方式必须与它们处理VM网络(ip)的方式不同。由于许多Netflix系统是IP感知的，而不是端口感知的，所以将额外的端口数据改造到必要的系统中是非常重要的。

Titus通过将容器接入到虚拟机所在的AWS VPC网络，为每个容器提供唯一的IP地址。使用公共VPC，可以让容器和虚拟机共享相同的IP地址空间，使用相同的组网策略和安全组等特性。这种方法避免了管理端口的需要，因为每个容器都有自己的IP和完整的端口范围，以及网络网关。

当启动一个请求路由IP地址的容器时，Titus附加了一个AWS ENI(弹性网络接口)²到运行容器的代理VM。绑定ENI会在虚拟机上创建一个新的网络接口，该网络接口可以分配多个IP地址。这些地址与VPC内的虚拟机在相同的CIDR范围内分配，即容器和虚拟机可以直接为对方的ip地址分配地址。通过ENIs分配ip，避免了Titus对VPC的可用ip进行管理，也避免了Titus直接修改VPC的路由表。

当Titus准备启动一个新容器时，它会为它创建一个网络名称空间，从ENI为它分配一个特定的IP地址，并使用veth(虚拟以太网)接口将容器的网络名称空间连接到主机的网络名称空间。主机上的路由规则将该IP的所有流量路由到veth接口，网络名称空间内的路由规则为容器配置分配的IP。

容器与虚拟机共享VPC网络的另一个好处是可以使用常见的网络安全策略，如AWS安全组提供虚拟防火墙。¹每个ENI都可以配置为使用一组SG防火墙规则，这些规则适用于任何进出该接口的流量。Titus将容器请求的SGs应用于与该容器关联的ENI，允许对其通信执行SG防火墙规则。

可以连接到VM的ENIs数量是有限的，可能比Titus分配给它的容器数量要少。为了更有效地使用ENI, Titus允许集装箱共享相同的ENI。但是，这种共享只有在容器使用相同的安全组配置时才可能实现，因为SGs只能对整个ENI配置。在这种情况下，每个容器都有一个惟一的IP地址，并对它们的通信应用通用的防火墙规则。图2显示了一个共享ENI的示例。在本例中，三个容器都有一个唯一的IP地址，由附加到主机的ENIs分配。然而，容器1和2可以通过相同的ENI路由流量，因为它们都只使用安全组X。

图2。Titus容器IP配置。

Titus Master通过将SGs和ENIs作为两级资源来实现这种共享，因此它可以使用相同的SG配置调度现有ENIs后面的容器。Titus还通过Linux流量控制为每个容器提供有保证的网络带宽。它根据容器请求的带宽设置令牌桶速率。这些网络特性避免了将应用程序的更改迁移到容器中，并使在容器或VM中运行的应用程序对外部服务透明。

拥有一个共同的网络基础设施有助于容器的采用。需要连接到应用程序的外部服务不必关心应用程序使用的是哪种技术。这种透明性允许现有系统更容易地处理容器化的应用程序，并使vm和容器的混合环境更易于管理。

同时支持批处理和服务工作负载。早期的Netflix容器用例涉及批处理作业和服务应用程序。这些工作负载的不同之处在于，批处理作业的运行时间为秒到天，而服务的运行时间为“永远运行”。与使用两个不同的系统管理这两种不同类型的工作负载不同，容器隔离允许将这些作业放在一起，这将产生更好的集群利用率，并减少操作负担。

由于这两种工作类型有不同的生命周期和管理需要，Titus Master分离的角色通过任务放置进行作业管理。作业管理处理每种作业类型的生命周期，例如批处理作业的最大运行时和重试策略或服务作业的伸缩策略。任务放置将任务分配给集群中空闲的资源，只需要考虑任务所需的资源和调度约束，如可用分区平衡。

Titus用Fenzo来布置任务，¹⁹一个可扩展的Mesos框架调度程序库。Fenzo是由Netflix开发的，已经被一个叫做Mantis的内部流处理系统所使用。²⁴Fenzo将任务分配给Mesos提供的资源，并支持各种可配置和扩展的调度目标。

Titus将Fenzo的bin打包与它的代理自动伸缩功能结合起来，根据工作负载需求动态地增长和收缩代理池。自动伸缩代理池允许Titus向其他内部系统提供空闲的、已经购买的AWS保留实例，并限制AWS更昂贵的按需池的使用。Fenzo支持a健身计算器，它允许调优调度决策的质量。Titus使用这个特性来权衡调度速度和分配质量。

虽然Titus Master是一个单片的调度器，但这种解耦是一个有用的模式，因为它利用了两级调度器设计的某些方面。²⁵Fenzo充当集中的资源分配器，而作业管理器允许对不同的作业类型进行解耦管理。这为每个作业管理器提供了一致的任务放置和代理管理策略，并且需要它们只关注作业生命周期。其他调度器²⁶具有类似的关注点分离，但Fenzo提供了一个丰富的API，允许作业管理器支持各种用例，并且可以扩展为支持具有特定需求的作业类型。

构建具有独立作业管理器的单片调度程序与其他基于Mesos的系统不同，在其他系统中，不同类型的作业由不同的Mesos框架管理。在这些情况下，每个框架充当该作业类型的完整、独立的调度器。提图斯被设计成只有它避免了在多个框架中可能发生的资源锁定和资源可见性问题，并允许在整个集群状态可用的情况下放置任务。避免这些问题有助于提图斯大师时间表更快更好的安置决定。

异构容量管理。通过Titus使用容器的好处之一是，它抽象了许多应用程序在vm中所做的以机器为中心的管理。在许多情况下，用户可以告诉Titus“运行这个应用程序”，而不用担心容器在哪里或在哪个实例类型上运行。然而，用户仍然需要一些关于他们的应用程序是否或何时运行的保证。当运行具有不同目标和优先级的应用程序时，这些保证尤其重要。例如，微服务想要知道它是否能够扩展容器的数量以响应不断增加的流量，即使批处理作业可能会因为在同一个集群上启动数千个任务而消耗大量资源。

此外，运行在EC2虚拟机上的应用程序已经习惯了AWS的保留实例(Reserved Instances)概念，如果提前购买，保留实例可以保证虚拟机的容量。为了使VMs和容器之间的容量概念更加一致，Titus提供了层而且组织能力。

Titus目前提供了两层:一层确保Titus Agent VMs启动并准备运行容器，另一层允许代理池随着工作负载的变化而伸缩，如图3所示。两者之间的主要区别是发射一个集装箱所需的时间。第一层，叫做关键层，如图中实线边框所示。它使Titus能够立即启动容器，而不必等待EC2发放VM。这一层优化启动延迟，代价是运行比应用程序当前可能需要的更多的虚拟机。

图3。关键层和灵活层。

第二层，称为灵活的层，只提供足够的代理vm来处理当前的工作负载(尽管它保留了一小部分空闲实例空间，以避免过度扩张和下降)。在灵活层中扩展代理VM允许Titus消耗更少的资源，但是当需要在容器启动之前发放EC2 VM时，它会给任务带来启动延迟。通常，微服务使用关键层，这些微服务需要其应用程序快速扩展以响应流量变化或批处理具有人工交互元素的作业，例如，当用户希望从作业获得实时响应时。代理的数量根据需要缩放，如图中的虚线边界所示。

---

通过Titus使用容器的好处之一是，它抽象了许多应用程序在vm中所做的以机器为中心的管理。

---

组织能力是每个层上的一个逻辑概念，它保证一个或一组应用程序具有一定的专用容量。例如，微服务可能需要保证它有能力伸缩以匹配其峰值流量，或者批处理作业可能需要保证一定数量的任务吞吐量。在容量组出现之前，如果其他应用程序消耗了所有集群资源，那么Titus上的应用程序就会出现容量不足(通常这些不足是由提交任务的脚本中的bug或用户没有考虑到他们的任务将消耗的容量造成的)。此外，容量组帮助用户思考和沟通他们的预期容量需求，这有助于指导Titus自己的容量规划。

合并容量组和层允许应用程序在成本(为应用程序留出可能未使用的代理资源)和可靠的任务执行(确保一个应用程序不会被另一个应用程序耗尽)之间进行权衡。这些概念有点类似AWS的保留实例和按需实例的概念。提供类似的容量概念，允许用户以类似于考虑VM容量的方式来考虑容器容量，从而简化了容器的采用。

回到顶部

管理容器采用

对于大多数公司来说，开始采用新技术是困难的，Netflix也不例外。在早期，存在着相互竞争的采用问题:随着Titus的成熟，容器采用会发展得太快，并导致可伸缩性和可靠性问题，或者容器采用会被限制到只有几个用例，并且不保证投资。

尽管存在这些担忧，并且缺乏内部支持，一小部分团队已经采用了容器并实现了好处。这些早期用户提供了具体的用例，其中容器解决了真正的问题，所以最初的重点是他们的用例。我们假设这些早期的采用者将展示容器和Titus的价值，同时也允许我们建立一个特性的基础，以便在未来推广使用。我们希望这种方法能够使采用有机地进行，并减轻前面提到的问题。

这些早期团队运行各种各样的临时批处理作业，并有理由作为Titus的初始用户。首先，他们的用例更能容忍Titus早期提供的有限可用性和性能;Titus宕机不会危及Netflix的用户体验。其次，这些团队已经在使用容器了，因为他们的数据处理框架和语言使容器图像成为一种简单的打包解决方案。第三，许多用户是数据科学家，简化的界面吸引了他们不去管理基础设施的愿望。其他球队也对提图斯感兴趣，但他们被故意拒之门外，因为他们不适合。这些团队要么不会从容器中看到显著的好处，要么拥有Titus在此阶段无法轻易满足的需求。

早期用户推动我们专注于Netflix和AWS的集成、调度性能和系统可用性，帮助其他早期用户。随着这些方面的改进，我们开始进行服务工作支持。早期的服务采用者包括多语言的应用程序和那些快速开发迭代很重要的应用程序。这些用户推动了前面描述的调度器增强、自动化金丝雀分析系统等服务常用的集成，以及更好的端到端开发人员体验。

Titus目前每天启动约15万个容器，其代理池由数千个横跨多个AWS区域的EC2虚拟机组成。随着使用量的增长，运营方面的投资也在增加。这一重点提高了Titus的可靠性和可伸缩性，并增加了内部团队对它的信心。因此，Titus支持不断增长的内部用例。它为客户交互流媒体体验的一部分服务、推动内容推荐和购买决策的批处理工作，以及帮助工作室和内容生产的应用程序提供动力。

回到顶部

未来的重点领域

到目前为止，Titus主要关注Netflix应用程序使用容器的基本特性和功能。随着越来越多的用例采用容器以及规模的扩大，开发重点的领域有望发生变化。Netflix计划投资的关键领域包括:

多租户。虽然当前的容器技术提供了重要的进程隔离机制，但它们并不能完全消除噪声邻居干扰。共享CPU资源会导致上下文切换和缓存争用的开销，^28，13和共享的内核组件(例如，网络文件系统内核模块)并不都是容器感知的。我们计划改进Titus代理在用户空间和内核级别提供的隔离。

更可靠的调度。对于批处理和服务应用程序，有许多高级调度器特性可以提高它们的可靠性和效率。例如，Titus目前不会重新安排任务一旦它被放置。随着代理池的更改或其他任务的完成，主服务器最好重新考虑任务的最佳放置，例如改善其在可用性区域之间的平衡。

更好的资源效率。除了更密集地封装EC2虚拟机，Titus还可以通过更智能地使用资源来提高云的使用率。例如，当分配了容量组但没有使用时，Titus可以在这些空闲资源上运行可抢占的、最有效的批处理作业，并在需要时将它们交付给保留的应用程序。

类似地，Netflix在一些内部用例中代理它已经购买但空闲的EC2保留实例。²³Titus可以通过一个低成本、短暂的代理池，让更多的内部团队更容易地使用这些实例。

虽然只有一小部分Netflix的内部应用程序使用Titus，但我们相信我们的方法使Netflix能够迅速采用并受益于容器。尽管细节可能是netflix特有的，但是通过与现有的基础设施集成并与正确的早期采用者合作来提供低摩擦的容器采用方法对于任何希望采用容器的组织来说都是一个成功的策略。

致谢我们要感谢Amit Joshi、Corin Dwyer、Fabio Kung、Sargun Dhillon、Tomasz Bak和Lorin Hochstein对本文的帮助。

相关文章
在queue.acm.org

博格，欧米茄，和库伯涅茨
布兰登·伯恩斯，布莱恩·格兰特，大卫·奥本海默，埃里克·布鲁尔和约翰·威尔克斯
http://queue.acm.org/detail.cfm?id=M2898444

用容器对容器进行集群级日志记录
辛格分水岭
http://queue.acm.org/detail.cfm?id=2965647

容器向蜉蝣服务器推
克里斯•爱德华兹
//www.eqigeno.com/magazines/2016/12/210377-containers-push-toward-the-mayfly-server/fulltext

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2018 ACM, Inc。

---

没有发现记录