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 流程

1. 当运维人员要进行 MCP 部署或者变动时，他首先在 Gerrit 中提交 SaltStack 程序 或者 Reclass 模型的代码检视申请。
2. 代码检视结束后，根据配置的不一样（有没有staging环境），触发Jenkins 相应的变动 job。
3. Jenkins job 从 Jenkins 中获取SaltStack 程序 或者 Reclass 模型的代码，以及从  MCP 库中获取二进制文件。
4. 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 已经有了不少的尝试，相信未来会进一步利用起来。

这是 TCPCloud 以前放的一篇文章：

这是 Mirantis 在今年波士顿OpenStack 峰会上的展现，它将大数据不一样的组件做为不一样的工做负载运行在不一样的环境中，在使用 OpenContrail 做为统一的 SDN：

 

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

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

 

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

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

 

 

 参考连接

• https://www.mirantis.com/blog/a-dash-of-saltstack-using-salt-for-better-openstack-kubernetes-and-cloud/
• https://docs.mirantis.com/mcp/1.0/