Netflix Titus Adds Single-Tenant VM Isolation for Containers

TL;DR · AI 摘要
Netflix Titus 新增单租户 VM 隔离功能,解决多租户容器资源竞争问题,适用于高吞吐场景。
核心要点
- Netflix Titus 通过单租户 EC2 实例实现容器隔离,避免资源竞争
- 多租户模式下 cgroups 等机制无法完全隔离硬件资源
- Titus 使用联邦层和自动扩展策略确保任务独占节点
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Netflix Titus 单租户隔离
- 隔离机制
- 独占 EC2 实例
- 联邦层控制
- 技术选型
- 拒绝微虚拟机
- 采用 gVisor 优化
- 性能验证
- 参考应用测试
- 启动延迟成本
金句 / Highlights
值得收藏与分享的关键句。
Netflix 的 Titus 平台新增单租户模式,每个任务独占 EC2 实例,解决多租户资源竞争问题。
cgroups、seccomp 等机制无法隔离最后一级缓存和内存带宽等硬件资源。
微虚拟机方案需要裸金属或嵌套虚拟化,且缺乏 GPU 支持。
Netflix Titus 为容器新增单租户虚拟机隔离功能 - InfoQ
InfoQ 首页 News Netflix Titus 为容器新增单租户虚拟机隔离功能
DevOps
InfoQ 认证高绩效团队计划(在线,11月17日):为您的团队构建更清晰的运营模型。
Netflix Titus 为容器新增单租户虚拟机隔离功能
2026年10月30日 3分钟阅读
作者:
- Claudio Masolo
#### 关注我们
Youtube
232K 粉丝
26K 粉丝
新
RSS
19K 读者
X
57.1k 粉丝
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主题
##### 相关主题:
- DevOps
- Netflix
- Kubernetes
- 相关编辑
- 相关赞助商 智能代理AI威胁:为何你的Java补丁策略已不再足够
- 相关赞助商 了解Azul如何帮助Java团队降低JVM漏洞风险、加强应用安全性,并为智能代理AI做好Java环境准备。学习如何在保持性能和可靠性的同时,制定Java工作负载的安全策略。了解更多
InfoQ新闻简报
每周五发送InfoQ最新内容摘要。加入超过25万名高级开发者的社区。查看示例
我们保护您的隐私。