openstack没有mac地址不可用 openstack magnum

转载

mob64ca14163a4f 2024-01-09 23:48:06

文章标签 openstack没有mac地址不可用运维后端 API Docker 文章分类 OpenStack 云计算

背景

Liberty

我们知道，眼下 OpenStack 中 Nova 项目已经通过 nova-docker 的形式支持了 Docker 容器（把容器当虚机管）。但在实际使用中，会发现有不少的问题。毕竟，Nova 设计的初衷是管理虚拟机，而容器跟虚拟机在行为和特性上存在较大的不同。不管是管理层还是底层的虚拟化支持层都全然不同。

并且，让 Nova 支持各种各样的容器机制（Docker、OpenVZ、Rocket、LXC 等）要进行改动的地方着实不少，可能跟现有框架形成冲突。

此外，Heat 项目也支持 Docker 官方插件。来直接通过 Docker 的 REST API 来管理容器，而且支持容器的高级特性。

然而。不支持资源的调度和网络功能。

社区之所以接收 Magnum 项目。一方面是容器技术如今着实火热，还有一方面，也是往更高一层发展提供更好的支持。

设计原理

Magnum 在设计上，希望调用其他的容器管理平台的 API 来实现功能，自身作为一套 API 框架，眼下支持 Docker、Kubernetes、Swarm 等。主要优势包含多租户、多后端框架、完好的容器功能、支持资源调度等。

假设说 Nova 是一套支持不同 Hypervisor （KVM、VMWare 等虚拟机平台）的 API 框架，那么 Magnum 则是支持不同容器机制的 API 框架。

基本概念

从小往大的顺序：

Node：容器执行的节点，能够是裸机、虚拟机甚至容器。
Bay：一组 Node 的集合（底层同一个驱动机制），是 Magnum 中容器调度的基本单元。Bay 在租户之间是隔离的。
BayModle：类似于 Nova 中的 flavor。定义一个 Docker 集群的规格。

以下几个是来自 Kubernetes 中的概念。

Container：容器。
Pod：最小的管理单元。一个或多个相互关联的容器（一般执行相同应用），执行在同一个 Minion Node 上。共享相同的数据挂载和网络空间，代表某种应用的一个实例。
Service：由一个或者多个 Pod 组成，代表一个抽象的应用服务。对外呈现为同一个訪问接口。这样訪问能够通过 service 来路由。而无需详细知道 Pods 的地址。
ReplicationController：对 pod 指定副本数，RC 能够保证一直存在该数目的副本存在并执行。

主要服务

主要服务有两个。Magnum API 和 Magnum Conductor。

前者提供调用的接口，接收 python-magnumclient 的请求。能够同一时候执行一个或者多个实例。这些请求终于扔给 AMQP 消息队列。发送到 magnum-conductor 服务。

后者执行在控制节点上，详细负责将 client 的请求转发到详细的后端机制（Kubernetes API 或者 Docker API）。眼下限制仅仅能存在一个实例。

背景