OpenStack 合力 Kubernetes 打造 IoT 平台，提供智能城市解决方案

本文详细介绍了 OpenStack 奥斯丁峰会上主题演讲所提及的开源 IoT 平台。首先我们会介绍关于 IoT 的方法和愿景，随后会提供简要的技术概述并展示两个使用案例。

物联网（IoT）是云计算领域的“下一件大事”。领先的行业供应商都提供了自己的 IoT 解决方案，并将其视作自己的业务战略。因此 IoT 这个词已经被滥用成为描述不同供应商专有解决方案的一个新流行词汇。“IoT”这个词几乎可以代表一切，甚至比“云计算服务”更加空泛。物联网主要围绕日益增加的计算机间通信，可通过用于收集数据传感器的网络和连接到云计算服务的执行程序处理各类信息。这个技术可以让我们生活中的一切，从街边路灯到港口都变得更加“智能”。

我们对 IoT 的看法与其他供应商有所差异。我们会通过相同的方法向客户提供私有云解决方案，并使用现有的开源项目对云服务的实现方式进行扩展，借此打造通用 IoT 平台，以应对不同用例的需求。为此我们定义了下列需求：

开源软件 整个平台必须基于现有的开源解决方案，并且绝对不能只由某一家供应商开发。我们希望使用现有的平台：OpenStack、Kubernetes、Docker、OpenContrail 等。

不依赖具体硬件和供应商 软硬件方面不能存在供应商锁定的情况。IoT 网关 CPU 必须支持 x86/64 或 ARM 架构。我们不想因为昂贵的专有装置而被迫只能使用某一供应商的产品。

互操作性IoT 平台必须是通用的，可以适合不同用例。举例来说，如果某一 IoT 网关可用于统计街灯数量，那么也必须能通过相同的方式将其用于智能工厂或工业 4.0 应用程序中。

因此我们设计出涉及 OpenStack、Kubernetes、OpenContrail 和 Docker 开源项目的下列高层体系结构。

开源软件

整个平台必须基于现有的开源解决方案，并且绝对不能只由某一家供应商开发。我们希望使用现有的平台：OpenStack、Kubernetes、Docker、OpenContrail 等。

不依赖具体硬件和供应商

软硬件方面不能存在供应商锁定的情况。IoT 网关 CPU 必须支持 x86/64 或 ARM 架构。我们不想因为昂贵的专有装置而被迫只能使用某一供应商的产品。

互操作性

IoT 平台必须是通用的，可以适合不同用例。举例来说，如果某一 IoT 网关可用于统计街灯数量，那么也必须能通过相同的方式将其用于智能工厂或工业 4.0 应用程序中。

下文技术概述一节将详细介绍其中的技术细节。首先一起来看看我们构建解决方案原型的两个用例。

智能城市原型

第一个用例是为捷克共和国一个名为皮斯克（Pisek）的小城市构建的智能城市项目。智能城市的理念和架构需要部署超过 3000 个端点，以及大约 300 个 IoT 网关，这些网关以高可用模式运行在 Kubernetes 驱动的容器中。该解决方案还包含开放数据门户，并通过数据 API 为第三方公司提供了下列信息：

• 交通流量、路线、停车位
• 监控和管理能源的使用以实现节能
• 电子商务、营销、旅游信息
• 环境分析
• 生活方式、社交服务、社交网络

该解决方案使用基于 RaspberryPi 2 的 IoT 网关。来自网关的数据存储在 Graphite 中，通过自行开发的数据挖掘应用程序进行处理，将结果显示在基于 Leonardo CMS 构建的市民门户网站中。Leonardo CMS 是一种 Web 服务，可以将复杂的可视化结果混合显示在一起呈现任何内容。这个开放数据门户可以通过可视化仪表盘或 API 提供数据访问。

下图展示了特定时间内，Kollarova 和 Zizkova 两条街道十字路口的机动车和行人通行情况。

