目录
文章目录
前言
年关将至，闲暇之余，回顾我与 OpenStack 的 2018。
NOTE：本文内容仅作为个人见解，与公司及合作伙伴无关。
OpenStack 一年来的成长
首先，不妨从 OpenStack Releases Notes 回顾一下今年社区开发者们作出了哪些努力，下面列举一些我个人而言比较惊喜的新功能。
https://releases.openstack.org/rocky/
https://releases.openstack.org/queens/
Nova
GPU（图形处理单元）的 “加速” 能力在科学计算、图形处理密集型计算、机器学习、深度学习、人工智能等高性能计算领域有着广泛的应用，Nova Libvirt Driver 支持 vGPU 无疑是为了满足这方面的市场需求。管理员可以通过 Flavors 来定义 vGPU 的资源特性与分辨率。
nova flavor-key <flavor-id> set resources:VGPU=1
我认为 Nova vGPUs Support 是一个挺具有标志性的新功能，可以看出社区有非常积极的去适应新的技术潮流。
vGPU 的资源管理依旧是交由 OpenStack Placement 负责。Placement 是最近才从 Nova Placement API 孵化出来的新 Repo，并计划在 Stein 版本中成为独立项目，期望能最终代替 nova-scheduler service。随着 OpenStack 的定义被社区进一步升级为「一个开源基础设施集成引擎」，意味 OpenStack 的资源系统将会由更多外部（第三方）资源类型构成（e.g. 外部存储资源、外部网络资源、各类 PCI 设备）。所以，当资源类型和提供者变得多样时，就会需求一种高度抽象且简单统一的管理方法，让用户和代码能够便捷的使用、管理整个 OpenStack 的系统资源，这就是 Placement（布局）。
今年对 Nova Cell 的支持力度依然很大，主要改进了 Multi-Cell 的性能和可操作性，这让 OpenStack 拥有了更加强大的弹性和可扩展性，使 OpenStack 适用于更大的集群规模。
Ironic 支持基于 Traits（特征）的调度方式，该功能同样由 OpenStack Placement 实现的 Resource traits 支持，是 Nova 支持基于 Traits 对 Compute Node 进行调度的延伸功能。Placement resource traits 是一种灵活设计，类似 “标签”，用户可以建立 “标签云” 并决定为某个 Resource Provider 贴上 “标签”，是一种资源归纳分类需求的辅助工具。
Placement 支持 RBAC（角色访问控制）策略规则，是成为独立项目前的必要手续。我个人认为，OpenStack Placement 是非常值得关注的，它将来会逐步融汇到 OpenStack 操作的各个层面中。
Cinder
Cinder Multi-Attach 支持将同一个 Volume 挂载到多个不同的 VM，这是一个让人期待已久的功能，因为讨论的时间实在是太长了。Multi-Attach 最直接的价值就是支撑核心业务数据盘的高可用冗余特性，比如说：一个 Volume 同时挂载在两个 VM 上，当 ACTIVE VM 失联时，可以由另外的 PASSIVE VM 继续访问（RO、R/W）这个卷。多台 VM 共享一个 Volume，在集群场景中带来了很多便利，类似的功能一直是云环境中最受欢迎的功能之一。
对于 Cinder，我一直比较关注它「Volume Backup and DR」的进展，这与我曾经有过云备份与容灾恢复的开发经历有关。现在 Cinder 已经支持了从备份创建新卷，而且通过优化 cinder-backup service 使用多处理器来提升了备份的性能。另一个值得高兴的是，现在可以通过 cinder-manage 指令来执行故障转移以及故障恢复，避免用户直接操作数据库的必要。可以看出 Cinder 在提升用户体验上也花费了不少精力。
另外，今年的丹佛 OpenStack PTG，Cinder 团队还讨论了关于 Cinder 项目独立的议题，使 Cinder 成为在没有 Keystone 或 Nova 的场景中（e.g. K8s CSI）仍可以独立部署并提供服务价值的项目。这个就比较有意思了，因为这样的议题在社区中一直都颇具争议，有一部分社区开发者会对这些希望 “脱离” OpenStack 体系的项目持有抵触心理，他们认为只有跟 OpenStack 结合得更加紧密才能产生 1+1 > 2 的效益。但随着社区提倡了所谓的 “可组合性” 项目生态协作方式，的确有感觉到讨论这个话题的团队在逐渐增多。对此，我是持保留意见的，这个我们后面再聊。
Neutron
Neutron 项目的人气一直都很高，更新的内容自然也多，我主要还是关注 OVN 的更新动态。OVN 是 OpenvSwitch 的 SDN 控制器，作为 OVS 的控制平面，它对于运行平台没有特殊的要求，只要能够运行 OVS，就可以平滑的运行 OVN。所以 OVN 对于 OpenStack 也有非常优秀的的兼容性，Neutron 只需要添加一个 Plugin 来配置 OVN 即可实现集成。采用 OVN 会为 Neutron 带来一些便利，比如说：OVN 原生的网络功能可以替代 Neutron 的 OVS agent、L3 agent、 DHCP agent 以及 DVR，让 Neutron 的部署架构变得更加轻巧，同时 OVN 还提供了更加高的 L3 转发性能。
可惜的是由于 OVS DB 不是类似 MySQL 一类的 ACID 事务型数据库，而是一个 JSON-Base 的文件数据库，记录的都是一些执行命令，每次有更新或初始化都会逐条地去执行这些的指令，这种实现的并发处理性能显然是不行的。所以 OVN 现在还只适用于小规模场景，社区有提议过把 OVS DB 换成 ETCD，但也不了了之。不过从 OVN 在 Neutron 更新列表中的比重来看，依旧挺值得关注。
浮动 IP 也开始支持 Qos 了，Octavia 支持 VIP Qos 也得益于这个实现。
Port forwarding 是一个比较实用的功能，应用 iptables 规则映射，实现了 IP 复用的效果，有效的节省了浮动 IP 的浪费。是一个很省钱的功能。
Ironic
Ironic rescue mode 类比 Nova 实现的 Rescue/Unrescue 虚拟机实例修复功能，通过指定的启动盘启动，进入 Rescue 模式以修复受损的系统盘，现在 Ironic 也支持通过这种方式来修复裸机实例。那些老丢失 SSH Keys 的云管们可以松一口气了。
BIOS 是物理硬件加载的第一个程序，负责执行硬件初始化，拥有很多可作为的配置选项。Ironic manage BIOS settings 为 iLO 和 iRMC 硬件类型提供 BIOS 设置管理界面可支持众多使用场景。比如说：配置电源管理、RAID、启用 SR-IOV 或 DPDK 等等，对于裸机云和 NFV 这类对硬件管理灵活性要求比较高的应用场景而言是一个非常友好的支持。
RAMDisk 支持在没有安装操作系统的裸金属设备上通过特定的引导方式将 ramdisk 运行在内存中为 ironic-python-agent 提供执行环境，以这种方式来控制 diskless（无磁盘节点）的裸金属硬件设备，是大规模高性能计算部署场景的经典需求。现在不仅提供了 ramdisk deployment interface 而且还支持电源故障自动修复，这些对于裸机云来说都是非常不错的增强。
Ironic Conductor 是 Ironic 的核心 Worker，每个 Conductor 可以运行多个 Drivers，Conductor 通过这些 Drivers 在硬件设备上执行操作。Conductor Group 用于划分 Conductors，并将 Nodes 分配到 Conductor Group，以此来限制指定的 Conductors 对指定的 Nodes 拥有控制权。简单来说这是一种划分故障域的手段，通过将物理位置相近的 Conductors 分为一组能够有效缩小网络分区，提升了安全和性能。
Ironic 在这一年还真是做了不少事情，全球峰会关于裸机云（Bare Metal Cloud）议题的热度也很高，这跟 Ironic 部署率逐年攀升的市场反馈是成正比的。我个人感觉市场对裸机、虚拟机、容器三足鼎立的格局还是比较认同的，现在有越来越多的企业愿意自己的云平台实现跨虚拟化，除了虚拟机之外，也开始直接在裸机上部署容器，这样的云架构会更加灵活。从 Ironic 发布的这些新功能来看，Ironic 团队的裸机云蓝图也越来越清晰了。
Cyborg
Cyborg 是一个新发布的项目，脱胎于电信领域，旨在为专用加速设备（e.g. GPU，FPGA，SoC，NVMe SSD）以及各类加速器实现（e.g. iNIC，IP-Sec，DPDK/SPDK，eBPF/XDP）提供通用的生命周期管理框架。
通过 Cyborg，用户可以发现、显示加速器分类列表，连接/分离加速器实例，安装/卸载相关驱动程序，在 NFV、人工智能等高性能计算应用场景有很大潜力。Cyborg 可以单独使用，也可以与 Nova 或 Ironic 结合使用。对于前者而言，Cyborg 是 OpenStack Placement 对加速资源管理的补充；对于后者而言，Cyborg 是 Ironic 对加速硬件设备管理的补充。
以往 Nova 通过 PciDevTracker 来统计 PCI 资源（e.g. SR-IOV 网卡）数据并结合 PciPassthroughFilter 来实现 PCI 资源的调度，缺乏统一的 PCI 资源管理 API，而这正是 Placement 的历史使命。Placement 结合 Cyborg 的方案有利于解决加速设备资源统计与管理的问题。当用户需要创建一个 vGPU 虚拟机时，由 Nova 发起创建，由 Cyborg API 提供 GPU 设备管理，由 Placement API 负责调度、统筹 vGPU 资源，三者协同合作并最终通过 PCI-Passthrough 技术将 vGPU 挂载到虚拟机。
所以，我觉得 Cyborg 项目的发布同样具有标志性，它会加速推进 OpenStack 在高性能计算场景的应用，是社区布局边缘计算、物联网、人工智能领域的直接反映。
Octavia
Octavia 是 OpenStack 官方推荐的 LBaaS 解决方案，它比 Neutron-lbaas 具有更好的扩展性、高可用性和稳定的 API，是运营商级别的负载均衡器服务。Neutron-lbaas 已经被标记为废弃，但旧版本的 Neutron-lbaas 依旧可以通过 Proxy Plugin 的方式来调用 Octavia API。
Octavia 有专属的 Dashboard 和 CLI 操作入口，早期 Octavia 和 Neutron-lbaas 共用一套 UI，但具有 Octavia 特色的操作并不能体现出来。现在专门针对 Octavia 的 Dashboard 和 CLI 肯定会带来更好的用户体验。
Neutron-lbaas 实现了很多第三方负载均衡器的 Drivers 碍于时间和人力的问题迟迟没有迁移到 Octavia，实在非常可惜。早前的用户只能选择使用 Octavia Amphorae LoadBalancer Provider 实现方式，现在 Octavia 的架构调整已经完成，可以支持集成第三方负载均衡器 Drivers 了。对于那些因为使用第三方负载均衡器（e.g. F5）导致无法升级至 Octavia 的用户而言，也是一个好消息。
Octavia Pool 支持设置 Backup Member，当 Pool 中所有的 Members 都失联时，将有 Backup Member 响应，进一步提升了 LB 可用性和服务体验。
Octavia 开始支持 UDP 协议，UDP 协议经常被用于处理音频、视频数据流及其他实时应用中的传输层，满足了在物联网和边缘计算场景中的负载均衡需求。
Kolla
Kolla 已经可以支持 Keystone 和 Cinder 的最小停机时间的，这预设着 OpenStack 项目无缝升级的可行性，无论是对用户还是对运维人员来说都是一件极大的利好。
今年 Kolla 对 Ceph 的支持力度依旧很大，Ceph 现在已经是所有 OpenStack 用户都会考虑的分布式存储方案。将 Ceph 和 OpenStack 一起打包部署相信会是一个很棒的用户爽点。
Kolla 实现的原子服务容器化结合 Kolla-ansible 来完成配置管理的自动化 OpenStack 部署方案，在经过了多次大规模生产级别部署后，已经得到了业内广泛的认可。Kolla 现在已经成为了国内 OpenStack 用户首选的规模化部署方案，国内一直在为 Kolla 作出主要贡献的九州云实在是功不可没。
Magnum
Magnum 项目由 OpenStack Containers Team 开发并推出，旨在将容器编排引擎作为 OpenStack 的首类资源，异构兼容 Kubernetes，Mesos，Swarm 等容器管理平台，为 OpenStack 用户提供无缝的容器运行体验。通过 Magnum，你可以像创建虚拟机一样创建一个容器集群，透明的 COE（Container Orchestration Engine）部署及网络调整，开箱即用。借助于 OpenStack 服务，Magnum 还可以额外提供 COE 不具有的多租户认证鉴权和多租户网络隔离等功能。
在 Kubernetes 稳坐容器编排平台老大地位同时，Magnum 今年的更新也主要围绕着它进行，而且还通过了 Kubernetes 社区认可的部署工具认证。如果你想通过 Kubernetes 来构建你的容器环境，那么使用 Magnum 在 OpenStack 上部署 Kubernetes 是一个不错的选择。因为安全性的问题，直接在裸机上部署 Kubernetes 不见得是一个令人放心的选择，通过 Magnum 则可以更加灵活的选择将 Kubernetes 部署到 “Nova” 或者 “Ironic” 上。
值得一提的是，由于 Octavia Member 对象的代码实现是依附于 IP 而非 Instance 的，这样的设计使其能够适用于多种不同的场景，而非仅限于只能够为 OpenStack Nova Instance 提供负载均衡服务。所以 Octavia 也可以为 Kubernetes 的 Pods 提供外层负载均衡服务。
Zun
熬了这么久的 Zun 项目，终于在今年发布了 1.0，紧接着在下半年发布了 2.0。Zun 是一个 OpenStack Container as a Service 项目，目标是通过与 Neutron、Cinder、Keystone、Kuryr 等等 OpenStack 项目协同合作以提供原生的容器管理服务。通过这种方式，将 OpenStack 原有的网络、存储以及身份鉴权等服务无缝的融入到容器技术体系，它允许用户无需管理服务器或集群即可快速地启动、运行容器，进而确保容器能够满足用户在安全与合规性方面的要求。
Zun 实际是 Nova Docker Driver 的替代方案，Nova Docker Driver 的缺点在于 Docker 容器和虚拟机始终无法实现完全统一的抽象层，通过类虚拟机方式来操作容器，难免会丧失一部分优秀的容器特性，例如容器关联、端口映射等等。所以，简单来说 Zun 就是独立于 Nova 之外的 Docker 容器部署调度框架。这本应该是 Magnum 的初衷，实现容器创建和生命周期管理，把容器作为 OpenStack 首类资源。但 Magnum 在发展的进程中已经演变成了 COEs 的部署调度管理项目，这就是 Zum 和 Magnum 的本质区别。
我个人认为 Zun 这个项目其实是挺尴尬的，我一直觉得把容器当作虚拟机来用根本就是一个天大的误会，没有编排的容器感觉就缺少了灵魂。但我是知道国内有些大企业在使用它的，所以我也很好奇 Zun 可以在怎样的应用场景中落地。拭目以待吧。
Kuryr
Kuryr 的历史使命就是将容器网络与 OpenStack Neutron 对接，实现虚拟机实例、容器、外部网络三者互通。随着容器网络发展出现的分歧，Kuryr 也相应的有两个分支：kuryr-libnetwork（CNM）和 kuryr-kubernetes（CNI）。从更新列表可以看出，今年的 Kuryr 团队似乎更倾向于以推进 kuryr-kubernetes 为主。使用 Kuryr-Kubernetes 可以讓你的 OpenStack VM 與 Kubernetes Pods 运行在同一个网络中，並且能夠使用 Neutron 的 L3 与 Security Group 來实现网络路由以及隔离特定的 Ports。
Kuryr CNI 根据 Kuryr Controller 分配的资源将网络绑定到特定的 Pods 上，现在增加了一个 CNI Daemon 会有效提升运维 Kubernetes 的可扩展性。
随着 Octavia 的成熟，越来越多的项目有意借助于 Octavia Amphorae 的网络连通性，我个人也认为 Amphorae 带来的这种打通网络的能力是一个很有想象空间的实现方式。
除了网络之外，Kuryr 还希望可以成为容器与 OpenStack 之间的 Storage Bridge，支持容器访问 Cinder 块存储以及 Manila 共享存储服务。Kuryr 是 OpenStack 与容器结合的关键节点，值得关注。
从 OpenStack 到 OpenInfra
之所以花这么长时间来整理今年两个新版本 Queens 和 Rocky 的 Release Note，是因为这些都是 OpenStack 发展方向最直接体现。从宏观角度看，我是这么来总结的。
- Pike 版的主导的是降低运维成本
- Queens 版主导的是实现更好的易用性和操作体验
- Rocky 版主导的是业务场景融合
之前有人说 PQR 三个版本不会有太明显的突变，依旧会以稳定性为主。我不赞同，通过上面的整理，我们可以感受到 OpenStack 这一年在大规模部署、快速升级、高性能计算、硬件加速、裸机云、拥抱容器以及资源管理整合方面都有不错的表现，这些努力显然是为了迎接 5G 时代的物联网、边缘计算、电信 NFV 以及人工智能领域的业务负载。OpenStack 社区依旧在紧贴用户需求，追随技术潮流。正如 OpenStack 基金会首席运营官 Mark Collier 所言：“我们现在看到的市场，是人们希望用云做更多的事情，如机器学习、人工智能和容器等新的工作负载。”
去年我在《从 2017 OpenStack Days China 看国内云计算的发展现状》一文中提到：国内的 OpenStack 私有云已经正式迈入成熟阶段。成熟的标志就是用户冲突从 “如何做云” 向 “如何用云” 的偏移；用户的部署案例从测试环境向生产环境转移；用户托付给 OpenStack 的工作负载从非核心业务向核心业务迁移。17 年是 OpenStack 遍地开花的一年，那么 18 年就应该是纵深挖掘行业价值、业务融合、市场更加细分的一年。简单总结一下今年 OpenStack 给我感受最深的变化 —— 从稳定性中解放，在应用场景中深化。
随着整个云计算行业的飞速发展，用户对云价值转化的思考也更加复杂有深度，而不是滞留于上云的表面。有更多的用户会考虑 PaaS、两地三中心容灾、混合云、多云间数据流转等应用场景。伴随着行业用户的多样性，OpenStack 也需要为不同的业务负载（e.g. 人工智能、大数据、物联网）提供运行支撑，这些实际上是用户业务深度融合与进一步提高平台自主性的刚性需求。用户需要的往往是一个整体的云解决方案，这里面不仅仅只有 IaaS，但并非所有的技术都会在 OpenStack 社区内得到发展。所以，社区在继 “可组合性” 的项目协作方式之后，在今年又提出了更加彻底的 OpenInfra 思想，以更 “开放” 的态度拥抱一切可以组合的开源项目，将 OpenStack 打造成一个开源基础设施的集成引擎。
对于从 OpenStack 到 OpenInfra 的转变，我认为社区是做了长足准备的。从去年的轻量级安全容器项目 Kata Container（融合了虚拟化和容器技术）、今年的 CI/CD 项目 Zuul、再到融合了 IaaS 与 PaaS 的 Airship 与边缘计算项目 StarlingX，它们逐一成为 OpenStack 基金会的顶级项目与 OpenStack 项目并驾齐驱，搭建出整个 Open Infrastructure 的蓝图。
Mark Collier 还说过：“OpenStack 社区主要目的是为了解决问题，并不断完善计算、存储和网络。但现在已经不仅限于这些。我们正在建立技术堆栈，但这不是一个固定的堆栈，它是一个灵活的可编程基础设施技术栈。我们需要将不同的开源项目粘合在一起，而 OpenStack 社区成员已经获得了这方面的专业知识。”这段话凸显了 OpenStack 以社区运营为中心的管理特色，你要知道每个社区都有自己的个性，协同社区间的合作共赢是一项极具工程与人文追求的事业，而 OpenStack 社区正为之付出努力，并在 OpenStack、OpenNFV、KVM、Ceph 社区之间得到了实践，这正是我所钦佩的。
其实我个人认为无论是 “可组合性” 还是 OpenInfra，这些思路都是正确的。但在实践上却出现了偏差。我觉得可组合的粒度应该是 OpenStack 与其他开源项目，而非 OpenStack 下属项目（e.g. Keystone、Cinder、Neutron）与其他开源项目。OpenStack 内部的项目应该进一步加深紧密联系、互相依赖以提供更加完备而流畅的计算、存储、网络等基础设备资源的服务能力，再对外提供简易而统一的 API，以此实现开发式的 API 经济。从上文可以感受到，在这一方面 Octavia 项目就是一个很棒的例子。可惜的是，有些项目会希望谋求独立运营，花费精力去适配诸如 Kubernets 之类的平台，最终导致方向分散，内部撕裂，成为 “四不像” 项目的结果。其实 OpenStack 的计算、存储和网络依旧存在改进的空间，例如：Nova Cell、Nova Placement、Cinder DR、Neutron DVR 等等。不知道是否有人计算过，花费了这么多人力与时间围绕着 OpenStack 体系构建起来的项目，再去对其他平台进行适配需要花费多少沟通、研发和讨论的成本？这是理想与现实之间的差距，也是我认为现在有些项目之所以变得疲软的原因。
当然了，这也只是部分情况，如此庞大的开源社区，总会有各种各样的问题。现在的 OpenStack 依旧在迸发其旺盛的生命力，依旧快速增长的国内市场就是力证。无论如何，OpenStack 在这八年间不仅成为了一个优秀的开源私有云架构，还极大推动 OpenFlow、Ceph 等开源项目的发展，甚至在全世界范围内传播开源、开发的思想与社区运营案例，仅凭这些 OpenStack 就是成功的。
曾经有人问我 OpenStack 之于我而言意味着什么？我说：开源。云的未来不会只有 OpenStack，也不会只有 Kubernetes，但却总会有主流的开源技术，例如：KVM、Container、Ceph、OVS 以及 Cassandra，万变不离其宗，作为一名云计算技术工程师，我看重的也是这些。