Kubernetes与OpenStack

OpenStack is a resource-oriented IaaSCloud platform management software that helps users build and manage private and public clouds.

At present, OpenStack is still the mainstream platform in the field of open source IaaS, and more than 80% of Chinese enterprises are using OpenStack.But with the increasing popularity of K8s, many OpenStack users have begun to pay attention to cloud native.Some users are also trying to migrate workloads from Openstack to cloud-native environments.

 

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

 

In this scenario, the network interconnection between OpenStack VMs and Kubernetes Pods has become an urgent problem to be solved.At the same time, the network isolation function provided by OpenStack should also take effect in the process of connecting with Kubernetes: VMs belonging to one VPC should not be able to access VMs and Pods/Svcs of another VPC.

 

Faced with this demand, Lingqueyun Kube-OVN team engineers and Intel's OpenStack experts jointly formulated a corresponding plan.In the solution, the basic functions that Kube-OVN needs to provide are as follows:

There are currently two types of implementation schemes, one is based on ovn-ic, which provides routing switching and network isolation in a loosely coupled manner; the other is based on ovn-ic.It is a scheme based on the same ovn base, which is a tightly coupled scheme.

Pre-requirements for the solution:

Scheme 1: Based on ovn-ic

Networking Method 1:

ovn-ic is an inter-connection tool provided by ovn, which is used to exchange routes between different ovn controllers. The reliability and performance are guaranteed by ovn.

As shown in the figure, ovn-ic isThe middleman exchanges routing information between OpenStack OVN and Kubernetes Kube-OVN.

The advantage of this design is that the deployment is simple, OpenStack and Kubernetes are relatively independent and will not affect each other.

There are also some disadvantages: OpenStack and Kubernetes are deployed separately, and resource utilization is calculated independently; and the network isolation feature of OpenStack cannot be displayed.

 

Networking method 2:

It is still based on ovn-ic, but a Kubernetes cluster will be established for each tenant of OpenStack.

As shown in the figure, ovn-ic willResponsible for routing each VPC network in the OpenStack cluster and its corresponding Kubernetes cluster.

The advantage of this design is that the deployment is simple, OpenStack and Kubernetes are relatively independent, not affected by each other's changes, and can support the network isolation feature of OpenStack.

There are also the same drawbacks. OpenStack and Kubernetes are deployed separately, and resource utilization is calculated independently.

Option 2: Based on the same OVN base

This solution requires Kubernetes and OpenStack to be deployed based on the same ovn controller.Kube-OVN currently supports OpenStack deployment on Kube-OVN's ovn controller.

In this scenario, OpenStack deploys, The network component follows the interface provided by Kube-OVN in Kubernetes. Therefore, the network base of OpenStack and Kubernetes is the same ovn.Correspondingly, the networking capabilities of Kubernetes and OpenStack are exactly the same.

The benefits of this solution are obvious:

Of course, there will also be some drawbacks, including complex deployment, Kubernetes and OpenStack will interact with each other in virtual network networkingWait.These two solutions have been listed on GitHub (https://github.com/kubeovn/kube-ovn/blob/master/docs/OpenstackOnKubernetes.md), which one will suit your usage scenario better?