Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

K3s – Lightweight Kubernetes

k3s.io

Post reply on HN
Print view View original

41–50 of 194 posts

Re: K3s – Lightweight Kubernetes

#41

Post by znpy »

zoobab wrote: post #22

Welcome to 2019 where an "embedded" system has 1GB RAM. The problem of GO is that all those unused libraries are loaded in RAM instead of staying on disk, and loaded when needed. An helloworld in GO (around 1.6MB) is still too large for my openwrt router.

> Welcome to 2019 where an "embedded" system has 1GB RAM.

Thirty years ago someone could have said the same when seeing laptop computers and remembering when computer literally used to occupy whole large rooms.

Come on, let's stop doing this kind of jokes, they add nothing to the discussion.

Re: K3s – Lightweight Kubernetes

#42

Post by vidarh »

znpy wrote: post #41
zoobab wrote: post #22

Welcome to 2019 where an "embedded" system has 1GB RAM. The problem of GO is that all those unused libraries are loaded in RAM instead of staying on disk, and loaded when needed. An helloworld in GO (around 1.6MB) is still too large for my openwrt router.

> Welcome to 2019 where an "embedded" system has 1GB RAM. Thirty years ago someone could have said the same when seeing laptop computers and remembering when computer literally used to occupy whole large rooms. Come on, let's stop doing this kind of jokes, they add nothing to the discussion.

We're still in a place where there are millions of embedded devices out there in actual real world use where these resource constraints are real.

Re: K3s – Lightweight Kubernetes

#43

Post by Ruddle »

Jedi72 wrote: post #29

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang." - Virding's Law

IMO any program with a sufficiently high number of entities in a low level language contains an ad hoc informally-specified bug-ridden slow implementation of a garbage collector

Re: K3s – Lightweight Kubernetes

#45

Post by 05 »

londons_explore wrote: post #33
05 wrote: post #27

Earlier quoted context omitted.

Nope, they mean there's no flash memory available on the resource constrained device to store megabytes of useless runtime. Routers/other IOT Linux devices regularly use SPI ROM chips sized 4MB..16MB, you can't just install a 100MB Ubuntu/Arm rootfs on those.

I think the days of the small SPI flash chip are numbered. A a few hundreds of megabytes of flash will soon cost less than the plastic and manufacturing costs of the chip itself. At that point, manufacturers will be putting in 128megabyte flash chips simply because 16 megabyte flash chips cost more. The only place that argument won't apply is in microcontrollers where the flash is on the same die as the CPU.

SPI chips are unreasonably expensive per MB compared to NAND, some reasons on why: https://electronics.stackexchange.com/questions/32200/why-is...

Re: K3s – Lightweight Kubernetes

#46

Post by mgoetzke »

londons_explore wrote: post #33
05 wrote: post #27

Earlier quoted context omitted.

Nope, they mean there's no flash memory available on the resource constrained device to store megabytes of useless runtime. Routers/other IOT Linux devices regularly use SPI ROM chips sized 4MB..16MB, you can't just install a 100MB Ubuntu/Arm rootfs on those.

I think the days of the small SPI flash chip are numbered. A a few hundreds of megabytes of flash will soon cost less than the plastic and manufacturing costs of the chip itself. At that point, manufacturers will be putting in 128megabyte flash chips simply because 16 megabyte flash chips cost more. The only place that argument won't apply is in microcontrollers where the flash is on the same die as the CPU.

and why would you run k3s on these ...

Re: K3s – Lightweight Kubernetes

#47

Post by pas »

sandGorgon wrote: post #25

Oh nice - this is by the Rancher guys. Would love to compare this not with k8s, but with Docker Swarm. Docker Swarm on Raspberry Pi is a very common thing. So, from a performance perspective, these are on par. Another question is around ingress and network plugin - is it a seamless "batteries included" experience ? Because these are two of the biggest pains in k8s to decide and setup .

Based on the README [0], quickly comparing to Swarm:

- this has the same great K8S API, that Swarm lacks. (Deployment is a first class citizen in kube land, but you only have to make do with the service YMLs in the Swarm sphere.)

- k3s lacks some in-tree plugins, that swarm might have (mount cloud provider managed block device), but there are out of tree addons

- sqlite instead of etcd3 [but available], so out of the box k3s is not HA ready (if I interpret this[1] right, there's one APIserver, and it's something in development )

- this seems more lightweight than a docker setup in some sense (it uses containerd, not full docker), but of course this needs a proper evaluation

- ingress plugins: good question. it should work with traefik [2]

[0] https://github.com/rancher/k3s/blob/master/README.md#what-is...

[1] https://github.com/rancher/k3s/blob/master/README.md#server-...

[2] https://github.com/rancher/k3s/search?q=ingress&type=Commits

Re: K3s – Lightweight Kubernetes

#48

Post by omeid2 »

Ruddle wrote: post #43
Jedi72 wrote: post #29

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang." - Virding's Law

IMO any program with a sufficiently high number of entities in a low level language contains an ad hoc informally-specified bug-ridden slow implementation of a garbage collector

Not exactly, a garbage collector is by definition a collector (there is sweeps rather than per-reference and more importantly has runtime cost). I think, manual memory management is a lot more similar to a poorman's ARC implementation.

Re: K3s – Lightweight Kubernetes

#49

Post by omeid2 »

detaro wrote: post #4

Looks quite interesting for small setups, curious to read more about the limitations (E.g. " Added sqlite3 as the default storage mechanism. etcd3 is still available, but not the default. " - what availability promises can this make?)

In terms of etcd3 vs sqlite3, it is as reliable as most airplane systems that depend on it.

https://www.sqlite.org/famous.html

I think the "high availability by redundancy" story is oversold.

Re: K3s – Lightweight Kubernetes

#50

Post by rkangel »

londons_explore wrote: post #33
05 wrote: post #27

Earlier quoted context omitted.

Nope, they mean there's no flash memory available on the resource constrained device to store megabytes of useless runtime. Routers/other IOT Linux devices regularly use SPI ROM chips sized 4MB..16MB, you can't just install a 100MB Ubuntu/Arm rootfs on those.

I think the days of the small SPI flash chip are numbered. A a few hundreds of megabytes of flash will soon cost less than the plastic and manufacturing costs of the chip itself. At that point, manufacturers will be putting in 128megabyte flash chips simply because 16 megabyte flash chips cost more. The only place that argument won't apply is in microcontrollers where the flash is on the same die as the CPU.

I think you're seriously underestimating both cost sensitivity, and the degree to which chip packaging evolves.

I worked on a bit of premium consumer electronics. Retail would be about $80. That allowed an electronics BOM cost of $20. When selecting the processor, the size of the flash was a more dominant effect than RAM, clock speed or chip peripherals, because we're in the $1 vs $1.20 region.

There is a lot of software running in some very cheap electronics, all around you all the time. Everyone just forgets because it's all designed in corporations and not talked about on the internet so much.

Post reply on HN