背景
近几年,Container 相关技术不断得到架构师、研发人员、运维人员等的持续关注,而且也不断涌出了不少 Container 的实现方案,比如:Cloud Foundry 的 Warden、Google 的 Imctfy 等,随着云计算在国内的逐步壮大、成熟,相信未来会有越来越多的平台会采用类 Container 技术,我们也希望能把我们的一些经验、教训分享给大家,和大家一起共同推进 Container 技术的发展。
搜狐云景为什么会选择 LXC
在使用 Container 技术之前,搜狐私有云 PaaS 平台使用了沙盒模式,利用 JVM 虚拟机对用户的进程进行隔离和安全控制,这种方式的优势是可以侵入到 JVM 内部对用户的代码进行拦截,方便的实施白名单机制,进而保证平台的安全性。但随着接入应用数量的逐渐增多,更多的需求接踵而来,比如:需要多语言的支持,应用希望有更大的灵活性,不希望平台有过多的限制等。
新版 PaaS 平台设计之初,我们也考虑了多种方案,首选的方案就是继续采用沙盒模式,为每种语言去实现一个沙盒,这种方案的代价比较大,而且仍然无法满足应用的灵活性需求。
第二种方案就是采用虚拟化技术进行隔离,传统的半虚或全虚的虚拟化技术如:KVM、Xen 等,由于是完整的模拟 OS,因此带来的 Overhead 会比较大,而且一台物理机上能生成的虚拟机数量也非常有限,这样的虚拟化技术并不适合应用在 PaaS 平台上。而基于内核的虚拟化方案 Container 则很好的满足了我们的需求,宿主上的所有 Container 都共享同一个内核,共享同一个 OS,它足够的轻量,它的 provisioning 时间在秒级,一个宿主上甚至可以运行上千个 Container,可以极大地提升资源利用率,因此,我们最终就选用了 Container 方案。
Container 在不同的平台下也有不同的方案,比如:Solaris Zones,FreeBSD Jails,Linux 平台下的 LXC,OpenVZ,Linux VServer 等。搜狐一直以来就是 Linux 平台,因此也就只能在该平台下去选择相应的技术。其实就技术的成熟度来讲,OpenVZ 发展的比较早,有很多特性,相对也比较稳定,国内外有很多 VPS 就是使用的 OpenVZ,但 OpenVZ 和 VServer 是单独的一个内核分支,没有进入 upstream 中,而 LXC 则从 2.6.29 就进入到了主内核中,我们还是希望跟着主内核走,因此最后就采用了 LXC。
搜狐云景基于容器的架构
搜狐云景的整个弹性运行环境就是基于容器构建的,这些容器都运行在物理服务器上,总体上分为以下几层:
- Node OS:即物理服务器的操作系统层,所有的 Container 都共享此 OS 和系统内核。
- Node Agent:对 Container 的生命周期进行管控,它和云景平台的其它模块通信,进行容器的创建、销毁、更新等操作,并负责对 Containers 进行监控。
- LXC Scripts:在 LXC 的基本命令行基础上,抽象出一层对 Container 的管理功能。
- Containers:即真正的容器,它是由 Node Agent 发出调度指令,通过 LXC Scripts 创建出来的容器。
搜狐云景目前使用的内核版本为 2.6.32,此系列的内核版本对 Container 的支持还不太完善,我们前期在测试和使用过程中,也遇到了不少的问题,其中不乏一些严重的 Bug。因此,搜狐内部专门成立了一个系统研发团队,负责对 Kernel 和 LXC 进行研究,在标准的内核基础上做了大量的工作,修复了若干 Bug,同时也将一些新特性移植到了内核中,从而形成了我们自己的内核。
Linux Kernel 2.6.32 优化工作
下面简单介绍一下我们做的一些主要工作:
- 将 AUFS 和 OverlayFS 移植到内核中,通过这种 UnionFS 技术,我们为每个 Container 挂载一个基础的只读 RootFS 和一个可读写的文件系统,从而可以实现一个 Node 上所有容器共享同一个 RootFS,大大缩减了空间的占用,而且可以共享一些基础的动态链接库以及 Page Cache。
- 在 2.6 的标准内核中引入了 setfs 系统调用,从而实现了对 lxc-attach 的支持,搜狐云景的 Node Agent 上有不少操作需要通过此命令去实现对 Container 的管理。
- 修复了一些可能导致 Kernel Crash 的 Bug,比如:系统 Driver 的 Bug,AUFS 操作的 Bug。这类的 Bug 影响非常大,直接可造成内核崩溃,Node 自动重启,从而造成上面的所有 Container 全部消失,极大的影响整个平台的稳定性。
- 修复了一些 Container 的安全性问题:比如:在 Container 内部可以直接 mount cgroup,从而修改 cgroup 对该容器的管控配额信息。禁止容器对系统敏感文件的读写操作,防止容器内部对 Node 的一些危险操作。
- 修改了容器内系统信息显示的问题,比如:top/free 等命令显示不准确。
搜狐云景实现了对哪些资源的隔离和管控
Container 技术主要是通过 Namespace 机制对不同实例的资源进行隔离,包括网络隔离、进程隔离、文件系统隔离等,保证运行在一个容器的应用,不会影响到其它容器的应用。通过 Cgroup 机制对每个实例的资源进行管控,主要实现了对以下资源的限制,防止实例滥用系统资源:
- 内存:设置每个容器所能使用的最大物理内存,当容器内的进程使用内存超限后,则 Cgroup 会自动将相应的进程 Kill 掉。
- CPU:通过为不同的容器指定不同的 CPU 核,去限制其只能使用特定的核,并为每个容器设置不同的 CPU shares,另外还控制每个容器对 CPU 资源的最长连续使用时间,防止某个容器过度使用 CPU 资源。
- 磁盘:LXC 目前对磁盘配额的支持不够,搜狐云景通过 LVM 卷去限制单个容器的配额,并可以方便的对磁盘进行扩容。
在网络隔离方面,我们也使用了 Iptables、TC、SDN 等技术方案,对实例的网络流、流量进行管控,最终可以细化到实例可访问哪些网络资源,不能访问哪些网络资源。针对一些静态的访问策略,比如:容器无法访问某台服务器,搜狐云景在设备上做 ACL 或者在服务器上通过 Iptables 去实现。在搜狐云景上也会有一些动态的策略,比如:某个应用绑定了 Cache 服务,则需要动态将该应用的所有实例开通到 Cache 服务器的网络连接权限,这些动态策略主要是通过 SDN 去完成的。通过 TC,我们去限制每个容器的流入流出流量,防止发生由于某个容器的异常流量,造成云景内部网络带宽跑满,从而影响到其它应用的正常运行。
搜狐私有 PaaS 平台在内部的应用情况
搜狐云景在对外发布公测之前,其私有 PaaS 平台其实已经在搜狐内部经历了近 3 年的磨练,也经历了 2 次版本的迭代过程,从 V1 版本的沙盒模式到 V2 版本的 Container,一路走下来,虽然踩了很多的坑,但也收获了很多。在 Container 使用初期,整个平台表现不太稳定,Node 或者 Container 总会时不时的出现问题,甚至崩溃,经过我们的优化和改进后,平台日趋成熟,并已经处于稳定运行阶段,现在,Node 或 Container 几乎没有出现 Crash 的情况。目前我们私有 PaaS 平台的可用性可达到 99.99%。
现在搜狐内部已有多个业务线将其应用迁移到了私有 PaaS 平台上,比如:搜狐焦点,搜狐汽车,企业网盘,通行证等,部分业务线几乎做到了服务器“零采购”和”零运维“。这些应用的每个实例均运行在不同的 Container 中。内部应用对资源的需求相对比较大,因此,我们的单台物理机上目前运行 30-50 个左右的容器,而对搜狐云景来说,我们提供了更多不同配置的容器,最小容器配置为 256M 内存,这样单台物理机上可运行上百个不同类型的容器,可满足不同应用的需求。
Container 总结和前瞻
虽然 Container 技术已经被众多的互联网企业所接受和采用,并大量地应用在企业内部的云平台上,但不可否认的是,现在 Container 相关的技术仍然还不太完善,还有不少的问题,它在 CPU、IO 等隔离性方面还比较薄弱。尤其是将 Container 技术应用在公有云平台上,会面临不小的挑战,如何保证公有云平台上应用和环境的安全性,是需要大家持续研究和跟进的。而且,现在也有了一些方案,比如:OpenShift 将 SELinux 和 Container 进行结合,而 Ubuntu 则通过 Apparmor 去加强 Container 的安全性。相信随着云计算在业界的不断蓬勃发展,Container 相关技术也会得到持续的改进和完善,并被大量地应用在企业的云平台上。
目前,大家所能看到的是 Container 被广泛地使用在了 PaaS 平台,其实在大部分企业内部的 IaaS 平台上,Container 也是一个很不错的选择方案。由于其更轻量、性能更好,我认为在不少场景中,Container 可能可以完全替代现有的虚拟化技术,如:Xen、KVM 等,而且相信未来支持 Container 的 IaaS 管理平台也会不断地涌现出来,Container 的未来值得我们期待!
感谢刘宇对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。
评论