K3s-server uses 10% CPU for no reason

Heyo, I would like to continue the discussion of k3s-server uses 10% CPU for no reason | Page 3 | TrueNAS Community. I found the blog Resolved: High Idle CPU Usage Bug in k3s - A Milestone for Stability that was monitoring this issue for a long time and could finally report that this has been resolved in version 1.28 of k3s. Any chance we could upgrade in dragon fish? it still has 1.26 :cry: :pray:

With the next major update later this year k3s will be depreciated and replaced by native docker. So i dont think iX will invest time in something that will be removed later this year.

1 Like

LarsR is correct. Upgrading k3s version in a dot release is very risky so we have no reason to do it unless there is another very critical bug (vulnerability) that cannot be backported.

An interim solution, if you use docker apps, would be to use jailmaker to host them instead, until the official rework of the app subsystem is complete.

More work to set up compared to official TN apps but once up it uses less resources.

1 Like

…although this may be another reason TrueCharts are suggesting that a VM-based replacement would require less system overhead than the system as it currently exists. They expect to have their beta out early next month.

But even with less CPU overhead I don’t want my files to live inside the VM zvol (which is a filesystem, e.g. ext4 on top of the zfs filesystem). Nor do I want to create a dedicated zvol for files inside the VM and I don’t want to make the files available to the VM via NFS or SMB either for performance, compatibility and security reasons. Even if virtiofs could be used to mount host directories inside a VM on SCALE (which currently isn’t possible) that would still cause a noticeable performance hit. I’m curious what they come up with of course but I don’t see how this could become great.

The biggest problem I have with NFS is how it handles nested datasets–if I have datasets of video and video/tv, and expose video via SMB, everything in video/tv is available as well (as long as permissions allow it). No so with NFS; I need to separately mount both video and video/tv.

As to performance, I expect my pool is going to be the limiting factor rather than either network protocol (and if the VM is running on my NAS, the network itself won’t be a limit at all). If I were running a big, all-NVMe pool, I might worry about performance, but mine is all spinners; I don’t expect it to be a problem.

But everyone’s needs are different. You may find that k3s in a sandbox is a better way for you to go. That isn’t what TC say they’re doing; I expect at least part of their reason is to move as far away as possible from anything iX controls, and wouldn’t blame them in the least if that were the case. But it’s a possibility. Or use their migration solution, which they’re suggesting will be VM-based. Or set up your own Kubernetes-compatible cluster and manage it however you like. Or ditch k3s and apps entirely, and run Docker in a sandbox. Or use whatever iX comes up as an apps system in 24.10. Or no doubt other possibilities I’m not even thinking of.

Just for reference, this is also true of mounting datasets inside BSD jails.

With jailmaker you have the systemd-nspawn --inaccessible flag which could be used to prevent this I think. systemd-nspawn

Also, I think specifying norbind as a bind option could restore the nfs style behavior, as opposed to the default recursive bind rbind

1 Like