K3S Autoinstall get wrong hostname

[amalashin]

Required Information

• DietPi version
  G_DIETPI_VERSION_CORE=7
  G_DIETPI_VERSION_SUB=3
  G_DIETPI_VERSION_RC=2
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'

• Distro version
  buster 10.10

• Kernel version
  Linux saffron 5.10.17-v8+ #1421 SMP PREEMPT Thu May 27 14:01:37 BST 2021 aarch64 GNU/Linux

• SBC model
  RPi 4 Model B (aarch64)

• Power supply used
  5V 10W

• SDcard used
  SanDisk ultra

Additional Information (if applicable)

• Software title
  K3S

• Was the software title installed freshly or updated/migrated?
  Freshly autonstalled

• Can this issue be replicated on a fresh installation of DietPi?
  yes

Steps to reproduce

1. Set dietpi.txt options:
   • AUTO_SETUP_NET_HOSTNAME=myhostname
   • AUTO_SETUP_INSTALL_SOFTWARE_ID=193
   • SOFTWARE_K3S_EXEC=server --disable servicelb --disable traefik --disable local-storage
2. Add " cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory" to thecmdline.txt

Expected behaviour

• kubectl get nodes should show myhostname at the nodes list

Actual behaviour

• kubectl get nodes shows dietpi at the nodes list

Extra details

• by default with autoinstall option of the K3S, the system should change hostname to the AUTO_SETUP_NET_HOSTNAME

[Joulinar]

Hi,

Did you restart your system after installation?

[amalashin]

Sure. After the reboot I have two nodes one with NotReady state.

root@myhostname:~# kubectl get nodes -o wide
NAME      STATUS     ROLES                  AGE     VERSION        INTERNAL-IP     EXTERNAL-IP   OS-IMAGE                       KERNEL-VERSION   CONTAINER-RUNTIME
myhostname   Ready      control-plane,master   80s     v1.21.2+k3s1   192.168.6.101   <none>        Debian GNU/Linux 10 (buster)   5.10.17-v8+      containerd://1.4.4-k3s2
dietpi    NotReady   control-plane,master   4m56s   v1.21.2+k3s1   192.168.6.101   <none>        Debian GNU/Linux 10 (buster)   5.10.17-v8+      containerd://1.4.4-k3s2

Moreover, it is not trivial to remove old node because of system pods are bound to that node with Terminating state.

root@myhostname:~# kubectl get pods -A
NAMESPACE     NAME                                      READY   STATUS        RESTARTS   AGE
kube-system   local-path-provisioner-5ff76fc89d-n8fkq   1/1     Terminating   0          17m
kube-system   coredns-7448499f4d-wp9nc                  1/1     Terminating   0          17m
kube-system   metrics-server-86cbb8457f-bqj9r           1/1     Terminating   0          17m
kube-system   metrics-server-86cbb8457f-chb8x           1/1     Running       0          10m
kube-system   local-path-provisioner-5ff76fc89d-chtzw   1/1     Running       0          10m
kube-system   coredns-7448499f4d-q54kq                  1/1     Running       0          10m

So, I should forcibly delete old system pods, and then I can delete the old dietpi node. It seems like in this case (k3s autoinstall) some scripts should set node-name parameter to K3S_EXEC variable.

[Joulinar]

@MichaIng
can you have a look. Another case where the hostname change would need to be initiated on fist install before any other software installation continue.

[MichaIng]

I'll test if hostname <new_hostname> from within a script is sufficient or if a reboot is required in any case. If so, we can add a forced reboot after firstrun installs when K3s was installed, just as it was before we removed the mandatory reboot some versions ago. That would be done prior to service starts, so the node is not created in the first place.

Another good point is adding the cgroups on RPi. We do that for Docker installs on Armbian-based systems, but we should as well do it on K3s installs and on RPi. There has been some back and forth whether the memory cgroup is enabled by default or not and latest master has it again disabled: raspberrypi/linux@2b13c54

[amalashin]

I can confirm that by adding --node-name myhostname to the SOFTWARE_K3S_EXEC at dietpi.txt works as a workaround. Maybe it will be a good idea to place this option based on the hostname to the config file or to the service startup file with ExecStart=.

[MichaIng]

The hostname is now additionally applied via hostname command: b5d86e4
I'll test if this is sufficient for K3s to pick up the new one.

[MichaIng]

Okay, works fine:

/boot/dietpi/func/change_hostname anotherone # The script called on first boot and by dietpi-config to change the hostname
dietpi-software install 193 # Install K3s
kubectl get nodes -o wide

NAME         STATUS   ROLES                  AGE     VERSION        INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                       KERNEL-VERSION    CONTAINER-RUNTIME
anotherone   Ready    control-plane,master   2m38s   v1.21.2+k3s1   192.168.1.22   <none>        Debian GNU/Linux 10 (buster)   4.19.0-17-amd64   containerd://1.4.4-k3s2

This theoretically makes the reboot obsolete. Running processes which use the hostname usually need to be restarted though, including the shell itself, e.g. the bash PS1 \h expands to the old hostname for already running bash instances.