Feature Overview (aka. Goal Summary)  

This feature defines GA for Egress Service support for OpenShift clusters operating in Local Gateway Mode (LGM), enabling cluster administrators to explicitly control how egress traffic from pods behind a LoadBalancer Service is sourced and routed when traffic exits the cluster directly from the hosting node.

Using the EgressService custom resource (CR), administrators can configure egress traffic so that:

• Outbound traffic from pods behind a LoadBalancer Service uses the LoadBalancer service IP as the source IP, presenting a consistent ingress and egress identity.

• Egress traffic is routed through a non-default node network, such as a VRF-backed interface, instead of the default node routing table.

In Local Gateway Mode, OVN-Kubernetes programs host-level policy routing rules on the node that hosts the service endpoints, ensuring that traffic exits the node using the correct routing table and network interface without traversing a shared gateway.

Goals (aka. expected user outcomes)

• Enable deterministic, node-local egress routing for services in Local Gateway Mode.

• Allow LoadBalancer-backed applications to present a single, stable IP identity for both ingress and egress traffic.

• Support per-service egress routing via alternate node networks, such as VRFs or secondary interfaces.

• Preserve the performance and simplicity benefits of Local Gateway Mode while introducing controlled egress behavior.

• Integrate seamlessly with OVN-Kubernetes using native Linux policy routing on individual nodes.

Requirements (aka. Acceptance Criteria):

Functional Requirements

• Support the EgressService custom resource for clusters configured in Local Gateway Mode.

• Ensure that:

• • Egress routing rules are applied only on the node(s) hosting the service endpoints.

• • The Network field in EgressService selects the routing table used for service egress traffic.

• Automatically configure host-level ip rules for:

• • Service ClusterIP

• • Service endpoint pod IPs

• Ensure correct handling of:

• • Outbound egress traffic from service endpoints

• • Reply traffic for inbound LoadBalancer connections that traverse ClusterIP before exiting the node

• Dynamically update or remove routing rules as:

• • Service endpoints change

• • Node placement changes

• • EgressService configuration is modified or removed

Non-Functional Requirements

• Must not require manual node-level configuration by administrators.

• Must preserve Local Gateway Mode characteristics, including node-local egress and reduced encapsulation.

• Must provide clear observability using standard Linux networking tools (ip rule, ip route, etc.).

• Must not impact services or pods that do not opt into Egress Service behavior.

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Use Cases (Optional):

• Node-Local Egress with Stable Source IP
  An application deployed in Local Gateway Mode requires all outbound traffic to originate from the LoadBalancer service IP, ensuring symmetry between ingress and egress traffic for external systems.

• VRF-Based Egress Isolation Per Node
  Each node is configured with one or more VRFs or secondary interfaces, and services require egress traffic to exit through a specific VRF while maintaining node-local routing.

• High-Performance or Low-Latency Environments
  Customers using Local Gateway Mode for performance reasons need direct node egress without shared gateways, while still enforcing predictable service-level egress behavior.

• Service-Oriented Network Control
  Platform teams define egress behavior at the service level, allowing application teams to consume controlled networking without managing pod-level routing or policies.

Questions to Answer (Optional):

Out of Scope

Background

In Local Gateway Mode, OVN-Kubernetes routes pod egress traffic directly from the node hosting the pod, bypassing centralized or shared gateway nodes. While this provides performance and simplicity benefits, it also means that egress traffic typically follows the default node routing table and may use node IPs or dynamically SNATed addresses.

Egress Service augments Local Gateway Mode by introducing policy-based routing on individual nodes. OVN-Kubernetes installs ip rule entries that match traffic sourced from:

• The LoadBalancer Service ClusterIP

• The IP addresses of service endpoint pods

These rules steer matching traffic into a specific routing table, typically associated with a VRF or secondary interface. Additional rules ensure that return traffic for inbound LoadBalancer connections is correctly marked early in the packet path so that it exits the node using the same routing table.

This approach preserves Local Gateway Mode’s node-local egress model while enabling service-aware routing decisions.

Customer Considerations

• Node Affinity and Endpoint Placement
  In Local Gateway Mode, egress behavior is inherently node-scoped. Customers should ensure that service endpoint placement aligns with network availability and VRF configuration on each node.

• Reduced Load Balancer Distribution
  When using the LoadBalancer service IP as the egress source, ingress and egress traffic may be constrained to fewer nodes, depending on endpoint placement and load balancer behavior.

• Operational Complexity
  Egress Service relies on host-level policy routing, which may require advanced networking knowledge to troubleshoot in complex environments.

• Network Prerequisites
  Using alternate networks for egress assumes:

• • VRFs or secondary interfaces are preconfigured on nodes

• • Appropriate routing tables and upstream connectivity exist

• Service-Level Scope
  Egress Service applies at the service level, not per pod or namespace. Customers should evaluate whether this granularity matches their operational and application requirements.

Documentation Considerations

Interoperability Considerations