为什么选择Kubernetes和Mesos作为容器云的基础平台？在项目启动前，我们对当前流行的容器社区做了很多调研，主要是Docker、Mesos和Kubernetes社区。

我们先看一下Docker，Docker社区主要由Docker公司把控，虽然是开源的，但其实Docker社区相对来说不是很开放，因为Docker公司有基于Docker的所有产品，包括Docker的公有云、私有云Docker Data Center等等。这样就导致了其他公司如果想基于Docker创业的话会比较困难，因为难以与Docker公司竞争。

而Mesos社区则更开放一些，主要原因是Mesosphere在基于Mesos研发了DC/OS，正在积极寻找一些合作者来推动DC/OS在企业的落地。同时Mesosphere也期望更多的公司、更多的人加入到这个社区，增加Mesos的影响力。所以这个社区相对Docker来说更开放一些，而且Mesos已经有很多落地的案例，在刚结束的MesosCon Asia上，我们可以看到国内其实有很多骨灰级的Mesos用户，但这些用户过于低调，没有及时将自己的经验分享出来，所以也希望这些用户或已在生产使用Mesos的用户能及时为大家分享一些经验，促进Mesos生态的发展。

相比起来，Kubernetes社区是最开放、最活跃、最多元化的，虽然Kubernetes是Google开源的，但Google没有任何一个产品是基于Kubernetes的。这样就给了大家很公平的机会，基本上每个人、每个公司都可以基于Kubernetes开发自己的产品。但Kubernetes目前欠缺的是一些落地的案例，另外其支持的集群规模大小也需要提升。

我曾试着把容器的这几个社区和我们以前做虚拟化的社区做过一些对比，不知道合不合适，Docker可以类比到VMWare，Mesos可以类比到Citrix，Kubernetes可以类比到KVM。大家可以在调研选型或者使用的时候，根据自己的需求选择合适的技术。

另外一个问题，大家应该可以看到Mesos和Kubernetes都在提供除了Docker之外的容器管理能力，Mesos花了很多时间去做Unified Container这个项目，目的就是即使没有Docker Daemon，用户也可运行Docker容器，同时使用Unified Container，还可运行其他容器，例如AppC、OCI等；Kubernetes也在集成Rkt给用户除了Docker之外的另一种选择。

以上是我们容器云的总体概览，最左边是我们很熟悉的云平台的最重要的三层，IaaS、PaaS、SaaS，我们的BlueDock主要是提供PaaS的功能，是基于Kubernetes和Mesos（可选）来研发的。但如果我们建容器云的话，只有这两个是远远不够的，因为容器云里还有很多其他的功能，所以我们围绕着Kubernetes和Mesos，在上面加了很多企业级的东西，包括应用商店，资源调度的改进策略，应用、服务器的双层扩展，多租户管理，镜像管理，统一界面等等。

应用商店：最主要的功能是把用户常用的一些应用做成模板，类似手机上的App Store，用户可以很方便地通过应用市场来对应用进行部署，同时BlueDock还支持对不同版本的应用在同一个应用商店进行管理。我们还支持用户对应用市场进行定制，这样就可以让用户把一些自己常用的应用上传到应用商店，供其它用户使用。

资源调度的改进策略：因为容器的使用是一种高密度计算，对资源调度的要求很高，尤其是一些资源的抢占策略等等，这部分是原生的Kubernetes和Mesos都没有的功能，IBM对这块功能做了很大的改进，为容器云加入了资源抢占的功能。

应用、服务器的双层扩展：这个我们可以理解为是一种联动扩展。当用户的应用因为负载的变化在扩展的时候，如果发现底层的服务器不够了，那应用就没办法去扩展了。这时我们的容器云就会和底层的OpenStack交互，通过OpenStack去申请一些新的服务器加入到容器云中，实现了容器云平台和用于应用的联动扩展。我们的容器云可以和多个不同的云平台集成，实现联动扩展的功能。

