mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
TELCODOCS-1237: VRFs for consistent isolated routes
This commit is contained in:
Ronan Hennessy
@@ -1323,6 +1323,8 @@ Topics:
|
||||
File: configuring-egress-ips-ovn
|
||||
- Name: Assigning an egress IP address
|
||||
File: assigning-egress-ips-ovn
|
||||
- Name: Configuring an egress service
|
||||
File: configuring-egress-traffic-for-vrf-loadbalancer-services
|
||||
- Name: Considerations for the use of an egress router pod
|
||||
File: using-an-egress-router-ovn
|
||||
- Name: Deploying an egress router pod in redirect mode
|
||||
@@ -1451,6 +1453,8 @@ Topics:
|
||||
File: metallb-configure-bfd-profiles
|
||||
- Name: Configuring services to use MetalLB
|
||||
File: metallb-configure-services
|
||||
- Name: Managing symmetric routing with MetalLB
|
||||
File: metallb-configure-return-traffic
|
||||
- Name: MetalLB logging, troubleshooting, and support
|
||||
File: metallb-troubleshoot-support
|
||||
- Name: Associating secondary interfaces metrics to network attachments
|
||||
|
||||
BIN
images/357_OpenShift_MetalLB_VRF_0823.png
Normal file
BIN
images/357_OpenShift_MetalLB_VRF_0823.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
45
modules/nw-egress-service-cr.adoc
Normal file
45
modules/nw-egress-service-cr.adoc
Normal file
@@ -0,0 +1,45 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc
|
||||
|
||||
:_content-type: REFERENCE
|
||||
[id="nw-egress-service-ovn-cr_{context}"]
|
||||
= Egress service custom resource
|
||||
|
||||
Define the configuration for an egress service in an `EgressService` custom resource. The following YAML describes the fields for the configuration of an egress service:
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: k8s.ovn.org/v1
|
||||
kind: EgressService
|
||||
metadata:
|
||||
name: <egress_service_name> <1>
|
||||
namespace: <namespace> <2>
|
||||
spec:
|
||||
sourceIPBy: <egress_traffic_ip> <3>
|
||||
nodeSelector: <4>
|
||||
matchLabels:
|
||||
node-role.kubernetes.io/<role>: ""
|
||||
network: <egress_traffic_network> <5>
|
||||
----
|
||||
<1> Specify the name for the egress service. The name of the `EgressService` resource must match the name of the load-balancer service that you want to modify.
|
||||
<2> Specify the namespace for the egress service. The namespace for the `EgressService` must match the namespace of the load-balancer service that you want to modify. The egress service is namespace-scoped.
|
||||
<3> Specify the source IP address of egress traffic for pods behind a service. Valid values are `LoadBalancerIP` or `Network`. Use the `LoadBalancerIP` value to assign the `LoadBalancer` service ingress IP address as the source IP address for egress traffic. Specify `Network` to assign the network interface IP address as the source IP address for egress traffic.
|
||||
<4> Optional: If you use the `LoadBalancerIP` value for the `sourceIPBy` specification, a single node handles the `LoadBalancer` service traffic. Use the `nodeSelector` field to limit which node can be assigned this task. When a node is selected to handle the service traffic, OVN-Kubernetes labels the node in the following format: `egress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: ""`. When the `nodeSelector` field is not specified, any node can manage the `LoadBalancer` service traffic.
|
||||
<5> Optional: Specify the routing table for egress traffic. If you do not include the `network` specification, the egress service uses the default host network.
|
||||
|
||||
.Example egress service specification
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: k8s.ovn.org/v1
|
||||
kind: EgressService
|
||||
metadata:
|
||||
name: test-egress-service
|
||||
namespace: test-namespace
|
||||
spec:
|
||||
sourceIPBy: "LoadBalancerIP"
|
||||
nodeSelector:
|
||||
matchLabels:
|
||||
vrf: "true"
|
||||
network: "2"
|
||||
----
|
||||
125
modules/nw-egress-service-ovn.adoc
Normal file
125
modules/nw-egress-service-ovn.adoc
Normal file
@@ -0,0 +1,125 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="nw-egress-service-ovn_{context}"]
|
||||
= Deploying an egress service
|
||||
|
||||
You can deploy an egress service to manage egress traffic for pods behind a `LoadBalancer` service.
|
||||
|
||||
The following example configures the egress traffic to have the same source IP address as the ingress IP address of the `LoadBalancer` service.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* Install the OpenShift CLI (`oc`).
|
||||
* Log in as a user with `cluster-admin` privileges.
|
||||
* You configured MetalLB `BGPPeer` resources.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Create an `IPAddressPool` CR with the desired IP for the service:
|
||||
|
||||
.. Create a file, such as `ip-addr-pool.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: metallb.io/v1beta1
|
||||
kind: IPAddressPool
|
||||
metadata:
|
||||
name: example-pool
|
||||
namespace: metallb-system
|
||||
spec:
|
||||
addresses:
|
||||
- 172.19.0.100/32
|
||||
----
|
||||
|
||||
.. Apply the configuration for the IP address pool by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f ip-addr-pool.yaml
|
||||
----
|
||||
|
||||
. Create `Service` and `EgressService` CRs.
|
||||
|
||||
.. Create a file, such as `service-egress-service.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml,subs="+quotes,+macros"]
|
||||
----
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: example-service
|
||||
namespace: example-namespace
|
||||
annotations:
|
||||
metallb.universe.tf/address-pool: example-pool <1>
|
||||
spec:
|
||||
selector:
|
||||
app: example
|
||||
ports:
|
||||
- name: http
|
||||
protocol: TCP
|
||||
port: 8080
|
||||
targetPort: 8080
|
||||
type: LoadBalancer
|
||||
---
|
||||
apiVersion: k8s.ovn.org/v1
|
||||
kind: EgressService
|
||||
metadata:
|
||||
name: example-service
|
||||
namespace: example-namespace
|
||||
spec:
|
||||
sourceIPBy: "LoadBalancerIP" <2>
|
||||
nodeSelector: <3>
|
||||
matchLabels:
|
||||
node-role.kubernetes.io/worker: ""
|
||||
----
|
||||
<1> The `LoadBalancer` service uses the IP address assigned by MetalLB from the `example-pool` IP address pool.
|
||||
<2> This example uses the `LoadBalancerIP` value to assign the ingress IP address of the `LoadBalancer` service as the source IP address of egress traffic.
|
||||
<3> When you specify the `LoadBalancerIP` value, a single node handles the `LoadBalancer` service's traffic. In this example, only nodes with the `worker` label can be selected to handle the traffic. When a node is selected, OVN-Kubernetes labels the node in the following format `egress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: ""`.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If you use the `sourceIPBy: "LoadBalancerIP"` setting, you must specify the load-balancer node in the `BGPAdvertisement` custom resource (CR).
|
||||
====
|
||||
|
||||
.. Apply the configuration for the service and egress service by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f service-egress-service.yaml
|
||||
----
|
||||
|
||||
. Create a `BGPAdvertisement` CR to advertise the service:
|
||||
|
||||
.. Create a file, such as `service-bgp-advertisement.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: metallb.io/v1beta1
|
||||
kind: BGPAdvertisement
|
||||
metadata:
|
||||
name: example-bgp-adv
|
||||
namespace: metallb-system
|
||||
spec:
|
||||
ipAddressPools:
|
||||
- example-pool
|
||||
nodeSelector:
|
||||
- matchLabels:
|
||||
egress-service.k8s.ovn.org/example-namespace-example-service: "" <1>
|
||||
----
|
||||
|
||||
<1> In this example, the `EgressService` CR configures the source IP address for egress traffic to use the load-balancer service IP address. Therefore, you must specify the load-balancer node for return traffic to use the same return path for the traffic originating from the pod.
|
||||
|
||||
.Verification
|
||||
|
||||
. Verify that you can access the application endpoint of the pods running behind the MetalLB service by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ curl <external_ip_address>:<port_number> <1>
|
||||
----
|
||||
<1> Update the external IP address and port number to suit your application endpoint.
|
||||
|
||||
. If you assigned the `LoadBalancer` service's ingress IP address as the source IP address for egress traffic, verify this configuration by using tools such as `tcpdump` to analyze packets received at the external client.
|
||||
203
modules/nw-metallb-configure-return-traffic-proc.adoc
Normal file
203
modules/nw-metallb-configure-return-traffic-proc.adoc
Normal file
@@ -0,0 +1,203 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="nw-metallb-configure-return-traffic-proc_{context}"]
|
||||
= Configuring symmetric routing by using VRFs with MetalLB
|
||||
|
||||
You can configure symmetric network routing for applications behind a MetalLB service that require the same ingress and egress network paths.
|
||||
|
||||
This example associates a VRF routing table with MetalLB and an egress service to enable symmetric routing for ingress and egress traffic for pods behind a `LoadBalancer` service.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
* If you use the `sourceIPBy: "LoadBalancerIP"` setting in the `EgressService` CR, you must specify the load-balancer node in the `BGPAdvertisement` custom resource (CR).
|
||||
|
||||
* You can use the `sourceIPBy: "Network"` setting on clusters that use OVN-Kubernetes configured with the `gatewayConfig.routingViaHost` specification set to `true` only. Additionally, if you use the `sourceIPBy: "Network"` setting, you must schedule the application workload on nodes configured with the network VRF instance.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* Install the OpenShift CLI (`oc`).
|
||||
* Log in as a user with `cluster-admin` privileges.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Create a `NodeNetworkConfigurationPolicy` CR to define the VRF instance:
|
||||
|
||||
.. Create a file, such as `node-network-vrf.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: nmstate.io/v1
|
||||
kind: NodeNetworkConfigurationPolicy
|
||||
metadata:
|
||||
name: vrfpolicy <1>
|
||||
spec:
|
||||
nodeSelector:
|
||||
vrf: "true" <2>
|
||||
maxUnavailable: 3
|
||||
desiredState:
|
||||
interfaces:
|
||||
- name: ens4vrf <3>
|
||||
type: vrf <4>
|
||||
state: up
|
||||
vrf:
|
||||
port:
|
||||
- ens4 <5>
|
||||
route-table-id: 2 <6>
|
||||
routes: <7>
|
||||
config:
|
||||
- destination: 0.0.0.0/0
|
||||
metric: 150
|
||||
next-hop-address: 192.168.130.1
|
||||
next-hop-interface: ens4
|
||||
table-id: 2
|
||||
route-rules: <8>
|
||||
config:
|
||||
- ip-to: 172.30.0.0/16
|
||||
priority: 998
|
||||
route-table: 254
|
||||
- ip-to: 10.132.0.0/14
|
||||
priority: 998
|
||||
route-table: 254
|
||||
----
|
||||
<1> The name of the policy.
|
||||
<2> This example applies the policy to all nodes with the label `vrf:true`.
|
||||
<3> The name of the interface.
|
||||
<4> The type of interface. This example creates a VRF instance.
|
||||
<5> The node interface that the VRF attaches to.
|
||||
<6> The name of the route table ID for the VRF.
|
||||
<7> Defines the configuration for network routes. The `next-hop-address` field defines the IP address of the next hop for the route. The `next-hop-interface` field defines the outgoing interface for the route. In this example, the VRF routing table is `2`, which references the ID that you define in the `EgressService` CR.
|
||||
<8> Defines additional route rules. The `ip-to` fields must match the `Cluster Network` CIDR and `Service Network` CIDR. You can view the values for these CIDR address specifications by running the following command: `oc describe network.config/cluster`.
|
||||
|
||||
.. Apply the policy by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f node-network-vrf.yaml
|
||||
----
|
||||
|
||||
. Create a `BGPPeer` custom resource (CR):
|
||||
|
||||
.. Create a file, such as `frr-via-vrf.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: metallb.io/v1beta2
|
||||
kind: BGPPeer
|
||||
metadata:
|
||||
name: frrviavrf
|
||||
namespace: metallb-system
|
||||
spec:
|
||||
myASN: 100
|
||||
peerASN: 200
|
||||
peerAddress: 192.168.130.1
|
||||
vrf: ens4vrf <1>
|
||||
----
|
||||
<1> Specifies the VRF instance to associate with the BGP peer. MetalLB can advertise services and make routing decisions based on the routing information in the VRF.
|
||||
|
||||
.. Apply the configuration for the BGP peer by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f frr-via-vrf.yaml
|
||||
----
|
||||
|
||||
. Create an `IPAddressPool` CR:
|
||||
|
||||
.. Create a file, such as `first-pool.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: metallb.io/v1beta1
|
||||
kind: IPAddressPool
|
||||
metadata:
|
||||
name: first-pool
|
||||
namespace: metallb-system
|
||||
spec:
|
||||
addresses:
|
||||
- 192.169.10.0/32
|
||||
----
|
||||
|
||||
.. Apply the configuration for the IP address pool by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f first-pool.yaml
|
||||
----
|
||||
|
||||
. Create a `BGPAdvertisement` CR:
|
||||
|
||||
.. Create a file, such as `first-adv.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: metallb.io/v1beta1
|
||||
kind: BGPAdvertisement
|
||||
metadata:
|
||||
name: first-adv
|
||||
namespace: metallb-system
|
||||
spec:
|
||||
ipAddressPools:
|
||||
- first-pool
|
||||
peers:
|
||||
- frrviavrf <1>
|
||||
nodeSelectors:
|
||||
- matchLabels:
|
||||
egress-service.k8s.ovn.org/test-server1: "" <2>
|
||||
----
|
||||
<1> In this example, MetalLB advertises a range of IP addresses from the `first-pool` IP address pool to the `frrviavrf` BGP peer.
|
||||
<2> In this example, the `EgressService` CR configures the source IP address for egress traffic to use the load-balancer service IP address. Therefore, you must specify the load-balancer node for return traffic to use the same return path for the traffic originating from the pod.
|
||||
|
||||
.. Apply the configuration for the BGP advertisement by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f first-adv.yaml
|
||||
----
|
||||
|
||||
. Create an `EgressService` CR:
|
||||
|
||||
.. Create a file, such as `egress-service.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml,options="nowrap",role="white-space-pre"]
|
||||
----
|
||||
apiVersion: k8s.ovn.org/v1
|
||||
kind: EgressService
|
||||
metadata:
|
||||
name: server1 <1>
|
||||
namespace: test <2>
|
||||
spec:
|
||||
sourceIPBy: "LoadBalancerIP" <3>
|
||||
nodeSelector:
|
||||
matchLabels:
|
||||
vrf: "true" <4>
|
||||
network: "2" <5>
|
||||
----
|
||||
<1> Specify the name for the egress service. The name of the `EgressService` resource must match the name of the load-balancer service that you want to modify.
|
||||
<2> Specify the namespace for the egress service. The namespace for the `EgressService` must match the namespace of the load-balancer service that you want to modify. The egress service is namespace-scoped.
|
||||
<3> This example assigns the `LoadBalancer` service ingress IP address as the source IP address for egress traffic.
|
||||
<4> If you specify `LoadBalancer` for the `sourceIPBy` specification, a single node handles the `LoadBalancer` service traffic. In this example, only a node with the label `vrf: "true"` can handle the service traffic. If you do not specify a node, OVN-Kubernetes selects a worker node to handle the service traffic. When a node is selected, OVN-Kubernetes labels the node in the following format: `egress-service.k8s.ovn.org/<svc_namespace>-<svc_name>: ""`.
|
||||
<5> Specify the routing table for egress traffic.
|
||||
|
||||
.. Apply the configuration for the egress service by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f egress-service.yaml
|
||||
----
|
||||
|
||||
.Verification
|
||||
|
||||
. Verify that you can access the application endpoint of the pods running behind the MetalLB service by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ curl <external_ip_address>:<port_number> <1>
|
||||
----
|
||||
<1> Update the external IP address and port number to suit your application endpoint.
|
||||
|
||||
. Optional: If you assigned the `LoadBalancer` service ingress IP address as the source IP address for egress traffic, verify this configuration by using tools such as `tcpdump` to analyze packets received at the external client.
|
||||
|
||||
214
modules/nw-metallb-configure-vrf-bgppeer.adoc
Normal file
214
modules/nw-metallb-configure-vrf-bgppeer.adoc
Normal file
@@ -0,0 +1,214 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/metallb/metallb-configure-bgp-peers.adoc
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="nw-metallb-bgp-peer-vrf_{context}"]
|
||||
= Exposing a service through a network VRF
|
||||
|
||||
You can expose a service through a virtual routing and forwarding (VRF) instance by associating a VRF on a network interface with a BGP peer.
|
||||
|
||||
:FeatureName: Exposing a service through a VRF on a BGP peer
|
||||
include::snippets/technology-preview.adoc[]
|
||||
|
||||
By using a VRF on a network interface to expose a service through a BGP peer, you can segregate traffic to the service, configure independent routing decisions, and enable multi-tenancy support on a network interface.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
By establishing a BGP session through an interface belonging to a network VRF, MetalLB can advertise services through that interface and enable external traffic to reach the service through this interface. However, the network VRF routing table is different from the default VRF routing table used by OVN-Kubernetes. Therefore, the traffic cannot reach the OVN-Kubernetes network infrastructure.
|
||||
|
||||
To enable the traffic directed to the service to reach the OVN-Kubernetes network infrastructure, you must configure routing rules to define the next hops for network traffic. See the `NodeNetworkConfigurationPolicy` resource in "Managing symmetric routing with MetalLB" in the _Additional resources_ section for more information.
|
||||
====
|
||||
|
||||
These are the high-level steps to expose a service through a network VRF with a BGP peer:
|
||||
|
||||
. Define a BGP peer and add a network VRF instance.
|
||||
. Specify an IP address pool for MetalLB.
|
||||
. Configure a BGP route advertisement for MetalLB to advertise a route using the specified IP address pool and the BGP peer associated with the VRF instance.
|
||||
. Deploy a service to test the configuration.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* You installed the OpenShift CLI (`oc`).
|
||||
* You logged in as a user with `cluster-admin` privileges.
|
||||
* You defined a `NodeNetworkConfigurationPolicy` to associate a Virtual Routing and Forwarding (VRF) instance with a network interface. For more information about completing this prerequisite, see the _Additional resources_ section.
|
||||
* You installed MetalLB on your cluster.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Create a `BGPPeer` custom resources (CR):
|
||||
|
||||
.. Create a file, such as `frrviavrf.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: metallb.io/v1beta2
|
||||
kind: BGPPeer
|
||||
metadata:
|
||||
name: frrviavrf
|
||||
namespace: metallb-system
|
||||
spec:
|
||||
myASN: 100
|
||||
peerASN: 200
|
||||
peerAddress: 192.168.130.1
|
||||
vrf: ens4vrf <1>
|
||||
----
|
||||
<1> Specifies the network VRF instance to associate with the BGP peer. MetalLB can advertise services and make routing decisions based on the routing information in the VRF.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
You must configure this network VRF instance in a `NodeNetworkConfigurationPolicy` CR. See the _Additional resources_ for more information.
|
||||
====
|
||||
|
||||
.. Apply the configuration for the BGP peer by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f frrviavrf.yaml
|
||||
----
|
||||
|
||||
. Create an `IPAddressPool` CR:
|
||||
|
||||
.. Create a file, such as `first-pool.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: metallb.io/v1beta1
|
||||
kind: IPAddressPool
|
||||
metadata:
|
||||
name: first-pool
|
||||
namespace: metallb-system
|
||||
spec:
|
||||
addresses:
|
||||
- 192.169.10.0/32
|
||||
----
|
||||
|
||||
.. Apply the configuration for the IP address pool by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f first-pool.yaml
|
||||
----
|
||||
|
||||
. Create a `BGPAdvertisement` CR:
|
||||
|
||||
.. Create a file, such as `first-adv.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: metallb.io/v1beta1
|
||||
kind: BGPAdvertisement
|
||||
metadata:
|
||||
name: first-adv
|
||||
namespace: metallb-system
|
||||
spec:
|
||||
ipAddressPools:
|
||||
- first-pool
|
||||
peers:
|
||||
- frrviavrf <1>
|
||||
----
|
||||
<1> In this example, MetalLB advertises a range of IP addresses from the `first-pool` IP address pool to the `frrviavrf` BGP peer.
|
||||
|
||||
.. Apply the configuration for the BGP advertisement by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f first-adv.yaml
|
||||
----
|
||||
|
||||
. Create a `Namespace`, `Deployment`, and `Service` CR:
|
||||
|
||||
.. Create a file, such as `deploy-service.yaml`, with content like the following example:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: test
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: server
|
||||
namespace: test
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: server
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: server
|
||||
spec:
|
||||
containers:
|
||||
- name: server
|
||||
image: registry.redhat.io/ubi9/ubi
|
||||
ports:
|
||||
- name: http
|
||||
containerPort: 30100
|
||||
command: ["/bin/sh", "-c"]
|
||||
args: ["sleep INF"]
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: server1
|
||||
namespace: test
|
||||
spec:
|
||||
ports:
|
||||
- name: http
|
||||
port: 30100
|
||||
protocol: TCP
|
||||
targetPort: 30100
|
||||
selector:
|
||||
app: server
|
||||
type: LoadBalancer
|
||||
----
|
||||
|
||||
.. Apply the configuration for the namespace, deployment, and service by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc apply -f deploy-service.yaml
|
||||
----
|
||||
|
||||
.Verification
|
||||
|
||||
. Identify a MetalLB speaker pod by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get -n metallb-system pods -l component=speaker
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
speaker-c6c5f 6/6 Running 0 69m
|
||||
----
|
||||
|
||||
. Verify that the state of the BGP session is `Established` in the speaker pod by running the following command, replacing the variables to match your configuration:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> neigh"
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
BGP neighbor is 192.168.30.1, remote AS 200, local AS 100, external link
|
||||
BGP version 4, remote router ID 192.168.30.1, local router ID 192.168.30.71
|
||||
BGP state = Established, up for 04:20:09
|
||||
|
||||
...
|
||||
----
|
||||
|
||||
. Verify that the service is advertised correctly by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc exec -n metallb-system <speaker_pod> -c frr -- vtysh -c "show bgp vrf <vrf_name> ipv4"
|
||||
----
|
||||
45
modules/virt-example-host-vrf.adoc
Normal file
45
modules/virt-example-host-vrf.adoc
Normal file
@@ -0,0 +1,45 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc
|
||||
|
||||
[id="virt-example-host-vrf_{context}"]
|
||||
= Example: Network interface with a VRF instance node network configuration policy
|
||||
|
||||
Associate a Virtual Routing and Forwarding (VRF) instance with a network interface by applying a `NodeNetworkConfigurationPolicy` custom resource (CR).
|
||||
|
||||
:FeatureName: Associating a VRF instance with a network interface
|
||||
include::snippets/technology-preview.adoc[]
|
||||
|
||||
By associating a VRF instance with a network interface, you can support traffic isolation, independent routing decisions, and the logical separation of network resources.
|
||||
|
||||
In a bare-metal environment, you can announce load balancer services through interfaces belonging to a VRF instance by using MetalLB. For more information, see the _Additional resources_ section.
|
||||
|
||||
The following YAML file is an example of associating a VRF instance to a network interface.
|
||||
It includes samples values that you must replace with your own information.
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: nmstate.io/v1
|
||||
kind: NodeNetworkConfigurationPolicy
|
||||
metadata:
|
||||
name: vrfpolicy <1>
|
||||
spec:
|
||||
nodeSelector:
|
||||
vrf: "true" <2>
|
||||
maxUnavailable: 3
|
||||
desiredState:
|
||||
interfaces:
|
||||
- name: ens4vrf <3>
|
||||
type: vrf <4>
|
||||
state: up
|
||||
vrf:
|
||||
port:
|
||||
- ens4 <5>
|
||||
route-table-id: 2 <6>
|
||||
----
|
||||
<1> The name of the policy.
|
||||
<2> This example applies the policy to all nodes with the label `vrf:true`.
|
||||
<3> The name of the interface.
|
||||
<4> The type of interface. This example creates a VRF instance.
|
||||
<5> The node interface to which the VRF attaches.
|
||||
<6> The name of the route table ID for the VRF.
|
||||
@@ -48,6 +48,14 @@ include::modules/virt-example-ethernet-nncp.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/virt-example-nmstate-multiple-interfaces.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/virt-example-host-vrf.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../networking/multiple_networks/about-virtual-routing-and-forwarding.adoc#cnf-about-virtual-routing-and-forwarding_about-virtual-routing-and-forwarding[About virtual routing and forwarding]
|
||||
* xref:../../networking/metallb/metallb-configure-bgp-peers.adoc#nw-metallb-bgp-peer-vrf_configure-metallb-bgp-peers[Exposing a service through a network VRF]
|
||||
|
||||
[id="capturing-nic-static-ip_k8s-nmstate-updating-node-network-config"]
|
||||
== Capturing the static IP of a NIC attached to a bridge
|
||||
|
||||
|
||||
@@ -23,6 +23,20 @@ include::modules/nw-metallb-configure-bgppeer.adoc[leveloffset=+1]
|
||||
// Add a BGP peer
|
||||
include::modules/nw-metallb-configure-specificpools-to-bgppeer.adoc[leveloffset=+1]
|
||||
|
||||
// Add a BGP peer with VRF
|
||||
include::modules/nw-metallb-configure-vrf-bgppeer.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../networking/multiple_networks/about-virtual-routing-and-forwarding.adoc#cnf-about-virtual-routing-and-forwarding_about-virtual-routing-and-forwarding[About virtual routing and forwarding]
|
||||
|
||||
* xref:../../networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc#virt-example-host-vrf_k8s_nmstate-updating-node-network-config[Example: Network interface with a VRF instance node network configuration policy]
|
||||
|
||||
* xref:../../networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc#configuring-egress-traffic-loadbalancer-services[Configuring an egress service]
|
||||
|
||||
* xref:../../networking/metallb/metallb-configure-return-traffic.adoc#metallb-configure-return-traffic[Managing symmetric routing with MetalLB]
|
||||
|
||||
// Examples
|
||||
include::modules/nw-metallb-example-bgppeer.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
64
networking/metallb/metallb-configure-return-traffic.adoc
Normal file
64
networking/metallb/metallb-configure-return-traffic.adoc
Normal file
@@ -0,0 +1,64 @@
|
||||
:_content-type: ASSEMBLY
|
||||
[id="metallb-configure-return-traffic"]
|
||||
= Managing symmetric routing with MetalLB
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: metallb-configure-return-traffic
|
||||
|
||||
toc::[]
|
||||
|
||||
As a cluster administrator, you can effectively manage traffic for pods behind a MetalLB load-balancer service with multiple host interfaces by implementing features from MetalLB, NMState, and OVN-Kubernetes. By combining these features in this context, you can provide symmetric routing, traffic segregation, and support clients on different networks with overlapping CIDR addresses.
|
||||
|
||||
To achieve this functionality, learn how to implement virtual routing and forwarding (VRF) instances with MetalLB, and configure egress services.
|
||||
|
||||
:FeatureName: Configuring symmetric traffic by using a VRF instance with MetalLB and an egress service
|
||||
include::snippets/technology-preview.adoc[]
|
||||
|
||||
[id="challenges-of-managing-symmetric-routing-with-metallb"]
|
||||
== Challenges of managing symmetric routing with MetalLB
|
||||
|
||||
When you use MetalLB with multiple host interfaces, MetalLB exposes and announces a service through all available interfaces on the host. This can present challenges relating to network isolation, asymmetric return traffic and overlapping CIDR addresses.
|
||||
|
||||
One option to ensure that return traffic reaches the correct client is to use static routes. However, with this solution, MetalLB cannot isolate the services and then announce each service through a different interface. Additionally, static routing requires manual configuration and requires maintenance if remote sites are added.
|
||||
|
||||
A further challenge of symmetric routing when implementing a MetalLB service is scenarios where external systems expect the source and destination IP address for an application to be the same. The default behavior for {product-title} is to assign the IP address of the host network interface as the source IP address for traffic originating from pods. This is problematic with multiple host interfaces.
|
||||
|
||||
You can overcome these challenges by implementing a configuration that combines features from MetalLB, NMState, and OVN-Kubernetes.
|
||||
|
||||
[id="overview-of-managing-symmetric-routing-using-vrf-based-networks-with-metallb"]
|
||||
== Overview of managing symmetric routing by using VRFs with MetalLB
|
||||
|
||||
You can overcome the challenges of implementing symmetric routing by using NMState to configure a VRF instance on a host, associating the VRF instance with a MetalLB `BGPPeer` resource, and configuring an egress service for egress traffic with OVN-Kubernetes.
|
||||
|
||||
.Network overview of managing symmetric routing by using VRFs with MetalLB
|
||||
image::357_OpenShift_MetalLB_VRF_0823.png[Network overview of managing symmetric routing by using VRFs with MetalLB]
|
||||
|
||||
The configuration process involves three stages:
|
||||
|
||||
.1. Define a VRF and routing rules
|
||||
|
||||
* Configure a `NodeNetworkConfigurationPolicy` custom resource (CR) to associate a VRF instance with a network interface.
|
||||
* Use the VRF routing table to direct ingress and egress traffic.
|
||||
|
||||
.2. Link the VRF to a MetalLB `BGPPeer`
|
||||
|
||||
* Configure a MetalLB `BGPPeer` resource to use the VRF instance on a network interface.
|
||||
* By associating the `BGPPeer` resource with the VRF instance, the designated network interface becomes the primary interface for the BGP session, and MetalLB advertises the services through this interface.
|
||||
|
||||
.3. Configure an egress service
|
||||
|
||||
* Configure an egress service to choose the network associated with the VRF instance for egress traffic.
|
||||
* Optional: Configure an egress service to use the IP address of the MetalLB load-balancer service as the source IP for egress traffic.
|
||||
|
||||
// Deploying an egress service for VRF
|
||||
include::modules/nw-metallb-configure-return-traffic-proc.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../networking/multiple_networks/about-virtual-routing-and-forwarding.adoc#cnf-about-virtual-routing-and-forwarding_about-virtual-routing-and-forwarding[About virtual routing and forwarding]
|
||||
|
||||
* xref:../../networking/metallb/metallb-configure-bgp-peers.adoc#nw-metallb-bgp-peer-vrf_configure-metallb-bgp-peers[Exposing a service through a network VRF]
|
||||
|
||||
* xref:../../networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc#virt-example-host-vrf_k8s_nmstate-updating-node-network-config[Example: Network interface with a VRF instance node network configuration policy]
|
||||
|
||||
* xref:../../networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc#configuring-egress-traffic-loadbalancer-services[Configuring an egress service]
|
||||
@@ -0,0 +1,44 @@
|
||||
:_content-type: ASSEMBLY
|
||||
[id="configuring-egress-traffic-loadbalancer-services"]
|
||||
= Configuring an egress service
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: configuring-egress-traffic-loadbalancer-services
|
||||
|
||||
toc::[]
|
||||
|
||||
As a cluster administrator, you can configure egress traffic for pods behind a load balancer service by using an egress service.
|
||||
|
||||
:FeatureName: Egress service
|
||||
include::snippets/technology-preview.adoc[]
|
||||
|
||||
You can use the `EgressService` custom resource (CR) to manage egress traffic in the following ways:
|
||||
|
||||
* Assign a load balancer service IP address as the source IP address for egress traffic for pods behind the load balancer service.
|
||||
+
|
||||
Assigning the load balancer IP address as the source IP address in this context is useful to present a single point of egress and ingress. For example, in some scenarios, an external system communicating with an application behind a load balancer service can expect the source and destination IP address for the application to be the same.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
When you assign the load balancer service IP address to egress traffic for pods behind the service, OVN-Kubernetes restricts the ingress and egress point to a single node. This limits the load balancing of traffic that MetalLB typically provides.
|
||||
====
|
||||
|
||||
* Assign the egress traffic for pods behind a load balancer to a different network than the default node network.
|
||||
+
|
||||
This is useful to assign the egress traffic for applications behind a load balancer to a different network than the default network. Typically, the different network is implemented by using a VRF instance associated with a network interface.
|
||||
|
||||
// Describe the CR and provide an example.
|
||||
include::modules/nw-egress-service-cr.adoc[leveloffset=+1]
|
||||
|
||||
// Deploying an egress service
|
||||
include::modules/nw-egress-service-ovn.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../networking/metallb/metallb-configure-bgp-peers.adoc#nw-metallb-bgp-peer-vrf_configure-metallb-bgp-peers[Exposing a service through a network VRF]
|
||||
|
||||
* xref:../../networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.adoc#virt-example-host-vrf_k8s_nmstate-updating-node-network-config[Example: Network interface with a VRF instance node network configuration policy]
|
||||
|
||||
* xref:../../networking/metallb/metallb-configure-return-traffic.adoc#metallb-configure-return-traffic[Managing symmetric routing with MetalLB]
|
||||
|
||||
* xref:../../networking/multiple_networks/about-virtual-routing-and-forwarding.adoc#cnf-about-virtual-routing-and-forwarding_about-virtual-routing-and-forwarding[About virtual routing and forwarding]
|
||||
Reference in New Issue
Block a user