K3S-Deploy: Issues on Ubuntu Server 22.04

[fabionl]

Had a few issues when running the K3S deploy script (k3s.sh). I'm trying to describe my steps to manually handle the issues in the hopes that it will help the magicians find work arounds to improve the scripts. :)

Context

Using k3s deploy on VMs with Ubuntu Server 22.04 minimal installation.

VMs are setup with 4GB RAM and 4 processors, and are running on a mini pc with 32GB of RAM running XCP-NG hypervisor.

• Created an admin VM (4GB + 4 processors)
• Updated apt
• Installed XCP-NG guest tools
• Installed ssh
• Created ssh key
• Shut down the VM, and created a snapshot
• From the snapshot, created 5 new VMs
• Went through each VM to edit hostname and Netplan ip address
• Shutdown the newly created VMs and snapshot them
• Turned all VM on

Issues

At this point I expected to have everything ready to run the script, but the script end up in a loop with error stating that could not reach the api on localhost. At first I thought it was a firewall config, but turns out there were errors when running the script.

It was going all the way through, so in order to find the issues we need to check every log message and eventually find the failing commands in the script.

After some time, I noticed the k3sup command in the script failed because SSH requires the user password. I haven't found a way around this, so end up changing ssh config on all VMs to not require password for my username (sudo visudo, and below the config for root added a line for the user with last argument NOPASSWD: ALL).

Warning: This is not an ideal solution because it essentially opens a big security whole.

Another command that was also failing: kubectl apply -f ~/ipAddressPool.yaml. This was leading to nginx not being reachable (displays external IP as pending). Manually running it again solved the issue.

Sorry for messy notes. Hope this is helpful. :)

[Simon-CR]

I have the same issue. using 24.04 however (not much of a difference for this kind of issue). I've also increased all the version numbers to the latest available.

[Simon-CR]

for the first issue, at the very least, we can add something like this to a snippet:

cloud-config

users:

• name: your-username sudo: ALL=(ALL) NOPASSWD:ALL groups: sudo shell: /bin/bash

a more secure compromise would be to use a PAM module to restrict the password less sudo to console authenticated selected users, or users that authenticated using a key pair (skipping anyone who authenticated with a password (assuming it's allowed).

OR just disable the passwordless once the deployment is complete..