玩转企业云计算平台系列（十三）：Openstack 容器管理服务 Zun

民工哥

发布于 2024-01-18 16:22:51

1900

发布于 2024-01-18 16:22:51

什么是Zun？

作为提供容器管理服务的组件，Zun允许用户在没有管理服务器或集群参与的情况下快速启动和操作管理容器。它集成了Neutron、Cinder、Keystone等核心OpenStack服务，实现了容器的快速普及。通过这种方式，OpenStack的所有原始网络、存储和识别验证工具都应用于容器系统，使容器能够满足安全性和合规性要求。

Zun计划支持多种容器技术，如Docker、Rkt和clear container。现在，对Docker技术的支持已经完成。

Zun服务和Nova服务的功能和结构非常相似，只是前者提供容器服务，后者提供虚拟机服务，二者都是主流的计算服务交付模式。功能类似体现在如下几点：

通过Neutron提供网络服务。
通过Cinder实现数据的持久化存储。
都支持使用Glance存储镜像。
其他如quota、安全组等功能。

组件结构结构相似则表现在:

二者都是由API、调度、计算三大组件模块构成，Nova由nova-api、nova-scheduler、nova-compute三大核心组件构成，而Zun由zun-api、zun-compute两大核心组件构成，之所以没有zun-scheduler是因为scheduler集成到zun-api中了。
nova-compute调用compute driver创建虚拟机，如Libvirt。zun-compute调用container driver创建容器，如Docker。
Nova通过一系列的proxy代理实现VNC（nova-novncproxy)、Splice(nova-spiceproxy)等虚拟终端访问，Zun也是通过proxy代理容器的websocket实现远程attach容器功能。

为什么用Zun？

OpenStack 平台主要有几个方案支持容器技术：Nova-docker driver、Heat-docker-plugin、Magnum等。

1、Nova Docker驱动程序

该解决方案将容器作为VM运行。添加Nova Docker驱动程序以执行与常规VM类似的操作，以启动、停止或创建Docker容器。由于Docker和VM之间的差异，这种操作模式将禁用容器的许多功能，例如容器相关和端口映射。

2、Magnum

Magnum是一个OpenStack服务，提供容器集群部署功能。Magnum通过Heat部署VM和物理机，形成集群，然后调用COE接口完成容器的部署。在Magnum成立之初，该项目以“容器即服务”（CaaS）为目标。在以后的开发过程中，Magnum的大部分功能都集中在容器的集群部署上。

3、Heat-docker-plugin

Heat-docker-plugin方案不依赖于Nova的调用，而是通过 OpenStack Heat进行编排，使用 Heat Docker plugin插件，编辑Heat Templates 设定 Docker 的参数，在虚拟机上管理容器。虽然可以使用 Docker API 提供的所有功能，但是在虚拟机上使用 Docker，无法实现资源调度，需要较多的配置工作，无法实现规模化的集群管理。

4、Zun

Zun将容器作为一种OpenStack资源进行管理，并集成了OpenStack的其他服务，为用户提供统一、简化的API。用户可以通过API创建和管理容器，而不需要考虑不同容器技术之间的差异。

Zun已与多个OpenStack服务集成。Keystone、Neutron和Kuryr-libnetwork是运行Zun的必要服务。它们为Zun提供身份验证、网络、Neutron和docker网络之间的连接。OpenStack用户可以轻松学习使用Zun容器。

集成OpenStack服务的优点是用户可以借助OpenStack的现有功能扩展容器的功能。例如，默认情况下，Zun容器可以使用Neutron分配的IP地址，并可以使用Keystone提供的身份验证服务。使用Zun和Neutron，用户可以在Nova实例所在的隔离网络环境中创建容器。VM的Neutron功能（安全组、QoS）也可用于Zun容器。在实际业务中，经常有需要长时间保存数据的场景。常用方法是使用外部服务为容器提供持久卷。Zun通过与OpenStack Cinder集成解决了这个问题。

创建容器时，用户可以选择将Cinder卷安装到容器中。Cinder卷可以是租户中现有的或新创建的卷。每个卷都将绑定到容器文件系统路径，并且将保留该路径下存储的数据。

对于编排，与提供内置编排的其他容器平台不同，Zun使用外部编排系统来实现此目的，例如Heat和Kubernetes。借助外部编排工具，最终用户可以使用该工具提供的DSL来定义容器化应用程序。

使用Heat，用户还可以定义由容器资源和OpenStack资源组成的资源，例如Neutron负载均衡器、浮动IP、Nova实例等。

Zun和Kubernetes是互补的。事实上，Zun社区正在积极推动与Kubenetes的整合。目前，Zun与COE的整合工作主要集中在Kubenetes上，这将使容器更易于部署、管理和扩展。

但是，在OpenStack上使用Kubernetes仍然需要用户手动部署底层基础设施，例如虚拟服务器集群。用户负责初始容量规划，例如确定VM集群的大小和维护正在运行的VM集群。

无服务器容器技术或解决方案（如AWS Fargate、Azure Container Instance（ACI）和OpenStack Zun）的出现为在云上运行容器提供了可行的替代方案。无服务器方法允许用户按需运行容器，而无需事先创建或管理自己的集群。

Zun将使用Kubernetes作为业务流程层，Kubernetes将使用OpenStack Zun提供“无服务器”容器。

Zun提出了Container和Capsule的概念。Container负责集成Docker或其他容器引擎技术。Capsule的概念有点像Kubernetes Pod，它代表一组容器。Capsule用于对需要彼此紧密合作以实现服务目标的多个容器进行分组。

Zun不准备实现COE提供的许多高级功能（例如容器保持活动、负载均衡），而是专注于提供基本容器操作（CRUD）并保持与OpenStack的紧密集成。

