While Deploying an BareOS Multi-Master cluster, as of know the PMK management plane takes inputs of API FQDN and VIP out of which the VIP is an mandatory field.
If we add only VIP and later when the cluster gets deployed, keepalived gets install on all the masters which manages the VIP placement on one of masters at any point of time. The cluster kubconfig file points to that VIP.
Now if we also add some FQDN (along with VIP as its mandatory) then the kubeconfig gets that FQDN rather than VIP.
With an intention to use an external LB solution like F5/Haproxy etc for API, customer can make that FQDN resolve to the IP of that external LB, however in that case TWO solutions to manage API are getting implemented at the same time - external LB and internal keepalived.
If the FQDN is getting resolved to the VIP itself then again customer has to rely on internal keepalived for API management, external LB can't be used in that case.
Thus rather then making API VIP as mandatory field, if any one field is made mandatory then it will solve the issue. So customer will either input FQDN or VIP.