每周运行30万个容器实例 - Netflix 的容器化实践


Netflix 是谁?



Netflix 是欧美地区最大的网络视频提供商,超过了 Youtube。全球每天有超过190个国家,一亿多会员在 Netflix 上观看1.2亿小时的电影,电视剧和纪录片等等。Netflix 也制作了像纸牌屋这样广受欢迎的电视剧。


为了应对巨大的并发流量,Netflix 用了7年时间,网站架构从传统巨石应用演进成为业界超前的微服务架构。目前,Netflix 的云平台上运行了500个微服务,每天会有1000次的变更部署到线上环境。线上环境部署在亚马逊3个 Region,9个可用区,为全球用户提供稳定的网络视频服务。


每周运行30万个容器实例 - Netflix 的容器化实践_第1张图片


Netflix 为什么使用容器技术?


每周运行30万个容器实例 - Netflix 的容器化实践_第2张图片


Netflix 在亚马逊 EC2 上已经运行了上万台虚拟机,他们的虚拟机集群非常的稳定,实现了云原生应用的转型而且非常易于扩展,为什么还需要用容器技术?


每周运行30万个容器实例 - Netflix 的容器化实践_第3张图片


使用容器技术提升了 Netflix 的创新速度。笔者之前的文章也提到,在 Netflix 研发团队的文化里,创新是排名第一位,其次是产品的稳定性。所以 Netflix 对于应用的容错性做的非常强,这样即使创新的应用失败,也可以将失败的范围控制到最小,开发者也就更敢于做创新的尝试。Chaos Monkey 就是 Netflix 团队发布的专门做灾难性测试的工具。


使用容器可以更好的管理应用以及应用的依赖,将所有内容都打包在容器里易于管理和发布。当线上容器出现了问题,可以随时 Pull 下来到本地进行调试,让开发者更快的重现问题。


使用容器的 UseCase


1. 视频媒体转码

之前使用虚拟机进行大量视频流媒体的转码需要一个月的时间,使用容器进行高并发转码,只需要一周。


2. 统一代码构建,打包和测试系统

之前 Netflix 团队发布包之后,只会跑包本身的测试用例,并不会做上游包(UpStream)的集成测试,所以经常发布包会破坏上游包的测试,上游开发者需要反复调试,修复问题。使用容器之后,Netflix 会在容器里跑上游包的测试用例,如果上游测试用例失败,这次包发布也会失败,这叫做 Fail Fast。


3. 开发者无需关心环境

例如 NodeJs 的开发者,他们完全不关心运行的系统是什么,也不想关心,所以使用容器可以让这些开发者专注于开发上,减少 APP 运维的成本。


Netflix 的容器管理平台 Titus


Netflix 最开始并没有使用 Docker,而是使用 CGruop,之后使用了 Mesos 进行容器的管理,目前推出了自行研发的 Titus 容器管理平台,实现容器的管理。


市场上已有了很多容器管理平台,为什么需要自行研发容器管理平台?由于市面上的平台多数关注于数据中心的建设,支持混合云的方案,且目前市面上的方案没有能够满足 Netflix 如此大规模的容器使用情况。


Titus 的最初是用来管理 Netflix 内部大量的 Batch 任务,主要包括视频转码,加水印,生成每日 CDN 网络流量的报表。 这些任务有些共同的特点,耗时较长,属于计算资源密集型的任务,并且不依赖于平台,比较适合用容器来运行。


后来 Titus 开始接管 Services,Services 的要求比 Batch 任务要高很多,需要实时扩容,且需要不间断的运行,服务有更多的状态管理需求,难以升级等等。对此,Titus 做了很多容器管理的改进。


网络管理


每周运行30万个容器实例 - Netflix 的容器化实践_第4张图片


在 VPC 网络里使用 Docker。通过 Titus 的执行器,可以创建一个 Namespace,创建并启动一个 Pod root container,类似于 K8S 的 Pods。随后创建 Veth,路由的规则,iptables 等等。


Metadata Proxy


Metadata Proxy 是 Titus 基于亚马逊的 Metadata Service 实现的统一网络管理模块。它解决的是容器的安全问题,它统一管理的容器的 “whoami” 的信息,例如容器的 IP,权限,容器的宿主机 ID,域名等等,容器本身无法知道宿主机的更多信息,从而确保容器的网络安全性。将 VPC 网络和 Metedata Proxy 合起来,就是下面的这张图:


每周运行30万个容器实例 - Netflix 的容器化实践_第5张图片


和 Spinnaker CI/CD 集成


Titus 和 Netflix 现有的CI/CD 工具 Spinnaker 进行了集成。在创建 Spinnaker 的集群时,Spinnaker 提供了 AWS 虚拟机集群的创建,和 Titus 容器集群的创建。


每周运行30万个容器实例 - Netflix 的容器化实践_第6张图片


当某个容器 Push 到了 Artifactory Docker 注册中心,这个 tag 会实时的显示在 Spinnaker 部署的任务里供用户选择 Docker 镜像的版本。


每周运行30万个容器实例 - Netflix 的容器化实践_第7张图片


Titus 也集成了 Chaos Monkey,在 Chaos Monkey里执行线上环境破坏性测试的时候,选择 Titus,就会随机销毁在线上运行的容器。


每周运行30万个容器实例 - Netflix 的容器化实践_第8张图片


Fenzo 任务调度框架


Netflix 开源了任务调度框架 Fenso,它是一个可扩展的任务调度框架,用于管理所有调度任务的生命周期。


每周运行30万个容器实例 - Netflix 的容器化实践_第9张图片


你只要给 Fenzo 一个任务列表,并且给 Fenzo 一堆可以的计算资源,Fenzo 就会自行决策,进行任务的执行。如果你给的计算资源太少,不足以执行所有任务,Fenzo 会告诉你需要多少计算资源,如何扩容。


Titus 和 Fenzo 集成


每周运行30万个容器实例 - Netflix 的容器化实践_第10张图片


为了实现计算资源利用率的最大化,Netflix 的生产环境和 Batch 任务会共用容器资源。某些 Batch 任务会占用大量的计算资源,导致在生产环境的 APP 需要扩容时,得等待 Batch 任务执行完成,才能获取资源。


为了解决这个问题,Fenzo 将容器分为核心层和 Flex 层,核心层的应用会保障扩容的能力。Flex 层会将低优先级的任务进行排队执行。


Titus 的现状


之前 Titus 是和 Netflix 内部的 Mesos 的平台进行容器管理,目前已使用 ECS 替换了 Mesos 作为容器编排的平台。 


每周运行30万个容器实例 - Netflix 的容器化实践_第11张图片


Titus 支持了 OutBound 和 Inbound 的请求处理,从 OutBound 可以实现 ECS 里容器的启动和停止。如果容器停止,CloudWatch 会监测到 ECS 的变化,并且通知 Titus 里任务的状态变化。


未来 Titus 将会专注于基于:

1. 服务的自动扩容,以及跨数据中心的容器负载均衡。

2. 实现核心层任务的 SLA 保障,当核心层的计算资源达到上限时,会将 Flex 层的资源抢占过来,保障核心层任务的 SLA。

3. 更好的支持动态扩容。


作者:王青

目前任职 JFrog 中国首席架构师,之前在 IBM,HPE,爱奇艺,新浪,VIPKID 等公司做过研发和架构,是有十多年开发经验的互联网老兵,专注于软件生命周期管理,微服务架构,云原生应用,容器化等领域。

欢迎转载,但转载请注明作者与出处。谢谢!

你可能感兴趣的:(Netflix)