OpenStack 与 Kubernetes 的共存
OpenStack 是面向资源层的 IaaS 云平台管理软件，能够帮忙用户构建和治理公有云和私有云。
目前，OpenStack 依然是开源 IaaS 畛域的支流平台，有超过 80% 的中国企业正在应用 OpenStack。然而随着 K8s 的日益遍及，有很多 OpenStack 用户开始关注云原生。有一些用户也尝试将工作负载从 Openstack 迁徙到云原生环境中。
OpenStack + Kubernetes 是目前绝对风行的云利用解决方案栈。对于那些部署了 OpenStack，同时又在尝试应用 Kubernetes 的用户，为了帮忙他们更好地同时治理 OpenStack 和 K8s，咱们倡议用户以 K8s 作为底座，OpenStack 由 K8s 对立部署和治理，以及对立编排。各种租户子网（跨 K8s 和 OpenStack）可能动静定义和连贯 / 断开，用以反对动态变化的租户需要。
在这种场景下，OpenStack VMs 和 Kubernetes Pods 的网络互通成为了一个亟待解决的问题。同时, OpenStack 所提供的网络隔离性能也应该在与 Kubernetes 连贯的过程中失效: 属于一个 VPC 的 VMs 理所应当地不能拜访另外一个 VPC 的 VMs 以及 Pods/Svcs。
面对这样的需要，灵雀云 Kube-OVN 团队工程师与 Intel 的 OpenStack 专家独特拟定了相应的计划。在计划里，Kube-OVN 须要提供的基本功能如下:
提供 Kubernetes Pods 和 OpenStack VMs 之间的路由替换, 实现网络互通；
为 Kubernetes 提供和 OpenStack 雷同的网络隔离标准, 保障 VPC 之间的网络隔离。
目前有两类实现计划, 一种是基于 ovn-ic 的计划, 以松耦合的形式提供路由替换和网络隔离；另一种是基于同一个 ovn 底座的计划, 这是一种紧耦合的计划。
计划前置要求：
Kube-OVN 降级到 V 1.7 版本以上；
OpenStack usurri +. 必须基于 ovn 部署。
计划一：基于 ovn-ic:
组网形式一:
ovn-ic 是 ovn 提供的一个 inter-connection 工具, 用于在不同的 ovn 控制器之间替换路由，可靠性和性能由 ovn 保障。
如图所示，ovn-ic 作为中间人, 相互交换 OpenStack OVN 和 Kubernetes Kube-OVN 的路由信息。
这样设计的益处是部署简略, OpenStack 和 Kubernetes 绝对独立，相互之间不会影响。
同时也有一些弊病：OpenStack 和 Kubernetes 别离部署, 资源利用率独立计算；而且 OpenStack 的网络隔离个性无奈展示。
组网形式二:
仍然基于 ovn-ic, 然而会为 OpenStack 的每个租户建设一个 Kubernetes 集群。
如图所示，ovn-ic 会负责买通 OpenStack 集群中的每个 VPC 网络和其对应的 Kubernetes 集群的路由。
这样设计的益处是部署简略, OpenStack 和 Kubernetes 绝对独立, 相互不受对方变动的影响，同时可能反对 OpenStack 的网络隔离个性。
也有同样的弊病，OpenStack 和 Kubernetes 别离部署, 资源利用率独立计算。
计划二：基于雷同 OVN 底座：
这个计划要求 Kubernetes 与 OpenStack 基于雷同的 ovn 控制器部署。Kube-OVN 目前反对 OpenStack 部署在 Kube-OVN 的 ovn 控制器上。
在这个计划中，OpenStack 在部署时, 网络组件沿用了 Kubernetes 中的 Kube-OVN 提供的接口，因而，OpenStack 和 Kubernetes 的网络底座是同一个 ovn。相应地，Kubernetes 和 OpenStack 的组网能力也完全相同。
这个计划的益处不言而喻：
OpenStack 和 Kubernetes 可能在同一个 host node 部署 VM 和 Pod，可能最大化一个 host node 的资源利用率；
反对 OpenStack 的网络隔离个性。
当然，也会有一些弊病，包含部署简单，Kubernetes 和 OpenStack 在虚构网络组网时会有相互影响等。
这两种计划曾经登陆 GitHub，哪种会更满足你的应用场景？欢送感兴趣的小伙伴们退出 Kube-OVN 社群参加探讨。
https://github.com/kubeovn/ku…