蒋暕青 Reading time ~1 minute

背景

OpenStack 作为开放的 Infrastracture as a Service云操作系统，支持业界各种优秀的技术，这些技术可能是开源免费的，也可能是商业收费的。 这种开放的架构使得 OpenStack 保持技术上的先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。 那 OpenStack 的这种开放性体现在哪里呢？一个重要的方面就是采用基于 Driver 的框架。

Cinder组件，存储节点支持多种 volume provider，包括 LVM, NFS, Ceph, GlusterFS，以及EMC, IBM等商业存储系统。cinder-volume为这些volume provider定义了统一的driver接口，volume provider只需要实现这些接口，就可以driver的形式即插即用到 OpenStack 中。

目前，Cinder只允许将卷连接到单个主机或实例。但是有时用户可能希望能够将相同的卷附加到多个实例。在多年的上游社区的努力后，终于在Queens版本发布了这个期待已久的功能。

案例需求

能够使同一块卷提供给不同的用户使用，卷本身可以是read-only的也可以是read/write。

场景：

1

云平台中的应用可能由多个虚拟机组成集群的方式提供，其中一台是active，一台是passive状态，若通过cinder mutil-attach方式连接卷，那么在active虚拟机宕机情况下，passive虚拟机可以直接变为active，由于两台虚拟机同时attach同一个cinder卷，因此不需要进行数据同步，这样对于集群应用有很大的便利性。

如果没有mutil-attach功能，那么用户就需要克隆原始卷并将克隆卷attach到第二个实例。这样做的缺点是操作复杂，而且对原始卷的更改都不会显示在克隆卷中。

问题描述

Cinder-client目前在detach（）方法中只要求传入单个volume参数，这样从client端限制了主机可attach卷的数量，在外部的UI和内部组件的API上，也并没有支持mutil-attach。
Nova组件在代码层面上限制主机attach的数量，在attach动作发生时，nova会去检查改卷的状态，如果卷已经attach主机，那么就不能再attach其他主机。代码在nova/volume/cinder.py: check_attach()。

RO/RW情况分类

Multi-Attach RO：
能够以正常方式连接卷（读写访问权限），然后以只读模式将该卷附加到另一个主机/服务器。问题在于，要求使用者（即Nova / KVM）知道如何在附加卷上设置只读模式和强制执行只读模式。

Multi-Attach RW：
能够像通常那样附加卷（读写访问权限），然后将该卷附加到另一个主机/服务器。 在这种情况下，多个attachment之间没有区别。它们都被视为独立项目，并且都是读写卷。

目前，所有后端卷都将以读写（RW）模式attach，包括boot from volume模式。用户可以使用两个新的Cinder策略打开或关闭该功能：
volume:multiattach
volume:multiattach_bootable_volume

实现方式

OpenStack’s multiattach Feature允许一个volume经iscsi/FC被attached到多个VM

1.要启用将卷附加到多个主机或实例的功能，需要一个新的volume_attachment表来跟踪cinder卷的每个attachment。 将从volume表（attached_host，instance_uuid，mountpoint，attach_time，attach_mode）迁移现有列到新的表。 volume_attachment表将具有一个id（称为attachment_id），用于跟踪每个卷的各个attachment。 调用cinder API可返回的现有卷具有的attachment列表。 此attachment列表包含每个attachment的attachment_id。

2.attachment_id是nova在发生detach动作时API传递给cinder，因此cinder知道要detach哪个attachment。 cinder API将支持默认attachment_id为None，如果只有一个attachment，它将尝试分离。

3.执行分离（detach）动作时，如果cinder没有获得attachment_id，并且该卷只有1个attachment，那么分离该attachment的动作成功。 如果该卷有多个attachment，则cinder将返回Nova一个错误消息，指出该卷有多个attachment并需要attachment_id。

4.卷表将被更新为包含一个名为’multiattach’的新列，该列是一个布尔标志，用于指示cinder该卷可以/不能连接多于一次。cinder API和cinderclient将支持在卷附加时设置该布尔标志。

