Mirantis MCP 1.0：OpenStack 和 Kubernetes 整合的第一步

1.前言

Mirantis 公司在2014年9月14日宣布收购 TCPCloud，然后宣布在2017年第一季度会推出全新的私有云产品。从那时候开始，我就一直满怀期待。终于，今年4月19日，Mirantis 宣布推出全新的 MCP 1.0。本文根据公开的文档，试着对该产品做些分析和总结，并且展望一下其未来。因为只是看文档和视频，并没有进行实际部署和操作，因此，可能有一些错误。本文会持续进行更新。

2. MCP 1.0 概况

2.1 MCP 1.0 的组成

MCP 1.0 主要包括三大部分：

DriveTrain：即部署和变更系统，用于整个平台的部署（Day 1）和部署后的变更（Day 2）。
云系统：包括支持物理机和虚机的 OpenStack，支持容器的 Kubernetes，分布式块和对象存储 Ceph，面向 OpenStack 集群的SDN OpenContrail，面向 Kubernetes 的 SDN Calico。
StackLight：即日志、监控和告警系统，为云平台提供运维支持。

2.2 设计出发点

Mirantis 设计 MCP 1.0 的出发点包括但不限于：

基础架构的消费模式是由公有云定义的，它的主要特征包括 API 驱动（API driven）、持续交付（continuously delivered）和托管模式（managed）。因此，MCP 1.0 就由之前的以安装为中心的架构（installer-centric architecture）变为以运维为中心的架构（operations-centric architecture）。
面向各种工作负载的统一云平台，包括为迁移到云上的传统应用（cloud hosted）提供虚机和裸机；为已经为云做过优化的应用（cloud optimized）提供虚机；为云原生应用（cloud native）提供虚机和容器。

变更不再以6到12个月为周期，而是以周为周期进行小迭代（minor increments）而持续发生。

3. MCP 1.0 具体

下面具体分析 MCP 1.0 中的具体组件。

3.1 DriveTrain

3.1.1 概况

（1）理念：Infrasture-as-code 基础架构即代码，将基础架构代码化。

（2）目标：支持 Day 1 定制化安装和 Day 2 部署后配置，包括功能和架构变更。

（3）方法：采用 CI/CD 工具和流程，实现 DevOps 模式。

（4）支持：当前支持 OpenStack 集群和 Kubernets 集群，将来会增加更多集群支持。

（5）界面：DriveTrain 的界面集成在 DevOps 界面中。

3.1.2 组件

DriveTrain 是 DevOps 形式的云平台部署和配置系统。它主要包括以下生命周期管理工具：

SaltStack + Reclass：SlatStack 类似Puppet 和 Chef，提供配置管理和 MCP 集群的部署和变更；Reclass 结合 SaltStack 使用。
Gerrit：提供 Git 库和代码检视管理系统，保存源代码、SaltStack 程序（formulas）、Reclass 模型（models）。
Jenkins：job 自动化工具。它检测提交到 Gerrit 的针对 MCP 集群配置的变化，然后通过执行一系列 jobs，将相应的 SaltStack 程序和Reclass 模型应用到 MCP 集群。
MCP Registry：保存 MCP 集群所需的软件库，比如 Docker 镜像、Debian 包等。

3.1.3 部署

要部署DriveTrain，至少需要3个虚机。它的组件运行在由 Docker Swarm 管理的容器之中。

使用三节点 Docker Swarm 部署模式，每个 DriveTrain 组件运行在 Docker Swarm 容器中，确保提供高可用的服务。（mysql 如何运行在容器中，没有具体说明）
使用 GlusterFS 共享文件系统作为共享存储
使用 Keepalived 对各个 service 提供 HA VIP
使用 nginx 提供公网访问能力

3.1.4 CI/CD 流程

当运维人员要进行 MCP 部署或者变更时，他首先在 Gerrit 中提交 SaltStack 程序或者 Reclass 模型的代码检视申请。
代码检视结束后，根据配置的不同（有没有staging环境），触发Jenkins 相应的变更 job。
Jenkins job 从 Jenkins 中获取SaltStack 程序或者 Reclass 模型的代码，以及从 MCP 库中获取二进制文件。
SaltStack 将更改应用到 MCP 集群

3.1.5 简单分析

与Mirantis之前的 Fuel 做比较，

