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 的组成

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第1张图片

 

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)提供虚机和容器。

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第2张图片

 

 

  • 变更不再以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 管理的容器之中。

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第3张图片

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

3.1.4 CI/CD 流程

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第4张图片

  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 集群

一个部署实例:

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第5张图片

MCP OpenStack 集群的特点:

  • 采用 DriveTrain 进行部署和变更
  • 使用 StackLight 作为 LMA(Logging, Metering, Alerting) 系统
  • 每个组件使用多个分布在不同物理服务器上的虚机来实现高可用
  • SDN 支持 OpenContrail 或者 Neutron OVS,前者是推荐配置
  • 推荐采用 Ceph 做块和对象存储。
  • 支持多种 OpenStack 服务,支持物理机和虚机:
  • Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第6张图片 

3.2.2 Kubernetes 集群

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

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第7张图片

特点:

  • 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 的日志(收集、分析、可视化)、监控(包括设备,服务,和租户资源等)和告警系统。

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第8张图片

3.3.1 功能汇总

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第9张图片

3.3.2 总体架构

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第10张图片

3.3.2 日志(logging)

(1)日志收集目标包括:

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第11张图片

(2)特点

  • 采用 Heka 作为日志收集器。它被安装在MCP集群的每个节点上,负责收集这些节点上的日志。
  • 采用 ElasticSearch 作为日志存储
  • 使用 Kabana 作可视化
  • Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第12张图片

3.3.3 监控 (Metering)

特点:

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

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第13张图片

 

3.3.4 告警(Altering)

 特点:

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

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第14张图片

3.4 DevOps Portal

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

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

3.4.1 架构

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第15张图片

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 中:

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第16张图片

 3.5 多集群支持

3.5.1 DriveTrain 能支持多集群 

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

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第17张图片

  • 一个 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 能支持多集群

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第18张图片

 

 

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 MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第19张图片

这是 Mirantis 在今年波士顿OpenStack 峰会上的展示,它将大数据不同的组件作为不同的工作负载运行在不同的环境中,在使用 OpenContrail 作为统一的 SDN:

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第20张图片

 

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

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

Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步_第21张图片

 

(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/

你可能感兴趣的:(Mirantis MCP 1.0:OpenStack 和 Kubernetes 整合的第一步)