Kube-OVN

News

As cloud native technologies converge to data centers and the infrastructure, more and more enterprises are using Kubernetes and KubeVirt to run virtualized workloads and manage both virtual machines and containers from a unified control plane. However, the usage scenarios of VMs are significantly different from those of containers. At the same time, the emerging container networking solutions are not designed for virtualization scenarios - the feature set and the performance characteristics are quite different from those of the traditional data center networks. Networking has become the bottleneck of adopting cloud native virtualization.

, as its name implies, is an integration of the OVN/OVS based networking with Kubernetes. Since OVN and OVS have been widely used in traditional virtualization scenarios, Kube-OVN has attracted a lot of attention from the KubeVirt community since it was open sourced. Some early adopters of KubeVirt have further improved the networking capabilities of Kube-OVN for their use cases. This resulted in a large number of new and optimized Kube-OVN features specifically targeted towards solving some of the networking challenges faced by KubeVirt.

Container networks usually do not require that IP addresses be fixed. In VM usage scenarios, however, the IP addresses are often used as the primary access method. Users typically require that the VM addresses remain stable as the VM is restarted, upgraded, or migrated. Virtualization administrators also have a need to control address assignments and want the ability to specify VM addresses.

After several iterations, Kube-OVN now supports:

* IP address specification at VM creation, with addresses remaining stable throughout the lifecycle of the VM.

* Random IP address assignment at VM creation, with addresses remaining stable throughout the lifecycle of the VM.

* NICs remaining fixed during VM live migration.

Specifying static IP addresses at VM creation

To assign a specific IP address to a VM at its creation time, simply add an annotation 

For VMs created this way, Kube-OVN will automatically assign the specified IP address according to the annotation field, and this address will remain stable for the remainder of the VM’s lifecycle.

https://github.com/kubeovn/kube-ovn/blob/master/docs/static-ip.md

Assigning random static IP addresses at VM creation

In some cases, the administrator does not want to manually assign an IP address each time a VM is created, but still want the address to remain fixed for the VM throughtout its lifecycle.

The ability to associate the assigned addresses with VirtualMachine instances has been introduced in Kube-OVN v1.8.3 and v1.9.1. The lifecycle of the assigned IP addresses in Kube-OVN will be aligned with that of the VirtualMachine instance, enabling a one-to-one mapping. Administrators do not need to manually assign VM addresses in order to keep them stable.

To enable this feature, simply add the following parameter to the kube-ovn-controller.

https://github.com/kubeovn/kube-ovn/issues/1297

https://github.com/kubeovn/kube-ovn/pull/1307

Stable IP addresses across VM live migration

KubeVirt's live migration faces a lot of networking challenges, especially in the fixed IP scenario, which makes it more complicated to avoid IP conflicts. KubeVirt uses the default network for state synchronization during live migration. By using the multus-cni to separate the service network from the migration network, we can manage IP address migration at the functional level.

The default network is only used for live migration and requires multus-cni to attach Kube-OVN as an attachment NIC to the VM.

Add the corresponding annotation to the VM to enable fixed IP and live migration support:

<attach>.<ns>.ovn.kubernetes.io/allow_live_migration: 'true’

KubeVirt's DHCP will set the wrong default route. You need to add an annotation:

<attach >.<ns>.ovn.kubernetes.io/default_route: 'true'

to select the correct default routing NIC.

With the above configuration, Kube-OVN will take over the transfer process of the network during the live migration and choose the right point in time for the network switchover.

https://github.com/kubeovn/kube-ovn/pull/1001

In traditional virtualization usage scenarios, multi-tenancy with VPCs is generally considered a best practice in many enterprise IT environments. However, the lack of built-in support for tenant level isolation in Kubernetes has led to shortcomings in the ability to support multi-tenancy in container networks and KubeVirt.

Kube-OVN enables multi-tenant networking in Kubernetes by introducing a new set of networking CRDs: VPC, Subnet, NAT-Gateway. The virtualization control plane in KubeVirt can manage VPCs and Subnets so that different VMs reside in different tenant networks. This enables complete multi-tenancy capabilities in virtualization scenarios.

In addition, Kube-OVN provides control knobs around LB/EIP/NAT/Route Table, etc. This enables administrators to manage a cloud native virtualization network as if it were a traditional data center network.

kube-ovn/vpc.md at master · kubeovn/kube-ovn

