Skip to content

Latest commit

 

History

History
111 lines (97 loc) · 5.67 KB

configuring-localnet-switched-topology.adoc

File metadata and controls

111 lines (97 loc) · 5.67 KB

Configuration for a localnet switched topology

The switched localnet topology interconnects the workloads created as Network Attachment Definitions (NADs) through a cluster-wide logical switch to a physical network.

You must map an additional network to the OVN bridge to use it as an OVN-Kubernetes additional network. Bridge mappings allow network traffic to reach the physical network. A bridge mapping associates a physical network name, also known as an interface label, to a bridge created with Open vSwitch (OVS).

You can create an NodeNetworkConfigurationPolicy object, part of the nmstate.io/v1 API group, to declaratively create the mapping. This API is provided by the NMState Operator. By using this API you can apply the bridge mapping to nodes that match your specified nodeSelector expression, such as node-role.kubernetes.io/worker: ''.

When attaching an additional network, you can either use the existing br-ex bridge or create a new bridge. Which approach to use depends on your specific network infrastructure.

  • If your nodes include only a single network interface, you must use the existing bridge. This network interface is owned and managed by OVN-Kubernetes and you must not remove it from the br-ex bridge or alter the interface configuration. If you remove or alter the network interface, your cluster network will stop working correctly.

  • If your nodes include several network interfaces, you can attach a different network interface to a new bridge, and use that for your additional network. This approach provides for traffic isolation from your primary cluster network.

The localnet1 network is mapped to the br-ex bridge in the following example:

Example mapping for sharing a bridge
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: mapping (1)
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: '' (2)
  desiredState:
    ovn:
      bridge-mappings:
      - localnet: localnet1 (3)
        bridge: br-ex (4)
        state: present (5)

  1. The name for the configuration object.

  2. A node selector that specifies the nodes to apply the node network configuration policy to.

  3. The name for the additional network from which traffic is forwarded to the OVS bridge. This additional network must match the name of the spec.config.name field of the NetworkAttachmentDefinition CRD that defines the OVN-Kubernetes additional network.

  4. The name of the OVS bridge on the node. This value is required only if you specify state: present.

  5. The state for the mapping. Must be either present to add the bridge or absent to remove the bridge. The default value is present.

In the following example, the localnet2 network interface is attached to the ovs-br1 bridge. Through this attachment, the network interface is available to the OVN-Kubernetes network plugin as an additional network.

Example mapping for nodes with multiple interfaces
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ovs-br1-multiple-networks (1)
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: '' (2)
  desiredState:
    interfaces:
    - name: ovs-br1 (3)
      description: |-
        A dedicated OVS bridge with eth1 as a port
        allowing all VLANs and untagged traffic
      type: ovs-bridge
      state: up
      bridge:
        allow-extra-patch-ports: true
        options:
          stp: false
          mcast-snooping-enable: true (4)
        port:
        - name: eth1 (5)
    ovn:
      bridge-mappings:
      - localnet: localnet2 (6)
        bridge: ovs-br1 (7)
        state: present (8)

  1. The name for the configuration object.

  2. A node selector that specifies the nodes to apply the node network configuration policy to.

  3. A new OVS bridge, separate from the default bridge used by OVN-Kubernetes for all cluster traffic.

  4. The state of multicast snooping. When enabled, multicast snooping prevents network devices from flooding multicast traffic to all members of the network. By default, an OVS bridge does not enable multicast snooping. The default value is`false`.

  5. A network device on the host system to associate with this new OVS bridge.

  6. The name for the additional network from which traffic is forwarded to the OVS bridge. This additional network must match the name of the spec.config.name field of the NetworkAttachmentDefinition CRD that defines the OVN-Kubernetes additional network.

  7. The name of the OVS bridge on the node. This value is required only if you specify state: present.

  8. The state for the mapping. Must be either present to add the bridge or absent to remove the bridge. The default value is present.

This declarative approach is recommended because the NMState Operator applies additional network configuration to all nodes specified by the node selector automatically and transparently.

The following JSON example configures a localnet secondary network:

{
  "cniVersion": "0.3.1",
  "name": "ns1-localnet-network",
  "type": "ovn-k8s-cni-overlay",
  "topology":"localnet",
  "subnets": "202.10.130.112/28",
  "vlanID": 33,
  "mtu": 1500,
  "netAttachDefName": "ns1/localnet-network"
  "excludeSubnets": "10.100.200.0/29"
}