Coexistence of OpenStack and Kubernetes OpenStack is a resource-oriented IaaS cloud platform management software that helps users build and manage private and public clouds.

At present, OpenStack is still the mainstream platform in the open source IaaS field. More than 80% of Chinese enterprises are using OpenStack. However, with the increasing popularity of K8s, many OpenStack users began to pay attention to cloud native. Some users have also attempted to migrate their workloads from Openstack to the cloud native environment.

OpenStack + Kubernetes is a relatively popular cloud application solution stack. For those who have deployed OpenStack and are trying to use Kubernetes, to help them manage OpenStack and K8s at the same time, we recommend that users use K8s as the base, and that OpenStack be deployed, managed, and orchestrated by K8s in a unified manner. Various tenant subnets (across K8s and OpenStack) can be dynamically defined and connected/disconnected to support dynamically changing tenant requirements.

In this scenario, interoperability between OpenStack VMs and Kubernetes Pods becomes an urgent issue. In addition, the network isolation function provided by OpenStack should also be in effect when connecting to Kubernetes: VMs belonging to one VPC should not be able to access VMs and Pods/Svcs of another VPC.

Faced with this requirement, the Kube-OVn team of engineers worked with OpenStack specialists from Intel to develop a solution. In the scheme, kube-OVn needs to provide the following basic functions:

Footed provides a route exchange between Kubernetes Pods and OpenStack VMs, enabling connectivity.

Variation provides The same network isolation specifications for Kubernetes as OpenStack, ensuring network isolation between VPCS.

At present, there are two kinds of implementation schemes. One is based on OVN-IC, which provides routing and network isolation in a loose coupling manner. The other is based on the same OVN base, which is a tightly coupled scheme.

Pre-requirements of the scheme:

Anyway Kube-ovn upgrades to V 1.7 or above;

Peculiar OpenStack Usurri +. Must be deployed based on OVN.

Solution 1: Based on OVN-IC:

Networking mode 1:

Ovn-ic is an inter-connection tool provided by OVN. It is used to exchange routes between different OVN controllers. Reliability and performance are guaranteed by OVN.



As shown in the figure, OVN-IC acts as an intermediary and exchanges routing information between OpenStack OVN and Kubernetes Kube-OVN.

The benefits of this design are simple deployment, and OpenStack and Kubernetes are relatively independent of each other.

There are drawbacks: OpenStack and Kubernetes are deployed separately, and resource utilization is calculated independently. In addition, the OpenStack network isolation feature cannot be displayed.

Networking mode 2:

It will still be based on OVN-IC, but a Kubernetes cluster will be built for each tenant of OpenStack.

As shown in the figure, OVN-IC is responsible for routing each VPC network in an OpenStack cluster and its corresponding Kubernetes cluster.

The advantage of this design is that the deployment is simple, OpenStack and Kubernetes are relatively independent, and are not affected by each other’s changes. At the same time, the network isolation feature of OpenStack is supported.

OpenStack and Kubernetes are deployed separately and resource utilization is calculated independently.

Scheme 2: Based on the same OVN base:

This solution requires Kubernetes to be deployed on the same OVN controller as OpenStack. Kube-ovn currently supports OpenStack deployment on the OVN controller of Kube-OVN.



In this solution, the network components of OpenStack are deployed using the interface provided by Kube-OVN in Kubernetes. Therefore, the base network of OpenStack and Kubernetes is the same OVN. Accordingly, Kubernetes and OpenStack have exactly the same networking capabilities.

The benefits of this scheme are clear:

Kyrgyz OpenStack and Kubernetes deploy VMS and pods on the same host node, maximizing resource utilization for a single host node.

Slim supports OpenStack’s network isolation feature.

Of course, there are some downsides, including the complexity of the deployment and the interaction between Kubernetes and OpenStack on virtual networks.

Both of these options are available on GitHub. Which is more appropriate for your usage scenario? Interested parties are welcome to join the Kube-ovn community for discussion.

https://github.com/kubeovn/ku…