Live data from Hacker News

K3s – Lightweight Kubernetes

k3s.io

111–120 of 194 posts

Re: K3s – Lightweight Kubernetes

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

Alternatively the K3s authors could have embedded a single node etcd process into Kubernetes using the embed package instead of introducing sqlite.

https://godoc.org/github.com/etcd-io/etcd/embed

This is something the Kubernetes community might consider as well.

Re: K3s – Lightweight Kubernetes

#112
Would love this or something similar for local development. Currently using the Docker for Mac k8s and it shreds my machine and end up with an hour of battery life. Had similar experience with minikube.

Re: K3s – Lightweight Kubernetes

#113
post #81
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…

Not sure what point you’re making specifically. Could you elaborate?

Re: K3s – Lightweight Kubernetes

#114
post #47

Earlier quoted context omitted.

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.

https://twitter.com/kelseyhightower/status/93525292372179353...

That's the exact problem Rancher itself is trying to solve, and it does a pretty fantastic job at it.

Though suggesting its "on par" with CloudFormation suggests that you either know a ton about CloudFormation (anything becomes second nature if you're skilled in it) or you don't know much about either of them. Kubernetes isn't that bad.

Re: K3s – Lightweight Kubernetes

#117
I'm going to try this - I really hope its good. I've spent a lot of days trying to get k8s working with a cheap home server. With VMs and docker conflicting networks its a nightmare. Upgrading is worse.

Re: K3s – Lightweight Kubernetes

#119
post #117

I'm going to try this - I really hope its good. I've spent a lot of days trying to get k8s working with a cheap home server. With VMs and docker conflicting networks its a nightmare. Upgrading is worse.

kubespray is great for multi-vms on home server. Just install base OS, run their ansible playbook (though might need to tell it the OS type in config, it will install and configure node requirements like docker).

Re: K3s – Lightweight Kubernetes

#120
post #68

Earlier quoted context omitted.

True, but not for all developers. For at least 50% of developers, the "physical reality" is that of gathering client requirements quickly and accurately and implementing them correctly and on budget. Not of micro-optimizing CPU cache hits :)

You missed the point. A day will come when CPU speeds and RAM sizes will stop increasing. When that day comes you don't be able to ignore performance, because a lack of performance will mean actual, real-world dollar costs for the client, and so performance will be the #1 requirement of the client.

CPU speeds haven't changed much in 10 years, and to be honest, I would argue that performance has been getting worse and is not a priority for many/most developers.

The client doesn't seem to care, and just sees the 5-20 second webpage load times as totally normal (at my company/industry at least). Our applications are horrifically slow, but we're still the market leaders in our segment

Post reply on HN