Kubernetes和OpenStack相虐相杀，还是珠联璧合？_行业深度_才云科技

【AICon】如何构建高效的 RAG 系统？RAG 技术在实际应用中遇到的挑战及应对策略？>>> 了解详情 



 写点什么

上周，在 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 Neutron 配置都会使用覆盖（VXLAN，GRE，MPLSoverGRE，MPLSoverUDP），我们可以使他们之间互相联系。
分布式路径引擎——东西和南北流量无法通过同一个中央软件服务。网络流量不得不在 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 发布表明。点击这里查看：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 有公共 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 运行完全没有问题。