Kuryr一词来自捷克语，意思是“信使”。在OpenStack的大家庭里，Kuryr正在尝试做一项具有重大意义的工作，即把容器和Docker网络加入到Neutron解决方案和网络服务的使用中，从而弥补其中现存的差距。

Kuryr正在尝试解决什么问题？
OpenStack和Neutron已经不再是新的东西。目前Neutron已经成熟，它们正在nova-network上的OpenStack部署中流行起来，并且有着非常丰富的插件与驱动生态系统，可以提供网络解决方案和服务（例如负载平衡即服务LBaaS、虚拟私有网络即服务VPNaaS，以及防火墙即服务FWaaS）。云部署者可以对Neutron抽象层组件进行互换。

在容器网络和容器与OpenStack混合的环境中，我们已经注意到每个网络解决方案都试着进行改造，以便让网络能够适应容器，但是这次涉及的是Docker API（或者其他抽象层）。例如，OpenStack Magnum项目已经根据所使用的容器编排引擎（Container OrchestrationEngine，简称为COE）为不同的libnetwork驱动引入了一个抽象层。如果Kuryr能够成为Magnum COE的默认选项，那么这将是最理想的情况。

Kuryr背后的理念是能够利用抽象层、Neutron及其插件与服务中的所有工作，为容器应用案例提供一个生产级的网络。与试图解决这一问题的每个独立的Neutron插件或解决方案不同，我们可以集聚所有力量，并将这些力量聚焦在Kuryr这一个点之上。

Kuryr旨在成为一座连接Docker和Neutron两个社区的“整合桥梁”，将Neutron（或Docker）中的建议与实际变化结合在一起，让它们能够满足容器网络所需的使用案例。

值得注意的是，Kuryr本身并不是一个网络解决方案，同时它也没有尝试成为一个网络解决方案。Kuryr将重点放在了“信使”功能上，以向Docker 传递Neutron网络和服务。

Kuryr的架构
Kuryr的组件很少，其中部分组件已经处于工作流程当中，另有一部分组件正处于讨论和设计过程中。

将Docker libnetwork映射至Neutron API
下列示意图展示的是Kuryr架构的基本概念，其在Docker和libnetwork网络模式之间向Neutron API进行映射。

Kuryr映射了libnetwork API，并在Neutron中创建了一个适当的对象。这意味着每个执行NeutronAPI的解决方案都能够被用于容器网络。Neutron的所有附加功能都可以应用至容器端口，例如安全群组、NAT服务和浮动IP的端口处。

不过，Kuryr的潜力并不止步于核心API和基本的扩展，它还能够利用网络服务和LBaaS等功能，从而为执行Kubernetes服务提供抽象层。

当API的映射并不明显，或是所需驱动在Neutron社区中发生了变化时，Kuryr还可以用于弥补这些问题。最近的一个例子是，除了Neutron资源外的标签允许Kuryr这样的API客户端存储映射数据和端口转发，并且可以提供Docker类型的端口（当然，所有的这些仍处于评估和批准流程中）。

提供通用的VIF-Binding基础设施
希望支持容器网络的Neutron解决方案中存在的一个常见问题是，在这些环境中缺乏绑定了nova端口的基础设施，以及没有libvirt的支持。

Kuryr尝试着为不同类型的端口提供一个通用的VIF绑定机制，让它们能够从Docker那里接收命名空间端点，并根据它们的类型将其附加在网络解决方案基础设施中。

VIF绑定也是运行内嵌在VM产品内部的容器所需要的。我们会在随后内容中进行详细叙述。这些VM产品没有被nova直接管理，因此也不需要在内部有任何OpenStack代理，这意味着需要一些机制执行VIF绑定，其可通过本地Docker远程驱动调用Kuryr层的方式启动（目前这部分也仍在讨论当中）。

下图展示了VIF绑定与Kuryr的关系：

提供Neutron插件的容器化镜像和与Kolla的整合
Kuryr旨在提供不同Neutron插件的容器化镜像，并有望与Kolla程序整合在一起。如果不清楚OpenStack Kolla项目的内容可以访问https://wiki.openstack.org/wiki/Kolla。

这意味着我们有许多如OVS L2 Agent、Midonet和带来有Kuryr 层的OVN的不同Neutron插件的镜像。Kolla整合可以让部署变得更加容易，运营者希望既不丧失对内部服务的控制权，也不损害可配置性。

嵌入式的VM和Magnum使用案例
Kuryr致力于解决的另一个使用案例是，以一种通用方案在由用户自己的OpenStack所生成的VM上部署容器。这种部署方案为容器部署提供了一个额外的层，用户需要将自己的容器从Nova Compute机器中分离出来。

这种使用案例也被OpenStack Magnum所使用。Magnum是OpenStack容器团队通过容器编排引擎所开发出来的OpenStack API服务。它使得在OpenStack中，Docker和Kubernetes可作为一类资源使用。

目前，Neutron插件已经支持这类使用案例，其提供一种将嵌入式容器附加至不同逻辑网络中、而不是VM网络中的好办法，并且可以将Neutron功能应用其中，例如OVN。

Kuryr的目的是提供一个组件，以支持类似定义neutron端口和为其附加子端口的解决方案。通过Kuryr，OVN和MidoNet等Neutron厂商可以利用通用基础设施与Docker进行交互，让他们一直聚焦在执行Neutron API和推动网络发展方面。

结论
在我看来，Kuryr的任务非常重要且极为关键，它们未来还将面临一系列重大的挑战。为此，我们希望大家能够提供贡献、反馈和帮助。欢迎大家关注我们每周召开的网上交流大会，分享自己的想法和观点。我们的大会召开时间和地点的详细信息请访问http://eavesdrop.openstack.org/#Kuryr_Project_Meeting。

本文编译自superuser.openstack.org网站。该文章最先发布在作者Gal Sagie的个人博客中，Gal Sagie将与Mikodura的Antoni Segura Puimedon在东京OpenStack峰会上介绍更多关于Kuryr的信息。
 
转载自：OpenStack微信公众号