Networking service¶

Mirantis OpenStack for Kubernetes (MOSK) Networking service, represented by the OpenStack Neutron service, provides workloads with Connectivity-as-a-Service enabling instances to communicate with each other and the outside world.

The API provided by the service abstracts all the nuances of implementing a virtual network infrastructure on top of your own physical network infrastructure. The service allows cloud users to create advanced virtual network topologies that may include load balancing, virtual private networking, traffic filtering, and other services.

MOSK Networking service supports Open vSwitch and Tungsten Fabric SDN technologies as back ends.

MOSK offers Neutron as a part of its core setup. You can configure the service through the spec:features:neutron section of the OpenStackDeployment custom resource.

Tunnel interface¶

Parameter	`features:neutron:tunnel_interface`
Usage	Defines the name of the NIC device on the actual host that will be used for Neutron. Mirantis recommend setting up your Kubernetes hosts in such a way that networking is configured identically on all of them, and names of the interfaces serving the same purpose or plugged into the same network are consistent across all physical nodes.

Parameter

features:neutron:tunnel_interface

Usage

Defines the name of the NIC device on the actual host that will be used for Neutron.

Mirantis recommend setting up your Kubernetes hosts in such a way that networking is configured identically on all of them, and names of the interfaces serving the same purpose or plugged into the same network are consistent across all physical nodes.

DNS servers¶

Parameter	`features:neutron:dns_servers`
Usage	Defines the list of IPs of DNS servers that are accessible from virtual networks. Used as default DNS servers for VMs.

External networks¶

Parameter	`features:neutron:external_networks`
Usage	Contains the data structure that defines external (provider) networks on top of which the Neutron networking will be created.

Floating IP networks¶

Parameter	`features:neutron:floating_network`
Usage	If enabled, must contain the data structure defining the floating IP network that will be created for Neutron to provide external access to your Nova instances.

Networking service known limitations¶

DVR incompatibility with ARP announcements and VRRP¶

Due to the known issue #1774459 in the upstream implementation, Mirantis does not recommend using Distributed Virtual Routing (DVR) routers in the same networks as load balancers or other applications that utilize the Virtual Router Redundancy Protocol (VRRP) such as Keepalived. The issue prevents the DVR functionality from working correctly with network protocols that rely on the Address Resolution Protocol (ARP) announcements such as VRRP.

The issue occurs when updating permanent ARP entries for allowed_address_pair IP addresses in DVR routers since DVR performs the ARP table update through the control plane and does not allow any ARP entry to leave the node to prevent the router IP/MAC from contaminating the network.

This results in various network failover mechanisms not functioning in virtual networks that have a distributed virtual router plugged in. For instance, the default back end for MOSK Load Balancing service, represented by OpenStack Octavia with the OpenStack Amphora back end when deployed in the HA mode in a DVR-connected network, is not able to redirect the traffic from a failed active service instance to a standby one without interruption.