KubeVirt's default Pod mode network suffers from long network data paths and poor performance due to the need to adapt to CNI specifications. On the other hand, SR-IOV mode suffers from inflexible features and complex configurations.

Kube-OVN achieves high performance by directing SR-IOV devices to KubeVirt VMs through the OVS offload capability of the smart NIC. Kube-OVN also retains the address allocation and OVN logical flow table capabilities, enabling complete SDN networking and striking a good balance between performance and functionality.

Although upstream KubeVirt has no support for OVS-DPDK type networks, many users in the Kube-OVN community have independently developed KubeVirt support for OVS-DPDK . Therefore, even a normal NIC can enhance the network throughput within a VM when accelerated by OVS-DPDK.

kube-ovn/hw-offload-mellanox.md at master · kubeovn/kube-ovn

kube-ovn/hw-offload-corigine.md at master · kubeovn/kube-ovn

kube-ovn/dpdk-hybrid.md at master · kubeovn/kube-ovn

In this blog post, we described several interesting use cases and special considerations when designing the network fabric for cloud native virtualization. The KubeVirt community has contributed to a number of virtualization related features in Kube-OVN, including VM static IP addresses, multi-tenant networks and SR-IOV and OVS-DPDK. We see Kube-OVN as a great companion for KubeVirt, and when used together, they really light up the cloud native virtualization experiences. We hope more users from the KubeVirt community will try out these features and give us feedback.

KubeVirt + Kube-OVN:  Networking for Cloud Native Virtualization

With contributions from the community, the Kube-OVN team is excited to announce the release of Kube-OVN 1.8.

Within this release cycle, we focus on the underlay network enhancement, datapath latency optimization ,and further improvement on VPC functions. With 10+ function improvements and 50+ security and stability improvements, the overall stability of Kube-OVN has been testified. Thanks for the support and contribution from the coummunity!

In Kube-OVN 1.8, the underlay network implementation has been refactored to achieve more flexible network setups. A new CRD ProviderNetwork is provided to map the underlay network into container network and provide options for complex real networks requirements, including:

Host with a single network interface to achieve both manage network and underlay container network

Host with multiple network interfaces which mapping into different VLANs

Hosts in a cluster with different network interface names

Some VLANs only exist for part of hosts in the cluster

Performance has long been a challenage topic. In v1.8 we dive into the OVN flow tables and kernel internals to profile the datapath and find the bottlenecks. With the help of profile results, some aggressive optimization methods have been found. With these methods, 45% latency can be reduced under the 1byte packet latency benchmark. These methods include:

OVN logical flow re-organized to avoid some CPU consuming operation

FastPath kernel module to reduce netfilter cost

Replace veth device with ovs internal port to reduce IRQ

Re-compile ovs kernel module with ISA related optimization

The 1-byte packet benchmark result for origin and optimized version:

The 1-byte packet benchmark comparison for Kube-OVN overlay/underlay mode, Calico IPIP and noEncap mode:

As more and more users are trying to manage data center infrastructures with Kubernetes, VPC network functions in Kube-OVN are under rapid iteration. In this release, a new CRD SecurityGroup is provided to support VPC security management in VPC view.

Service support in custom VPC is also supported in this release, more L4 and L7 load balncer function is in the way.

Kubernetes and Openstack share the same OVN deployment

Manual route for multiple network interface

Kube-OVN 1.8

Kube-OVN 1.7: Hybrid overlay and underlay network, multiple ovn native network, VPC enhancement, active-active subnet gateway and more

With contributions from China Telecom, Inspur, Intel, and ByteDance The Kube-OVN team is excited to announce the release of Kube-OVN 1.7.

Within this release cycle, lots of requirements about complex network infrastructure orchestration in the real ente

rprise scene overwhelming us. We have built these abilities to resolve these complexities into Kube-OVN 1.7 including:

Pod with multiple ovn native network interface

VPC gateway with FloatingIP and NAT abilities

Previously, Overlay or Underlay is a cluster-level installation option. All subnets in a cluster must be the same type, overlay, or underlay. However, in enterprises more and more users need different types of networks for different use cases in one Kubernetes cluster. For example, run web applications in overlay network to achieve high flexibility, at the same time run middleware like db in underlay network to achieve high performance and connectivity with the external network.