若要详细了解该项目，建议阅读奥斯丁 SuperUser 杂志《更进一步，让城市变得更智能》一文，或观看 KubeCon 2016 演讲。

OpenStack 奥斯丁峰会上的智能会议系统

为了证明我们的 IoT 平台真正不依赖某种应用程序环境，在 OpenStack 峰会过程中，我们将智能城市项目中使用的 IoT 网关（RaspberryPi 2）带到了奥斯丁会议中心，通过基于 IQRF 的网状网络将其与传感器连接在一起，借此测量湿度、温度，以及二氧化碳浓度。这个演示证明了 IoT 网关可以对 IQRF、蓝牙、GPIO，以及任何其他基于 Linux 平台的通信标准进行管理并收集数据。

我们在会议中心三层楼内部署了 20 个传感器和 20 个路由器，通过一个 IoT 网关接收来自整个 IQRF 网状网络的数据，并将其中继至一个专门的时序数据库，本例中使用的数据库是 Graphite。数据收集器使用了 Docker 容器内运行，通过 Kubernetes 管理的 MQQT-Java 网桥。其中最有趣的地方是距离，运行 Docker 容器的 Raspberry 位于美国奥斯丁的会议中心内，而虚拟机运行在欧洲的数据中心。动态网络覆盖渠道由 OpenContrail SDN 提供。下文技术概述一节还将对该平台进行进一步介绍。

下图展示了传感器和路由器发现过程中找到的一个无线 IQRF 网状网络。区域 0 - 1 覆盖会议中心一楼，区域 2 - 4 覆盖四楼。

IQRF 是一种工作在亚 GHz ISM 波段的无线网状网络技术，可提供简单易行的集成能力，良好的互操作性，最多支持 240 个跃点的健壮网状网络连接，工作距离可达数百米，能耗非常低。

下图展示了会议中心二楼不同房间的二氧化碳实时浓度。历史图表显示了自周一以来的数值。从中可以直观了解到主题演讲的开始时间和午饭时间。

奥斯丁这套平台的数据收集方面，我们使用了下列服务架构。

技术概述

本节进一步介绍了这个 IoT 平台的一些技术构思。这个 IoT 平台以“通用”为愿景，旨在以安全的方式收集、管理和处理来自数千个端点的数据，并以动态的方式集中管理所有数据。

因此整个体系结构可以分为下列两大主要部分：

数据中心

数据中心是整个 IoT 平台的中心管理点。其中包含 OpenStack IaaS 云，以及伴随云同时运行的虚拟机和 SDN 控制面板。这些计算机负责了时序存储、数据处理群集、数据 API 网关访问，以及可视化 Web 服务等任务。

网关

IoT 网关可位于任何目标位置，例如街灯、工厂机械、家用电器中。SDN 提供的传输层将远程 IoT 网关与云服务连接在一起。网关可支持多平台，甚至可能混合使用了 x86/64 和 ARM 设备。该技术可以通过一个网关为多个客户承载多种传感器平台，这一特性是通过微服务分隔（Docker 容器）和 Kubernetes 对多租户的支持实现的。整个平台可以提供可伸缩的多租户环境，无论多远距离的应用程序和传感器都可位于同一个网络中。

下列架构图展示了数据中心层和网关端的相关组件。下文架构详情一节提供了进一步介绍。

架构详情

架构图展示了整个 IoT 平台在体系结构方面的逻辑视图。左侧是数据中心，右侧是上文提到的网关。

从下图可以看到，这里使用 OpenStack 作为承载所有控制服务的云，同时所有大数据处理和前端可视化任务也是在这里进行的。网关使用 Kubernetes 对服务进行微分隔，为了实现多租户功能并确保不同传感器的安全，这一步是必须的。同时该平台还使用 OpenContrail 将两端连接在一起，并为 Kubernetes POD 和 OpenStack Project 虚拟机提供网络分隔。