Nova组件

在Queens版本前，Nova尚未准备将单个Cinder卷附加到多个VM实例，即使卷本身允许该操作。默认情况下，libvirt假定所有磁盘都由一个guest虚拟机专用。如果要在实例之间共享磁盘，则需要在为该磁盘配置guest虚拟机XML时，通过设置磁盘的“可共享”标志来告诉libvirt。这样虚拟机管理程序不会尝试对磁盘进行独占锁定，并禁用所有I / O缓存，并且任何SELinux标签都允许所有域使用。

如果hypervisor层本身不支持mutilattach，Nova应该拒绝attach请求，但是使用当前的API是不可能做到对hypervisor支持性的检查。但是这可以通过用户配置策略规则来解决。 例如，运行的云平台不支持multiattach，假设hypervisor层是vmware，那么用户可以配置策略来禁用cinder端的multiattach卷.

如果是混合云，用户在尝试将卷附加到多个实例时，如果该compute节点的virt驱动程序不支持multiattach的计算机上的实例，那么attach请求将失败，并且nova-compute调用attachment_delete将删除通过nova-api创建的attachment。

如果nova-api可以检查后端存储是否具备了mutilattach功能，那么用户可以通过API直接调用获取，但是nova还没有该API，所以只能通过手动配置cinder和尝试attach这两种方式。

2

配置命令

为了能够将卷附加到多个实例，需要在配置文件中将’multiattach’标志设置为’True’。
$ cinder type-create multiattach
$ cinder type-key multiattach set multiattach=” True" 要创建卷，需要使用之前创建的卷类型，如下所示： $ cinder create --name --volume-type 详细配置可参考文档[3]

注意点

1.在Queens版本中，mutil-attach实现了三种Driver：LVM，NetApp / SolidFire和Oracle ZFSSA。 可以查看驱动程序支持列表[4]，了解其他驱动程序何时添加支持的更新。另外支持mutilattach的卷不支持加密。
2.Multi-Attach 功能在 cinder microversion >= 3.50 版本可用，查看 stable/queens 的cinder版本。

性能/安全性影响

1.可能的性能损失是在卷读取数据库对volume_attachment表的额外提取。 这是一个简单的外键表连接，并且是索引的。
2.在libvirt驱动程序中，磁盘被赋予一个共享的SELinux标签，因此磁盘不再具有sVirt SELinux隔离。

Horizon的更改

Horizon组件为了支持mutil-attach所需的更改是：
1.当卷连接到多个主机时，改进Volumes表中Attached To列的格式。目前，该字段被设置为1，并且在连接多主机时不会缩放。
2.在卷创建对话框中添加一个新复选框，将卷标记为可共享多个实例。
3.修改“编辑卷attachment”对话框以允许将可共享卷附加到多个实例。

OpenStack基金会表示，新的SDS功能是云环境中最受欢迎的功能之一，该功能提供存储冗余。如果一个节点发生故障，另一个节点可接管并允许访问该卷。通常，有多台前端服务器连接到一台后端的高端服务器上，当一台前端服务器 down 掉，仍可以通过其他的前端服务器访问后端高端服务器。通过 Cinder的新功能，可以利用虚拟存储提供相同级别的高可用性，而不依赖昂贵的光纤通道存储阵列（共享存储）。

参考文献

[1].https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/multi-attach-volume.html
[2],https://wiki.openstack.org/wiki/Cinder/blueprints/multi-attach-volume
[3],https://www.sunmite.com/openstack/cinder-multi-attch.html
[4],https://wiki.openstack.org/wiki/CinderSupportMatrix

蒋暕青 Reading time ~1 minute

什么是Octavia？

Octavia是一款开源的运营商级负载均衡解决方案，旨在与OpenStack配合使用。Octavia出自Neutron LBaaS项目。 当Neutron LBaaS从版本1转移到版本2时，Neutron LBaaS项目发生了一次大的转变。从Liberty版本的OpenStack开始，Octavia已成为Neutron LBaaS版本2的参考实现。