In Kube-OVN 1.7, the installation network type only takes effect for the default subnet users can select network type dynamically at the subnet level. We also provide a new CRD ProviderNetwork to map the underlay network into container network and provide options for complex real network setups. e.g different nodes may belong to different physic networks, the network interface names are different across the cluster, certain underlay network only exists in a group of nodes, and so on.

With the increasing number of users who run VM in Kubernetes, the need for multiple network interface VM also increased. In the previous version, Kube-OVN only provides OVN type network to the primary interface, attachment networks have to be provisioned by other CNIs. From this version on, users can use Multus CRDs and Kube-OVN annotations to define a Pod with multiple network interfaces all provisioned by Kube-OVN. This also gives VMs on Kuberentes to run on multiple virtual networks all provided by OVN.

The VPC in 1.6 only provides the independent address space for multi-tenants. However, Pod in VPC can not connect to external networks and can not be visited outside the VPC. In 1.7 release, we provide a new CRD VpcNatGateway to provide the ability to connect VPC and external networks.

In the VpcNatGateway users can define the eips allocated to the VPC and select how to use these eips for the VPC. It provides abilities like:

: map a group of pods egress traffic to a selected eip

: map a pod ingress and egress ip to a selected eip

Kube-OVN subnet support to egress mode distributed and centralized. For centralized mode, users can select a group of nodes to act as the egress gateway. In the previous version, these node work in active-backup mode, only one node is in active status that processes the egress traffic. This node will be the bottleneck when dealing with a large volume of egress traffic. In 1.7 release, all nodes can work together at the same time, egress traffic will be distributed to all selected nodes and it will automatically check failed node and rebalance the traffic.

Kube-OVN 1.7

Recently, the Cloud Native Computing Foundation (CNCF) announced that Kube-OVN, an open-source container network project of Alauda, has officially entered the CNCF Sandbox Hosting. This is the first global open source CNI network project incorporated by CNCF, and it is also the first time that China Container Company successfully donated an independently designed and developed projects to the CNCF.

Kube-OVN is an enterprise-class cloud native Kubernetes container network orchestration system independently developed by Alauda Company. It is based on SDN network virtualization technology and provides flexible container networks for enterprises. As the first accepted open source CNI network project by CNCF Sandbox, Kube-OVN has greatly enhanced the security, operability, management and performance of Kubernetes container network by translating mature network functions in the OpenStack field to Kubernetes, integrating various characteristics such as security enhancement, intelligent operation and maintenance, hardware acceleration, etc. It brings unique value to the success of Kubernetes ecology. Kube-OVN joins CNCF sandbox will promote the development and maturity of Kubernetes operating environment solutions.

Since Kube-OVN opens source, it has harvested 700 + star on Github. Twenty-four contributors from Alauda, China Telecom, Intel, Huawei and many other companies participating in the code writing. At the same time, it has accumulated 50 + enterprise users, including many Giant companies such as Unicom, Telecom, Huawei, China Electronics, ByteDance and Rakuten (Japan). In less than two years, we achieve thousands of cluster-level large-scale enterprise projects, and overseas projects landing, as well as commercialization of the initial attempt.

Next, Kube-OVN will strenghthen community operations and launch a series of community activities. We hope to join hands with more developers and users; then combined innovative technologies with application requirements, and use codes to resolve users’actual demands so that we are able to make Kubernetes network system available and efficient, and truly release the value of open source communities.

Kube-OVN now joins CNCF as a Sandbox project

With contributions from the community, the Kube-OVN team is excited to announce the release of Kube-OVN 1.8.

Within this release cycle, we focus on the underlay network enhancement, datapath latency optimization ,and further improvement on VPC functions. With 10+ function improvements and 50+ security and stability improvements, the overall stability of Kube-OVN has been testified. Thanks for the support and contribution from the coummunity!

Underlay Network Enhancement

In Kube-OVN 1.8, the underlay network implementation has been refactored to achieve more flexible network setups. A new CRD ProviderNetwork is provided to map the underlay network into container network and provide options for complex real networks requirements, including:

Host with a single network interface to achieve both manage network and underlay container network

Host with multiple network interfaces which mapping into different VLANs

Hosts in a cluster with different network interface names

Some VLANs only exist for part of hosts in the cluster

Multicast in the network

Overlay and underlay networks co-exist

For more information, please read Vlan Support

Datapath Latency Optimization

