InfoQ

Netflix Titus Adds Single-Tenant VM Isolation for Containers

8.5内容质量
Netflix Titus Adds Single-Tenant VM Isolation for Containers

TL;DR · AI 摘要

Netflix Titus 新增单租户 VM 隔离功能,解决多租户容器资源竞争问题,适用于高吞吐场景。

核心要点

  • Netflix Titus 通过单租户 EC2 实例实现容器隔离,避免资源竞争
  • 多租户模式下 cgroups 等机制无法完全隔离硬件资源
  • Titus 使用联邦层和自动扩展策略确保任务独占节点

结构提纲

按章节快速跳转。

  1. Netflix Titus 新增单租户 VM 隔离功能,解决多租户容器资源竞争问题。

  2. cgroups、seccomp 等机制无法完全隔离硬件资源,导致性能干扰。

  3. 微虚拟机方案存在裸金属依赖、GPU支持不足等缺陷。

  4. 通过 allowlist、自动扩展和节点污点实现任务独占。

  5. 使用参考应用对比测试隔离效果,但未公开具体指标。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • Netflix Titus 单租户隔离
    • 隔离机制
      • 独占 EC2 实例
      • 联邦层控制
    • 技术选型
      • 拒绝微虚拟机
      • 采用 gVisor 优化
    • 性能验证
      • 参考应用测试
      • 启动延迟成本

金句 / Highlights

值得收藏与分享的关键句。

#容器#Kubernetes#Netflix#云原生
打开原文

Netflix Titus 为容器新增单租户虚拟机隔离功能 - InfoQ

InfoQ 首页 News Netflix Titus 为容器新增单租户虚拟机隔离功能

DevOps

InfoQ 认证高绩效团队计划(在线,11月17日):为您的团队构建更清晰的运营模型。

Netflix Titus 为容器新增单租户虚拟机隔离功能

2026年10月30日 3分钟阅读

作者:

  • Claudio Masolo

#### 关注我们

Youtube

232K 粉丝

Linkedin

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 点赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

  • 阅读列表

Netflix 新增了单租户 Titus 模式,该模式在独立配置大小的 EC2 实例上单独运行一个任务。Compute/Platform 团队仍然负责主机的维护和补丁更新,因此应用团队可以继续使用相同的 API 和部署路径。首批采用者包括有状态的高吞吐量流媒体工作负载。在此场景中,邻居任务的干扰可能导致分钟级的检查点恢复延迟。

Titus 每周在数万台 EC2 实例上启动数百万个容器,默认采用多租户模式。Netflix 表示,cgroups、seccomp、iocost 控制器和流量整形技术无法分割共享硬件资源,这包括最后级缓存和内存带宽等资源。其 HTB 流量整形器还会获取全局锁。一个向主机发送大量小数据包的容器可能消耗内核 CPU 并导致邻居任务资源饥饿。预测性 CPU 绑定和基于 eBPF 的检测技术有所改善,但 Netflix 认为共享内核调优只能缩小差距而无法完全消除问题。

Netflix 拒绝其他替代方案是基于特定原因。Firecracker 和 Kata 等微虚拟机需要裸金属或嵌套虚拟化,而 Netflix 的实例类型尚未准备好嵌套虚拟化。它们还需要运行虚拟化层,增加虚拟化开销且缺乏 GPU 支持。gVisor 在 I/O 密集型路径上增加开销,且主要由单一供应商负责维护。在 EC2 上运行容器将把主机补丁更新和集群规模调整重新交还给应用团队。Netflix 认为这些工作负载需要性能隔离,而非防御恶意租户。

Titus 联邦层承担了大部分工作。Compute/Platform 团队维护的白名单控制着资格和联邦记录,规定任务可使用的实例家族。自动扩展器会启动满足任务 CPU、内存和 GPU 请求的最小实例。Pod 反亲和性、不可抢占优先级类和节点污点强制每个节点仅运行一个任务。Netflix 禁用碎片整理,因此任务不会被迁移。为衡量隔离效果,Netflix 会单独运行参考应用,再与“混乱”容器并行运行,测量保留吞吐量和 P99 延迟。本文未公布具体指标。

启动延迟是主要成本。新实例需要数十秒启动时间才能开始镜像拉取。由于精确配置产生大量实例规格,暖池在共享集群中的帮助有限。Netflix 为最敏感的延迟场景保留了小型暖池,并限制可用规格。它已移除这些暖池中的金属实例。禁用 Kubernetes 预抢占消除了导致新节点空闲的调度瓶颈。懒惰镜像拉取(stargz、SOCI)和 CRIU 检查点恢复是长期解决方案。

效率仍有提升空间。将敏感型工作负载从共享主机迁移出去,可以消除导致这些主机部分空闲的反亲和性扩散和中断预算。而侧车组件和系统服务带来的固定开销则会拉低效率。Netflix表示,这种开销可能占用小型实例的数十个百分点资源,对最大规格实例的占用率则仅在百分之几。离散的EC2规格在大型共享主机上也会产生装箱打包的空隙,这在实践中反而更倾向于合理配置。

早期用户包括托管式Apache Flink、流数据连接器、遥测和日志管道等场景。随后是部分对延迟敏感的GraphQL和边缘服务。该方案的推广仍在持续。针对共享集群,Netflix正在基于eBPF开发预期出发时间塑形方案以替代HTB,同时引入缓存和内存带宽分区(Intel RDT、AMD PQoS)、NVIDIA MIG以及cgroup v2 IO控制器。其长期目标是构建统一的计算API,根据声明的意图自动选择EC2或Titus部署方案。

单租户Titus方案加入了更广泛的同类问题解决方法。NTT的Akihiro Suda开发的Instance-per-Pod Webhook开源项目,通过Kubernetes准入webhook和集群自动扩缩容控制器,为每个Pod创建带有污点的专用实例。AWS Fargate将Pod作为基础设施单元,使客户无需创建、修补或扩缩容工作节点。GKE提供专有节点(sole-tenant nodes),即仅运行单一项目虚拟机的专用物理服务器,以及GKE Sandbox方案,该方案通过Kata Containers微虚拟机为每个Pod提供独立运行环境。Azure的Pod Sandboxing同样基于Kata技术,为每个Pod分配独立的轻量级虚拟机,实现与其他Pod虚拟机及宿主机内核的隔离。这些方案大多聚焦于防范不可信代码带来的安全隔离问题,而Netflix的方案重点在于实现可信内部团队间的性能隔离。

运行共享Kubernetes平台的团队可以借鉴该模式:创建带有污点、关闭反亲和性和重装箱功能的专用节点池。Netflix建议该方案适用于规模接近节点规格、对中断敏感的大型长期运行工作负载,不适用于小型或突发性服务。白名单机制可防止该模式影响多租户密度。

关于作者

作者信息

#### Claudio Masolo

显示更多

显示更少

#### 本文属于DevOps主题

##### 相关主题:

InfoQ新闻简报

每周五发送InfoQ最新内容摘要。加入超过25万名高级开发者的社区。查看示例

我们保护您的隐私。