Using the none driver sets the hostname to 'control-plane'

[afbjorklund]

This is not desired, the hostname should stay the way it is.

For multi-node VMs that we create ourselves, then sure.

But existing machines get to keep their current hostnames.

Seen in #11174 with CentOS 8 (systemd 239)

[afbjorklund]

This happens when systemd co-conspires with NetworkManager.

Apr 28 17:09:22 control-plane NetworkManager[873]: <info>  [1619622562.5389] policy: set-hostname: set hostname to 'control-plane.minikube.internal' (from address lookup)
Apr 28 17:09:22 control-plane systemd-hostnamed[885]: Changed host name to 'control-plane.minikube.internal'

Adding the address entry to the /etc/hosts file caused it, I think.

        /* Hostname precedence order:
         *
         * 1) a configured hostname (from settings)
         * 2) automatic hostname from the default device's config (DHCP, VPN, etc)
         * 3) the last hostname set outside NM
         * 4) reverse-DNS of the best device's IPv4 address
         *
         */

[afbjorklund]

Here is the way to reproduce this behaviour:

1. Start a CentOS 8 VM, let's call it "localhost"
2. Add an entry to /etc/hosts, for the -i interface
3. Reboot the VM, see the hostname change as well

This does not happen with Ubuntu 18.04, though.

(it uses systemd, but it doesn't use NetworkManager)
At least the Vagrant installation uses systemd-networkd.
So adding an address just makes it add a second entry.

[afbjorklund]

Also we add another entry for localhost, as "host.minikube.internal".

127.0.0.1    host.minikube.internal
10.0.2.15    control-plane.minikube.internal

Not sure if that makes any sense either, maybe just remove both ?

[sharifelgamal]

This should be as simple as skipping setting the hostname for the none or ssh drivers. Help wanted!

[afbjorklund]

This is actually a systemd "feature", and not something that is caused by minikube:

https://www.freedesktop.org/wiki/Software/systemd/hostnamed/

If you have a system without a "proper" hostname, and it gets a network interface host.
Then systemd assigns it a "transient" hostname, while keeping the "static" hostname:

$ hostnamectl 
   Static hostname: localhost.localdomain
Transient hostname: control-plane.minikube.internal
         Icon name: computer-vm
           Chassis: vm
        Machine ID: b164b6646e3f4d75aa151a3848a9ac20
           Boot ID: f690c03a68f04e408f057e7f86ce9e70
    Virtualization: oracle
  Operating System: CentOS Linux 8
       CPE OS Name: cpe:/o:centos:centos:8
            Kernel: Linux 4.18.0-240.1.1.el8_3.x86_64
      Architecture: x86-64

Ubuntu sets up a network for the host, so it is not affected:

127.0.0.1	localhost
127.0.1.1	ubuntu-focal	ubuntu-focal

CentOS does not add any host network, so it is affected:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4

Not showing IPv6 in the name of brevity, same thing for ::1.

---

When minikube goes and adds a name for the NAT interface, systemd picks it up.

10.0.2.15	control-plane.minikube.internal

There is still no name assigned to the "real" Host-Only interface, so that is nameless.

192.168.50.4	minikube

Old versions of Vagrant has some bug adding multiple entries for localhost <sigh>
So that is the same problem as with minikube, adding several lines with 127.0.0.1

It is supposed to be able to set the hostname in the Vagrantfile, on a specific interface.
The workaround is doing it manually in a provision script, for the affected versions.

[afbjorklund]

Note: Removing the "control-plane" name for the kubernetes host interface breaks functionality.
Kubernetes has always chosen the "wrong" network interface to run on, on these VM setups...

    server: https://control-plane.minikube.internal:8443

For minikube it might be a feature, since it means it is not exposed to the outside by mistake.
The real address is added to the certificate hostnames, in case it is later exposed on purpose.

  certSANs: ["127.0.0.1", "localhost", "192.168.50.4"]

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten