Docker K8s vs Docker straight - TN Scale

[leckyBill]

What is the benefit of running say sonarr + jackett + transmission+openvpn as truecharts catalog items over just deploying the same as docker containers from linuxserver.io?
I understand that TrueNas Scale implements K8s to "orchestrate" the docker containers as charts, but they are still essentially separate things, right?
When I "add docker", I'm also getting a standalone k8s "wrapped" container? what is the difference? More overhead? More efficiency?

 

[leckyBill]

I didn't find any benefit, just over head...
Is there some documentation on how to disable Kubernetes and just use docker/portainer?
I really don't need the complexity of k8s...

• SCALE allows Kubernetes to be disabled. The user will then have access to the native container services within Debian. This will include Docker, LXC (Q1 2021) or any other Kubernetes distribution. There will be a Container Storage Interface (CSI) that can couple the container services with the SCALE storage capabilities. Users can script these capabilities and then use 3rd-party tools like Portainer to manage them. This approach can be used in SCALE 20.10 and later.

 

[ornias]

If you want help with scale, try asking in the scale forum next time. Posts here get drawned by plugin topics.

I just explained in another topic yesterday how to run just docker, why you shouldnt (need to) disable k8s and why you shouldnt run like that anyway.

TLDR:
Its allowed but not supported.

Why use the k8s solution
- k8s healthcheck are superior
- its actually supported by iX (so doesnt break)
- it automatically creates snapshot before updates of your config (if using dataset or PVC) storage
- you can easily (one click) revert updates including setting back the snapshot
- it includes a GUI
- k8s ingress is by FAR superior to dock reverse proxies
- k8s permissions offer a LOT more options than the crude linuxserver.io containers (if supported by the container).

So: its quite clear why iX made this design choice.

If you have TrueCharts specific questions, I would point towards the contact options on our website.

I’ve stopped providing active support on this forum for TrueCharts (because I cant track everything).

 

[leckyBill]

Totally understand, and it is by far the right solution for scalability and multi user. But right now I'm just looking at a home server with a bunch of individual , single instance docker containers. it was the native docker support that drew me to SCALE, but it is perhaps wrong solution for my use case.

 

[ornias]

Totally understand, and it is by far the right solution for scalability and multi user.

Hmm, thats not what I just explained to you. SCALE doesn't even (currently) support multinode or multi-tenant k8s clusters.
The things I explained above are all about the current single-node, single-user version of SCALE.


SCALE Apps, are great simplified entrypoints into k8s for single docker-container stances. Without touching too much of k8s.
Besides needing to learn a few concepts (such as what a nodeport does) and using a GUI instead of a file, SCALE Apps (or docker containers deployed from the GUI) do not require the user to touch k8s.

It's a bit hard when you don't want to drive a car, because you complain about not knowing how this specific engine runs, regardless of the fact you're not supposed to touch the engine as an end-user.

The (minimal) overhead is a almost laughable selfjusitification argument that i'm going to completely ignore.

Yes k8s is more complicated, but what do you plan to do? THAT is the question.
Even deploying Helm Charts, is not much more different than docker-compose.

 

[Jecvay]

Totally understand, and it is by far the right solution for scalability and multi user. But right now I'm just looking at a home server with a bunch of individual , single instance docker containers. it was the native docker support that drew me to SCALE, but it is perhaps wrong solution for my use case.

k3s or k8s is really too heavy for single node use.
a fresh k3s server without any pods running also take 10% ~ 20% cpu ( or about 10~15 Watt electric power, and full screen of k3s threads in htop command )
so, as I love debian more compare to bsd, i think install SCALE and disable k3s and use docker compose is a good choice.

 

[ornias]

so, as I love debian more compare to bsd, i think install SCALE and disable k3s and use docker compose is a good choice.

If thats what you want, I suggest not using SCALE. Because thats not supported.

 

[Yorick]

Good to point out as well that while k3s is a core feature, docker may very well not be. Right now SCALE uses docker as the container backend for k3s; but a couple years from now that might be CRI-O or something else. Relying on docker always being available in SCALE is a bit risky.

 

[Jecvay]

Understand. SCALE is totally not design to home user which has only one server instance. I have switched back to CORE.

 

[ornias]

Understand. SCALE is totally not design to home user which has only one server instance. I have switched back to CORE.

SCALE actually has significant improvements for home uses. For example the Apps system is much more solid and less trouble-causing as the plugins on CORE. I also think your 10-20% idle CPU usages for k3s on SCALE is off, it shouldn't be that way, Though I doubt you filed a bug report for it anyway.

 

[Jecvay]

SCALE actually has significant improvements for home uses. For example the Apps system is much more solid and less trouble-causing as the plugins on CORE. I also think your 10-20% idle CPU usages for k3s on SCALE is off, it shouldn't be that way, Though I doubt you filed a bug report for it anyway.

it's not the bug of truenas scale, but the feature of k3s.

Rancher Docs: K3s Resource Profiling

CPU and memory usage of k3s · Issue #2278 · k3s-io/k3s

Environmental Info: K3s Version: k3s version v1.18.8+k3s1 (6b59531) Running on CentOS 7.8 Node(s) CPU architecture, OS, and Version: Linux k3s 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54...

github.com

the architecture of k3s decided that it must use more resources to keep many base subsystem running.

and this design really make scale more suit for a NAS network which consists of multiple instances, without these subsystems and these layers, a nas network cannot be solid. because compare to the large number of APPs in multiple instances, the subsystems which inside k3s is smaller and robust, they can be a monitor role.

but i don't think a single instance use case will need these complex layers to keep them robust. Under this demand, the role played by k3s (monitoring) has deviated from the target due to the APP's scale is too small.

 

[ornias]

it's not the bug of truenas scale, but the feature of k3s.

Rancher Docs: K3s Resource Profiling

You do realise that your own source, contradicts what you just said? ;-)

 

[Yorick]

Interesting. So according to http://ceur-ws.org/Vol-2839/paper11.pdf k3s the lowest, followed by k8s and microk8s. And in the ballpark of 200-300M memory and 3-4% CPU for all three.