Why OpenStack’s Magnum Is the Key to Seamless Container Orchestration

Overview of Magnum

Magnum is the official OpenStack project that offers a unified API for container orchestration, translating OpenStack requests into calls to heterogeneous back‑ends such as Kubernetes, Mesos, and Docker Swarm.

Community Contributions

Analysis of commit statistics across releases shows a clear “four‑giant” pattern: IBM, Huawei, NEC, and Intel dominate contributions, with Huawei showing particularly strong involvement.

Why Magnum?

Before Magnum, OpenStack offered three Docker integration paths: Nova Docker Driver, Heat Docker Driver, and the Kilo‑based Magnum project. Magnum consolidates these efforts, providing Kubernetes‑as‑a‑Service, Swarm‑as‑a‑Service, and other back‑ends through a single API.

Nova Docker Driver

The Nova Docker Driver treats Docker containers as virtual machines, exposing them via the Nova Compute driver. It supports basic VM‑like operations (create, start, stop, pause) and integrates with Nova Scheduler, Heat, and Neutron, enabling multi‑tenant quota and network isolation. However, it cannot leverage advanced Docker features such as container linking, port mapping, or the full range of Docker network modes.

Heat Docker Driver

Heat Docker Driver implements a Heat resource plugin that communicates with Docker via a REST API, bypassing Nova and Neutron. It fully supports Docker’s API, allowing any advanced Docker feature to be expressed in Heat templates and providing built‑in multi‑tenant isolation. Its drawbacks include lack of resource scheduling (users must specify target Docker hosts) and limited network management, requiring manual configuration of tools like Flannel or OVS.

Key Concepts

Bay : A container cluster (Kubernetes or Swarm) created through Magnum.

Baymodel : Defines the specifications of a Bay, similar to a flavor, including management node flavor, compute node flavor, and image.

Node : An individual host within a Bay.

Container : A Docker container; related concepts such as Pod, Replication Controller, and Service map directly to Kubernetes terminology.

Pod : The smallest deployment unit in Kubernetes, grouping one or more containers and a network container.

Service : Provides stable networking for Pods, abstracting away IP changes.

Replication Controller : Ensures a desired number of Pod replicas for scaling and high availability.

Magnum Services

Magnum consists mainly of two services: the Magnum‑API, which receives client requests and forwards them via a message queue, and the Magnum‑Conductor, which processes those requests and interacts with the chosen Container Orchestration Engine (CoE) such as Kubernetes, Swarm, or Mesos.

Workflow

Create a BayModel that defines the desired cluster specifications.

Instantiate a Bay from the BayModel, selecting the backend (Kubernetes, Swarm, or future Mesos).

After the Bay is ready, use the Magnum API to create containers, which are delegated to the underlying backend’s scheduler.

Notes and Limitations

Magnum does not provide its own scheduler; it relies on the backend’s native scheduler (Kubernetes or Swarm). It supports multi‑tenant isolation, but Docker network management is delegated to the backend (e.g., Kubernetes uses Flannel). For pure Docker management, the recommendation is to use a Swarm Bay.