In VKS environment using HAProxy as the Load Balancer, the HAProxy service fails to start and remains in a down state when the process is restarted after adding a new IP address range from the vSphere Client (Supervisor --> Configure --> Network --> Virtual IP Ranges).
# systemctl list-units --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● haproxy.service loaded failed failed HAProxy Load Balancer
The journalctl logs record an alert indicating a failure to bind a socket to the newly added IP address.
# journalctl -r -u haproxy
MM DD hh:mm:ss <HAPROXY_FQDN> haproxy[xxxx]: [ALERT] 058/133339 (5623) : Starting frontend domain-c####:####-default-loadbalancer-svc-##: cannot bind socket [<NEW_ADDED_VIRTUAL_IP_RANGE_IP_ADDRESS>:PORT]
HAProxy in vSphere Kubernetes Service
When a new "Virtual IP Ranges" is added from the vSphere Client and an EXTERNAL-IP is allocated from that range to a Kubernetes Service, the HAProxy configuration file (/etc/haproxy/haproxy.cfg) is automatically updated with the settings for the new IP address.
However, this newly added IP address range is not automatically reflected in the routing configuration (/etc/vmware/anyip-routes.cfg) on the HAProxy appliance.
As a result, the HAProxy process cannot bind to the new IP address, which causes the service to fail during startup.
Note: Adding additional Virtual IP Ranges to HAProxy in a VKS environment is not officially supported. The following steps serve as a temporary workaround.
1. Manually add the new Virtual IP Ranges to /etc/vmware/anyip-routes.cfg.
vi /etc/vmware/anyip-routes.cfg
192.168.aaa.bbb/28 # Existing Virtual IP Ranges
192.168.ccc.ddd/28 # <---------- Add New Virtual IP Ranges manually
2. Restart the anyip-routes service and verify that the changes are reflected in the routing table.
systemctl restart anyip-routes
systemctl status anyip-routes
ip route list table local | grep local
#> ...
#> local 192.168.aaa.bbb/28 dev lo scope host
#> local 192.168.ccc.ddd/28 dev lo scope host # <-- New routing entry
3. Restart the HAProxy service and verify that its status becomes active.
systemctl restart haproxy
systemctl status haproxy # active (running)