与Nova Docker驱动程序比较，Zun旨在解决Nova Docker驱动程序解决方案的问题。它独立于Nova实现了Docker的部署调度框架，并与Glance、Neutron、Cinder和其他组件集成，但没有实现Container Orchestration Engines（COE）的部署调度。Nova-docker通过Nova API访问容器，Zun不受Nova API的限制。

与Magnum相比，Zun和Magnum之间的区别在于Zun专注于提供用于管理容器的API，而Magnum提供用于部署和管理COE的API。

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

Zun实现原理

调用容器接口实现容器生命周期管理

Zun主要由zun-api和zun-compute服务组成，zun-api主要负责接收用户请求、参数校验、资源准备等工作，而zun-compute则真正负责容器的管理，Nova的后端通过compute_driver配置，而Zun的后端则通过container_driver配置，目前只实现了DockerDriver。因此调用Zun创建容器，最终就是zun-compute调用docker创建容器。

通过websocket实现远程容器访问

我们知道虚拟机可以通过VNC远程登录，物理服务器可以通过SOL(IPMI Serial Over LAN)实现远程访问，容器则可以通过websocket接口实现远程交互访问。

Docker原生支持websocket连接，参考APIAttach to a container via a websocket，websocket地址为/containers/{id}/attach/ws，不过只能在计算节点访问，那如何通过API访问呢？

和Nova、Ironic实现完全一样，也是通过proxy代理转发实现的，负责container的websocket转发的进程为zun-wsproxy。当调用zun-compute的container_attach()方法时，zun-compute会把container的websocket_url以及websocket_token保存到数据库中。

使用Cinder实现容器持久化存储

john griffith开发的docker-cinder-driver以及OpenStack Fuxi项目，这两个项目都实现了Cinder volume挂载到Docker容器中。另外cinderclient的扩展模块python-brick-cinderclient-ext实现了Cinder volume的local attach，即把Cinder volume挂载到物理机中。

Zun没有复用以上的代码模块，而是重新实现了volume attach的功能，不过实现原理和上面的方法完全一样。

集成Neutron网络实现容器网络多租户

我们通过Zun创建容器，使用的就是Neutron网络，意味着容器和虚拟机完全等同的共享Neutron网络服务，虚拟机网络具有的功能，容器也能实现，比如多租户隔离、floating ip、安全组、防火墙等。

ZUN 怎么使用？

Zun主要使用Container和Capsule的概念。除了Container概念之外，Zun还提供了一些稍微先进的抽象概念，如Capsule。Zun Capsule的概念有点像Kubernetes Pod，代表一组容器。Capsule用于将多个需要彼此紧密合作的容器分组，以实现业务目标。

Container由Docker或其他容器引擎支持。Zun集成了基本的Docker的功能（如创建/删除容器）。

将Zun与Neutron一起使用，可以在Nova实例所在的隔离网络环境中创建容器。VM的Neutron功能（即安全组，QoS）也可用于Zun容器。

下面命令就是利用了Neutron和Kuryr来为zun容器提供网络服务的：

$ 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来持久化存储容器数据的：

$ 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结合实现细节：

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

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

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

ZUN-UI 预览

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

命令行创建演示

这里使用zun来创建一台云主机，以下操作均在命令行操作，步骤如下：

We will create and run a container that pings the address 8.8.8.8 four times:

$ zun run --name test cirros ping -c 4 8.8.8.8

Above command will use the Docker image cirros from DockerHub which is a public image repository. Alternatively, you can use Docker image from Glance which serves as a private image repository:

$ docker pull cirros
$ docker save cirros | openstack image create cirros --public --container-format docker --disk-format raw
$ zun run --image-driver glance cirros ping -c 4 8.8.8.8

You should see a similar output to:

$ zun list
  +--------------------------------------+------+--------+---------+------------+------------+-------+
  | uuid                                 | name | image  | status  | task_state | addresses  | ports |
  +--------------------------------------+------+--------+---------+------------+------------+-------+
  | 46dd001b-7474-412c-a0f4-7adc047aaedf | test | cirros | Stopped | None       | 172.17.0.2 | []    |
  +--------------------------------------+------+--------+---------+------------+------------+-------+

$ zun logs test
  PING 8.8.8.8 (8.8.8.8): 56 data bytes
  64 bytes from 8.8.8.8: seq=0 ttl=40 time=25.513 ms
  64 bytes from 8.8.8.8: seq=1 ttl=40 time=25.348 ms
  64 bytes from 8.8.8.8: seq=2 ttl=40 time=25.226 ms
  64 bytes from 8.8.8.8: seq=3 ttl=40 time=25.275 ms

  --- 8.8.8.8 ping statistics ---
  4 packets transmitted, 4 packets received, 0% packet loss
  round-trip min/avg/max = 25.226/25.340/25.513 ms

Delete the container:

$ zun delete test

除了上面的方式，还可以使用openstack命令行来创建，这里就不做演示了，有问题可以私信，下面是openstack zun的命令行操作介绍：https://docs.openstack.org/python-openstackclient/latest/cli/plugin-commands/zun.html

总结

Zun 的操作基本和 docker 的操作一致，使用起来和原生docker容器没有区别。OpenStack Zun项目非常完美地实现了容器与Neutron、Cinder的集成，加上Ironic裸机服务，OpenStack实现了容器、虚拟机、裸机共享网络与存储。未来我觉得很长一段时间内裸机、虚拟机和容器将在数据中心混合存在，OpenStack实现了容器和虚拟机、裸机的完全平等、资源共享以及功能对齐，应用可以根据自己的需求选择容器、虚拟机或者裸机，使用上没有什么区别，用户只需要关心业务针对性能的需求以及对硬件的特殊访问，对负载（workload）是完全透明的。