Fuel 使用 Puppet 来做配置管理，现在改为使用 SlatStack，应该是吸收了 TCPCloud 的成果。在 Github 上有看到有大量的 TCPCloud 写的 Slat 程序，比如 https://github.com/tcpcloud。
Fuel 主要是在 Day 1 部署，而 DriveTrain 则 Day 1 部署和 Day 2 变更并重。当然，现在的 Day 2 变更主要还只是做一些小的变更，比如安全补丁之类的。但是，长期看，两者都是必须的。
客户有了 DriveTrain 并接受了培训之后，就可以自动地进行变更了，这为 Mirantis 推行新的 build-operate-transfer 交付模式提供了产品基础。

3.2 MCP 集群

MCP 1.0 支持 OpenStack 集群和 Kubernetes 集群。

3.2.1 OpenStack 集群

一个部署实例：

MCP OpenStack 集群的特点：

采用 DriveTrain 进行部署和变更
使用 StackLight 作为 LMA（Logging, Metering, Alerting）系统
每个组件使用多个分布在不同物理服务器上的虚机来实现高可用
SDN 支持 OpenContrail 或者 Neutron OVS，前者是推荐配置
推荐采用 Ceph 做块和对象存储。
支持多种 OpenStack 服务，支持物理机和虚机：

3.2.2 Kubernetes 集群

MCP 1.0 支持单独部署一个 K8S 集群，也支持在 OpenStack 集群旁边部署一个 K8S 集群。一个部署示例如下：

特点：

K8S 集群和 OpenStack 集群目前没有关联。
采用 Calico 作为SDN。使用 OpenContrail 处于 technical preview 状态，也就是测试可用，但生产别用。
采用 Ceph 提供卷。
采用 DriveTrain 进行集群部署和变更。
典型地，K8S 集群会部署在裸金属服务器上。MCP 采用基于 Ironic 的 MaaS 组件来准备物理环境。

3.2.3 简单分析

MCP 中的 OpenStack 和 K8S 集群目前是独立的，两者之间没有关联
OpenStack 和 K8S 集群使用同一的部署和配置工具 DriveTrain，以及 LMA 工具 StackLight。
Mirantis 强调 100% 开源。

3.3 StackLight

MCP StackLight 是 Mirantis 的日志（收集、分析、可视化）、监控（包括设备，服务，和租户资源等）和告警系统。

3.3.1 功能汇总

3.3.2 总体架构

3.3.2 日志（logging）

（1）日志收集目标包括：

（2）特点

采用 Heka 作为日志收集器。它被安装在MCP集群的每个节点上，负责收集这些节点上的日志。
采用 ElasticSearch 作为日志存储
使用 Kabana 作可视化

3.3.3 监控（Metering）

特点：

包括云物理环境监控和租户环境监控。
租户资源监控基于 Ceilometer。它将监控指标数据保存在 InfluxDB 中，将资源数据保存在 Elasticsearch 中。
采用 InfluxDB 时间序列数据库保存监控数据
采用 Grafana 作为可视化

3.3.4 告警（Altering）

特点：

采用 Sensu 和 Uchiwa，支持集群
支持通过标准协议将告警导向第三方系统

3.4 DevOps Portal

MCP 1.0 还提供了处于技术预览状态的 DevOps 界面。它是 MCP 管理员的主要入口。它的主要内容有：

通过各种图标和状态等展示云环境的各种信息
提供链接到其它工具的链接，包括 Grafana，Kibana 和 Rundeck等。

3.4.1 架构

3.4.2 Cloud Intelligence Service （CIS，云智能服务）

CIS 包括一系列用于收集系统信息的收集器（collectors），包括 OpenStack 集群和MaaS 等等。CIS 保存这些信息，跟踪它们的变化，并进行分类。CIS 会查询各种服务的API，并且连接到特定的数据库去加速数据收集。尽管 CIS 的搜索功能很强大，但是它不能修改任何资源。

Runbooks 每隔5分钟会运行这些收集器去收集各种信息，并保存到 ElasticSearch 中。

3.4.3 Cloud Health Service 服务（CHS，云状态服务）

CHS 也包括一组收集器，它们通过各种资源的通知来提供云的状态概要，包括网络、存储、计算节点等。这些结果会被展示在 DevOps 界面中。

