// Module included in the following assemblies: // // * installing/installing_bare_metal/upi/installing-bare-metal.adoc // * installing/installing_bare_metal/upi/installing-bare-metal-network-customizations.adoc // * installing/installing_bare_metal/upi/installing-restricted-networks-bare-metal.adoc // * installing/installing_platform_agnostic/installing-platform-agnostic.adoc // * installing/installing_ibm_z/installing-ibm-z.adoc // * installing/installing_ibm_z/installing-restricted-networks-ibm-z.adoc // * installing/installing_ibm_z/installing-ibm-z-kvm.adoc // * installing/installing_ibm_z/installing-ibm-z-lpar.adoc // * installing/installing_ibm_z/installing-restricted-networks-ibm-z-lpar.adoc // * installing/installing_ibm_z/installing-ibm-power.adoc // * installing/installing_ibm_z/installing-restricted-networks-ibm-power.adoc // * installing/installing_openstack/installing-openstack-installer-custom.adoc ifeval::["{context}" == "installing-openstack-installer-custom"] :user-managed-lb: endif::[] :_mod-docs-content-type: CONCEPT [id="installation-load-balancing-user-infra-example_{context}"] ifndef::user-managed-lb[] = Example load balancer configuration for user-provisioned clusters [role="_abstract"] Reference the example API and application Ingress load balancer configuration so that you can understand how to meet the load balancing requirements for user-provisioned clusters. The sample is an `/etc/haproxy/haproxy.cfg` configuration for an HAProxy load balancer. The example is not meant to provide advice for choosing one load balancing solution over another. endif::user-managed-lb[] ifdef::user-managed-lb[] = Example load balancer configuration for clusters that are deployed with user-managed load balancers This section provides an example API and application Ingress load balancer configuration that meets the load balancing requirements for clusters that are deployed with user-managed load balancers. The sample is an `/etc/haproxy/haproxy.cfg` configuration for an HAProxy load balancer. The example is not meant to provide advice for choosing one load balancing solution over another. endif::user-managed-lb[] [TIP] ==== If you are using HAProxy as a load balancer, you can check that the `haproxy` process is listening on ports `6443`, `22623`, `443`, and `80` by running `netstat -nltupe` on the HAProxy node. ==== In the example, the same load balancer is used for the Kubernetes API and application ingress traffic. In production scenarios, you can deploy the API and application ingress load balancers separately so that you can scale the load balancer infrastructure for each in isolation. [NOTE] ==== If you are using HAProxy as a load balancer and SELinux is set to `enforcing`, you must ensure that the HAProxy service can bind to the configured TCP port by running `setsebool -P haproxy_connect_any=1`. ==== .Sample API and application Ingress load balancer configuration [source,text] ---- global log 127.0.0.1 local2 pidfile /var/run/haproxy.pid maxconn 4000 daemon defaults mode http log global option dontlognull option http-server-close option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 3000 listen api-server-6443 bind *:6443 mode tcp option httpchk GET /readyz HTTP/1.0 option log-health-checks balance roundrobin server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3 server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3 server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3 listen machine-config-server-22623 bind *:22623 mode tcp server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup server master0 master0.ocp4.example.com:22623 check inter 1s server master1 master1.ocp4.example.com:22623 check inter 1s server master2 master2.ocp4.example.com:22623 check inter 1s listen ingress-router-443 bind *:443 mode tcp balance source server compute0 compute0.ocp4.example.com:443 check inter 1s server compute1 compute1.ocp4.example.com:443 check inter 1s listen ingress-router-80 bind *:80 mode tcp balance source server compute0 compute0.ocp4.example.com:80 check inter 1s server compute1 compute1.ocp4.example.com:80 check inter 1s ---- where: `listen api-server-6443`:: Port `6443` handles the Kubernetes API traffic and points to the control plane machines. `server bootstrap bootstrap.ocp4.example.com`:: The bootstrap entries must be in place before the {product-title} cluster installation and they must be removed after the bootstrap process is complete. `listen machine-config-server`:: Port `22623` handles the machine config server traffic and points to the control plane machines. `listen ingress-router-443`:: Port `443` handles the HTTPS traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default. `listen ingress-router-80`:: Port `80` handles the HTTP traffic and points to the machines that run the Ingress Controller pods. The Ingress Controller pods run on the compute machines by default. + [NOTE] ==== If you are deploying a three-node cluster with zero compute nodes, the Ingress Controller pods run on the control plane nodes. In three-node cluster deployments, you must configure your application Ingress load balancer to route HTTP and HTTPS traffic to the control plane nodes. ==== ifeval::["{context}" == "installing-openstack-installer-custom"] :!user-managed-lb: endif::[]