github.com/openshift/installer@v1.4.17/docs/user/metal/external_loadbalancer_ipi.md (about) 1 # Using a Custom External Load Balancer - post deployment 2 3 You can shift api/ingress traffic from the default self-hosted load balancer to a load balancer that you provide. To do so, the instance that it runs from must be able to access every machine in your cluster. You might ensure this access by creating the instance on a subnet that is within your cluster's network. 4 5 ## External Facing OpenShift Services 6 7 Add the following external facing services to your new load balancer: 8 9 - The master nodes serve the OpenShift API on port 6443 using TCP. 10 - The apps hosted on the master and worker nodes are served on ports 80, and 443. They are both served using TCP. 11 12 ## HAProxy Example Load Balancer Config 13 14 The following `HAProxy` config file demonstrates a basic configuration for an external load balancer: 15 16 ```haproxy 17 18 defaults 19 mode tcp 20 log global 21 timeout connect 30s 22 timeout client 1m 23 timeout server 1m 24 frontend <cluster-name>-api-6443 25 bind :::6443 v4v6 26 default_backend api 27 frontend <cluster-name>-apps-80 28 bind :::80 v4v6 29 default_backend ingress 30 frontend <cluster-name>-apps-443 31 bind :::443 v4v6 32 default_backend ingress-sec 33 backend api 34 option httpchk GET /readyz HTTP/1.0 35 option log-health-checks 36 balance roundrobin 37 server master-0 <master0-IP>:6443 check check-ssl inter 1s fall 2 rise 3 verify none 38 server master-1 <master1-IP>:6443 check check-ssl inter 1s fall 2 rise 3 verify none 39 server master-2 <master2-IP>:6443 check check-ssl inter 1s fall 2 rise 3 verify none 40 backend ingress 41 option httpchk GET /healthz/ready HTTP/1.0 42 option log-health-checks 43 balance roundrobin 44 server master-0 <master0-IP>:80 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 45 server master-1 <master1-IP>:80 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 46 server master-2 <master2-IP>:80 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 47 server worker-0 <worker0-IP>:80 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 48 server worker-1 <worker1-IP>:80 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 49 backend ingress-sec 50 option httpchk GET /healthz/ready HTTP/1.0 51 option log-health-checks 52 balance roundrobin 53 server master-0 <master0-IP>:443 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 54 server master-1 <master1-IP>:443 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 55 server master-2 <master2-IP>:443 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 56 server worker-0 <worker0-IP>:443 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 57 server worker-1 <worker1-IP>:443 check check-ssl port 1936 inter 1s fall 2 rise 3 verify none 58 ``` 59 60 ## DNS Lookups 61 62 To ensure that your API and apps are accessible through your load balancer, create or update your DNS entries for those endpoints. To use your new load balancing service for external traffic, make sure the IP address for these DNS entries is the IP address your load balancer is reachable at. 63 64 ```dns 65 <load balancer ip> api.<cluster-name>.<base domain> 66 <load balancer ip> apps.<cluster-name>.base domain> 67 ``` 68 69 ## Verifying that the API is Reachable 70 71 One good way to test whether or not you can reach the API is to run the `oc` command. If you can't do that easily, you can use this curl command: 72 73 ```sh 74 curl https://api.<cluster-name>.<base domain>:6443/version --insecure 75 ``` 76 77 Result: 78 79 ```json 80 { 81 "major": "1", 82 "minor": "20", 83 "gitVersion": "v1.20.0+ba45583", 84 "gitCommit": "ba455830ecb91ff61bb61ca4f70b6f3f4a5e3796", 85 "gitTreeState": "clean", 86 "buildDate": "2021-02-05T22:18:43Z", 87 "goVersion": "go1.15.5", 88 "compiler": "gc", 89 "platform": "linux/amd64" 90 } 91 ``` 92 93 Note: The versions in the sample output may differ from your own. As long as you get a JSON payload response, the API is accessible. 94 95 ## Verifying that Apps Reachable 96 97 The simplest way to verify that apps are reachable is to open the OpenShift console in a web browser. If you don't have access to a web browser, query the console with the following curl command: 98 99 ```sh 100 curl http://console-openshift-console.apps.<cluster-name>.<base domain> -I -L --insecure 101 ``` 102 103 104 Result: 105 106 ```http 107 HTTP/1.1 302 Found 108 Cache-Control: no-cache 109 Content-length: 0 110 Location: https://console-openshift-console.apps.<cluster-name>.<base domain>/ 111 112 HTTP/1.1 200 OK 113 Referrer-Policy: strict-origin-when-cross-origin 114 Set-Cookie: csrf-token=ZPwr8qTwPBh/NQjoENlDWxmACNEsLl1PYrQyyX87wnIm5AnBrwv3dEqpZwClwpN4nWlGp2ufBh7KbM0ycwLQpQ==; Path=/; Secure 115 X-Content-Type-Options: nosniff 116 X-Dns-Prefetch-Control: off 117 X-Frame-Options: DENY 118 X-Xss-Protection: 1; mode=block 119 Date: Wed, 17 Mar 2021 09:18:06 GMT 120 Content-Type: text/html; charset=utf-8 121 Set-Cookie: 1e2670d92730b515ce3a1bb65da45062=1115fecfa3e981219adba594404c9b69; path=/; HttpOnly; Secure; SameSite=None 122 Cache-control: private 123 ```