Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow hostname to be set via user-data #1608

Closed
jaxesn opened this issue Jun 10, 2021 · 2 comments · Fixed by #1664
Closed

Allow hostname to be set via user-data #1608

jaxesn opened this issue Jun 10, 2021 · 2 comments · Fixed by #1664
Assignees
Labels
area/core Issues core to the OS (variant independent) type/enhancement New feature or request
Milestone

Comments

@jaxesn
Copy link

jaxesn commented Jun 10, 2021

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:

@jhaynes jhaynes added area/core Issues core to the OS (variant independent) priority/p1 status/needs-triage Pending triage or re-evaluation type/enhancement New feature or request labels Jun 14, 2021
@jhaynes jhaynes added this to the next+1 milestone Jun 14, 2021
@zmrow zmrow self-assigned this Jun 21, 2021
@zmrow
Copy link
Contributor

zmrow commented Jul 2, 2021

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.

@zmrow
Copy link
Contributor

zmrow commented Jul 20, 2021

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.

@jhaynes jhaynes added status/in-progress This issue is currently being worked on and removed status/needs-triage Pending triage or re-evaluation labels Jul 22, 2021
@bcressey bcressey removed the status/in-progress This issue is currently being worked on label Nov 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/core Issues core to the OS (variant independent) type/enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants