-
Notifications
You must be signed in to change notification settings - Fork 524
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
Add a new setting for configuring hostname #1664
Conversation
fn generate_hostname() -> Result<()> { | ||
let ip_string = | ||
fs::read_to_string(CURRENT_IP).context(error::CurrentIpReadFailed { path: CURRENT_IP })?; | ||
let ip = IpAddr::from_str(&ip_string).context(error::IpFromString { ip: &ip_string })?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be good to add this deserialization check to node_ip()
also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll open a separate PR for this.
This removes the custom argument parsing logic in favor of using `argh`. `argh` makes it simpler to add additional subcommands that may or may not have their own arguments.
This adds a new subcommand `generate-hostname` that is meant to be used as a settings generator. It will attempt to read the current IP from file and resolve it via DNS reverse lookup. If the lookup is successful it is used, otherwise the IP is used with dots replaced by dashes to avoid any confusion from other software that may attempt to read it, e.g "1.2.3.4" will end up being hostname "ip-1-2-3-4".
This adds a new subcommand `set-hostname` that sets the hostname for the system by writing it to `/proc/sys/kernel/hostname`
^ Addresses @bcressey 's comments! |
^ Rebases on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. If we know changing the hostname during runtime is harmful for k8s variants (might be variant specific). We should probably think of a way to disallow that.
edit: sorry just remembered it's already covered in an follow up issue
This commit adds the ability to configure the hostname of the system via a new setting `settings.network.hostname`. If the setting isn't populated, at boot time we use the settings generator `netdog generate-hostname` to populate it. The generator attempts to resolve the current IP via reverse lookup, and if unsuccessful uses the IP to create a hostname in the format "ip-x-x-x-x". A new service `set-hostname` runs after `settings-applier` and writes the hostname to `/proc/sys/kernel/hostname` via `netdog set-hostname $HOSTNAME`. The service unit file uses an env file that is a template using the setting `settings.network.hostname` to populate the $HOSTNAME variable.
This adds the migrations needed for `settings.network.hostname`, one for the setting, its service and configuration file, and one for the setting generator metadata.
Sorry for pointing this out after the fact. The next release version should be v1.2.0 so the migrations path and Release.toml needs to be updated from v1.1.5 to v1.2.0. |
I'm a bit confused - I thought that EKS forced us to always use the |
Hi @diranged - as mentioned in the setting documentation in the README, most users shouldn't need to touch this setting as the defaults make sure that the hostname is set the same as it always has been. In VMware, this setting can be useful to set the hostname the same as the VM name so I expect it will get the most use there. If you're primarily running in EC2 - you shouldn't ever need to touch this setting. :) |
Issue number:
Fixes #1608
Description of changes:
Reading through this PR by commit will probably be easiest.
Previously, hostname was written directly to disk by
netdog
called bywicked
early in boot. At the point in the boot sequence whenwicked
callsnetdog
, the API server isn't up yet. Rather than rework the boot sequence (which would be tricky as this point in boot) and add the ability to netdog to talk to the API, we opted to add a subcommand tonetdog
as a settings generator for the newsettings.network.hostname
setting. The setting is used in a template file, which is an env file for a new systemd unit that callsnetdog set-hostname
. This command is what will write the hostname to disk at/proc/sys/kernel/hostname
.This means that at boot time, if a user has the
hostname
setting in their user data, we will use it, otherwise we will set the hostname using largely the same logic as was in the program previously. (The only change is that if the DNS reverse lookup fails, we use the IP in the format "ip-x-x-x" as the hostname).netdog
was reworked to useargh
for argument parsing since our custom logic was starting to get unwieldy with the addition of more subcommands with their own arguments.Testing done:
/etc/resolv.conf
is populated in all casesapiclient
at runtime.kubelet
logs some errors. I can't speak to what will happen to the kubelet or if it will continue to function or for how long.No
settings.network.hostname
in user data:aws-k8s-1.19
: it starts, gets a correct hostname, and connects to the cluster just fine and runs a podvmware-k8s-1.20
: it starts, gets the stringip-x-x-x-x
as its hostname, connects to the cluster, runs a podsettings.network.hostname="br-test-1"
in user data:aws-k8s-1.10
: it boots, gets the hostname from user data, but (correctly) doesn't ever become ready in the cluster.vmware-k8s-1.20
: it boots, gets hostname from user data, and shows up neatly in the cluster, runs a pod.Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.