https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# k3s
a
This message was deleted.
c
The couple hundred lines of code you'd save from eliminating those commands would not reduce the binary size or memory footprint in any noticable way. K3s includes all of Kubernetes, containerd, flannel, and kube-router. You'd need to actually remove components, and not just hack away at the CLI, to make it much smaller.
Even then what would be the point? Just saving a couple mb off the binary? If you want to reduce memory at runtime just disable the components you don't want.
Anything so resource constrained that you'd see a difference from cutting things out of k3s probably shouldn't really be running kubernetes anyway.
h
I assumed (and yeah I know I need to dig deeper) that things would get transitively pulled in as required so a k3s binary without 
k3s server
would not have the server components. The point is to reduce the size of the binary. I am not sure what to expect and perhaps as you say there is little point, but my gut was suggesting a 50% smaller binary without the server components or any etcd stuff. Hard to know - I could not find any info on how much the various parts contribute to the total binary
c
The server bits aren't a significant contribution to the size. You still need all the shared code used by everything else.
But again, so what if you take the binary from 70mb to 40. What does that get you? Anywhere that a couple mb of disk makes a difference isn't going to run Kubernetes well anyway.
That's the size of like, one container image
h
I'm thinking of small diskless nodes, so the rootfs image would be in RAM. I do not know what savings to expect but thought there would be some
c
You're gonna keep all your docker images in ram too?
h
nope. remote mounted. longer term plan
I have a vague hand-wavey plan to have a registry that can serve images read-only that can be mounted across the network. There's no read reason why k8s has to add much overhead - containers are just processes (and a bit more, I know) so I'm thinking about how much that overhead can be reduced, with the idea of compute nodes without disk as a common way to grow capacity
But thanks for the feedback on the expected savings on the binary. I'll play with the build myself and see what I get - I'm not overly concerned with the current 70MB size but for a 1GiB node (or even 512MiB which I have a few of), every little bit counts
f
diskless nodes have been around since the 1980s, when a machine with big RAM had 1MiB. Most modern OSes mmap the executables, so only pages needed are in RAM. In other words, the size of the file is no longer an indicator of how much RAM is needed.
h
If your root filesystem is in RAM then file size does matter
c
sure but if the plan here is to mount remote filesystems over the network then why does k3s even need to be in the ramdisk to begin with.
I don’t understand any of the goals here tbh
2 Views
Open in Slack
PreviousNext
Powered by