Performance has long been a challenage topic. In v1.8 we dive into the OVN flow tables and kernel internals to profile the datapath and find the bottlenecks. With the help of profile results, some aggressive optimization methods have been found. With these methods, 45% latency can be reduced under the 1byte packet latency benchmark. These methods include:

OVN logical flow re-organized to avoid some CPU consuming operation

FastPath kernel module to reduce netfilter cost

Replace veth device with ovs internal port to reduce IRQ

Re-compile ovs kernel module with ISA related optimization

For more information, please read Performance Tunning

The 1-byte packet benchmark result for origin and optimized version:



The 1-byte packet benchmark comparison for Kube-OVN overlay/underlay mode, Calico IPIP and noEncap mode:



VPC Enhancement

As more and more users are trying to manage data center infrastructures with Kubernetes, VPC network functions in Kube-OVN are under rapid iteration. In this release, a new CRD SecurityGroup is provided to support VPC security management in VPC view.



Service support in custom VPC is also supported in this release, more L4 and L7 load balncer function is in the way.

For more information, please read VPC Usage

What's more

Kubernetes and Openstack share the same OVN deployment

Pod level mirror control

Manual route for multiple network interface

Dynamically modify tunnel IP

New OVN 21.03

Getting Started

New to Kube-OVN? Follow the Installation Guide.

Release

Release Note

As the creators of Kube-OVN, Alauda has the experience and expertise to help make your journey successful with Kube-OVN in production.

Enterprise

 Features

The most advanced Kubernetes feature set

Kube-OVN integrates the OVN-based Network Virtualization with Kubernetes. It offers an advanced Container Network Fabric that is feature rich and enterprise friendly.

 Looking to contribute?

Here is a quick development guide to help you get started with Kube-OVN.

 Meet us at [KubeCon + CloudNativeCon Europe 2021]

The CNCF’s flagship conference gathers adopters and technologists from leading open source and cloud native communities virtually from May 4 – 7. Join us at the Kube-OVN Project Office Hours 

Thu, May 6, 9:00 AM (CEST) / Fri, May 7, 9:00 AM (CEST)

 

The Most Advanced Kubernetes Network Fabric for Enterprises

Recently, the Cloud Native Computing Foundation (CNCF) announced that Kube-OVN, an open-source container network project of Alauda, has officially entered the CNCF Sandbox Hosting. This is the first global open source CNI network project incorporated by CNCF, and it is also the first time that China Container Company successfully donated an independently designed and developed projects to the CNCF.



Kube-OVN is an enterprise-class cloud native Kubernetes container network orchestration system independently developed by Alauda Company. It is based on SDN network virtualization technology and provides flexible container networks for enterprises. As the first accepted open source CNI network project by CNCF Sandbox, Kube-OVN has greatly enhanced the security, operability, management and performance of Kubernetes container network by translating mature network functions in the OpenStack field to Kubernetes, integrating various characteristics such as security enhancement, intelligent operation and maintenance, hardware acceleration, etc. It brings unique value to the success of Kubernetes ecology. Kube-OVN joins CNCF sandbox will promote the development and maturity of Kubernetes operating environment solutions.

Since Kube-OVN opens source, it has harvested 700 + star on Github. Twenty-four contributors from Alauda, China Telecom, Intel, Huawei and many other companies participating in the code writing. At the same time, it has accumulated 50 + enterprise users, including many Giant companies such as Unicom, Telecom, Huawei, China Electronics, ByteDance and Rakuten (Japan). In less than two years, we achieve thousands of cluster-level large-scale enterprise projects, and overseas projects landing, as well as commercialization of the initial attempt.

Next, Kube-OVN will strenghthen community operations and launch a series of community activities. We hope to join hands with more developers and users; then combined innovative technologies with application requirements, and use codes to resolve users’actual demands so that we are able to make Kubernetes network system available and efficient, and truly release the value of open source communities.

Kube-OVN Website: http://www.Kube-ovn.io
GitHub: https://github.com/alauda/kube-ovn

Kube-OVN 1.7: Hybrid overlay and underlay network, multiple ovn native network, VPC enhancement, active-active subnet gateway and more



With contributions from China Telecom, Inspur, Intel, and ByteDance The Kube-OVN team is excited to announce the release of Kube-OVN 1.7.

Within this release cycle, lots of requirements about complex network infrastructure orchestration in the real ente

rprise scene overwhelming us. We have built these abilities to resolve these complexities into Kube-OVN 1.7 including:

