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

81–90 of 194 posts

Re: K3s – Lightweight Kubernetes

#81

Post by Jedi72 »

cdoxsey wrote: post #75
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

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…

I am not talking about Go. I dont care what your language is, the true underlying reasoning for your engineering choices is independent of language. It just so happens that these problems have been around for ~30 years, and there has been significant progress in developing tooling to face them, in the domains that the BEAM languages sphere of influence. Just like how Ecto, despite being a great tool, does not free us of knowing about Relational Databases. If you approach the tooling infependently though, as a true knowledge expert does, you will see the progress made by other giants in these fields who are not afraid of specialised tools.

Re: K3s – Lightweight Kubernetes

#82

Post by johnmarcus »

"Added sqlite3 as the default storage mechanism. etcd3 is still available, but not the default."

I want to use and support this product for this reason alone. Etcd was always an un-necessary complexity added for god knows what reason. Later cluster management solutions have abstracted etcd creation and management away (thankfully), but it's always irksome that it is there. Thank you to the K3s development team for taking on that challenge!

Re: K3s – Lightweight Kubernetes

#83

Post by geofft »

Jedi72 wrote: post #81
cdoxsey wrote: post #75

Earlier quoted context omitted.

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…

I am not talking about Go. I dont care what your language is, the true underlying reasoning for your engineering choices is independent of language. It just so happens that these problems have been around for ~30 years, and there has been significant progress in developing tooling to face them, in the domains that the BEAM languages sphere of influence. Just like how Ecto, despite being a great tool, does not free us…

What are "these problems"?

Re: K3s – Lightweight Kubernetes

#84

Post by geofft »

johnmarcus wrote: post #82

"Added sqlite3 as the default storage mechanism. etcd3 is still available, but not the default." I want to use and support this product for this reason alone. Etcd was always an un-necessary complexity added for god knows what reason. Later cluster management solutions have abstracted etcd creation and management away (thankfully), but it's always irksome that it is there. Thank you to the K3s development team for ta…

AIUI it gets you away from a single point of failure, right? Unless you have a reliable NFS server (and non-SPOF NFS servers are rare and pricy), running k8s on SQLite sounds like you can only have one master.

Of course that's totally fine for many k8s deployments and might even increase reliability for some use cases, but still, moving from a distributed system to a local one is a significant change.

Re: K3s – Lightweight Kubernetes

#85

Post by geofft »

omeid2 wrote: post #49
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.

Airplanes also contain expensive hardware. My own desire for reliability via redundancy is that commodity hardware (which is what's in most datacenters) likes to fail.

Re: K3s – Lightweight Kubernetes

#86

Post by johnmarcus »

Jedi72 wrote: post #81
cdoxsey wrote: post #75

Earlier quoted context omitted.

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…

I am not talking about Go. I dont care what your language is, the true underlying reasoning for your engineering choices is independent of language. It just so happens that these problems have been around for ~30 years, and there has been significant progress in developing tooling to face them, in the domains that the BEAM languages sphere of influence. Just like how Ecto, despite being a great tool, does not free us…

When I came across Erlang last year at a new company, I thought it was interesting how many problems Erlang solved that were also in Kubernetes. Self registering named services, processes that crash and restart automatically, health checks, etc.

Unfortunately to use all those features the services needed to be written in Erlang of course, which isn't bad in itself, but unfortunately not the reality in todays multi-lingual atmosphere. Speaks to how highly Erlang was designed and written. It took a lot of real life operational concerns into account in it's design, a concept few other languages even attempt to address.

Re: K3s – Lightweight Kubernetes

#87

Post by sheeshkebab »

pas wrote: post #47
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…

> great K8S API, that Swarm lacks

Hmm... nothing against k8s, but it’s deployment api is an abomination on par with aws cloudformation.

You need teams of yaml engineers to manage these things.

Re: K3s – Lightweight Kubernetes

#88

Post by geofft »

rkangel wrote: post #52
znpy wrote: 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…

Then what do you call a server with a CPU+MMU for its remote management or an iPhone with a CPU+MMU for its secure enclave? A cluster?

There is certainly a lot of technical merit in calling the five-inch thing in my hand a distributed system of multiple computers, but in practice it's not the common definition.

Re: K3s – Lightweight Kubernetes

#90

Post by zoobab »

mgoetzke wrote: post #46
londons_explore wrote: post #33

Earlier quoted context omitted.

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

LXC runs fine on openwrt, and uses very few amount of RAM compared to docker.

I still do not understand why you need hundreds of MBs of RAM for a container orchestrator.

Post reply on HN