Currently, the keepalived priority is influenced by a track_file which is supposed to represent that the LBM matches the latest revision. This allows for a rolling update, since all older instances will have a lower priority.
However, the track file is not always removed correctly, for example if the yawollet cannot reach the API-Server at all. So this change replaces the file-based check with a health endpoint, which is checked by keepalived via track_script. This now covers 3 conditions:
is the yawollet running correctly (if now wget gets no response/timeouts)
are the informers/caches synced
is the LBM the current revision
Is the LBM condition heartbeat up-to-date.
The last check is essentially a check if we can reach the API-Server. We could call the /healthz endpoint, but that might cause unnecessary load. By checking the conditions that the yawollet should be writing itself, we check both that we can write and read (watch) successfully from the API-Server without causing additional calls.
Currently, the keepalived priority is influenced by a
track_filewhich is supposed to represent that the LBM matches the latest revision. This allows for a rolling update, since all older instances will have a lower priority.However, the track file is not always removed correctly, for example if the yawollet cannot reach the API-Server at all. So this change replaces the file-based check with a health endpoint, which is checked by keepalived via
track_script. This now covers 3 conditions:The last check is essentially a check if we can reach the API-Server. We could call the
/healthzendpoint, but that might cause unnecessary load. By checking the conditions that the yawollet should be writing itself, we check both that we can write and read (watch) successfully from the API-Server without causing additional calls.