We are running a deploy of Kubernetes on Canonical distribution with Juju on a local vSphere 6.5 cluster, but we noticed a DHCP related issue when adding a new kubernetes worker (via "juju add-unit kubernetes-worker").

While the new VM gets created without problems, the following sequence happens on first power up, just before network is up:

1) the hostname is initially set as "ubuntu"

2) networking is started up and a DHCP request for an IP lease is made, using hostname "ubuntu" (thus the DHCP server record the lease as "ubuntu")

3) the hostname is changed to proper value (ie: "juju-fe12e1-11"), but no additional DHCP request is sent to update the lease information, leaving it indefinitely as "ubuntu"

So basically on the DHCP server all the IP leases have the same "ubuntu" assigned name, and the same happens on the local DNS server as automatic update of records by DHCP server is enabled on our local environment.

Of course manually restarting the VMs once fixes the situation, because at second boot the hostname is already correct and the DHCP registration has the correct "juju-xxxxxx-xx" name (the same would happens also if a dhclient release/renew command would be issued without actual rebooting). The trouble is that until either one of these actions is taken, the node is unresolvable by DNS name and that also cause some Kubernetes side issues.

Does everybody know of a way to effect this behaviour and have the DHCP name registration consistent with actual hostname without requiring manual intervention ?

Else, there is any possibility to have the sequence of operations that runs at boot fixed in a way that a DHCP renew command is properly issued after the hostname is changed ? (this would be enough to make the name records consistent)



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.