Octavia自kilo版本从neutron lbaas项目中分离出来，通过管理一系列amphora(vm、containers, or bare metal servers)来完成负载均衡的功能。其框架结构也是一个典型的openstack项目框架。api作为项目入口，rpc来作为组内模块之间通信的中介，controller及数据库来保证数据存储及一致性，实现使用driver来保证能够实现兼容性。

Octavia通过管理一系列虚拟机，容器或裸机服务器（统称为amphorae）来完成其负载均衡服务的交付，这些服务器可根据需要进行调整。 这种按需水平缩放功能将Octavia与其他负载平衡解决方案区分开来，从而使Octavia真正适合“云端”。

Octavia可以结合哪些OpenStack组件 ？

负载均衡对于实现简单或自动交付扩展和可用性至关重要。为了发挥其作用，Octavia使用了其他OpenStack项目：

Nova - 用于管理amphorae生命周期并根据需求启动计算资源。
Neutron - 用于amphorae，租户环境和外部网络之间的网络连接。
Barbican - 用于管理TLS证书和凭证。
Keystone - 用于针对Octavia API进行认证，并用于Octavia与其他OpenStack项目进行认证。
Glance - 用于存储amphorae虚拟机映像。
Oslo - 用于Octavia与其他组件之间的通信
Octavia旨在与前面列出的组件进行交互。在设计原则上，我们都通过driver interface来定义这种交互。这样，外部组件可以用功能相同的其他组件进行替换。
建议将Octavia作为独立的负载平衡解决方案运行。 Neutron LBaaS在Queens版本中已弃用，而Octavia则是其替代产品。对于最终用户来说，这种转换应该是相对无缝的，因为Octavia支持Neutron LBaaS v2 API并且具有类似的CLI界面。也可以使用Octavia作为Neutron LBaaS插件。
有关OpenStack Neutron LBaaS弃用的更多信息，请参阅https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation。

Octavia架构

1

Octavia 0.9版包含以下主要组件：
amphorae - Amphorae是完成向租户应用程序环境提供负载平衡服务的单个虚拟机，容器或裸机服务器。在Octavia 0.8版本中，amphorae映像的参考实现是运行HAProxy的Ubuntu虚拟机。
Controller - Controller是Octavia的“大脑”。它由四个子组件组成，它们是单独的守护进程。如果需要，它们可以在单独的后端基础架构上运行：
API Controller - 顾名思义，这个子组件运行Octavia的API。它需要API请求，对它们执行简单的处理，并通过Octavia消息总线将它们发送给Controller Worker。
Controller Worker - 此子组件从API控制器获取已过滤的API命令，并执行必要的操作以完成API请求。
Health Manager - 该子组件监视单个amphorae以确保它们正常运行，并且保持健康。它还处理故障事件。
Housekeeping Manager - 该子组件清理陈旧（已删除）的数据库记录，管理备用池并管理amphora证书轮换。
Network - Octavia无法在不使用网络环境的情况下完成任务。 Amphorae在“负载平衡器网络”上构建了一个网络接口，并且它们也可能直接插入到租户网络中以访问后端池成员，具体取决于租户如何部署给定的负载平衡服务。

Octavia组件设计

2

Octavia的这个版本致力于使服务交付可扩展（尽管单个的listener在此阶段不能水平扩展），Driver是允许Octavia与OpenStack环境中的其他服务进行交互的“粘合”的组件。 Octavia希望尽可能与那些必须交互的服务尽可能松散耦合，以便保持这些接口的松耦合度。

为了保持Octavia的设计更独立，作为网络服务的纯粹消费者，但是仍然不能“绕过”现有的Neutron API，Octavia决定编写一个“网络驱动程序”组件，通过编写的API来执行那些dirty back-end配置命令，直到它们成为Neutron的标准组件。 该组件应与Octavia松散耦合，因为Octavia将与Neutron一起使用，并为Octavia提供完成网络配置任务。

