Chapter 3. Deploying the Load-balancing service in an existing environment Deploying the Load-balancing service (octavia) to an existing Red Hat OpenStack Services on OpenShift (RHOSO) environment consists of performing the required steps for network configuration and security and then deploying the Load-balancing service in the RHOSO control plane. Overview You must perform the steps in the following procedures to deploy the Load-balancing service (octavia): Add the Load-balancing service interface to the configuration policy . Add the network attachment definition for the load-balancing management network . Create a CA passphrase for certificate generation and signing . Deploy the Load-balancing service . Important The steps in these procedures provide sample values that you add to the required CRs. The actual values that you provide will depend on your particular hardware configuration and local networking policies. 3.1. Adding the Load-balancing service interface to the configuration policy You begin the process of deploying the Load-balancing service (octavia) in a pre-existing Red Hat OpenStack Services on OpenShift (RHOSO) environment by adding the required interface to the node network configuration policy ( nncp ). Prerequisites You have the oc command line tool installed on your workstation. You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges. You have a unique VLAN ID for the load-balancing management network, lb-mgmt-net . Procedure Add the VLAN interface as a port to the octbr bridge. Performing this step enables pods connected to the octavia network attachment to communicate with pods running on other worker nodes. Because the interface is a VLAN, it isolates the load-balancing management network from other networks that might share the same base interface. Example In this example, the base interface name used is enp6s0 and the VLAN ID used is 24 . Replace these values with ones that are appropriate for your environment. For more information, see Preparing networks for Red Hat OpenStack Services on OpenShift in Deploying Red Hat OpenStack Services on OpenShift . Validation Confirm that the interface was successfully added, by running the following command: USD oc get nncp -n openstack Sample output When successful, you should see output similar to the following: NAME STATUS REASON worker-0 Available SuccessfullyConfigured worker-1 Available SuccessfullyConfigured worker-2 Available SuccessfullyConfigured steps Proceed to Section 3.2, "Adding the network attachment definition of the load-balancing management network" . 3.2. Adding the network attachment definition of the load-balancing management network Adding the network attachment definition for the load-balancing management network is a required step for deploying the Load-balancing service (octavia) in a Red Hat OpenStack Services on OpenShift (RHOSO) environment. The octavia network attachment is required to connect pods that manage load balancer virtual machines (amphorae) and the Open vSwitch pods that are managed by the OVN operator. RHOSO uses the podified Open vSwitch instance to implement the route between the provider network and the management project (tenant) network. This attachment must be a bridgeable interface in the Open vSwitch pod, and must permit communication between other pods on the same node. The bridge attachment type, in conjunction with the VLAN interface added to the bridge in the NodeNetworkConfigurationPolicy , creates the necessary layer 2 link that enables connectivity across the nodes. Prerequisites You have the oc command line tool installed on your workstation. You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges. Procedure Add the network attachment definition. Example In the following example, a network attachment definition is added to a definition file named, octavia-net-attach-def.yaml . Important The IP addresses and CIDRs defined in the network attachment definition are used only on a private network and VLAN. The values shown in this example are only for demonstration purposes. Use values that are appropriate for your environment. cat >> octavia-net-attach-def.yaml << EOF_CAT apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: octavia name: octavia namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "octavia", "type": "bridge", "bridge": "octbr", "ipam": { "type": "whereabouts", "range": "192.0.2.0/16", "range_start": "192.0.2.30", "range_end": "192.0.2.70", "routes": [ { "dst": "192.1.2.0/16", "gw" : "192.0.2.150" } ] } } EOF_CAT oc apply -n openstack -f octavia-net-attach-def.yaml Verification Confirm that the network attachment for the load-balancing management network is successful. oc get net-attach-def -n openstack Sample output When successful, you should see octavia displayed in the network name list: steps Proceed to Section 3.3, "Creating a CA passphrase for certificate generation and signing" . 3.3. Creating a CA passphrase for certificate generation and signing In Red Hat OpenStack Services on OpenShift (RHOSO) environments, you create a Secret custom resource (CR) which is used to encrypt the generated private key of the Server CA. RHOSO uses dual CAs to make communication between the Load balancing service (octavia) amphora and its controller more secure. Prerequisites You have the oc command line tool installed on your workstation. You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges. Procedure Generate a Base64, encoded password. Retain the encoded output to use in a later step. Example In this example, the password, my_password is encoded using the Base64 encoding scheme: USD echo -n my_password | base64 Create a Secret CR file on your workstation, for example, octavia-ca-passphrase.yaml . Add the following configuration to octavia-ca-passphrase.yaml : apiVersion: v1 data: server-ca-passphrase: <Base64_password> kind: Secret metadata: name: octavia-ca-passphrase namespace: openstack type: Opaque Replace the <Base64_password> with the Base64-encoded password that you created earlier. Create the Secret CR in the cluster: USD oc create -f octavia-ca-passphrase.yaml Verification Confirm that the Secret CR exists: USD oc describe secret octavia-ca-passphrase -n openstack steps Proceed to Section 3.4, "Deploying the Load-balancing service" . 3.4. Deploying the Load-balancing service To deploy the Red Hat OpenStack Services on OpenShift (RHOSO) Load-balancing service (octavia), you must configure the OVN controller to create a NIC mapping for the provider network as well as add it to the networkAttachments property for each Load-balancing service that controls load balancers (amphorae). Prerequisites You have the oc command line tool installed on your workstation. You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges. Procedure Update the OpenStackControlPlane custom resource with the required values for the Load-balancing service. Important In the following example, controlplane is the name of the OpenStackControlPlane custom resource (CR). Use the correct name for your OpenStackControlPlane CR. The value for nicMappings must be octavia: octbr . Note the one-character difference between the OVN networkAttachment property and the octavia networkAttachments property. Verification Confirm that the Load-balancing service (octavia) pods are running: USD oc get pods | grep octavia Sample output You should see output similar to the following. The number of entries and their suffixes will vary depending on the details of your environment: octavia-api-5cf9bc78f7-4lmds 2/2 Running 0 42h octavia-healthmanager-5g94j 1/1 Running 0 21h octavia-housekeeping-5gtw8 1/1 Running 0 21h octavia-image-upload-78b4b6c47c-xzdtl 1/1 Running 0 35h octavia-worker-pq55m 1/1 Running 0 21h Access the remote shell for the OpenStackClient pod from your workstation: Confirm that the networks octavia-provider-net and lb-mgmt-net are present: Sample output The network, octavia-provider-net , is the external provider network, and is limited to the RHOSO control plane. The lb-mgmt-net network connects the Load-balancing service to amphora instances. Exit the openstackclient pod: USD exit

