如何实现Kubernetes和OpenStack的多云端网络

这篇文章将为大家详细讲解有关如何实现Kubernetes和OpenStack的多云端网络，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

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和应用程序工作负载。这个应用程序堆栈包括以下组件：

• 数据库——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发布表明。点击这里查看：https://github.com/pupapaik/scripts/tree/master/kubernetes/leonardo

为了使之顺利在网络隔离情况下运行，来看以下部分。

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 replication controller with 3 replicas and virtual networknginx and policy allowing traffic to leonardo-svc network. This sample does notuse SSL.）

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

我们来调用kubecl来运行所有的密钥清单。

在Kubernetes里创建了以下的pods和services。

只有Nginx service有Public 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的路径。

关于“如何实现Kubernetes和OpenStack的多云端网络”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。