As a cluster administrator, you can configure the OVN-Kubernetes default Container Network Interface (CNI) network provider to assign one or more egress IP addresses to a namespace, or to specific pods in a namespace.
The OpenShift Container Platform egress IP address functionality allows you to ensure that the traffic from one or more pods in one or more namespaces has a consistent source IP address for services outside the cluster network.
For example, you might have a pod that periodically queries a database that is hosted on a server outside of your cluster. To enforce access requirements for the server, a packet filtering device is configured to allow traffic only from specific IP addresses. To ensure that you can reliably allow access to the server from only that specific pod, you can configure a specific egress IP address for the pod that makes the requests to the server.
An egress IP address is implemented as an additional IP address on the primary network interface of a node and must be in the same subnet as the primary IP address of the node. The additional IP address must not be assigned to any other node in the cluster.
In some cluster configurations, application pods and ingress router pods run on the same node. If you configure an egress IP address for an application project in this scenario, the IP address is not used when you send a request to a route from the application project.
Support for the egress IP address functionality on various platforms is summarized in the following table:
The egress IP address implementation is not compatible with Amazon Web Services (AWS), Azure Cloud, or any other public cloud platform incompatible with the automatic layer 2 network manipulation required by the egress IP feature.
Red Hat OpenStack Platform (RHOSP)
To assign one or more egress IPs to a namespace or specific pods in a namespace, the following conditions must be satisfied:
At least one node in your cluster must have the
k8s.ovn.org/egress-assignable: "" label.
EgressIP object exists that defines one or more egress IP addresses to use as the source IP address for traffic leaving the cluster from pods in a namespace.
If you create
To ensure that egress IP addresses are widely distributed across nodes in the cluster, always apply the label to the nodes you intent to host the egress IP addresses before creating any
When creating an
EgressIP object, the following conditions apply to nodes that are labeled with the
k8s.ovn.org/egress-assignable: "" label:
An egress IP address is never assigned to more than one node at a time.
An egress IP address is equally balanced between available nodes that can host the egress IP address.
spec.EgressIPs array in an
EgressIP object specifies more than one IP address, the following conditions apply:
No node will ever host more than one of the specified IP addresses.
Traffic is balanced roughly equally between the specified IP addresses for a given namespace.
If a node becomes unavailable, any egress IP addresses assigned to it are automatically reassigned, subject to the previously described conditions.
When a pod matches the selector for multiple
EgressIP objects, there is no guarantee which of the egress IP addresses that are specified in the
EgressIP objects is assigned as the egress IP address for the pod.
Additionally, if an
EgressIP object specifies multiple egress IP addresses, there is no guarantee which of the egress IP addresses might be used. For example, if a pod matches a selector for an
EgressIP object with two egress IP addresses,
10.10.20.2, either might be used for each TCP connection or UDP conversation.
The following diagram depicts an egress IP address configuration. The diagram describes four pods in two different namespaces running on three nodes in a cluster. The nodes are assigned IP addresses from the
192.168.126.0/18 CIDR block on the host network.
Both Node 1 and Node 3 are labeled with
k8s.ovn.org/egress-assignable: "" and thus available for the assignment of egress IP addresses.
The dashed lines in the diagram depict the traffic flow from pod1, pod2, and pod3 traveling through the pod network to egress the cluster from Node 1 and Node 3. When an external service receives traffic from any of the pods selected by the example
EgressIP object, the source IP address is either
192.168.126.102. The traffic is balanced roughly equally between these two nodes.
The following resources from the diagram are illustrated in detail:
The namespaces are defined in the following manifest:
apiVersion: v1 kind: Namespace metadata: name: namespace1 labels: env: prod --- apiVersion: v1 kind: Namespace metadata: name: namespace2 labels: env: prod
EgressIP object describes a configuration that selects all pods in any namespace with the
env label set to
prod. The egress IP addresses for the selected pods are
apiVersion: k8s.ovn.org/v1 kind: EgressIP metadata: name: egressips-prod spec: egressIPs: - 192.168.126.10 - 192.168.126.102 namespaceSelector: matchLabels: env: prod status: items: - node: node1 egressIP: 192.168.126.10 - node: node3 egressIP: 192.168.126.102
For the configuration in the previous example, OpenShift Container Platform assigns both egress IP addresses to the available nodes. The
status field reflects whether and where the egress IP addresses are assigned.
The following YAML describes the API for the
EgressIP object. The scope of the object is cluster-wide; it is not created in a namespace.
apiVersion: k8s.ovn.org/v1 kind: EgressIP metadata: name: <name> (1) spec: egressIPs: (2) - <ip_address> namespaceSelector: (3) ... podSelector: (4) ...
|1||The name for the
|2||An array of one or more IP addresses.|
|3||One or more selectors for the namespaces to associate the egress IP addresses with.|
|4||Optional: One or more selectors for pods in the specified namespaces to associate egress IP addresses with. Applying these selectors allows for the selection of a subset of pods within a namespace.|
The following YAML describes the stanza for the namespace selector:
namespaceSelector: (1) matchLabels: <label_name>: <label_value>
|1||One or more matching rules for namespaces. If more than one match rule is provided, all matching namespaces are selected.|
The following YAML describes the optional stanza for the pod selector:
podSelector: (1) matchLabels: <label_name>: <label_value>
|1||Optional: One or more matching rules for pods in the namespaces that match the specified
In the following example, the
EgressIP object associates the
192.168.126.102 egress IP addresses with pods that have the
app label set to
web and are in the namespaces that have the
env label set to
apiVersion: k8s.ovn.org/v1 kind: EgressIP metadata: name: egress-group1 spec: egressIPs: - 192.168.126.11 - 192.168.126.102 podSelector: matchLabels: app: web namespaceSelector: matchLabels: env: prod
In the following example, the
EgressIP object associates the
192.168.127.40 egress IP addresses with any pods that do not have the
environment label set to
apiVersion: k8s.ovn.org/v1 kind: EgressIP metadata: name: egress-group2 spec: egressIPs: - 192.168.127.30 - 192.168.127.40 namespaceSelector: matchExpressions: - key: environment operator: NotIn values: - development
You can apply the
k8s.ovn.org/egress-assignable="" label to a node in your cluster so that OpenShift Container Platform can assign one or more egress IP addresses to the node.
Install the OpenShift CLI (
Log in to the cluster as a cluster administrator.
To label a node so that it can host one or more egress IP addresses, enter the following command:
$ oc label nodes <node_name> k8s.ovn.org/egress-assignable="" (1)
|1||The name of the node to label.|
You can alternatively apply the following YAML to add the label to a node: