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

91–100 of 194 posts

Re: K3s – Lightweight Kubernetes

#91

Post by johnmarcus »

geofft wrote: post #84
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.

meh. Practically speaking, we're talking about a single point of disk failure - which certainly happens but at a rate that is sufficiently low. Plus, the actual amount of data stored is tiny, you can replicate it in seconds. Amazon has solutions for this if it's truly of concern, I would guess google does as well. IMHO, the operation of etcd - and the fact the data became unreadable if you lost quorum - was a much higher risk factor than possible disk failure. It was impractical to backup as well, you either have quorum or you don't. Even without NFS, I could backup that sqlite db every 5 minutes via a cron job and have most of my cluster state perfectly preserved.

Re: K3s – Lightweight Kubernetes

#92

Post by cdoxsey »

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…

I'm not afraid of specialized tools. For example I've used RabbitMQ which I believe is written in Erlang.

We run it in Kubernetes in both our CI environment and locally so we can use the same configuration for both. It runs a dozen microservices and saves us a lot of devops time.

In our CI environment it's nice for a developer to roll out a new copy of the services from a different branch for testing, and because of the autoscaler nodes are dynamically provisioned when needed, and then removed when the test environment is destroyed. That's pretty nice functionality you get basically out of the box. On EKS anyway. There are some occasional rough edges, but I think the decision to use k8s for this makes sense...

At some point we'll migrate prod too.

Kubernetes has a lineage as well... Based on the Borg project at Google.

I guess I'm not seeing why these things are being compared. Aren't they solving different problems?

Re: K3s – Lightweight Kubernetes

#94

Post by otabdeveloper1 »

oblio wrote: post #68
otabdeveloper1 wrote: post #53

Earlier quoted context omitted.

At some point in time, the physical realities of electrons and metal wires will kick in. Then the growth will stop and you'll start kicking your own ass about performance and pointer arithmetic and cache policy. Maybe that point in time is now, maybe it isn't. But it is coming nonetheless, that is one thing we can be sure of.

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.

Re: K3s – Lightweight Kubernetes

#95

Post by base698 »

mrweasel wrote: post #51
pictur wrote: post #2

Do you think kubernetes are necessary for small businesses?

Kubernetes isn't even necessary for medium and large businesses. It's more a question of what problem you're trying to solve. Kubernetes is only relevant if you have the need to scale your service quickly and/or often. If you run it on your own hardware the value is even more tricky to work out, it can still be a benefit. Whether or not it help you save on hardware cost is extremely dependent on your usage.

I see it as decoupling the system administrator tasks from the software tasks. Sys admins can setup the OS, volumes, kubernetes, and monitoring processes. Application developers can do their own thing and deploy apps without having to care about the details of which mount their app needs for disks or the intricacies of whichever process runner they use.

Re: K3s – Lightweight Kubernetes

#96

Post by dankohn1 »

dajohnson89 wrote: post #61
tecleandor wrote: post #39

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?

I believe it goes:

Kubernetes -> K8s -> "kates" -> k3s

Re: K3s – Lightweight Kubernetes

#97

Post by styfle »

dajohnson89 wrote: post #61
tecleandor wrote: post #39

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?

I'm guessing they sliced the "8" down the middle which makes a "3"

Re: K3s – Lightweight Kubernetes

#98

Post by newaccoutnas »

sheeshkebab wrote: post #87
pas wrote: 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.

I think that's the first time I've seen anyone advocate cloudformation above anything.
Post reply on HN