You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I'd like:
When using bottlerocket with CAPV the hostname resolves as the IP of the node. It is unknown if this causes any real issues, but it has the unfortunate side-effect of naming the kubernetes nodes based on this IP instead of the CAPV set hostname. This creates an inconsistency when working with CAPV based clusters between bottlerocket and other OSs as well as the node names not matching the CAPV objects that are created in the cluster.
It would be great if the hostname could be set as part of the user-data or some other bootstrapping process to avoid this inconsistency.
Any alternatives you've considered:
The text was updated successfully, but these errors were encountered:
Update: I have an implementation of this over on my fork. It took a little bit of thinking and is a bit different than the addition of most other settings. For details on the implementation, see the PR link above.
Issues with setting hostname
At first blush, setting hostname seems fairly harmless. But because hostname is closely tied to the kubelet identity both for registration and certificate/auth purposes we have to be extremely careful.
In AWS EKS variants, setting hostname to anything other than the EC2 instance ID causes issues with kubelet registration.
For VMware variants, setting hostname is useful to match the VM name, and will be helpful to support CAPV in the future. In this case, if we set it at boot time before kubelet registration, it may work just fine.
However, because settings in the API can be freely set at any time, at boot and after the fact, we can't prevent hostname from being changed at any time. We can't provide a known way for users to break their system in both known and unknown ways by setting hostname after boot and borking their kubelet.
We're going to mull this over a bit and will update this issue with the ideas we've come up with.
After some additional discussion with the team, we've decided to move forward without any extra guards for this setting in the api server. We will document the fact that changing the hostname at runtime (after first boot), can cause issues with kubelet.
What I'd like:
When using bottlerocket with CAPV the
hostname
resolves as the IP of the node. It is unknown if this causes any real issues, but it has the unfortunate side-effect of naming the kubernetes nodes based on this IP instead of the CAPV set hostname. This creates an inconsistency when working with CAPV based clusters between bottlerocket and other OSs as well as the node names not matching the CAPV objects that are created in the cluster.It would be great if the hostname could be set as part of the user-data or some other bootstrapping process to avoid this inconsistency.
Any alternatives you've considered:
The text was updated successfully, but these errors were encountered: