Kubernetes和OpenStack的多云端网络

上周，在Austin举行的OpenStack Summit上，CoreOS发布Stackanetes，整合Kubernetes和OpenStack。

一个月前，CoreOS、Intel和Mirantis宣布合做，目标是把OpenStack云管理框架搬上K8S，当OpenStack出故障时，能借助K8S的编排机制以极快的速度重启OpenStack组件。此番“珠联璧合”，却有以前“相虐相杀”之说的铺垫。

去年11月东京OpenStack峰会让咱们嗅到了容器的“腾腾杀机”：每一个人都在谈论容器，以及用各类容器编排器在不久的未来替代虚拟机！由于容器的轻量级、易用、部署快速，迅速成为开发者最爱，用以轻松创建、维护、扩容和滚动更新他们的应用程序。

如下让咱们来看一篇技术帖，描述如何基于Kubernetes，在TCP云端建立私有云解决方法，运用在生产或是在OpenStack启动的虚拟化。

Kubernetes带来一个崭新的方法来管理基于容器的工做负载，而且为虚拟机开启相似于OpenStack的功能。若是你开始使用Kubernetes，你很快会感觉到轻松在AWS、GCE或者Vagrant上部署的快感，可是你的本地逻辑部署怎么样呢？如何将其整合到你目前的OpenStack或者虚拟基础设施上呢？全部的博客帖和手册文档用文件证实用简单的网页程序跑在虚拟机上的小集群，可是目前的网络设计却没有可以为裸机或者企业性能负载展现真实场景。设计网络是架构设计中最难的部分，就比如使用OpenStack。所以，咱们来定义如下网络需求：

• 多租户——容器工做负载是每一个安全策略标准的基础要求。例如，默认的Flannel网络只提供平坦的网络体系结构。

• 多云端支持——不是每一个工做负载都适用于容器的，你仍然须要将像数据库一个的重负载放到虚拟机或者裸机里。因为这个缘由，单个控制面板是最好的选择

• 多云端支持——不是每一个工做负载都适用于容器的，你仍然须要将像数据库一个的重负载放到虚拟机或者裸机里。因为这个缘由，单个控制面板是最好的选择

• 分布式路径引擎——东西和南北流量没法经过同一个中央软件服务。网络流量不得不在OpenStack计算节点和Kubernetes节点之间走动。最优方案就是在路由器上面提供路由，而不是专用网关设备。

基于这些需求，咱们决定首先开始使用OpenContrail SDN，咱们的任务是将OpenStack和Kubernetes整合到一块儿，而后为实际负载测试找一个合适的应用程式堆栈。

OpenContrail概述

OpenContrail是一个开源SDN&NFV解决方案，从Havana开始，跟OpenStack有着些许的联系。它和Nicira（如今的VMware NSX－VH）是第一个产品Neutron插件，上一届峰会调查显示，它也是最常被配置的解决方案，排名仅在OpenVwitch以后，是第一个基于Vendor的解决方案。

OpenContrail已经整合到OpenStack、VMware、Docker和Kubernetes上了。Kubernetes 网络插件 kube-network-manager早在去年于温哥华举办的OpenStack峰会的时候已经在开发当中了，于去年年末首次发布。

架构

咱们从两个独立的Contrail配置开始测试，而后安装BGP联盟。联盟的缘由是kube-network-manager的重点验证。当启用contrail－neutron－plugin开启的时候，contrail API启用keystone验证的时候，contrail API用keystone验证，这个功能尚未在Kubernetes插件实施。Contrail联盟等下会详细描述。

下面的这个架构是一个高水平架构图，图中左边是OpenStack集群，右边是Kubernetes集群。OpenStack和OpenContrail被部署在高可得性的最佳实践设计中，这个设计能够被扩容成成百上千个计算节点。

下图展现了两个Contrail集群的联盟。整体上，这个功能在不须要物理网关的状况下能够链接Contrail controllers与多站点数据中心的站点。每一个站点的控制节点和其它使用BGP的站点同样。有可能的话，能够用这种方法延伸到L2和L3网络在多个数据中心上面。

一般，两个独立的OpenStack云端或者两个OpenStack区域会用到这个设计。全部的Contrail的组件（包括vRouter）是同样的。Kube－network－manager和neutron－contrail－plugin为不一样的平台转换API请求。网络解决方案的核心功能仍是没有改变。这不只带来强大的网络引擎，还带来了分析。

应用程序堆栈

概述

让咱们来看看典型的场景。咱们的开发人员给了咱们docker compose.yml(点我)，这也是为在笔记本上的开发和本地测试所用。这个方法更加轻松，可是咱们的开发者已经了解过docker和应用程序工做负载。这个应用程序堆栈包括如下组件：

