1. Background
In the openshift cluster (hereinafter referred to as OCP), the forwarding of external traffic is achieved by controlling the routing rules in the Route object through the Router controller to overload the HAProxy configuration file in the Infra node.
In step 3 in the above figure, during the process of Router reloading the Haproxy configuration, the Haproxy service will be unavailable for a short period of time. So how to ensure that user requests are not lost during the Haproxy reloading process?
2. Haproxy’s strategy for handling seamless reloading in different versions
OpenShift 3.9 and above
OpenShift 3.9 and later ships with a HAProxy router image based on HAProxy 1.8 7. One feature that has been completed in HAProxy 1.8 is built-in seamless reloading. Pass the file descriptor of the listening socket to the new HAProxy process via: another socket. Since the socket is never closed, the delay in reloading the configuration is minimized!
OpenShift 3.7 and earlier
OpenShift 3.7 and earlier ships with HAProxy router images based on HAProxy 1.5 or earlier. These older versions do not come with the seamless reloading feature detailed above. An alternative solution to the missing seamless reload functionality (detailed below) has been put into the default reload script shipped with OpenShift. In OpenShift 3.7 and earlier, the Router’s DROP_SYN_DURING_RESTART environment variable must be set to true in order to enable this feature. Disabled by default. Additionally, the pod must have privileged access. Because the DROP_SYN_DURING_RESTART feature causes iptables rules (that’s why privileged access is required!) to be added to the application node that drops SYN packets during router reinstallation. Once the reload process is complete, this iptables rule will be removed, allowing SYN packets to return.
References:
- https://access.redhat.com/articles/3679861
- https://www.haproxy.com/blog/truly-seamless-reloads-with-haproxy-no-more-hacks/