在前端，Octavia使用来自LBaaS驱动程序的命令和控制。
Octavia在设计上保持足够的灵活性，以便某些组件（如amphorae）可以被第三方产品替代（如果需要）。Amphorae的LB驱动程序还为用户提供了可以替换不同（可通过不同flavor访问）的其他开源Amphorae的选择，这样的话可以方便地对新的amphorae进行测试。
LB Network是控制器用来与amphorae进行通信的子网。 这意味着控制器必须连接到到这个子网才能起作用。由于amphorae将在其上进行通信，这意味着该网络不属于“undercloud”。

HEALTH MONITORS

控制器需要能够监控它们控制的amphorae的可用性和整体健康状况。对于active的amphorae，这种检查大约每5秒一次。对于备用的amphorae，检查可能会发生得更少（比如每分钟一次）。
octavia采用虚拟机来做为负载均衡的执行体，这是一个Nova VM，它实际上提供用户配置的负载均衡服务，可以实现灵活的弹性伸缩。

文档

https://wiki.openstack.org/wiki/Octavia/Roadmap
https://github.com/openstack/octavia-dashboard
https://wiki.openstack.org/wiki/Octavia

蒋暕青 Reading time ~1 minute

Cyborg项目背景

随着机器学习（machine learning）和机器视觉（compute vision）的快速发展，用户对GPU的需求也日益剧增。截止目前，大多数用户仍会选择带有GPU的裸机服务器。然而，这同时意味着用户需要承担由配置此类设备所带来的管理性成本。如今，用户将能够使用vGPU驱动的虚拟机，并利用这部分资源运行人工智能相关的Workload。

随着OpenStack社区对AI和边缘计算的布局，而加速计算在边缘比在数据中心更为普遍，所以这又会加强OpenStack的地位，因此OpenStack在第17个版本迎来了Cyborg项目。

Cyborg项目起源于NFV acceleration management以及ETSI NFV-IFA 004 document，和OPNFV DPACC项目。Cyborg（以前称为Nomad）是用于管理硬件和软件加速资源（如 GPU、FPGA、CryptoCards和DPDK / SPDK）的框架，在Queens发布中首次亮相。特别是对于有 NFV workload的运营商，计算加速已经成为云虚拟机的必备功能。通过Cyborg，运维者可以列出、识别和发现加速器，连接和分离加速器实例，安装和卸载驱动。它也可以单独使用或与Nova或Ironic结合使用。Cyborg可以通过Nova计算控制器或Ironic裸机控制器来配置和取消配置这些设备。

在加速器方面，Nova计算控制器现在可以将Workload部署到Nvidia和Intel的虚拟化GPU（AMD GPU正在开发）。加速器可用于图形处理的场景（如虚拟桌面和工作站），还可以应用于集群上的通过虚拟化GPU以运行HPC或AI Workload的场景。

Cyborg组件架构

1

Cyborg API—应该支持有关加速器的基本操作，API支持以下接口：

  • attach：连接现有的物理加速器或创建新的虚拟加速器，然后分配给虚拟机
  • detach：分离现有物理加速器或释放虚拟机的虚拟加速器
  • list：列出所有附加的加速器
  • update：修改加速器（状态或设备本身）
  • admin：CRUD操作无关的某些配置

Cyborg Agent—Cyborg agent将存在于计算主机以及可能使用加速器的其他主机上，agent具体的作用：

  • 检查硬件以找到加速器
  • 管理安装驱动程序，依赖关系和卸载驱动
  • 将实例连接到加速器
  • 向Cyborg服务器报告有关可用加速器，状态和利用率的数据

  • 硬件发现：
    每隔数秒就会扫描实例的加速器和现有加速器的使用级别，并将这些信息通过心跳消息报告给Cyborg服务器，以帮助管理调度加速器

  • 硬件管理：
    Ansible将用于管理每个加速器的配置文件和加速器的Driver。install和uninstall特定的ansible playbook适配Cyborg所支持的硬件。在管理的硬件上进行的配置更改将通过运行不同配置的playbook作为底层实现

  • 实例连接：
    一旦产生一个实例需要连接到主机上的特定加速器，Cyborg服务器将向Cyborg agent发送消息。由于不同加速器之间的连接方法不同，因此agent需要不同的driver提供连接功能