Runbook 会执行 FCI，API 测试，并将数据保存在 LMA 中。DevOps 界面查询 LMA，创建云状态的各种图表。云管理员监控这些图表。

3.4.4 Runbook 后端和UI

Runbooks Auotmation 是一个自动化服务。用户可以在其UI中创建工作流任务，这些任务会被定时或者周期性执行。其它 OSS 组件会使用 Runbooks 服务来自动化执行这些任务，比如创建备份、监控数据查询、生成报表、云维护等等。Runbooks 是有 Rundeck 工具提供的，它使得用户可以方便地添加 Rundeck 任务，并将它们嵌入工作流。 Jenkins 和 SaltStack 主要用于部署和生命周期管理，Rundeck 则会帮助用户执行每天的运维和维护任务。

3.4.5 Capacity Management Serice （CMS，容量管理服务）

CMS 服务利用LMA 和 CIS 产生的数据，提供多个界面来显示云中的资源使用情况。它的内容包括：

按照可用区（AZ）分组的计算节点的 CPU 和内存利用率
在用内存容量
在用存储容量
计算节点总数

它的部分界面会集成到Horizon 中：

3.5 多集群支持

3.5.1 DriveTrain 能支持多集群

一套包含 SlatStack 和 Reclass 的 DriveTrain 环境能支持多集群的配置：

一个 Service class 定义MCP 集群中的一个组件（component），比如 RabbitMQ，MySql 等。Service class 定义为 SlatStack 程序。
一个 System class 定义 MCP 集群中的一个节点（node），比如控制节点和计算节点，以及部署在节点上的 service。
一个 Cluster class 定义一个 MCP 集群，比如一个 demo OpenStack 集群，一个生产 K8S 集群等。一个 cluster class 组合多个 system classes。

通过 DriveTrain 的 CI/CD 流程，管理员就可以定义、部署、维护多个 MCP 云环境。

3.5.2 StackLight 能支持多集群

4. 总结和展望

4.1 总结

根据上面的信息，对 Mirantis MCP 1.0 做个简单的总结：

产品化思路非常直接：将合适用户工作负载的云环境（当前是OpenStack环境和K8S环境）通过好用的部署和变更工具（DriveTrain）和 LMA 系统（StackLight）提供给用户，使得这个产品既能解决业务需要，又好用。
OpenStack 地位确定：由神化（无所不能）回到人间（支持物理机和虚机），在整个 Mirantis 私有云产品中的分量由之前的 100% 下降到当前的 60%，将来应该会进一步下降。
OpenStack 功能得到聚焦：MCP 1.0 使用 Salt 而不是 OpenStack 自带的 Magnum 项目来编排 K8S 集群，显示出 Mirantis 有将 OpenStack 功能收缩到核心组件的趋势，这应该和 Mirantis 减少 OpenStack 研发人员同时TCPCloud 团队有非常强大的 SaltStack 能力有一定关系。
K8S 地位清晰：即定位在 CAAS 平台。它既不能取代OpenStack，也不是 PAAS，而是在其该在的 CAAS 位置。
强调 Day 2 （部署后运维），推行 CI/CD 模式的自动化运维平台。
强调 LMA （日志-监控-告警），并强调事前分析告警。

4.2 展望

如本文标题，MCP 1.0 只是 Mirantis 新私有云产品的第一个版本，还处于 OpenStack 和 K8S 整合的第一步。不负责任地预测，将来 MCP 会：

（1）通过 OpenContrail 将 K8S 和 OpenStack 做进一步的整合，打通物理机-虚机-容器的网络。这方面之前 TCPCloud 已经有了很多的尝试，相信将来会进一步利用起来。

（2）进一步拓宽云产品栈，OpenStack 的分量会进一步下降，也许会到 30% 左右。

通过 DriveTrain 和 StackLight 支持更多的云产品，比如大数据、AI 等云技术栈。相信 Mirantis 也不会限于 OpenStack 和 K8S，而是会选择更多的开源云产品。我们也许会看到 Mirantis 参与到更多的开源云项目中。

（3）用户体验（UI）的进一步优化，包括 DriveTrain UI， StackLight UI，DevOps 界面等的增强，以及多个界面之间的整合。

（4）DriveTrain 功能的进一步丰富。当前它更多的只能支持 Day 1 部署，将来会在 Day 2 部署后变更方面做增强，使它真正成为 DevOps 样式的完整的系统。

参考链接