• 数据库——PostgreSQL或者MySQL数据库集群

• 下载并安装——为内容缓存

• Django 应用 Leonardo——Django CMS Leonardo被用于应用程序堆栈测试

• Nginx——网络代理

• 负载均衡——容器缩放的HAProxy负载均衡器

当咱们想将之运用到产品中的时候，咱们能够将全部东西和service一块儿转移到Kubernetes RC上面，可是就如咱们在一开始提到的，不是全部的东西都适用于容器。所以，咱们将数据库集群分开到OpenStack虚拟机，而后将剩下的部分重写到Kubernetes密钥清单。

应用程序部署

这个部分描述了在OpenStack和Kubernetes上的应用程序供应的工做流程。

OpenStack方面

第一步，咱们已经在OpenStack上正式推出数据库堆栈。这就用PostgreSQL和数据库网络建立了3个虚拟机。数据库网络是私人租户隔离网络。

Kubernetes方面

在Kubernetes这边，咱们不得不用Leonardo和Nginx services发布代表。点击这里查看：点我 为了使之顺利在网络隔离状况下运行，来看如下部分。

• leonardo-rc.yaml－Leonardo应用的RC，replicas3，和虚拟网络leonardo

• leonardo－svc.yaml－leonardo service 用虚拟IP在端口8000从集群网络挂载应用程序pods。

nginx－rc.yaml－3个副本的NGINX RC，虚拟网络nginx和策略，这三者容许与leonardo－svc 网络通讯。这个例子不使用SSL。

• nginx－svc.yaml－用集群vip IP和虚拟IP建立service，从网络上访问应用程序

咱们来调用kubecl来运行全部的密钥清单。

在Kubernetes里建立了如下的pods和services。

只有Nginx service有公共IP 185.22.97.188，这是一个负载均衡的浮动IP。全部的流量如今已经在Juniper MX上面被ECMP平衡。为了让集群彻底运行起来，就必须在OpenStack上的数据库虚拟网络和Kubernetes Contrail上的leonardo 虚拟网络。进入这两个Contrail UI，而后为这两个网络设置同样的Route Target。这也能够经过contrail 资源（heat resource）来进行自动化。

下面的这张图展现了应该怎样查看产品应用程序堆栈。在最上面是两个有Public VRF的Juniper MXs，就是浮动IP传播的地方。流量经过ECMP到MPLSoverGRE隧道传播到3个nginx pods。Nginx代理请求到Leonardo应用程序服务器，它将会议和内容存储到运行在OpenStack 虚拟机上的PostgreSQL数据库集群。

pods和虚拟机间的链接是直接的，没有任何路由中心点的。Juniper MXs只运用于外向链接到互联网。多亏存储应用程序会话到数据库（一般来讲是下载安装或者是redis），咱们不须要特定的L7负载均衡器，ECMP运行彻底没有问题。

其它的输出

这个部分展现的是其它从应用堆栈的有趣输出。用负载均衡器描述的Nginx service展现了浮动IP和私有集群IP。而后是nginx pods的3个IP地址。流量经过vRouter ECMP分布。

Nginx路由表展现了pods和route10.254.98.15／32间的内部路由，指向leonardo service。

以前的route10.254.98.15／32是leonardo service里面的描述。

Leonardo路由表跟nginx十分类似，除了routes 10.0.100.X／32，他在不一样的Contrail里指向OpenStack 虚拟机。

最近的输出是从Juniper MXs VRF出来的，展现了多个到nginx pods的路径。

结语

咱们已经证实，OpenStack、Kubernetes、裸机和VMware vCenter可使用单个SDN解决方案。更重要的一点是，这个使用案例实际上能够为生产环境所用。

若是你对这个话题更加感兴趣的话，能够为咱们的这个文章投票，点击连接：点我。

目前，咱们正处理Kubernetes网络堆栈的要求，而后提供不一样Kubernetes网络插件，好比Weave、Calico、Open VSwitch、Flannel和250个裸机服务器的Contrail等，这几个插件间的对照。
咱们也在用Kubernetes备份来处理OpenStack Magnum，给开发者带来简单测试和开发的自助服务门户。而后他们就可以在OpenStack虚拟机里准备应用程序密钥清单，而后推进最终生产定义的修改到git，最后在生产过程当中使用它们。

特别感谢来自Juniper的Pedro Marques的支持和在测试过程当中做出的贡献。

原文连接

（若是须要转载，请联系咱们哦，尊重知识产权人人有责）