Cyborg-Conductor—Cyborg-db的数据库查询更新操作都需要通过向Cyborg-conductor服务发送RPC请求来实现，conductor负责数据库的访问权限控制，避免直接访问数据库

openstack-Cyborg-generic-driver功能

  • 识别和发现附加的加速器后端
  • 列出在后端运行的服务
  • 将加速器附加到通用后端
  • 从通用后端分离加速器。
  • 列出附加到通用后端的加速器。
  • 修改附加到通用后端的加速器。

Quata—cyborg resource quota，Cyborg的配额管理用于在构建虚拟机时管理用户或项目对加速器的访问。目前，项目或用户可能拥有无限数量的加速资源，应该有一个限制，限制是可配置的

Cyborg调用加速器过程（vFPGA）

2

1.ronic监控网络并发现新资源
2.新的主机通过pXE启动并用Hypervisor初始化
3.Agent更新Nova和Neutron DB
4.Ironic agent根据存储在swift / glance / glare中的比特流加载静态区域
5.Nova agent被通知存在新的PCIe设备（来自SR-IOV的VF）并更新Nova DB
6.Nova根据用户指令需要孵化一台虚拟机并配备PR（vFPGA）
7.Nova过滤器找到可用资源并执行虚拟机创建/配置
8.VM cloud_init使用本地文件或Swift中的比特流加载PR—VM请求Cyborg从Glare加载PR
9.VF注册并分配给虚拟机
10.VM应用程序访问VF

总体来说，Cyborg的出现，在云主机中支持 vGPU（ 虚拟图形处理单元 ）的功能，这对于图形密集型工作负载以及许多科学性的、人工智能和机器学习的工作负载来说是一项重要的能力。

蒋暕青 Reading time ~1 minute

测试概要

OpenStack Neutron L3的南北网络性能一直没有官方权威的测试，但是L3的实际承载的南北向带宽又是每一个部署OpenStack的用户最关心的问题之一。由于社区最近有了Shaker的工具，使得网络测试变得更加容易。这篇文章主要是借助官方文档来描述一下Neutron L3的南北网络性能。

目前我们部署的OpenStack环境都是高可用的，至少有3个L3-agent，但是每个L3-agent都是SPOF。 如果L3-agent fail，则调度给该agent的所有虚拟路由器都将发生丢包，因此连接到这些虚拟路由器的所有虚拟机都将与外部网络失去通信。因此OpenStack社区实现了L3-HA的功能。

OpenStack官网上有L3-HA的网络性能测试说明，但是L3-HA的网络拓扑是一个L3-agent连着两个虚拟路由器（master/slave）模式，但是文档中主要测试的是在路由器主备切换时候的网络丢包情况，和同时存在两个虚拟路由器时候的性能情况。但是考虑到一台虚拟路由器是slave模式，在性能测试的时候，流量并不通过salve的虚拟路由器。而且在进行带宽测试的时候并没有路由器主备切换的情况发生，因此测试结果可以作为Neutron L3的南北网络性能参考，并具有一定的参考意义。

测试场景

OpenStack（Mitaka版本）高可用部署，三个Network节点（三个L3-agent），在两台不同的服务器中孵化多对虚拟机，虚拟机通过不同的子网连接到不同的路由器上，两个路由器通过Floating IP进行连接。

1

2

3

4

5

测试图表

TCP Download/Upload： 在并发数从1-22的过程中，下载速度从700Mbits/s下降到100多Mbits/s

10

UDP Download/Upload： 在并发数5的条件下，UDP的带宽平均值大约为765Mbits/s

11

在发生Restart L3的情况下，由于主备虚拟路由器的切换（master->slave），性能情况与流量直接走master虚拟路由器的性能并没有很大差别

12

测试数据：

