You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: cloud_experts_tutorials/cloud-experts-consistent-egress-ip.adoc
+1-6Lines changed: 1 addition & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,11 +78,6 @@ The above example uses `jq` as a friendly filter. If you do not have `jq` instal
78
78
79
79
== Create the egress IP rule(s)
80
80
81
-
[NOTE]
82
-
====
83
-
Generally speaking, it would be ideal to label the nodes prior to assigning the egress IP addresses, however there is a bug that exists which needs to be fixed first. Once this is fixed, the process and documentation will be re-ordered to address this. See link:https://issues.redhat.com/browse/OCPBUGS-4969[OCPBUGS-4969].
84
-
====
85
-
86
81
=== Identify the egress IPs
87
82
88
83
Before creating the rules, we should identify which egress IPs that we will use. It should be noted that the egress IPs that you select should exist as a part of the subnets in which the worker nodes are provisioned into.
@@ -97,7 +92,7 @@ Create a project to demonstrate assigning egress IP addresses based on a namespa
97
92
98
93
[source,terminal]
99
94
----
100
-
$ oc new-project demo-egress-ns
95
+
$ oc create -f demo-egress-pod.yaml
101
96
----
102
97
103
98
Create the egress rule. This rule will ensure that egress traffic will be applied to all pods within the namespace that we just created using the `spec.namespaceSelector` field:
Copy file name to clipboardExpand all lines: modules/nw-egress-ips-about.adoc
+29-6Lines changed: 29 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,17 +21,26 @@ To ensure that you can reliably allow access to the server from only that specif
21
21
22
22
An egress IP address assigned to a namespace is different from an egress router, which is used to send traffic to specific destinations.
23
23
24
-
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.
24
+
ifndef::openshift-rosa[]
25
+
In some cluster configurations,
26
+
endif::openshift-rosa[]
27
+
ifdef::openshift-rosa[]
28
+
In {hcp-title} clusters,
29
+
endif::openshift-rosa[]
30
+
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.
25
31
26
32
ifdef::openshift-sdn[]
27
33
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.
28
34
endif::openshift-sdn[]
29
35
36
+
ifndef::openshift-rosa[]
30
37
[IMPORTANT]
31
38
====
32
39
Egress IP addresses must not be configured in any Linux network configuration files, such as `ifcfg-eth0`.
33
40
====
41
+
endif::openshift-rosa[]
34
42
43
+
ifndef::openshift-rosa[]
35
44
[id="nw-egress-ips-platform-support_{context}"]
36
45
== Platform support
37
46
@@ -54,12 +63,20 @@ Support for the egress IP address functionality on various platforms is summariz
54
63
| Nutanix | Yes
55
64
56
65
|===
66
+
endif::openshift-rosa[]
57
67
58
68
[IMPORTANT]
59
69
====
60
-
The assignment of egress IP addresses to control plane nodes with the EgressIP feature is not supported on a cluster provisioned on Amazon Web Services (AWS). (link:https://bugzilla.redhat.com/show_bug.cgi?id=2039656[*BZ#2039656*])
70
+
The assignment of egress IP addresses to control plane nodes with the EgressIP feature is
71
+
ifdef::openshift-rosa[]
72
+
not supported.
73
+
endif::openshift-rosa[]
74
+
ifndef::openshift-rosa[]
75
+
not supported on a cluster provisioned on Amazon Web Services (AWS). (link:https://bugzilla.redhat.com/show_bug.cgi?id=2039656[*BZ#2039656*]).
When an {rh-openstack} cluster administrator assigns a floating IP to the reservation port, {product-title} cannot delete the reservation port. The `CloudPrivateIPConfig` object cannot perform delete and move operations until an {rh-openstack} cluster administrator unassigns the floating IP from the reservation port.
95
112
====
113
+
endif::openshift-rosa[]
96
114
97
115
The following examples illustrate the annotation from nodes on several public cloud providers. The annotations are indented for readability.
The following sections describe the IP address capacity for supported public cloud environments for use in your capacity calculation.
124
144
@@ -127,6 +147,7 @@ The following sections describe the IP address capacity for supported public clo
127
147
128
148
On AWS, constraints on IP address assignments depend on the instance type configured. For more information, see link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI[IP addresses per network interface per instance type]
129
149
150
+
ifndef::openshift-rosa[]
130
151
[id="nw-egress-ips-capacity-gcp_{context}"]
131
152
=== Google Cloud Platform (GCP) IP address capacity limits
132
153
@@ -148,11 +169,12 @@ On Azure, the following capacity limits exist for IP address assignment:
148
169
- Per virtual network, the maximum number of assigned IP addresses cannot exceed 65,536.
149
170
150
171
For more information, see link:https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits?toc=/azure/virtual-network/toc.json#networking-limits[Networking limits].
== Considerations for using an egress IP on additional network interfaces
154
176
155
-
In {product-title}, egress IPs provide administrators a way to control network traffic. Egress IPs can be used with the `br-ex`, or primary, network interface, which is a Linux bridge interface associated with Open vSwitch, or they can be used with additional network interfaces.
177
+
In {product-title}, egress IPs provide administrators a way to control network traffic. Egress IPs can be used with the `br-ex`, or primary, network interface, which is a Linux bridge interface associated with Open vSwitch, or they can be used with additional network interfaces.
156
178
157
179
You can inspect your network interface type by running the following command:
158
180
@@ -165,15 +187,16 @@ The primary network interface is assigned a node IP address which also contains
165
187
166
188
If the egress IP is not within the subnet of the primary network interface subnet, you can use an egress IP on another Linux network interface that is not of the primary network interface type. By doing so, {product-title} administrators are provided with a greater level of control over networking aspects such as routing, addressing, segmentation, and security policies. This feature provides users with the option to route workload traffic over specific network interfaces for purposes such as traffic segmentation or meeting specialized requirements.
167
189
168
-
If the egress IP is not within the subnet of the primary network interface, then the selection of another network interface for egress traffic might occur if they are present on a node.
190
+
If the egress IP is not within the subnet of the primary network interface, then the selection of another network interface for egress traffic might occur if they are present on a node.
169
191
170
-
You can determine which other network interfaces might support egress IPs by inspecting the `k8s.ovn.org/host-cidrs` Kubernetes node annotation. This annotation contains the addresses and subnet mask found for the primary network interface. It also contains additional network interface addresses and subnet mask information. These addresses and subnet masks are assigned to network interfaces that use the link:https://networklessons.com/cisco/ccna-200-301/longest-prefix-match-routing[longest prefix match routing] mechanism to determine which network interface supports the egress IP.
192
+
You can determine which other network interfaces might support egress IPs by inspecting the `k8s.ovn.org/host-cidrs` Kubernetes node annotation. This annotation contains the addresses and subnet mask found for the primary network interface. It also contains additional network interface addresses and subnet mask information. These addresses and subnet masks are assigned to network interfaces that use the link:https://networklessons.com/cisco/ccna-200-301/longest-prefix-match-routing[longest prefix match routing] mechanism to determine which network interface supports the egress IP.
171
193
172
194
[NOTE]
173
195
====
174
196
OVN-Kubernetes provides a mechanism to control and direct outbound network traffic from specific namespaces and pods. This ensures that it exits the cluster through a particular network interface and with a specific egress IP address.
$ rosa edit machinepool <machinepool_name> --cluster=<cluster_name> --labels "k8s.ovn.org/egress-assignable="
52
+
----
53
+
+
54
+
[IMPORTANT]
55
+
====
56
+
This command replaces any exciting node labels on your machinepool. You should include any of the desired labels to the `--labels` field to ensure that your existing node labels persist.
0 commit comments