What if you need to connect your Kubernetes workloads to a physical network, or more than one network? You can attach multiple network interfaces using Multus, but you'll need to specify every detail.

Virtualized workloads have extra requirements from the network, given their stateful nature. For instance, they require their IP addresses to be preserved during their life-cycle, and also during live migration. Currently, since the network does not provide these features, the network-admin must deploy and configure extra services in the network.

But, what if you had a SDN (software defined network) to take care of that, and while doing so abstract how to bridge hybrid infrastructure, from bare metal, to virtualized, to public cloud environments?

Join us to learn and understand how these features can be used to provide Kubernetes workloads access to physical networks (protected by network policies) through a live demo. The multi-network feature is paramount to delivering non-cloud deployments with enough flexibility for their use cases: connecting to the physical networks of their data-centers is extremely important, since some of their services are not deployed in Kubernetes. For security reasons, access to/from the workloads running in Kubernetes should be governed by network policies. OVN-K multi-networking also provides an opinionated network fabric that can automate what users previously had to specify in detail, simplifying configuration and cost of operation for cloud providers and admins.

While any pod will benefit from the above, KubeVirt workloads (VMs) will get more juice out of this SDN implementation. While the feature-set available today is good enough to allow users of traditional virtualization platforms to lift-and-shift their existing workloads into KubeVirt, the features in the pipeline are game changers: VM workloads requires things from the network a pod wouldn’t normally ask for, such as preserving the IP during its life cycle, and also during migration (so the established TCP connection can survive being moved to a different Kubernetes node). These features are a really good match for OVN-Kubernetes since OVN already provides some migration-centered improvements used on other platforms (i.e. Openstack) which can be re-used to provide seamless live-migration of the VM workloads.