Live data from Hacker News

K3s – Lightweight Kubernetes

k3s.io

71–80 of 194 posts

Re: K3s – Lightweight Kubernetes

#71
post #49
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.

If someone wanted to do it, the lxc/lxd team has a distributed sqlite, so you could adapt that to k3s. Though I suppose that's not a good match for the stated purpose of k3s.

https://github.com/lxc/lxd/blob/master/doc/database.md

https://github.com/CanonicalLtd/dqlite

Re: K3s – Lightweight Kubernetes

#72

I've been laughing myself of for some minutes, not because the project is uninteresting (I'll be testing it next week on ARM, probably), but because I've decided to call this "Kubernetres" (Being 'TRES' three in Spanish)

why isn’t it called k7?

They have a "5 less than K8S" tagline. I don't know if that means 5 fewer features, 5 fewer dependencies, or just "less than half the size".

Re: K3s – Lightweight Kubernetes

#73
post #59
post #37

Earlier quoted context omitted.

Well if you want a nice cheap, small cluster, with HA, and wide community support, and a container model so you have to trust the applications less. What else are you going to use? What else is going to provide a nice easy to use HA raspberry pi that's $100 ish?

Can containers really improve security in case of IoT where there's a single application that pretty much needs access to the whole device? I think they may only increase the attack surface. High availability seems like an orthogonal problem in case of IoT. It's not like you can spawn more devices. But I acknowledge that it may be just me getting old. Still happy to learn more arguments for using k8s in IoT (if you a…

IoT clients consume the entire device. Not necessarily the IoT server. k3s supports containerd on arm7 and provides good isolation. With efficient code you can easily support a web portal, a light weight database, and plenty of logic for IoT type needs. Seems ideal for trusting multiple 3rd parties, like say one company with your thermostat, one for your cameras, and a 3rd for your lights or similar.

Re: K3s – Lightweight Kubernetes

#74
post #59
post #37

Earlier quoted context omitted.

Well if you want a nice cheap, small cluster, with HA, and wide community support, and a container model so you have to trust the applications less. What else are you going to use? What else is going to provide a nice easy to use HA raspberry pi that's $100 ish?

Can containers really improve security in case of IoT where there's a single application that pretty much needs access to the whole device? I think they may only increase the attack surface. High availability seems like an orthogonal problem in case of IoT. It's not like you can spawn more devices. But I acknowledge that it may be just me getting old. Still happy to learn more arguments for using k8s in IoT (if you a…

I don't think the suggestion for Kubernetes in IoT is to run it on the Things, but for small local servers running services that work with the devices, instead of pushing all that in the cloud.

Re: K3s – Lightweight Kubernetes

#75
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

Are you talking about Go, the language this is written in?

Go's concurrency features are formally specified, are not ad-hoc (they are a major feature of the language, and the product of multiple language design iterations) and are certainly not bug-ridden.

Or are you talking about using Kubernetes to manage workloads on machines?

How does Erlang solve running my python webapp or my SQL database on my ec2 nodes, or in the case of this project, on an IoT device.

Re: K3s – Lightweight Kubernetes

#76
post #52
post #41

Earlier quoted context omitted.

> 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.

The problem is that the bottom end of 1k RAM still exists. In fact, because the main change is that it gets cheaper every year, it's even more prevalent. Just because there aren't lots of blog posts, doesn't mean that isn't a large proportion of the industry. The word 'embedded' is not well defined, but if you use it on things with 1GB of RAM, what do you call a PIC with 1K? My personal definition of embedded (which…

And nobody has suggested to use it on such tiny devices. "Embedded" spanning a large range of devices isn't new. 20 years ago, mainboards for high-end x86 CPUs of the day that were made to be put into industrial devices were already called "embedded". Because they're embedded into machines etc.

If you mean tiny devices, why not say "microcontroller" or something?

Re: K3s – Lightweight Kubernetes

#77
post #12

Earlier quoted context omitted.

Necessary, no. But with the hardware almost free, a 3 x Raspberry Pi cluster, switch, access pointer, and a small UPS would be a few $100 which allows for some interesting possibilities. Pretty much any business will want inventory tracking, tracking staff hours, monitoring cameras, sensors for detecting flooding/doors left open/freezers dying, running point of sales terminals, keeping the supply chain running smooth…

Hardware was never the bottleneck there. The systems could cost a hundred times that and it would still be a rounding error on the capex of even the smallest "real" business. The obstacle to using custom hardware and software in local biz is and has always been, the fact that by relying on it, the one guy who knows how to administer it all becomes the single point of failure for the whole business. No amount of tooli…

Dunno. I've know several business owners that didn't take credit cards until recently, and even then only did so because the newer companies have significantly lowered the investment cost. Maybe you don't consider small family owned restaurants "real".

Seems like there's an opportunity for a cheap 3 node cluster, sold as a value add to businesses and supported a platform that application writers could target. They might well come with a support contract, some basic functionality, and then users could pay for inventory, staff scheduling, point of sales terminal support, integration with food delivery services, etc.

Much like how some home/small business NASs these days have support for 100s of integrations to various online services.

Re: K3s – Lightweight Kubernetes

#78
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.

[deleted]

Re: K3s – Lightweight Kubernetes

#79
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.

Are you saying this because the page mentions IoT, or what brought this on? To me, the page doesn't suggest that they want it to be used on many embedded devices...

Re: K3s – Lightweight Kubernetes

#80

Technically speaking: cool Practically speaking: I worry this will become a parallel but subtlety different implementation of Kubernetes with it's own quirks.

That's why CNCF is thrilled that Rancher passed our Certified Kubernetes conformance tests for k3s prior to the public announcement. https://landscape.cncf.io/category=certified-kubernetes-dist...

Ah, interesting! Cool. Thanks.
Post reply on HN