多租户管理：这块主要是和OpenStack Keystone集成来对租户进行管理，同时将Keystone的Project映射为Kubernetes的namespace。另外一个是我们还通过和Keystone集成实现了层级的租户管理。按照这种层级的租户管理，一个很大的优势是可以按照层级的结构来对资源做事先的定义，这样的话就可以和企业的组织架构就可以很好的匹配起来，便于企业内部的资源分配。

镜像管理：这个服务主要是对镜像进行管理，然后我们也调研了很多开源的对镜像管理的软件，例如Harbor，但是Harbor功能太多了，里面不单单有镜像管理的功能，还有对用户，租户管理的功能，权限控制等等，里边很多功能和我们的容器云是重复的，所以我们最终决定我们没有用这个项目，而是参考Harbor自己开发了一个新的服务来对镜像进行管理。

日志管理：主要是通过ELK来实现。

持续集成：主要是通过Kubernetes Jenkins插件来实现的。这个插件的优势是在资源分配时，Jenkins根据任务属性自动创建临时Docker容器，并作为slave节点加入Jenkins集群，实现资源的分配；另外在任务执行结束后，Jenkins自动删除相关节点，并销毁相关Docker容器，实现资源的释放；整个资源分配和资源释放过程对用户来说是透明的，用户只需要创建好任务就可以了，不需要操作节点；对于Jenkins来说，slave节点（容器）是临时的，任务一结束就会销毁。为了实现数据持久化，需要和一些分布式的存储集成，例如Ceph、Glusterfs等等。

统一的UI：对所有的服务进行操作，包括可以对UI对服务对镜像进行管理，对应用市场进行管理等等。

上图是BlueDock中使用Kubernetes+Mesos的方案组件图。BlueDock中的所有组件，都是通过container来部署的。用container的一个最大的优势就是安装部署升级是很简单的，同时不会修改物理服务器的一些配置，对物理服务器不会有任何改动。我们现在的BlueDock，只需要一个通过一个“docker run”命令，就可以很方便在上百台服务器上把容器云跑起来，我们做过一些测试，如果要去部署五百台左右的服务器，我们可以在十分钟以内把整个容器云集群安装部署完成。

在图中的最下边用不同颜色的方框表示出了BlueDock中不同组件的管理方式。其中有三个比较重要的概念：Static pod、DaemonSet和Deployment。

Static pod是在特定节点上由kubelet守护程序直接管理的，Kubernetes APIServer不会对其进行管理。 它没有关联任何Relication Controller，kubelet守护进程来负责对Static pod的监控，并在static pod crash时重新启动它。 Static pod始终绑定到一个kubelet守护程序，并且始终在同一节点上运行。

DaemonSet可以确保所有（或一些）节点始终运行某个pod的副本。 当节点添加到集群时，DaemonSet可以保证自动在新添加的节点创建pod；如果节点被删除后，这些pod也会相应的被DaemonSet删除。 

Deployment是kubernetes 1.2的一个新引入的概念，它包含着对Pod和将要代替Replication Controller的Replica Set的描述。

BlueDock主要通过Static Pod、DaemonSet和Deployment来对主要组件进行管理，这三个功能可以通过Kubernetes自身的功能保证BlueDock self-healing的功能，某些Pod crash后，Static Pod、DaemonSet和Deployment可以保证其会被重启，从而保证系统的高可用。

基本流程是通过ansible调用docker-py通过docker container的形式在master节点启动kubelet，在master节点的kubelet服务启动后，就会以static pod的形式创建master节点的一些组件，例如k8sm-apiserver、k8sm-scheduler等等，当master节点的所有组件启动完毕后，开始通过docker-py在不同的worker上启动mesos agent，当整个BlueDock集群开始运行后，再通过DaemonSet的形式启动一些BlueDock的add-on的一些组件服务，例如日志管理、网络管理等等。

