Topology

By default networks are isolated: endpoints in different networks cannot reach each other. On top of that isolation you can model arbitrary topologies between networks, from VRF-style meshes to anything beyond. The same relations apply between pod networks and between a pod network and an external network.

Two resources express topology:

• NetworkRoutingPolicy — a source network may route to a destination network.
• ServiceRoutingPolicy — a source network may route to the services of another network.

Both select source and destination by label (src, dest), so one policy can relate many networks at once.

Network peering

A NetworkRoutingPolicy is directional: traffic may be initiated from the source toward the destination, not the other way around. Return traffic of an established flow is always allowed back via conntrack, so a reverse policy is only needed for the destination to initiate its own connections.

apiVersion: lace-cni.io/v1alpha1
kind: NetworkRoutingPolicy
spec:
  src:
    matchLabels: { tier: frontend }
  dest:
    matchLabels: { tier: backend }

When networks share a label, a single resource can select that label on both sides to create a bidirectional peering, letting every network in the group reach every other in both directions:

apiVersion: lace-cni.io/v1alpha1
kind: NetworkRoutingPolicy
spec:
  src:
    matchLabels: { vrf: prod }
  dest:
    matchLabels: { vrf: prod }

Note

The prefixes of the networks reachable from a single source may not overlap: a destination address must resolve to exactly one network. Multiple sources may still route to the same destination, since conntrack keeps their return flows distinct.

NetworkRoutingPolicy fields

• spec.src — the source networks, by name or by matchLabels/matchExpressions.
• spec.dest — the destination networks, selected the same way.
• spec.masqueradeEgress — source-NATs traffic egressing to the destination behind the node’s address, so the destination sees the node rather than the originating pod. Used for traffic leaving the cluster via an external network.

Service peering

A network’s services are reachable through their VIP only. Peering to a service grants reachability to the VIP, not to the backing endpoints, which stay isolated and cannot be addressed directly. Use a ServiceRoutingPolicy if all you need to reach is behind a service, instead of peering the entire network.

Service reachability comes from either:

• NetworkRoutingPolicy — peering to a network implicitly makes that network’s services reachable. No separate policy is needed.
• ServiceRoutingPolicy — reach a network’s services without peering to the network itself. The source can use the VIPs but cannot route to the network’s pods.

apiVersion: lace-cni.io/v1alpha1
kind: ServiceRoutingPolicy
spec:
  src:
    matchLabels: { tier: frontend }
  dest:
    name: payments
    namespaceSelector:
      matchLabels: { team: checkout }

The namespaceSelector nested under dest further scopes the destination to services in namespaces whose labels match. It matches on namespace labels only; omitting it admits services from every namespace.

Tip

Because service traffic is matched on the VIP, a ServiceRoutingPolicy’s destination may overlap the prefixes of networks the source already peers with. Reaching specific services never collides with the non-overlap rule for peered networks.

ServiceRoutingPolicy fields

• spec.src — the source networks, by name or by matchLabels/matchExpressions.
• spec.dest — the destination services, selected the same way, with an optional nested namespaceSelector.
• spec.dest.namespaceSelector — restricts the destination to services in namespaces whose labels match. Matches on namespace labels only; omitted selects every namespace.

See also

• Networks — network isolation and how pods are bound into a network.
• External networks — routing to and from networks outside the cluster.