Chapter 21. Load balancing on RHOSP

1. Open the kuryr-config ConfigMap. On a command line, enter:

   $ oc -n openshift-kuryr edit cm kuryr-config

2. In the ConfigMap, delete the line that contains kuryr-octavia-provider: default. For example:

   ...
   kind: ConfigMap
   metadata:
     annotations:
       networkoperator.openshift.io/kuryr-octavia-provider: default 1
   ...

   1

   Delete this line. The cluster will regenerate it with ovn as the value.

   Wait for the Cluster Network Operator to detect the modification and to redeploy the kuryr-controller and kuryr-cni pods. This process might take several minutes.

3. Verify that the kuryr-config ConfigMap annotation is present with ovn as its value. On a command line, enter:

   $ oc -n openshift-kuryr edit cm kuryr-config

   The ovn provider value is displayed in the output:

   ...
   kind: ConfigMap
   metadata:
     annotations:
       networkoperator.openshift.io/kuryr-octavia-provider: ovn
   ...

4. Verify that RHOSP recreated its load balancers.

   1. On a command line, enter:

      $ openstack loadbalancer list | grep amphora

      A single Amphora load balancer is displayed. For example:

      a4db683b-2b7b-4988-a582-c39daaad7981 | ostest-7mbj6-kuryr-api-loadbalancer  | 84c99c906edd475ba19478a9a6690efd | 172.30.0.1     | ACTIVE              | amphora

   2. Search for ovn load balancers by entering:

      $ openstack loadbalancer list | grep ovn

      The remaining load balancers of the ovn type are displayed. For example:

      2dffe783-98ae-4048-98d0-32aa684664cc | openshift-apiserver-operator/metrics | 84c99c906edd475ba19478a9a6690efd | 172.30.167.119 | ACTIVE              | ovn
      0b1b2193-251f-4243-af39-2f99b29d18c5 | openshift-etcd/etcd                  | 84c99c906edd475ba19478a9a6690efd | 172.30.143.226 | ACTIVE              | ovn
      f05b07fc-01b7-4673-bd4d-adaa4391458e | openshift-dns-operator/metrics       | 84c99c906edd475ba19478a9a6690efd | 172.30.152.27  | ACTIVE              | ovn

Procedure

1. To copy the current internal router service, on a command line, enter:

   $ oc -n openshift-ingress get svc router-internal-default -o yaml > external_router.yaml

2. In the file external_router.yaml, change the values of metadata.name and spec.type to LoadBalancer.

   Example router file

   apiVersion: v1
   kind: Service
   metadata:
     labels:
       ingresscontroller.operator.openshift.io/owning-ingresscontroller: default
     name: router-external-default 1
     namespace: openshift-ingress
   spec:
     ports:
     - name: http
       port: 80
       protocol: TCP
       targetPort: http
     - name: https
       port: 443
       protocol: TCP
       targetPort: https
     - name: metrics
       port: 1936
       protocol: TCP
       targetPort: 1936
     selector:
       ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
     sessionAffinity: None
     type: LoadBalancer 2

   1

   Ensure that this value is descriptive, like router-external-default.

   2

   Ensure that this value is LoadBalancer.

1. From a command line, create a service from the external_router.yaml file:

   $ oc apply -f external_router.yaml

2. Verify that the external IP address of the service is the same as the one that is associated with the load balancer:

   1. On a command line, retrieve the external IP address of the service:

      $ oc -n openshift-ingress get svc

      Example output

      NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                                     AGE
      router-external-default   LoadBalancer   172.30.235.33    10.46.22.161   80:30112/TCP,443:32359/TCP,1936:30317/TCP   3m38s
      router-internal-default   ClusterIP      172.30.115.123   <none>         80/TCP,443/TCP,1936/TCP                     22h

   2. Retrieve the IP address of the load balancer:

      $ openstack loadbalancer list | grep router-external

      Example output

      | 21bf6afe-b498-4a16-a958-3229e83c002c | openshift-ingress/router-external-default | 66f3816acf1b431691b8d132cc9d793c | 172.30.235.33  | ACTIVE | octavia |

   3. Verify that the addresses you retrieved in the previous steps are associated with each other in the floating IP list:

      $ openstack floating ip list | grep 172.30.235.33

      Example output

      | e2f80e97-8266-4b69-8636-e58bacf1879e | 10.46.22.161 | 172.30.235.33 | 655e7122-806a-4e0a-a104-220c6e17bda6 | a565e55a-99e7-4d15-b4df-f9d7ee8c9deb | 66f3816acf1b431691b8d132cc9d793c |

Procedure

1. Enable access to the cluster from your load balancer on ports 6443, 443, and 80.

   As an example, note this HAProxy configuration:

   A section of a sample HAProxy configuration

   ...
   listen my-cluster-api-6443
       bind 0.0.0.0:6443
       mode tcp
       balance roundrobin
       server my-cluster-master-2 192.0.2.2:6443 check
       server my-cluster-master-0 192.0.2.3:6443 check
       server my-cluster-master-1 192.0.2.1:6443 check
   listenmy-cluster-apps-443
           bind 0.0.0.0:443
           mode tcp
           balance roundrobin
           server my-cluster-worker-0 192.0.2.6:443 check
           server my-cluster-worker-1 192.0.2.5:443 check
           server my-cluster-worker-2 192.0.2.4:443 check
   listenmy-cluster-apps-80
           bind 0.0.0.0:80
           mode tcp
           balance roundrobin
           server my-cluster-worker-0 192.0.2.7:80 check
           server my-cluster-worker-1 192.0.2.9:80 check
           server my-cluster-worker-2 192.0.2.8:80 check

2. Add records to your DNS server for the cluster API and apps over the load balancer. For example:

   <load_balancer_ip_address> api.<cluster_name>.<base_domain>
   <load_balancer_ip_address> apps.<cluster_name>.<base_domain>

3. From a command line, use curl to verify that the external load balancer and DNS configuration are operational.

   1. Verify that the cluster API is accessible:

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure

      If the configuration is correct, you receive a JSON object in response:

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }

   2. Verify that cluster applications are accessible:

      Note

      You can also verify application accessibility by opening the OpenShift Container Platform console in a web browser.

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      If the configuration is correct, you receive an HTTP response:

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private