Hybrid overlay and underlay network

Pod with multiple ovn native network interface

VPC gateway with FloatingIP and NAT abilities

Active-Active subnet gateway

Hybrid overlay and underlay network

Previously, Overlay or Underlay is a cluster-level installation option. All subnets in a cluster must be the same type, overlay, or underlay. However, in enterprises more and more users need different types of networks for different use cases in one Kubernetes cluster. For example, run web applications in overlay network to achieve high flexibility, at the same time run middleware like db in underlay network to achieve high performance and connectivity with the external network.

In Kube-OVN 1.7, the installation network type only takes effect for the default subnet users can select network type dynamically at the subnet level. We also provide a new CRD ProviderNetwork to map the underlay network into container network and provide options for complex real network setups. e.g different nodes may belong to different physic networks, the network interface names are different across the cluster, certain underlay network only exists in a group of nodes, and so on.

For more information, please read Vlan Support

Pod with multiple ovn native network interface

With the increasing number of users who run VM in Kubernetes, the need for multiple network interface VM also increased. In the previous version, Kube-OVN only provides OVN type network to the primary interface, attachment networks have to be provisioned by other CNIs. From this version on, users can use Multus CRDs and Kube-OVN annotations to define a Pod with multiple network interfaces all provisioned by Kube-OVN. This also gives VMs on Kuberentes to run on multiple virtual networks all provided by OVN.

For more information, please read Multi network interace

VPC gateway with FloatingIP and NAT abilities

The VPC in 1.6 only provides the independent address space for multi-tenants. However, Pod in VPC can not connect to external networks and can not be visited outside the VPC. In 1.7 release, we provide a new CRD VpcNatGateway to provide the ability to connect VPC and external networks.

In the VpcNatGateway users can define the eips allocated to the VPC and select how to use these eips for the VPC. It provides abilities like:

SNAT: map a group of pods egress traffic to a selected eip

DNAT: map an eip IP:Porrt to a Pod IP:Port

FloatingIP: map a pod ingress and egress ip to a selected eip

For more information, please read VPC Usage

Active-Active subnet gateway

Kube-OVN subnet support to egress mode distributed and centralized. For centralized mode, users can select a group of nodes to act as the egress gateway. In the previous version, these node work in active-backup mode, only one node is in active status that processes the egress traffic. This node will be the bottleneck when dealing with a large volume of egress traffic. In 1.7 release, all nodes can work together at the same time, egress traffic will be distributed to all selected nodes and it will automatically check failed node and rebalance the traffic.

12

Getting Started

New to Kube-OVN? Follow the Installation Guide.

Release

Release Note





As cloud native technologies converge to data centers and the infrastructure, more and more enterprises are using Kubernetes and KubeVirt to run virtualized workloads and manage both virtual machines and containers from a unified control plane. However, the usage scenarios of VMs are significantly different from those of containers. At the same time, the emerging container networking solutions are not designed for virtualization scenarios - the feature set and the performance characteristics are quite different from those of the traditional data center networks. Networking has become the bottleneck of adopting cloud native virtualization.

Kube-OVN, as its name implies, is an integration of the OVN/OVS based networking with Kubernetes. Since OVN and OVS have been widely used in traditional virtualization scenarios, Kube-OVN has attracted a lot of attention from the KubeVirt community since it was open sourced. Some early adopters of KubeVirt have further improved the networking capabilities of Kube-OVN for their use cases. This resulted in a large number of new and optimized Kube-OVN features specifically targeted towards solving some of the networking challenges faced by KubeVirt.



VM Static IP Addresses

Container networks usually do not require that IP addresses be fixed. In VM usage scenarios, however, the IP addresses are often used as the primary access method. Users typically require that the VM addresses remain stable as the VM is restarted, upgraded, or migrated. Virtualization administrators also have a need to control address assignments and want the ability to specify VM addresses.

After several iterations, Kube-OVN now supports:

* IP address specification at VM creation, with addresses remaining stable throughout the lifecycle of the VM.

* Random IP address assignment at VM creation, with addresses remaining stable throughout the lifecycle of the VM.

* NICs remaining fixed during VM live migration.



Specifying static IP addresses at VM creation

To assign a specific IP address to a VM at its creation time, simply add an annotation ovn.kubernetes.io/ip_addressto the template of KubeVirt’s VirtualMachine resource:

apiVersion: kubevirt.io/v1alp

