共计 3110 个字符，预计需要花费 8 分钟才能阅读完成。
这篇文章将为大家详细讲解有关如何实现 Kubernetes 和 OpenStack 的多云端网络，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
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 的多云端网络”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
