搜狐云景Container经验谈

背景

近几年，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。

搜狐云景基于容器的架构

搜狐云景的整个弹性运行环境就是基于容器构建的，这些容器都运行在物理服务器上，总体上分为以下几层：

1. Node OS：即物理服务器的操作系统层，所有的Container都共享此OS和系统内核。
2. Node Agent：对Container的生命周期进行管控，它和云景平台的其它模块通信，进行容器的创建、销毁、更新等操作，并负责对Containers进行监控。
3. LXC Scripts：在LXC的基本命令行基础上，抽象出一层对Container的管理功能。

4. Containers：即真正的容器，它是由Node Agent发出调度指令，通过LXC Scripts创建出来的容器。

   搜狐云景目前使用的内核版本为2.6.32，此系列的内核版本对Container的支持还不太完善，我们前期在测试和使用过程中，也遇到了不少的问题，其中不乏一些严重的Bug。因此，搜狐内部专门成立了一个系统研发团队，负责对Kernel和LXC进行研究，在标准的内核基础上做了大量的工作，修复了若干Bug，同时也将一些新特性移植到了内核中，从而形成了我们自己的内核。

Linux Kernel 2.6.32优化工作

下面简单介绍一下我们做的一些主要工作：

1. 将AUFS和OverlayFS移植到内核中，通过这种UnionFS技术，我们为每个Container挂载一个基础的只读RootFS和一个可读写的文件系统，从而可以实现一个Node上所有容器共享同一个RootFS，大大缩减了空间的占用，而且可以共享一些基础的动态链接库以及Page Cache。
2. 在2.6的标准内核中引入了setfs系统调用，从而实现了对lxc-attach的支持，搜狐云景的Node Agent上有不少操作需要通过此命令去实现对Container的管理。
3. 修复了一些可能导致Kernel Crash的Bug，比如：系统Driver的Bug，AUFS操作的Bug。这类的Bug影响非常大，直接可造成内核崩溃，Node自动重启，从而造成上面的所有Container全部消失，极大的影响整个平台的稳定性。
4. 修复了一些Container的安全性问题：比如：在Container内部可以直接mount cgroup，从而修改cgroup对该容器的管控配额信息。禁止容器对系统敏感文件的读写操作，防止容器内部对Node的一些危险操作。
5. 修改了容器内系统信息显示的问题，比如：top/free等命令显示不准确。

搜狐云景实现了对哪些资源的隔离和管控

Container技术主要是通过Namespace机制对不同实例的资源进行隔离，包括网络隔离、进程隔离、文件系统隔离等，保证运行在一个容器的应用，不会影响到其它容器的应用。通过Cgroup机制对每个实例的资源进行管控，主要实现了对以下资源的限制，防止实例滥用系统资源：

1. 内存：设置每个容器所能使用的最大物理内存，当容器内的进程使用内存超限后，则Cgroup会自动将相应的进程Kill掉。
2. CPU：通过为不同的容器指定不同的CPU核，去限制其只能使用特定的核，并为每个容器设置不同的CPU shares，另外还控制每个容器对CPU资源的最长连续使用时间，防止某个容器过度使用CPU资源。

3. 磁盘：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的未来值得我们期待！