前段时间，由于工作上的原因，与Docker的联系发生了几个月的中断^_^，从10月份开始，工作中又与Docker建立了广泛密切的联系。不过这次，Docker却给我泼了一盆冷水:(。事情的经过请允许多慢慢道来。

经过几年的开发，Docker已经成为轻量级容器领域不二的事实标准，应用范围以及社区都在快速发展和壮大。今年的年中，Docker发布了其里程碑的版本Docker 1.12，该版本最大的变动就在于其引擎自带了swarmkit ，一款Docker开发的容器集群管理工具，可以让用户无需安装第三方公司提供的工具或Docker公司提供的引擎之外的工具，就能搭建并管理好一个容器集群，并兼有负载均衡、服务发现和服务编排管理等功能。这对于容器生态圈内的企业，尤其是那些做容器集群管理和服务编排平台的公司来说，不亚于当年微软在Windows操作系统中集成Internet Explorer。对此，网上和社区对Docker口诛笔伐之声不绝于耳，认为Docker在亲手打击社区，葬送大好前程。关于商业上的是是非非，我们这里暂且不提。不可否认的是，对于容器的普通用户而言，Docker引擎内置集群管理功能带来的更多是便利。

9月末启动的一款新产品的开发中，决定使用容器技术，需要用到容器的集群管理以及服务伸缩、服务发现、负载均衡等特性。鉴于团队的能力和开发时间约束，初期我们确定直接利用Docker 1.12版本提供的这些内置特性，而不是利用第三方，诸如k8s或Rancher这样的第三方容器集群管理工具或是手工利用各种开源组件“拼凑”出一套满足需求的集群管理系统，如利用consul做服务注册和发现等。于是Docker 1.12的集群模式之旅就开始了。

一、环境准备

这次我们直接使用的是阿里的公有云虚拟主机服务，这里使用两台aliyun ECS：

manager: 10.46.181.146/21(内网)
worker: 10.47.136.60/22 (内网）

系统版本为：

Ubuntu 14.04.4:
Linux iZ25cn4xxnvZ 3.13.0-86-generic #130-Ubuntu SMP Mon Apr 18 18:27:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Docker版本：

# docker version
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:22:43 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:22:43 2016
 OS/Arch:      linux/amd64

在Ubuntu上Docker的安装日益方便了，我个人习惯于采用daocloud推荐的方式，在这里可以看到。当然你也可以参考Docker官方的doc。

如果你的Ubuntu上已经安装了old版的Docker，也可以在docker的github上下载相应平台的二进制包，覆盖本地版本即可（注意1.10.0版本前后的Docker组件有所不同）。

二、Swarm集群搭建

Docker 1.12内置swarm mode，即docker原生支持的docker容器集群管理模式，只要是执行了docker swarm init或docker swarm join到一个swarm cluster中，执行了这些命令的host上的docker engine daemon就进入了swarm mode。

swarm mode中，Docker进行了诸多抽象概念（这些概念与k8s、rancher中的概念大同小异，也不知是谁参考了谁^_^）：

- node: 部署了docker engine的host实例，既可以是物理主机，也可以是虚拟主机。
- service: 由一系列运行于集群容器上的tasks组成的。
- task: 在具体某个docker container中执行的具体命令。
- manager: 负责维护docker cluster的docker engine，通常有多个manager在集群中，manager之间通过raft协议进行状态同步，当然manager角色engine所在host也参与负载调度。
- worker: 参与容器集群负载调度，仅用于承载tasks。

swarm mode下，一个Docker原生集群至少要有一个manager，因此第一步我们就要初始化一个swarm cluster：

# docker swarm init --advertise-addr 10.46.181.146
Swarm initialized: current node (c7vo4qtb2m41796b4ji46n9uw) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-1iwaui223jy6ggcsulpfh1bufn0l4oq97zifbg8l5na914vyz5-2mg011xh7vso9hu7x542uizpt \
    10.46.181.146:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

通过一行swarm init命令，我们就创建了一个swarm集群。同时，Docker daemon给出了清晰提示，如果要向swarm集群添加worker node，执行上述提示中的语句。如果其他node要以manager身份加入集群，则需要执行：docker swarm join-token manager以获得下一个“通关密语”^_^。

# docker swarm join-token manager
To add a manager to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-1iwaui223jy6ggcsulpfh1bufn0l4oq97zifbg8l5na914vyz5-8wh5gp043i1cqz4at76wvx29m \
    10.46.181.146:2377

对比两个“通关密语”，我们发现仅是token串的后半部分有所不同(2mg011xh7vso9hu7x542uizpt vs. 8wh5gp043i1cqz4at76wvx29m)。

在未添加新node之前，我们可以通过docker node ls查看当前集群内的node状态：

# docker node ls
ID                           HOSTNAME      STATUS  AVAILABILITY  MANAGER STATUS
c7vo4qtb2m41796b4ji46n9uw *  iZ25mjza4msZ  Ready   Active        Leader

可以看出当前swarm仅有一个node，且该node是manager，状态是manager中的leader。

我们现在将另外一个node以worker身份加入到该swarm：

# docker swarm join \
     --token SWMTKN-1-1iwaui223jy6ggcsulpfh1bufn0l4oq97zifbg8l5na914vyz5-2mg011xh7vso9hu7x542uizpt \
     10.46.181.146:2377
This node joined a swarm as a worker.

在manager上查看node情况：

# docker node ls
ID                           HOSTNAME      STATUS  AVAILABILITY  MANAGER STATUS
8asff8ta70j91myh734os6ihg    iZ25cn4xxnvZ  Ready   Active
c7vo4qtb2m41796b4ji46n9uw *  iZ25mjza4msZ  Ready   Active        Leader

Swarm集群中已经有了两个active node：一个manager和一个worker。这样我们的集群环境初建ok。

三、Service启动

Docker 1.12版本宣称提供服务的Scaling、health check、滚动升级等功能，并提供了内置的dns、vip机制，实现service的服务发现和负载均衡能力。接下来，我们来测试一下docker的“服务能力”：

我们先来创建一个用户承载服务的自定义内部overlay网络：

root@iZ25mjza4msZ:~# docker network create -d overlay mynet1
avjvpxkfg6u8xt0qd5xynoc28
root@iZ25mjza4msZ:~# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
dba1faa24c0d        bridge              bridge              local
a2807d0ec7ed        docker_gwbridge     bridge              local
2b6eb8b95c00        host                host                local
55v43pasf7p9        ingress             overlay             swarm
avjvpxkfg6u8        mynet1              overlay             swarm
6f2d47678226        none                null                local

我们看到在network list中，我们的overlay网络mynet1出现在列表中。这时，在worker node上你还看不到mynet1的存在，因为按照目前docker的机制，只有将归属于mynet1的task调度到worker node上时，mynet1的信息才会同步到worker node上。

接下来就是在mynet1上启动service的时候了，我们先来测试一下：

在manager节点上，用docker service命令启动服务mytest：

# docker service create --replicas 2 --name mytest --network mynet1 alpine:3.3 ping baidu.com
0401ri7rm1bdwfbvhgyuwroqn

似乎启动成功了，我们来查看一下服务状态：

root@iZ25mjza4msZ:~# docker service ps mytest
ID                         NAME          IMAGE       NODE          DESIRED STATE  CURRENT STATE                     ERROR
73hyxfhafguivtrbi8dyosufh  mytest.1      alpine:3.3  iZ25mjza4msZ  Ready          Preparing 1 seconds ago
c5konzyaeq4myzswthm8ax77w   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 1 seconds ago              "starting container failed: co…"
6umn2qlj34okagb4mldpl6yga   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 6 seconds ago              "starting container failed: co…"
5y7c1uoi73272uxjp2uscynwi   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 11 seconds ago             "starting container failed: co…"
4belae8b8mhd054ibhpzbx63q   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 16 seconds ago             "starting container failed: co…"

似乎服务并没有起来，service ps的结果告诉我：出错了！

但从ps的输出来看，ERROR那行的日志太过简略：“starting container failed: co…” ，无法从这里面分析出失败原因，通过docker logs查看失败容器的日志（实际上日志是空的）以及通过syslog查看docker engine的日志都没有特殊的发现。调查了许久，无意中尝试手动重启一下失败的Service task：

# docker start 4709dbb40a7b
Error response from daemon: could not add veth pair inside the network sandbox: could not find an appropriate master "ov-000101-46gc3" for "vethf72fc59"
Error: failed to start containers: 4709dbb40a7b

从这个Daemon返回的Response Error来看似乎与overlay vxlan的网络驱动有关。又经过搜索引擎的确认，大致确定可能是因为host的kernel version太low导致的，当前kernel是3.13.0-86-generic，记得之前在docker 1.9.1时玩vxlan overlay我是将kernel version升级到3.19以上了。于是决定升级kernel version。

升级到15.04 ubuntu版本的内核：

命令：

    apt-get install linux-generic-lts-vivid

升级后：

# uname -a
Linux iZ25cn4xxnvZ 3.19.0-70-generic #78~14.04.1-Ubuntu SMP Fri Sep 23 17:39:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

reboot虚拟机后，重新启动mytest service，这回服务正常启动了。看来升级内核版本这味药是对了症了。

这里issue第一个吐槽：Docker强依赖linux kernel提供的诸多feature，但docker似乎在kernel版本依赖这块并未给出十分明确的对应关系，导致使用者莫名其妙的不断遇坑填坑，浪费了好多时间。

顺便这里把service的基本管理方式也一并提一下：

scale mytest服务的task数量从2到4：

docker service scale mytest=4

删除mytest服务：

docker service rm mytest

服务删除执行后，需要一些时间让docker engine stop and remove container instance。

四、vip机制测试

Docker 1.12通过集群内置的DNS服务实现服务发现，通过vip实现自动负载均衡。单独使用DNS RR机制也可以实现负载均衡，但这种由client端配合实现的机制，无法避免因dns update latency导致的服务短暂不可用的情况。vip机制才是相对理想的方式。

所谓Vip机制，就是docker swarm为每一个启动的service分配一个vip，并在DNS中将service name解析为该vip，发往该vip的请求将被自动分发到service下面的诸多active task上（down掉的task将被自动从vip均衡列表中删除）。

我们用nginx作为backend service来测试这个vip机制，首先在集群内启动mynginx service，内置2个task，一般来说，docker swarm会在manager和worker node上各启动一个container来承载一个task：

# docker service create --replicas 2 --name mynginx --network mynet1 --mount type=bind,source=/root/dockertest/staticcontents,dst=/usr/share/nginx/html,ro=true  nginx:1.10.1
3n7dlr8km9v2xd66bf0mumh1h

一切如预期，swarm在manager和worker上各自启动了一个nginx container:

# docker service ps mynginx
ID                         NAME       IMAGE         NODE          DESIRED STATE  CURRENT STATE               ERROR
bcyffgo1q3i5x0qia26fs703o  mynginx.1  nginx:1.10.1  iZ25mjza4msZ  Running        Running about a minute ago
arkol2l7gpvq42f0qytqf0u85  mynginx.2  nginx:1.10.1  iZ25cn4xxnvZ  Running        Running about a minute ago

接下来，我们尝试在mynet1中启动一个client container，并在client container中使用ping、curl对mynginx service进行vip机制的验证测试。client container的image是基于ubuntu:14.04 commit的本地image，只是在官方image中添加了curl, dig, traceroute等网络探索工具，读者朋友可自行完成。

我们在manager node上尝试启动client container:

# docker run -it --network mynet1 ubuntu:14.04 /bin/bash
docker: Error response from daemon: swarm-scoped network (mynet1) is not compatible with `docker create` or `docker run`. This network can only be used by a docker service.
See 'docker run --help'.

可以看到：直接通过docker run的方式在mynet1网络里启动container的方法失败了，docker提示：docker run与swarm范围的网络不兼容。看来我们还得用docker service create的方式来做。

# docker service create --replicas 1 --name myclient --network mynet1 test/client tail -f /var/log/bootstrap.log
0eippvade7j5e0zdyr5nkkzyo

# docker ps
CONTAINER ID        IMAGE                                                 COMMAND                  CREATED             STATUS              PORTS                    NAMES
4da6700cdf4d        test/client:latest   "tail -f /var/log/boo"   33 seconds ago      Up 32 seconds                                myclient.1.3cew8x46i5b28e2q3kd1zz3mq

我们使用exec命令attach到client container中：

root@iZ25mjza4msZ:~# docker exec -it 4da6700cdf4d /bin/bash
root@4da6700cdf4d:/#

在client container中，我们可以通过dig命令查看mynginx service的vip：

root@4da6700cdf4d:/# dig mynginx

; <<>> DiG 9.9.5-3ubuntu0.9-Ubuntu <<>> mynginx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34806
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mynginx.            IN    A

;; ANSWER SECTION:
mynginx.        600    IN    A    10.0.0.2

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11)
;; WHEN: Tue Oct 11 08:58:58 UTC 2016
;; MSG SIZE  rcvd: 48

可以看到为mynginx service分配的vip是10.0.0.2。

接下来就是见证奇迹的时候了，我们尝试通过curl访问mynginx这个service，预期结果是：请求被轮询转发到不同的nginx container中，返回结果输出不同内容。实际情况如何呢？

root@4da6700cdf4d:/# curl mynginx
^C
root@4da6700cdf4d:/# curl mynginx
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title> 主标题 | 副标题< /title>
</head>
<body>
<p>hello world, i am manager</p>
</body>
</html>
root@4da6700cdf4d:/# curl mynginx
curl: (7) Failed to connect to mynginx port 80: Connection timed out

第一次执行curl mynginx，curl就hang住了。ctrl+c后，再次执行curl mynginx，顺利返回manager节点上的nginx container的response结果：”hello world, i am manager“。

第三次执行curl mynginx，又hang住了，一段时间后显示timed out，这也从侧面说明了，swarm下的docker engine的确按照rr规则将request均衡转发到不同nginx container，但实际看来，从manager node上的client container到worker node上的nginx container的网络似乎不通。我们来验证一下这两个container间的网络是否ok。

我们在两个node上分别用docker inspect获得client container和nginx container的ip地址：

    manager node:
        client container: 10.0.0.6
        nginx container: 10.0.0.4
    worker node:
        nginx container: 10.0.0.3

理论上，位于同一overlay网络中的三个container之间应该是互通的。但实际上通过docker exec -it container_id /bin/bash进入每个docker container内部进行互ping来看，manager node上的两个container可以互相ping通，但无法ping通 worker node上的nginx container，同样，位于worker node上的nginx container也无法ping通位于manager node上的任何container。

通过docker swarm leave将worker节点从swarm cluster中摘出，docker swarm会在manager上再启动一个nginx container，这时如果再再client container测试vip机制，那么测试是ok的。

也就是说我遇到的问题是跨node的swarm network不好用，导致vip机制无法按预期执行。

后续我又试过双swarm manager等方式，vip机制在跨node时均不可用。在docker github的issue中，很多人遇到了同样的问题，涉及的环境也是多种多样（不同内核版本、不同linux发行版，不同公有云提供商或本地虚拟机管理软件），似乎这个问题是随机出现的。 按照docker developer的提示检查了swarm必要端口的开放情况、防火墙、swarm init的传递参数，都是无误的。也尝试过重建swarm，在init和join时全部显式带上–listen-addr和–advertise-addr选项，问题依旧没能解决。

最后，又将docker版本从1.12.1升级到最新发布的docker 1.12.2rc3版本，重建集群，问题依旧没有解决。

自此确定，docker 1.12的vip机制尚不稳定，并且没有临时解决方案能绕过这一问题。

五、Routing mesh机制测试

内部网络的vip机制的测试失败，让我在测试Docker 1.12的另外一个机制：Routing mesh之前心里蒙上了一丝阴影，一个念头油然而生：Routing mesh可能也不好用。

对于外部网络和内部网络的边界，docker 1.12提供了ingress（入口） overlay网络应对，通过routing mesh机制，保证外部的请求可以被任意集群node转发到启动了相应服务container的node中，并保证高
可用。如果有多个container，还可以实现负载均衡的转发。

与vip不同，Routing mesh在启动服务前强调暴露一个node port的概念。既然叫node port，说明这个暴露的port是docker engine listen的，并由docker engine将发到port上的流量转到相应启动了service container的节点上去（如果本node也启动了service task，那么也会负载分担留给自己node上的service task container去处理）。

我们先清除上面的service，还是利用nginx来作为网络入口服务：

# docker service create --replicas 2 --name mynginx --network mynet1 --mount type=bind,source=/root/dockertest/staticcontents,dst=/usr/share/nginx/html,ro=true --publish 8091:80/tcp nginx:1.10.1
cns4gcsrs50n2hbi2o4gpa1tp

看看node上的8091端口状态：

root@iZ25mjza4msZ:~# lsof -i tcp:8091
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dockerd 13909 root   37u  IPv6 121343      0t0  TCP *:8091 (LISTEN)

dockerd负责监听该端口。

接下来，我们在manager node上通过curl来访问10.46.181.146:8091。

# curl 10.46.181.146:8091
^C
root@iZ25mjza4msZ:~# curl 10.46.181.146:8091
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title> 主标题 | 副标题< /title>
</head>
<body>
<p>hello world, i am master</p>
</body>
</html>
root@iZ25mjza4msZ:~# curl 10.46.181.146:8091

在vip测试中的一幕又出现了，docker swarm似乎再将请求负载分担到两个node上，当分担到worker node上时，curl又hang住了。routing mesh机制失效。

理论上再向swarm cluster添加一个worker node，该node上并未启动nginx service，当访问这个新node的8091端口时，流量也会被转到manager node或之前的那个worker node，但实际情况是，跨node流量互转失效，和vip机制测试似乎是一个问题。

六、小结

Docker 1.12的routing mesh和vip均因swarm network的问题而不可用，这一点出乎我的预料。

翻看Docker在github上的issues，发现类似问题从Docker 1.12发布起就出现很多，近期也有不少：

https://github.com/docker/docker/issues/27237

https://github.com/docker/docker/issues/27218

https://github.com/docker/docker/issues/25266

https://github.com/docker/docker/issues/26946

*https://github.com/docker/docker/issues/27016

这里除了27016的issue发起者在issue最后似乎顿悟到了什么（也没了下文）：Good news. I believe I discovered the root cause of our issue. Remember above I noted our Swarm spanned across L3 networks? I appears there is some network policy that is blocking VxLAN traffic (4789/udp) across the two L3 networks. I redeployed our same configuration to a single L3 network and can reliably access the published port on all worker nodes (based on a few minutes of testing)。其余的几个issue均未有solution。

不知道我在阿里云的两个node之间是否有阻隔vxlan traffic的什么policy，不过使用nc探测4789 udp端口均是可用的：

nc -vuz 10.47.136.60 4789

无论是配置原因还是代码bug导致的随机问题，Docker日益庞大的身躯和背后日益复杂的网络机制，让开发者（包括docker自己的开发人员）查找问题的难度都变得越来越高。Docker代码的整体质量似乎也呈现出一定下滑的不良趋势。

针对上述问题，尚未找到很好的解决方案。如果哪位读者能发现其中玄机，请不吝赐教。

当Docker, Inc在今年年初宣布收购Unikernel Systems公司时，Unikernel对大多数技术人员来说还是很陌生的。直到今天，知名问答类网站知乎上也没有以Unikernel为名字的子话题。国内搜索引擎中关于Unikernel的内容很少，实践相关的内容就更少了。Docker收购Unikernel Systems，显然不是为了将这个其未来潜在的竞争对手干掉，而是嗅到了Unikernel身上的某些技术潜质。和关注Docker一样，本博客后续将持续关注Unikernel的最新发展和优秀实践，并将一些国外的优秀资料搬(翻)移(译)过来供国内Unikernel爱好者和研究人员参考。

本文翻译自BSD Magazine2016年第3期中Russell Pavlicek的文章《Understanding Unikernels》，译文全文如下。

当我们描述一台机器（物理的或虚拟的）上的操作系统内核时，我们通常所指的是运行在特定处理器模式（内核模式）下且所使用的地址空间有别于机器上其他软件运行地址空间的一段特定的软件代码。操作系统内核通常用于提供一些关键的底层函数，这些函数被操作系统中其他软件所使用。内核通常是一段通用的代码，（有需要时）一般会被做适当裁剪以适配支持机器上的应用软件栈。这个通用的内核通常会提供各种功能丰富的函数，但很多功能和函数并不是内核支持的特定应用程序所需要的。

事实上，如果看看今天大多数机器上运行的整体软件栈，我们会发现很难弄清楚到底哪些应用程序运行在那台机器上了。你可能会发现即便没有上千，也会有成百计的低级别实用程序（译注：主要是指系统引导起来后，常驻后台的一些系统服务程序），外加许多数据库程序，一两个Web服务程序，以及一些指定的应用程序。这台机器可能实际上只承担运行一个单独的应用程序，或者它也可能被用于同时运行许多应用。通过对系统启动脚本的细致分析来确定最终运行程序的集合是一个思路，但还远非精准。因为任何一个具有适当特权的用户都可以去启动系统中已有应用程序中的任何一个。

Unikernel的不同之处

基于Unikernel的机器的覆盖面（footprint）是完全不同的。在物理机器（或虚拟机映像）中，Unikernel扮演的角色与其他内核是相似的，但实现特征显著不同。

例如，对一个基于Unikernel的机器的代码进行分析就不会受到大多数其他软件栈的模糊性的影响。当你考虑分析一个Unikernel系统时，你会发现系统中只存在一个且只有一个应用程序。那种标准的多应用程序软件栈不见了，前面提到的过多的通用实用程序和支持函数也不见了。不过裁剪并未到此打住。不仅应用软件栈被裁剪到了最低限度，操作系统功能也同样被剪裁了。例如，多用户支持、多进程支持以及高级内存管理也都不见了。

认为这很激进？想想看：如果整个独立的操作系统层也不见了呢！内核不再有独立的地址空间，应用程序也不再有独立的地址空间了。为什么？因为内核的功能函数和应用程序现在都成为了同一个程序的一部分。事实上，整个软件栈是由一个单独的软件程序构成的，这个程序负责提供应用程序所需的所有代码以及操作系统的功能函数。如果这还不够的话，只需在Unikernel中提供应用所需的那些功能函数即可，所有其他应用程序所不需要的操作系统功能函数都会被整体移除掉。

一个反映新世纪现实的软件栈

Unikernel的出现，其背后的目的在于对这个行业的彻底的反思。几十年来，在这个行业里我们的工作一直伴随着这样一个理念：机器的最好架构是基于一个通用多用户操作系统启动，加载一系列有用的实用工具程序，添加我们可能需要使用的应用程序。最后，再使用一些包管理软件来管理这种混乱的情况。

35年前，这种做法是合乎情理的。那个时候，硬件很昂贵，虚拟化的选择非常有限甚至是不可用。安全仅局限于保证计算中心坐在你身旁的人没有在偷看你输密码。一台机器需要同时处理许多用户运行的许多应用程序以保证较高的成本效益。当我还在大学（1、2千年前。 译注：作者开玩笑，强调那时的古老^_^）时，在个人计算机出现之前，学校计算机中心有一个超级昂贵的机器（以今天的标准来看） – 一台DEC PDP-11/34a，配置了248K字节的内存和25M磁盘，为全校的计算机科学、工程以及数学专业的学生使用。这台机器必须服务于几百名学生每个学期想出的每个功能。

对比计算机历史上那个远古时代的恐龙和现代的智能手机，你会发现手机拥有的计算能力高出那台机器几个数量级。这样一来，我们为什么还要用在计算机石器时代所使用的那些原则去创建机器内核映像呢？重新思考与新的计算现实相匹配的软件栈难道不是很有意义吗？

在现代世界，硬件十分便宜。虚拟化无处不在且运行效率很高。几乎所有计算设备都连接在一个巨大的、世界范围的且存在潜在恶意黑客的网络中。想想看：一台DNS服务器真的不需要上千兆的字节去完成它的工作；一台应用服务器也真的不需要为刚刚利用一个漏洞获得虚拟命令行访问权的黑客准备数千实用工具程序。 一个Web服务器并不需要验证500个不同的分时用户的命令行登录。那么为什么我们现在仍然在使用支持这些不需要的场景的过时的软件栈概念呢？

Unikernel的美丽新世界

那么一个现代软件栈应该是什么样子的呢？下面这个怎么样：单一应用映像，虚拟化的，高度安全的，超轻量的，具有超快启动速度。这些正是Unikernel所能提供的。我们逐一来说：

单一映像

叠加在一个通用内核上的数以百计的实用工具程序和大量应用程序被一个可执行体所替代。这个可执行体将所有需要的应用程序和操作系统代码放置在一个单一的映像中。它只包含它所需要的。

虚拟化的

就在几年前，你可以很幸运地在一台服务器上启动少量虚拟机。硬件的内存限制以及守旧的、吃内存的软件栈不允许你在一台服务器上同时启动太多虚机。今天我们有了配置了数千兆内存的高性能服务器，我们不再满足于每台机器仅能启动少量虚机了。如果每个虚机映像足够小，我们可以在一个服务器上同事运行数百个，甚至上千个虚机应用。

安全

在云计算时代，我们发现恶意黑客可以例行公事般入侵各地的服务器，即便是那些知名大公司和政府机构的服务器也不例外。这些违规行为常常是利用了某个网络服务的缺陷并进入了软件栈的更低层。从那开始，恶意入侵者可以利用系统中已有的实用程序或其他应用程序来实施他们的邪恶行为。在Unikernel栈中，没有其他软件可以协助这些恶意的黑客。黑客必须足够聪明才能入侵其中的应用程序，但接下来还是没有驻留的工具可以用来协助做坏事。虽然Unikernel栈不会使得软件彻底完全的变安全，但是它确能显著提升软件的安全级别。并且这是云计算时代长期未兑现的一种进步。

超轻量

一个正常的VM仅仅是为了能在网络中提供少量的服务就要占用千兆的磁盘和内存空间。若使用Unikernel，我们可以不再纠结于这些资源需求。例如，使用MirageOS(一个非常流行的Unikernel系统)，我们可以构建出一个具备DNS服务功能的VM映像，其占用的磁盘空间仅仅为449K – 是的，还不到半兆。使用ClickOS，一个来自NEC实验室的网络应用Unikernel系统制作的网络设备仅仅使用6兆内存却可以成功达到每秒5百万包的处理能力。这些绝不是基于Unikernel的设备的非典型例子。鉴于Unikernels的小巧精简，在单主机服务器上启动数百或数千这类微小虚拟机的想法似乎不再遥不可及。

快速启动

普通VM的引导启动消耗较长时间。在现代硬件上启动一个完整操作系统以及软件栈直到服务上线需要花费一分钟甚至更多的时间。但是对于基于Unikernel的VM来说，这种情况却不适用。绝大多数的Unikernel VM引导启动时间少于十分之一秒。例如，ClickOS网络VM文档中记录的引导启动时间在30毫秒以下。这个速度快到足以在服务请求到达网络时再启动一个用于处理该请求的VM了（这正是Jitsu项目所要做的事情，参见http://unikernel.org/files/2015-nsdi-jitsu.pdf）。

但是，容器不已经做到这一点了吗？

在创建轻量级，快速启动的VM方面，容器已经走出了很远。但在幕后容器依然依赖着一个共享的、健壮的操作系统。从安全的角度来看，容器还有很多要锁定的地方。很明显我们需要加强我们在云中的安全，但不是去追求这些相同的、陈旧的、在云中就会快速变得漏洞百出的安全方法。除此之外，Unikernel的最终覆盖面仍然要比容器能提供的小得很多。因此容器走在了正确的方向上，而Unikernel则设法在这个未来云所需要的方向上走的更远。

Unikernels是如何工作的？

正如之前提到的，传统机器自底向上构建：你选择一个通用的操作系统内核，添加大量实用工具程序，最后添加应用程序。Unikernel正好相反：它们是自顶向下构建的。聚焦在你要运行的应用程序上，恰到好处地添加使其刚好能运行的操作系统函数。大多数Unikernel系统依靠一个编译链接系统，这个系统编译应用程序源码并将应用程序所需的操作系统函数库链接进来，形成一个单独的编译映像。无需其他软件，这个映像就可以运行在VM中。

如何对结果进行调试？

由于在最终的成品中没有操作系统或实用工具程序，绝大多数Unikernel系统使用了一种分阶段的方法来开发。通常，在开发阶段一次编译会生成一个适合在Linux或类Unix操作系统上进行测试的可执行程序。这个可执行程序可以运行和被调试，就像任何一个标准程序那样。一旦你对测试结果感到满意，你可以重新编译，打开开关，创建独立运行在VM中的最终映像。

在生产环境机器上缺少调试工具并没有最初想象的那样糟糕。绝大多数组织不允许开发人员在生产机器上调试，相反，他们收集日志和其他信息，在开发平台重现失败场景，修正问题并重新部署。这个事实让调试生产映像的限制也有所缓和。在Unikernel世界中，这个操作顺序也已具备。你只需要保证你的生产环境映像可以输出足够多的日志以方便重构失败场景。你的标准应用程序可能正在做这些事情了。

有哪些可用的Unikernel系统？

现在有很多Unikernel可供选择，它们支持多种编程语言，并且Unikernel项目还在持续增加中。一些较受欢迎的Unikernel系统包括：

• MirageOS：最早的Unikernels系统之一，它使用Ocaml语言；
• HaLVM：另外一个早期Unikernels系统，由Haskell语言实现；
• LING：历史悠久的项目，使用Erlang实现；
• ClickOS：为网络应用优化的系统，支持C、C++和Python；
• OSv：稍有不同的Unikernel系统，它基于Java，并支持其他一些编程语言。支持绝大多数JAR文件部署和运行。
• Rumprun：使用了来自NetBSD项目的模块代码，目标定位于任何符合POSIX标准的、不需要Fork的应用程序，特别适合将现有程序移植到Unikernel世界。

Unikernel是灵丹妙药吗？

Unikernel远非万能的。由于他们是单一进程实体，运行在单一地址空间，没有高级内存管理，很多程序无法很容易地迁移到Unikernel世界。不过，运行于世界各地数据中心中的大量服务很适合该方案。将这些服务转换为轻量级Unikernel，我们可以重新分配服务器能力，任务较重的服务可以从额外的资源中受益。

转换成Unikernel的任务数量比你想象的要多。在2015年，Martin Lucina宣布成功创建了一个”RAMP”栈 – LAMP栈（Linux、Apache、MySQL和PHP/Python）的变种。RAMP栈使用了NGINX，MySQL和PHP，它们都构建在Rumprun之上。Rumprun是Rump内核的一个实例，而Rump内核则是基于NetBSD工程模块化操作系统功能函数集合的一个Unikernel系统。所以这种常见的解决方案堆栈可以成功地转化迁移到Unikernels世界中。

更多信息

要想学习更多有关Unikernels方面的内容，可以访问http://www.unikernel.org或观看2015年我在Southeast Linuxfest的演讲视频。