Cet article fait partie du dossier spécial OpenStack Summit 2015 :

• OpenStack Summit Tokyo 2015 Jour 1
• OpenStack Summit Tokyo 2015 Jour 1 : Focus sur Neutron
• OpenStack Project Navigator - Comment mesurer la qualité d'un projet OpenStack ?
• OpenStack Summit Tokyo 2015 Jour 2
• OpenStack Summit Tokyo 2015 Jour 2 : Le projet Kuryr
• OpenStack Summit Tokyo 2015 Jour 3

Présentation du projet Kuryr, pour rapprocher Neutron et Docker

• Intégration de Neutron et Docker libnetwork avec Kuryr (Mohammad Banikazemi, Phil Estes)

Kuryr est un projet du big-tent ayant pour but de connecter, d'un point de vue réseau, les conteneurs Docker aux instances OpenStack. Kuryr se présente comme un plugin réseau de Docker se connectant à Neutron afin d'étendre les fonctions Neutron aux conteneurs.
Kuryr est développé à +50% par Midokura, l'ensemble des contributeurs rassemble plus d'une dizaine d'entreprises et les équipes de Kuryr travaillent aussi en collaboration avec les projets Magnum, Kolla et Neutron.

Problématique

Un conteneur Docker est connecté au réseau de son host via un bridge. Si ce conteneur souhaite accéder à un conteneur situé sur le même host, cela ne pose pas de problème. En revanche, si le conteneur est situé sur un autre host, il est nécessaire de monter un overlay network entre les hosts afin de connecter les conteneurs.

Le problème est que Neutron peut aussi monter des overlay networks, avec du VXLAN par exemple.

Cet empilement d'overlay induit de la complexité, des performances moindres dues à la double encapsulation et une perte de souplesse. Il doit donc être évité.

Autre point pris en compte, la faible maturité des solutions existantes proposant des overlay networks au sein de Docker comme flannel ou weave.
Neutron, en revanche, est devenu suffisamment mature comme le prouvent les dernières statistiques de la fondation OpenStack faisant état d'un taux d'adoption de 89% à la date du Summit de Tokyo, soit en octobre 2015.

La maturité de Neutron ainsi que l'ensemble de ses fonctions ont permis d'imaginer un monde où les fonctions de Neutron pourraient être réutilisées pour les conteneurs sans avoir besoin de réinventer la roue.

Cette idée est renforcée par le fait que d'un point de vue "architecture réseau", les réseaux de conteneurs sont extrêmement semblables aux réseaux fournis par Neutron.

Le but : utiliser Neutron comme une abstraction du réseau pour les conteneurs

Le projet Kuryr se base sur deux idées principales :

• Neutron doit être l'unique API pour gérer le réseau (celui des conteneurs comme celui des instances),
• La double encapsulation doit être évitée.

Afin de permettre aux conteneurs Docker d'accéder à Neutron, Kuryr agit comme un proxy venant connecter un port Neutron au port du conteneur. On peut ainsi considérer le port du conteneur comme une entité Neutron sur laquelle on pourra éventuellement appliquer un security group ou une floating IP par exemple. Et on peut continuer à envisager de tirer profit des autres fonctions de Neutron (LBaaS, FWaaS, VPNaaS).

Il existe deux cas d'architecture pour les conteneurs : soit ceux-ci sont déployés sur du bare-metal, soit à l'intérieur "nested" d'une instance. Dans le premier cas, Kuryr se comporte comme un composant externe à Neutron et à Docker mais quand le conteneur est nested dans une instance, Kuryr vient se positionner comme le driver réseau Docker et ajoute une fine couche d'abstraction réseau au sein de Docker. Cette couche vient à l'heure actuelle taguer les paquets dans des VLAN pour assurer l'isolation. Des évolutions sont prévues dans Mitaka pour cette partie.

On rappellera que Kuryr n'est pas un service réseau, n'essaye pas de l'être mais cherche seulement à rester à la croisée des chemins. Cela impose un suivi assidu de Neutron et surtout de libnetwork, projet séparé de Docker il y a peu et qui évolue très rapidement.

La roadmap

Voici ce qui est prévu dans les cartons pour Mitaka ainsi que pour la release N :

• Neutron IPAM pour Docker
• Port forwarding
• VLAN trunk API (nested ports)
• DNS resolution pour les ports Docker
• Service Neutron avancés (LBaaS, VPNaaS FWaaS)
• Support de l'API Kubernetes

Romain GUICHARD

Rejoignez vous aussi la conversation !

Questions, remarques, suggestions... Contactez-nous directement sur Twitter sur @osones !
Pour discuter avec nous de vos projets, nous restons disponibles directement via contact@osones.com !
Enfin, la communauté Francophone d'OpenStack vous attend sur http://openstack.fr/ !