Shaker提供有关不同连接测量的最大值，最小值和平均值的统计数据。 在所有最大值中找出最大值和所有最小值中找出最小值，并且在所有平均值中统计最平均的值。 在下表中，列出了这些值。 在并发数为1-22的条件下：

6

7

参考文章

https://docs.openstack.org/performance-docs/latest/test_plans/neutron_features/l3_ha/plan.html

蒋暕青 Reading time ~1 minute

什么是ZUN？

Zun是Openstack中提供容器管理服务的组件，于2016年6月建立。Zun的目标是提供统一的Openstack API用于启动和管理容器，支持多种容器技术。Zun原来称为Higgins，后改名为Zun。Zun计划支持多种容器技术，Docker，Rkt，clear container等，目前只支持Docker。

OpenStack Queens版本发布，由于容器社区的火热，一项值得关注的补充则为“Zun”，它在OpenStack项目中负责提供容器服务，旨在通过与Neutron、Cinder、Keystone以及其它核心OpenStack服务相集成以实现容器的快速普及。通过这种方式，OpenStack的原有网络、存储以及身份验证工具将全部适用于容器体系，从而确保容器能够满足安全与合规性要求。

Zun集成了OpenStack什么服务？

Zun需要下列的OpenStack的服务来支持：

  • Keystone
  • Neutron
  • Kuryr-libnetwork

Zun也可以集成下面的OpenStack的服务（可选）：

  • Cinder
  • Heat
  • Glance

在使用Zun的时候，可以直接调用Zun的自带工具或API来创建和管理Docker的Workflow。 Zun的用户功能（以及某些管理员功能）都通过REST API公开，可以直接使用。

另外，也可以通过其他OpenStack组件的API或者SDK来间接调用Zun的API

  • Horizon: 通过OpenStack WebUI来调用
  • OpenStack Client: 通过OpenStack CLI来调用
  • Zun Client: 通过Zun的Python client来调用

Magnum与ZUN的区别

Magnum是OpenStack中一个提供容器集群部署的服务，通过Heat部署虚拟机和物理机，组成集群，然后调用COE接口完成容器的部署。Magnum项目创建之初，项目目标以CaaS为宗旨，即容器即服务；在后续的发展中将功能集中在容器的集群部署上。
Zun和Magnum的差异在于Zun目标是提供管理容器的API，而Magnum提供部署和管理容器编排引擎（COE）的API。Zun不准备实现COE提供的很多先进的功能（例如容器保活、负载均衡等），而是提供基本的容器操作（CRUD），并和Openstack紧密集成。

ZUN架构

为了更好理解zun与OpenStack其他组件的关系，下面是zun的架构图

  • Zun API: 处理 REST请求并确认输入参数
  • Zun Compute: 启动容器并调度计算资源
  • Keystone: 认证系统
  • Neutron: 提供容器网络
  • Glance: 用于存储docker镜像（另一种选择是使用DockerHub）
  • Kuryr: 用于连接容器网络和OpenStack Neutron的一种plugin

1

ZUN 怎么使用？

Zun主要使用Container和Capsule的概念。除了Container概念之外，Zun还提供了一些稍微先进的抽象概念，如Capsule。 Zun Capsule的概念有点像Kubernetes Pod，代表一组容器。 Capsule用于将多个需要彼此紧密合作的容器分组，以实现业务目标。
Container由Docker或其他容器引擎支持。Zun集成了基本的Docker的功能（如创建/删除容器）。
Zun的操作要求与其他OpenStack服务相似。 它需要在控制器节点上安装Zun API server，并在每个计算节点上安装Zun-agent。 Zun的主要依赖是一组OpenStack Base Services：与oslo兼容的数据库，消息队列，Etcd和Keystone。
此外，Zun还为容器添加了多个由OpenStack提供的功能。 例如，默认情况下，Zun容器可以使用Neutron分配的IP地址，可以attach Cinder卷，使用由Keystone提供的认证服务。 对于OpenStack用户，他们会发现开始使用Zun容器相当容易。
将Zun与Neutron一起使用，可以在Nova实例所在的隔离网络环境中创建容器。 VM的Neutron功能（即安全组，QoS）也可用于Zun容器。
下面命令就是利用了Neutron和Kuryr来为zun容器提供网络服务的：

