When using static IPs network manager will do reverse dns lookups to set the
hostname of the node. When that node is the boot strap is can set the hostname
as api-int. when the api_vip bridge is brought up. This causes
and issue with the bootkube container as it uses --network=host, podman will
therefore insert the hostname of the host into containers /etc/hosts pointing
it to 127.0.1.1. If the kubeboot container starts before network manager, network manager
reverts the hostname (as the brige is removed) then the bootkube container
will be unable to communicate with the clusters kubeapi as it will be redirected
to 127.0.1.1 as per the /etc/hosts file. This causes the cluster installation
to fail.
To work around this issue crucible has a flag use_hostname_workaround
this will set NetworkManager's hostname-mode=none. This means that network manger
will not set the hostname. It will also inject a systemd service to set the
hostname based on the mac address.
When using static IPs network manager will do reverse dns lookups to set the hostname of the node. When that node is the boot strap is can set the hostname as api-int. when the api_vip bridge is brought up. This causes
and issue with the bootkube container as it uses --network=host, podman will
therefore insert the hostname of the host into containers /etc/hosts pointing
it to 127.0.1.1. If the kubeboot container starts before network manager, network manager
reverts the hostname (as the brige is removed) then the bootkube container
will be unable to communicate with the clusters kubeapi as it will be redirected
to 127.0.1.1 as per the /etc/hosts file. This causes the cluster installation
to fail.
To work around this issue crucible has a flag use_hostname_workaround this will set NetworkManager's hostname-mode=none. This means that network manger will not set the hostname. It will also inject a systemd service to set the hostname based on the mac address.