背景

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

什么是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

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( 虚拟图形处理单元 )的功能,这对于图形密集型工作负载以及许多科学性的、人工智能和机器学习的工作负载来说是一项重要的能力。

测试概要

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

什么是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