OpenShift Egress IP Cannot Fail Over Across Subnets
An OpenShift 4.12 cluster uses OVN-Kubernetes. Worker nodes are split across two subnets: worker-1 and worker-2 are in 10.20.1.0/24, and worker-3 is in 10.20.2.0/24. The namespace payments has egress IP 10.20.1.50. The external firewall allows only 10.20.1.50 to a payment gateway. worker-1 and worker-3 are labeled k8s.ovn.org/egress-assignable; worker-2 is not. During a control-plane upgrade, worker-1 is drained. The egress IP does not move usefully: oc get egressip shows the IP without a working node assignment, and payments pods fall back to their node IPs. The gateway rejects those connections. worker-3 was expected to take over. The upstream router has a 300-second ARP cache. The team cannot change the firewall or the gateway source-IP requirement. They can relabel nodes, add a second egress IP, or change node placement.
1. Why did the egress IP not fail over usefully to worker-3?
Read the worked answer
OVN-Kubernetes assigns an egress IP only to a node whose primary network is in the same subnet as that egress IP. 10.20.1.50 belongs to 10.20.1.0/24, so worker-3 at 10.20.2.13 is not a valid host even though it has the egress-assignable label. Draining worker-1 therefore leaves no eligible node in 10.20.1.0/24. Pods on remaining nodes fall back to node IPs, and the gateway rejects them. The 300-second ARP cache is secondary; the primary issue is subnet eligibility.
2. Evaluate the three proposed fixes: relabel worker-3, add a second egress IP, or change node placement.
Read the worked answer
Labeling worker-3 again does nothing. Adding a second egress IP in 10.20.2.0/24 could restore egress, but the firewall only permits 10.20.1.50, so it violates the constraint. The correct move is to make worker-2 egress-assignable because it is in 10.20.1.0/24, giving the EgressIP object a second eligible node in the same subnet. Moving worker-3 into 10.20.1.0/24 also works but is a larger change. Check oc get egressip, oc describe egressip, and node labels after the change.
3. Recommend a change that preserves the firewall constraint and provides real failover.
Read the worked answer
Relabel worker-2 with k8s.ovn.org/egress-assignable, keep worker-1 labeled, and verify that the EgressIP object can move 10.20.1.50 between two nodes in 10.20.1.0/24. Test by draining worker-1 and confirming the gateway still sees 10.20.1.50. Keep worker-3 out of the egress-assignable set unless its subnet changes. Add a monitoring check that fails if fewer than two egress-assignable nodes share the egress IP subnet.