深度分析：Mirantis MCP 1.0：OpenStack 和 Kubernetes 整合的第一步

Posted 2021-04-24 云技术实践

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/

本文转发自博客“世民谈云计算”

http://www.cnblogs.com/sammyliu/p/6825522.html?from=timeline&isappinstalled=0

相关阅读：

完