继上次向大家分享了 docker 上的容器网络技术后，很多同学对虚拟化网络产生了浓厚的兴趣，进而想了解虚机网络和容器网络的关系，包括能否在云场景下的能否可以对虚机和容器进行统一的网络管理。

其实，OpenStack 中已经有了虚机和容器的集成方案，主要使用了 Nova、Zun 和 Neutron 等组件，本期“智汇华云”专栏将先通过介绍 Nova 和 Zun 来介绍 OpenStack 的虚机计算项目和容器计算项目，继而介绍如何在同一集群下如何实现虚机和容器的网络互联互通。

Nova 是 OpenStack中处理计算业务的组件，在历史版本中 Nova 可以管理虚机、裸机和容器等多种虚拟化计算，在近来的发展中，OpenStack 已经把裸机管理划分出交给 Ironic 组件，把容器管理划分出交给 Zun 组件。所以现在，Openstack Nova 主要负责维护和管理云环境的虚拟机计算资源，同时管理虚拟机的生命周期。

Nova 的组件架构如下图所示，其中红色框内为 Nova 服务组件，框外为数据库与 OpenStack 其它服务组件。

OpenStack Nova 组件：

API: 接收和响应客户的 API 调用

Conductor: 为 nova 访问数据库提供统一的接口层，比如更新某些虚机的状态等。

Scheduler：虚机调度服务，负责决定在哪个计算节点上运行虚机。

Compute：管理虚机的核心服务，通过调用 Hypervisor API 实现虚机生命周期管理。

Hypervisor：计算节点上的虚拟化管理程序，常用的 Hypervisor 有 KVM，Xen等。

OpenStack 其它组件：

Keystone：认证管理服务，提供了其余所有组件的认证信息/令牌的管理，创建，修改等等，使用MySQL作为统一的数据库
Glance：镜像管理服务，提供了对虚拟机部署的时候所能提供的镜像的管理，包含镜像的导入，格式，以及制作相应的模板。
Cinder：块存储服务，为虚机提供相应的块存储，如虚拟出一块磁盘挂载到相应的虚拟机之上。
Neutron：网络管理服务，为虚机提供虚拟化网络，包括云环境上计算节点与网络节点之间的通信服务。

Zun 是 Openstack 中提供容器管理服务的组件，于2016年6月建立。Zun 的目标是提供统一的Openstack API用于启动和管理容器，支持多种容器技术。Zun 计划支持多种容器技术，目前只支持Docker。

Zun 旨在通过与 Neutron、Cinder、Keystone 以及其它核心服务相集成以实现容器的快速普及。通过这种方式，OpenStack的原有网络、存储以及身份验证工具将全部适用于容器体系，从而确保容器能够满足安全与合规性要求。

OpenStack Zun 的组件架构如下：

Zun API: 处理 REST请求并确认输入参数
Zun Compute: 启动容器并调度计算网络存储资源
Keystone: 统一认证系统
Neutron: 提供容器网络
Glance: 用于存储容器镜像
Kuryr: 用于连接容器网络和 Neutron 的一种 docker plugin，即是之前提到的 Libnetwork 框架下的一种 remote driver 实现，现在已经成为 Docker 官网推荐的一个 remote driver。kuryr 需要做的就是实现 docker libnetwork remote driver 需要实现的接口。

从上面的介绍中我们知道，在 OpenStack 环境中，Nova 虚机和 Zun 容器都是通过 Neutron 组件来获取网络的。通常，在现在的云场景中，可以通过在一套 OpenStack 环境中集成部署 Nova 和 Zun，就能够为用户提供虚机和容器的网络统一管理，如在一个 VPC 中，可以任意分配一个 IP 地址给虚机或者容器，实现云环境中的虚机和容器的大二层网络互通。

下面是一个简易的 Nova 和 Zun 集成部署的三节点 OpenStack 集群：

如上图所示：

- 控制节点上部署了计算和网络服务的控制组件，以及数据库、中间件和计算服务依赖的其它组件。其中，Nova- 和 Zun- 分别是虚机和容器的计算控制组件，Neutron-Server 是虚拟化网络的控制组件。