1
2
3
4
5

$ openstack appcontainer run --net network=net1 \
    --net network=net2,v4-fixed-ip=10.0.0.31 \
    --net port=net3-port \
nginx:latest

为了容纳需要保存数据的应用程序，常用的方法是利用外部服务为容器提供持久卷。 Zun通过与OpenStack Cinder集成解决了这个问题。 创建容器时，用户可以选择将Cinder卷装入容器。 Cinder卷可以是租户中的现有卷或新创建的卷。 每个卷将被绑定到容器文件系统中的路径中，并且存储在那里的数据将被持久化。 下面命令就是利用Cinder来持久化存储容器数据的：

1
2
3

$ openstack appcontainer run \
    --mount source=my_cinder_volume,destination=/path/in/container \
nginx:latest

在Orchestration方面，与其他提供内置编排的容器平台不同，Zun使用外部编排系统来实现此目的（现在，Zun与OpenStack Heat集成，将来，Zun将与Kubernetes集成）。通过使用外部协调工具，最终用户可以使用该工具提供的DSL定义他们的容器化应用程序。特别是，借助Heat，还可以定义由容器资源和OpenStack资源组成的资源，例如Neutron负载平衡器，浮动IP，Nova实例等。

ZUN和Kubernetes是竞争关系吗？

Zun和Kubernetes是互补的关系，事实上，Zun社区正在积极地在与Kubenetes集成。目前Zun与COE集成的工作主要还是在Kubenetes上，与其他COE集成还需要时间。
Kubernetes使容器更易于部署，管理和扩展。 但是，在OpenStack上使用Kubernetes仍然需要用户手动底层基础设施，如虚拟服务器集群。 用户需要负责初始容量规划，例如决定VM群集大小以及正在运行的VM群集的维护。
Serverless容器技术或解决方案（如亚马逊网络服务（AWS）Fargate，Azure容器实例（ACI）和OpenStack Zun）的出现为在云上运行容器提供了一种可行的替代方案。 Serverless方法允许用户按需运行容器，而无需预先创建或管理自己的集群。
Zun将利用Kubernetes作为编排层，Kubernetes使用OpenStack Zun来提供“Serverless”容器。

ZUN和Kubernetes结合实现细节：

Virtual-kubelet这个项目可以完成kubelet 到Zun的转换，需要在virtual-kubelet这个项目里面注册一下Zun的driver
感兴趣的同学可以点击下面链接：

1

https://github.com/virtual-kubelet/virtual-kubelet

如果您选择私有云解决方案，则可以使用OpenStack Zun构建无服务器容器云。 但是，如果需求是独立的基础架构的解决方案，则可以选择使用平台级别的工具，例如Kubernetes。将来，可以将Kubernetes连接到无服务器技术，以便可以跳过配置Kubernetes节点集群并按需启动Kubernetes Pod的步骤。

ZUN-UI 预览

创建 Container 的页面和创建虚拟机的页面类似。可以选择来自 DockerHub 或者 Glance 的镜像，可以选择网络、端口、安全组等，支持容器特有的一些功能如限制cpu和内存的使用

2

对容器的一些基本操作：更新、停止、重启、暂停、执行命令、删除等操作

3

总结

Zun 的操作基本和 docker 的操作一致，使用起来和原生docker容器没有区别。但是现在可以和 Openstack 的资源良好的结合在一起，统一管理，提高的 OpenStack容器管理的灵活度，还是很令人期待的。

参考资料

https://docs.openstack.org/zun/latest/
Wiki: https://wiki.openstack.org/wiki/Zun
https://www.linkedin.com/pulse/aws-fargate-openstack-zun-comparing-serverless-container-hongbin-lu/?from=timeline&isappinstalled=0
Source code: https://github.com/openstack/zun