上文曾提到过，分隔是通过 SDN 覆盖实现的。这里的重点在于数据中心边缘路由器和 IoT 网关之间只存在 IP 连接。网关操作系统和数据中心边缘路由器之间的 VPN 连接可以看作该平台的最底层，该层之上是 SDN，在这里可以通过 OpenContrail 实现虚拟机（OpenStack 云）和容器（网关）之间的直接通信。这种方法使得用户可以自由选择不同类型的传感器和执行程序，为其设置权限，并用安全的方式将其与云中负责任务处理的应用程序连接在一起。

数据中心包含下列服务：

管理服务

硬件群集中运行的虚拟机承载了所有控制服务：OpenStack 控制器、OpenContrail 控制器（SDN）、Kubernetes 主机、Salt 主机。

OpenStack 云

OpenStack 项目为数据库（Graphite、Influxdb、openTSDB）、大数据处理（Hadoop），以及数据可视化（Grafana、LeonardoCMS）所涉及的不同虚拟机服务提供了分隔和划分。这个云运行在 KVM hypervisor 之上，通过 OpenContrail 的 Neutron 插件实现网络连接。

边缘路由器

OpenContrail 会与数据中心边缘路由器创建 iBGP 对端，这样便可以将 OpenStack 虚拟机和 Kubernetes POD 的动态网络路由传播至 IoT 网关。该设备可以 MPLSoverGRE 或 MPLSoverUDP 方式创建标准的 L3VPN。

远程网关包含下列组件：

Kubernetes Minion

Kubernetes minion 负责与数据中心内的 Kubernetes 主机通信，并负责管理 Kubeletand POD。Kubelet 使用了 Opencontrail 插件，借此将 Docker 容器与 vRouter 代理连接在一起。

Kubernetes POD

Kubernetes POD 是连接到 vRouter 的一个或多个 Docker 容器。POD 可按照标签进行分隔，这样即可启动不同应用程序，从不同消息总线以 IQRF、蓝牙，或 GPIO 方式读取数据。

Docker 容器

Kubernetes POD 中的 Docker 容器为整个平台提供了极大的收益，可在无需特别安装的情况下支持任何类型的操作系统。例如，IQRF 使用了某一版本的简单 Java 应用程序，可通过容器在几分钟内交付，并且不会与网关本身的操作系统产生不匹配的情况。

应用程序视图

下列架构图详细介绍了应用程序视图。从图中可知，借助 OpenContrail 覆盖的帮助，OpenStack 云内部的虚拟机可以通过 L2 或 L3 私有网络联系位于任何地理位置的 Docker 容器。因此应用程序开发者可以使用标准云平台中用过的同一套工具。他们可以通过 HEAT 部署虚拟机应用程序控制器，随后通过简单的 Yaml 文件在远程网关上的容器中部署 Kubernetes 服务。

以通过环境传感器收集数据的做法为例：传感器直接连接至容器，数据在 Docker 容器中处理后发送至 Graphite 时序数据库。因为我们希望以图形化方式实时呈现数据，因此使用了另一个虚拟机，通过 Leonardo CMS 借助 Graphite API 读取数据，并将其显示在网站上。据此我们可以通过同一个云平台，按照相同的原则创建不同项目，并使用多种输入和输出位置。

结论

我们希望对这个 IoT 平台的愿景和已经部署的原型进行一个简要的介绍。目前我们正在完成整个智慧城市解决方案的细节设计工作。

今年在奥斯丁举行的 OpenStack 峰会和伦敦举行的 KubeCon 上对该方案进行介绍后，我们收到了来自社区成员的大量反馈。在 IoT 平台的安全性、弹性，以及性能方面，我们的构想得到了大家的认可，很多技术合作伙伴希望通过合作对我们的 IoT 平台进行扩展，借此构建他们自己的解决方案。我们现在正在着手有关工业 4.0 的构想，打算通过开源项目创建第一个智能工厂。

作者：Jakub Pavlik
阅读英文原文： OpenStack and Kubernetes join forces for an Internet of Things platform

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。