Configure the dedicated octavia network to establish connectivity between amphora instances and Octavia controllers across your OpenShift cluster.

This octavia links the amphorae to the Octavia amphora controller services, and also provides a dedicated address pool that RHOSO uses to create additional static IP addresses for configuring heartbeat destinations for the amphorae.

The Load-balancing service uses a bridge-type network attachment definition (NAD), octbr, to connect the RHOSO control plane pods to the load-balancing management network. A bridge attachment is required because a macvlan interface would block the bridged packet flow that the Open vSwitch (OVS) bridge depends on to serve multiple tenants. On each node, a network configuration policy creates a VLAN sub-interface and attaches it to the octbr bridge. This setup provides the layer 2 path that carries traffic between pods on different worker nodes. Within the cluster, a dedicated link router connects the provider network to the lb-mgmt-net tenant network, where the amphora instances reside. The control plane pods receive their IP addresses from the provider network through the NAD. This routing arrangement provides the Load-balancing service controllers with direct connectivity to every amphora without using source network address translation (SNAT).

To route traffic between the tenant network and the control plane pods, the Networking service (neutron) treats the octavia network attachment as an externally routed provider network. The OVN controller uses a network interface controller (NIC) mapping to associate the network attachment name with the provider network. The octavia Operator also assigns each Octavia Health Manager an additional dedicated IP address that survives pod restarts so the related configuration in the running amphorae remains valid. This setup establishes standard routing to direct traffic, such as heartbeat signals and control commands, between the amphorae and the Load-balancing service controllers. The octavia network also connects the rsyslogd pods for the Load-balancing service to perform log offloading.

Review the Load-balancing service object model to configure load balancers, listeners, pools, members, health monitors, and L7 policies.

Load balancer

The top API object that represents the load-balancing entity. The VIP address is allocated when you create the load balancer. When you use the amphora provider to create the load balancer one or more amphora instances launch on one or more Compute nodes.

Listener

The port on which the load balancer listens, for example, TCP port 80 for HTTP. Listeners also support TLS-terminated HTTPS load balancers.

Health Monitor

A process that performs periodic health checks on each back-end member server to pre-emptively detect failed servers and temporarily remove them from the pool.

Pool

A group of members that handle client requests from the load balancer. You can associate pools with more than one listener by using the API. You can share pools with L7 policies.

Member

Describes how to connect to the back-end instances or services. This description consists of the IP address and network port on which the back end member is available.

L7 Rule

Defines the layer 7 (L7) conditions that determine whether an L7 policy applies to the connection.

L7 Policy

A collection of L7 rules associated with a listener, and which might also have an association to a back-end pool. Policies describe actions that the load balancer takes if all of the rules in the policy are true.

Understand how the Load-balancing service integrates with other RHOSO services to deliver scalable and highly available cloud deployments.

The Red Hat OpenStack Services on OpenShift (RHOSO) Load-balancing service (octavia) depends on other RHOSO services:

• Compute service (nova) - For managing the Load-balancing service VM instance (amphora) lifecycle, and creating compute resources on-demand.
• Networking service (neutron) - For network connectivity between amphorae, tenant environments, and external networks.
• Key Manager service (barbican) - For managing TLS certificates and credentials, when TLS session termination is configured on a listener.
• Identity service (keystone) - For authentication requests to the octavia API, and for the Load-balancing service to authenticate with other RHOSO services.
• Image service (glance) - For storing the amphora virtual machine image.

The Load-balancing service interacts with the other RHOSO services through a driver interface. The driver interface avoids major restructuring of the Load-balancing service if an external component requires replacement with a functionally-equivalent service.