搜狐云景Container经验谈-InfoQ



 写点什么

背景

近几年，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 ）关注我们，并与我们的编辑和其他读者朋友交流。