Commands:
get -n openstack --no-headers nncp | cut -f 1 -d ' ' | while read ; do oc patch -n openstack nncp USDREPLY --type=merge --patch ' spec: desiredState: interfaces: - description: Octavia vlan host interface name: enp6s0.24 state: up type: vlan vlan: base-iface: enp6s0 id: 24 - bridge: options: stp: enabled: false port: - name: enp6s0.24 description: Configuring bridge octbr mtu: 1500 name: octbr state: up type: linux-bridge ' done
oc get nncp -n openstack
NAME STATUS REASON worker-0 Available SuccessfullyConfigured worker-1 Available SuccessfullyConfigured worker-2 Available SuccessfullyConfigured
cat >> octavia-net-attach-def.yaml << EOF_CAT apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: octavia name: octavia namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "octavia", "type": "bridge", "bridge": "octbr", "ipam": { "type": "whereabouts", "range": "192.0.2.0/16", "range_start": "192.0.2.30", "range_end": "192.0.2.70", "routes": [ { "dst": "192.1.2.0/16", "gw" : "192.0.2.150" } ] } } EOF_CAT apply -n openstack -f octavia-net-attach-def.yaml
get net-attach-def -n openstack
NAME AGE ctlplane 25m datacentre 25m internalapi 25m octavia 25m storage 25m tenant 25m
echo -n my_password | base64
apiVersion: v1 data: server-ca-passphrase: <Base64_password> kind: Secret metadata: name: octavia-ca-passphrase namespace: openstack type: Opaque
oc create -f octavia-ca-passphrase.yaml
oc describe secret octavia-ca-passphrase -n openstack
patch -n openstack openstackcontrolplane controlplane --type=merge --patch ' spec: ovn: template: ovnController: networkAttachment: tenant nicMappings: octavia: octbr octavia: enabled: true template: octaviaHousekeeping: networkAttachments: - octavia octaviaHealthManager: networkAttachments: - octavia octaviaWorker: networkAttachments: - octavia '
oc get pods | grep octavia
octavia-api-5cf9bc78f7-4lmds 2/2 Running 0 42h octavia-healthmanager-5g94j 1/1 Running 0 21h octavia-housekeeping-5gtw8 1/1 Running 0 21h octavia-image-upload-78b4b6c47c-xzdtl 1/1 Running 0 35h octavia-worker-pq55m 1/1 Running 0 21h
oc rsh -n openstack openstackclient
openstack network list -f yaml
- ID: 2e4fc309-546b-4ac8-9eae-aa8d70a27a9b Name: octavia-provider-net Subnets: - eea45073-6e56-47fd-9153-12f7f49bc115 - ID: 77881d3f-04b0-46cb-931f-d54003cce9f0 Name: lb-mgmt-net Subnets: - e4ab96af-8077-4971-baa4-e0d40a16f55a
exit