- 计算节点上部署了实现计算虚拟化的必要组件，像虚机运行需要 Nova-Compute 组件和 Hypervisor(如 KVM) 底层服务，运行容器则需要 Zun-Compute、Kuryr 组件和 Docker 底层服务，同时，计算节点还需要运行 Neutron L2 Agent 去为虚机或者容器提供网络通信服务。

- 网络节点上部署了实现集群网络功能的 Neutron Agent 组件，其中 Neutron DHCP Agent 通过 dhcp namespace 为集群提供网络的 dhcp 和 dns 等服务，Neutron L3 Agent 则通过 router namespace 为集群提供虚拟化路由器服务，包括内网路由和NAT网关功能。

下图演示了实现了虚机容器网络统一管理的计算与网络节点上的网络拓扑。

通过上面两图可以了解到：

虚机服务方面

控制节点上的 Nova 组件会接收操作虚机的指令，然后进行调度并通知某一计算节点上的 nova-compute 组件去调用宿主机上的 Hypervisor 去落实虚机的创建、更新、删除等，同时 nova-compute 会在虚机创建前向 neutron-server 申请虚机的网络信息，如 ip 地址、mac 地址、网络号、等等。

容器服务方面

控制节点上的 Zun 组件会接收操作容器的指令，然后进行调度并通知某一计算节点上的 zun-compute 组件去调用 docker 去创建、更新或删除容器，同时 zun-compute 也会调用 kuryr 为容器创建对应的容器网络，其中，容器的网络信息像虚机一样，需要通过 kuryr 向 neutron-server 申请。

网络服务方面

首先，Neutron-Server 可以调用各节点的 Neutron Agent 去为集群提供虚拟化网络功能，如创建网络和端口、创建路由器等等；同时，Neutron-Server 也会响应 nova-compute 或 kuryr 为虚机或者容器提供更详细化的网络服务。

网络节点上主要采用网络命名空间和 OVS 网桥来提供虚拟化的网络和路由器，其中网络对应的是 dhcp namespace，路由器对应的是 router namespace；计算节点上虚机和容器都是通过接入 OVS 网桥来获取虚拟化网络服务，一般 OpenStack 集群中虚拟化网络可以简单分为租户网络和外部网络。

我们在开发环境中成功部署了一套虚机与容器集成的 OpenStack 环境，下面我们将通过具体操作来展示集群中虚机与容器如何方便地共享网络资源。

第一步，创建一个租户网络

第二步，上传 nova 虚机和 zun 容器使用的镜像

第三步，在同一网络下创建 nova 虚机和 zun 容器

可以看出，虚机和容器已经共享了网络，并能在创建时被统一分配地址，下面我们分别进入虚机和容器中，测试它们之间的网络互通性。

进入虚机 vm1 :

再进入容器 con1:

结果显示，虚机和容器可以共享网络，并能够互联互通。

在很多的云计算场景下，计算服务只有虚机是不能够满足用户需求的，比如当用户需要价格优惠、轻量化、无状态化等等新的虚拟化服务时，容器比虚机更有优势。

Nova&Zun 就是 OpenStack 社区提供给用户的一种虚机与容器相结合的云计算方案，Nova&Zun 下的虚机和容器可以共享 OpenStack 提供的虚拟化网络、存储、镜像等服务，方便用户无差异化地部署虚机和容器。

简言之，为了适用多场景，云厂商不但要能够提供基础的虚机服务，还要适应技术的发展和需求的更新，去提供更多样更方便的虚拟化计算服务，否则难以逃脱被市场淘汰的命运。

参考资料

https://docs.openstack.org/nova/pike/user/architecture.html

https://docs.openstack.org/zun/latest/

https://docs.openstack.org/kuryr-libnetwork/latest/

https://docs.openstack.org/zun/latest/contributor/quickstart.html

https://www.linux.com/tutorials/how-integrate-containers-openstack/