For VMs created this way, Kube-OVN will automatically assign the specified IP address according to the annotation field, and this address will remain stable for the remainder of the VM’s lifecycle.

https://github.com/kubeovn/kube-ovn/blob/master/docs/static-ip.md



Assigning random static IP addresses at VM creation

In some cases, the administrator does not want to manually assign an IP address each time a VM is created, but still want the address to remain fixed for the VM throughtout its lifecycle.

The ability to associate the assigned addresses with VirtualMachine instances has been introduced in Kube-OVN v1.8.3 and v1.9.1. The lifecycle of the assigned IP addresses in Kube-OVN will be aligned with that of the VirtualMachine instance, enabling a one-to-one mapping. Administrators do not need to manually assign VM addresses in order to keep them stable.

To enable this feature, simply add the following parameter to the kube-ovn-controller.

--keep-vm-ip=true

https://github.com/kubeovn/kube-ovn/issues/1297https://github.com/kubeovn/kube-ovn/pull/1307



Stable IP addresses across VM live migration

KubeVirt's live migration faces a lot of networking challenges, especially in the fixed IP scenario, which makes it more complicated to avoid IP conflicts. KubeVirt uses the default network for state synchronization during live migration. By using the multus-cni to separate the service network from the migration network, we can manage IP address migration at the functional level.

The default network is only used for live migration and requires multus-cni to attach Kube-OVN as an attachment NIC to the VM.

Add the corresponding annotation to the VM to enable fixed IP and live migration support:

<attach>.<ns>.ovn.kubernetes.io/allow_live_migration: 'true’

KubeVirt's DHCP will set the wrong default route. You need to add an annotation:

<attach >.<ns>.ovn.kubernetes.io/default_route: 'true'

to select the correct default routing NIC.







With the above configuration, Kube-OVN will take over the transfer process of the network during the live migration and choose the right point in time for the network switchover.

https://github.com/kubeovn/kube-ovn/pull/1001



Multi-tenant Networks

In traditional virtualization usage scenarios, multi-tenancy with VPCs is generally considered a best practice in many enterprise IT environments. However, the lack of built-in support for tenant level isolation in Kubernetes has led to shortcomings in the ability to support multi-tenancy in container networks and KubeVirt.

Kube-OVN enables multi-tenant networking in Kubernetes by introducing a new set of networking CRDs: VPC, Subnet, NAT-Gateway. The virtualization control plane in KubeVirt can manage VPCs and Subnets so that different VMs reside in different tenant networks. This enables complete multi-tenancy capabilities in virtualization scenarios.

In addition, Kube-OVN provides control knobs around LB/EIP/NAT/Route Table, etc. This enables administrators to manage a cloud native virtualization network as if it were a traditional data center network.





kube-ovn/vpc.md at master · kubeovn/kube-ovn



SR-IOV and OVS-DPDK support

KubeVirt's default Pod mode network suffers from long network data paths and poor performance due to the need to adapt to CNI specifications. On the other hand, SR-IOV mode suffers from inflexible features and complex configurations.

Kube-OVN achieves high performance by directing SR-IOV devices to KubeVirt VMs through the OVS offload capability of the smart NIC. Kube-OVN also retains the address allocation and OVN logical flow table capabilities, enabling complete SDN networking and striking a good balance between performance and functionality.



Although upstream KubeVirt has no support for OVS-DPDK type networks, many users in the Kube-OVN community have independently developed KubeVirt support for OVS-DPDK . Therefore, even a normal NIC can enhance the network throughput within a VM when accelerated by OVS-DPDK.



kube-ovn/hw-offload-mellanox.md at master · kubeovn/kube-ovn

kube-ovn/hw-offload-corigine.md at master · kubeovn/kube-ovn

kube-ovn/dpdk-hybrid.md at master · kubeovn/kube-ovn



To sum up

In this blog post, we described several interesting use cases and special considerations when designing the network fabric for cloud native virtualization. The KubeVirt community has contributed to a number of virtualization related features in Kube-OVN, including VM static IP addresses, multi-tenant networks and SR-IOV and OVS-DPDK. We see Kube-OVN as a great companion for KubeVirt, and when used together, they really light up the cloud native virtualization experiences. We hope more users from the KubeVirt community will try out these features and give us feedback.



News

Contact Us

Send us a message

News

Contact us

Contact Us

Send us a message