日志管理主要是通过DaemonSet的形式启动了Filebeat，来搜集每个worker的容器日志信息。网络管理主要是通过DaemonSet在每个worker节点启动了Calico node的container，这个container里面包含了Bird路由管理、Felix协议等。其它还有一些组件通过Deployment来管理，例如用于对log进行过滤的logstash，用于对Network Policy进行管理的calico congtroller等等。
 

上图是BlueDock没有Mesos的部署方式，基本和带有Mesos的部署模式是一样的，全部都是通过容器来对所有组件进行管理，同时可以self-healing。在这里主要想强调的是，BlueDock对k8s-scheduler做了很大的改进，支持资源的抢占，智能回收的策略。因为一台服务器上可以启动成百上千个容器，所以在这种高密度计算中，对资源的调度策略要求很高。BlueDock通过和IBM Platform的EGO集成，实现了资源的抢占和智能回收的策略。

上图是BlueDock的一个简单的改进的资源借入借出的一个例子。现在有两个tenant，T1和T2，都独占8个资源，但是我们看到在T1和T2之间有个虚线，这个虚线表示T2可以从T1借入4个资源。所以当T1和T2去申请资源的时候，T1要4个，T2要12个，那T1可以直接拿到他独占的4个资源，T2要12个，但是他只独占8个资源，所以他会先拿到自己独占的这8个资源。

拿完之后，T2发现，他可以再从T1借4个，所以当T2从T1借完4个后，T1和T2的资源请求都得到了满足，同时系统的资源使用率也达到了100％，所以这个是我们通过资源借入借出实现的提升资源利用率的一个例子。另外，如果T1的请求再提升的话，T1可以把借给T2的资源再抢占回来，保证T1的SLA。
 

上图是BlueDock的两种不同的安装模式：包含和不包含Mesos，这个可以在用户对BlueDock安装的时候，通过“—enable-mesos”来控制。当BlueDock安装完成后，这两种模式会有统一的GUI界面，终端用户不会感知Mesos的存在，唯一的区别就是如果使用了Mesos，可以通过BlueDock管理Mesos的Framework。

BlueDock的Auth主要是通过Keystone实现了一个Kubernetes OpenID的provider，方便与其它第三方的应用集成实现单点登录的功能。同时利用了Kubernetes的RBAC的功能，可以定义细粒度的权限控制。另外在和Keystone的集成过程中，BlueDock将Kubernetes的namespace映射为Keystone的project，这样的话，可以借助keystone来对Kubernetes的用户和namespace来统一管理。

在BlueDock集群中的每个节点上运行一个Filebeat的容器，收集容器的日志发送给到LogStash来进行过滤，然后统一存储到ElasticSearch集群中，用户可以通过Kibana查看任意Node、Namespace、Service、Pod和容器的数据。在BlueDock中，ElasticSearch是作为DaemonSet在所有管理节点启动的。

应用管理主要通过Kubernetes Helm来管理，Helm是官方Kubernetes的一部分，主要用来进行软件包的管理。Helm的一个很重要的概念是Charts，表示可以安装并组成的预配置Kubernetes资源包。Helm采用客户端机服务器模式。服务器部分被称为tiller，同时包括你运行Kubernetes集群。客户端部分被称为helm，安装在本地的开发系统上。

在BlueDock中，为了让BlueDock的UI能直接调用Helm的API，我们通过Helm的Client实现了Helm的Rest API，这样可通过BlueDock的UI来调用Helm的Rest API实现对Kubernetes应用包的管理。同时在BlueDock中将Rest API、Helm Client和Tiller通过一个Kubernetes Deployment进行管理部署，这样可通过Kubernetes自身来对Helm的所有组件进行管理。

注：IBM发布了BlueDock的开源版本，可以下载来玩一下。BlueDock安装的Docker镜像可从这里下载：https://hub.docker.com/r/ibmcom/cfc-installer/ ，一个“docker run”命令可帮助安装整个集群。如果在安装时有任何问题，可到slack channel寻求帮助，具体信息可参考：
https://www.ibm.com/developerworks/community/wikis/home?lang=zh#!/wiki/W1559b1be149d_43b0_881e_9783f38faaff