If anyone is having issues getting this to run, it may be because it defaults to the eth0 interface. Practially all newer distros use the “predictive naming model” that assigns names based on bus/slot numbers to keep names persistent between reboots (mainly for) multi adpater systems instead of just counting up from 0. You can use the envrionmental variable KEEPALIVED_INTERFACE to set it to whatever your network interface is (see ip a).
If you’re running this on an ARM based cluster (RPI 4 etc), you may run into some issues with the keepalived image from osixia. The problems were fixed here: Fix ARM builds e.g. for keepalived by linkvt · Pull Request #28 · osixia/docker-light-baseimage · GitHub
but it looks like the build failed when deploying that update to the base image.
TLDR you can use the linkvt/osixia_keepalived image in the meantime (it was a testbuild for the fix).
Replace osixia/keepalived with linkvt/osixia_keepalived:stable
Perhaps a bit late, but I had the same problem. I solved this by setting the priority of the master from 200 to 255.
It turns out the specification of keepalived indicates that the master’s priority should be 255 , with any backup servers having a value lower than 255. In practice, a priority of 255 isn’t strictly necessary as the protocol will select the server with the highest priority, even if it isn’t 255..
The side effect of having a priority lower then 255 for the master, is keepalived does not return control to the master. When I set the priority of the master to 255, this was solved. When the master is rebooted, keep alive returns control to the master.
are you guys running the container in privileged mode?
isn’t the ```
KEEPALIVED_INTERFACE
I get the error: Non-existent interface specified in configuration when running keepalived docker container.