导言

上周，在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。因此，我们来定义以下网络需求：

1. 多租户——容器工作负载是每个安全策略标准的基础要求。例如，默认的Flannel网络只提供平坦的网络体系结构。
2. 多云端支持——不是每个工作负载都适用于容器的，你仍然需要将像数据库一个的重负载放到虚拟机或者裸机里。由于这个原因，单个控制面板是最好的选择
3. 覆盖——与多租户相关。几乎每一个OpenStack Neutron配置都会使用覆盖（VXLAN，GRE，MPLSoverGRE，MPLSoverUDP），我们可以使他们之间互相联系。
4. 分布式路径引擎——东西和南北流量无法通过同一个中央软件服务。网络流量不得不在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(https://github.com/django-leonardo/django-leonardo/blob/master/contrib/haproxy/docker-compose.yml)，这也是为在笔记本上的开发和本地测试所用。这个方法更加轻松，但是我们的开发者已经了解过docker和应用程序工作负载。这个应用程序堆栈包括以下组件：

1. 数据库——PostgreSQL或者MySQL数据库集群
2. 下载并安装——为内容缓存
3. Django 应用 Leonardo——Django CMS Leonardo被用于应用程序堆栈测试
4. Nginx——网络代理
5. 负载均衡——容器缩放的HAProxy负载均衡器

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

应用程序部署

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

OpenStack方面

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

Kubernetes方面

在Kubernetes这边，我们不得不用Leonardo和Nginx services发布表明。点击这里查看：https://github.com/pupapaik/scripts/tree/master/kubernetes/leonardo为了使之顺利在网络隔离情况下运行，来看以下部分。

1. leonardo-rc.yaml－Leonardo应用的RC，replicas3，和虚拟网络leonardo
2. 
3. leonardo－svc.yaml－leonardo service 用虚拟IP在端口8000从集群网络挂载应用程序pods。
4. 
5. nginx－rc.yaml－3个副本的NGINX RC，虚拟网络nginx和策略，这三者允许与leonardo－svc 网络通信。这个例子不使用SSL。（NGINX replication controller with 3 replicas and virtual networknginx and policy allowing traffic to leonardo-svc network. This sample does notuse SSL.）
6. 
7. nginx－svc.yaml－用集群vip IP和虚拟IP创建service，从网络上访问应用程序
8. 
9. 我们来调用kubecl来运行所有的密钥清单。
10. 
11. 在Kubernetes里创建了以下的pods和services。
12. ,figure style="margin-top: 10px; margin-bottom: 10px; border: 0px; font-style: inherit; font-variant: inherit; font-weight: inherit; font-stretch: inherit; line-height: inherit; vertical-align: baseline;">只有Nginx service有公共IP 185.22.97.188，这是一个负载均衡的浮动IP。所有的流量现在已经在Juniper MX上面被ECMP平衡。
13. 为了让集群完全运行起来，就必须在OpenStack上的数据库虚拟网络和Kubernetes Contrail上的leonardo 虚拟网络。进入这两个Contrail UI，然后为这两个网络设置一样的Route Target。这也可以通过contrail 资源（heat resource）来进行自动化。
14. 

下面的这张图展示了应该怎样查看产品应用程序堆栈。在最上面是两个有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解决方案。

更重要的一点是，这个使用案例实际上可以为生产环境所用。

如果你对这个话题更加感兴趣的话，可以为我们的这个文章投票，点击链接：https://www.openstack.org/summit/austin-2016/vote-for-speakers/Presentation/8688。

目前，我们正处理Kubernetes网络堆栈的要求，然后提供不同Kubernetes网络插件，比如Weave、Calico、Open VSwitch、Flannel和250个裸机服务器的Contrail等，这几个插件间的对照。

我们也在用Kubernetes备份来处理OpenStack Magnum，给开发者带来简单测试和开发的自助服务门户。然后他们就能够在OpenStack虚拟机里准备应用程序密钥清单，然后推动最终生产定义的修改到git，最后在生产过程中使用它们。

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