Live data from Hacker News

K3s – Lightweight Kubernetes

k3s.io

101–110 of 196 posts

Re: K3s – Lightweight Kubernetes

#101
If you want something lighter than k3s, k0s could be worth a try. I recently switched to k0s and noticed the controller, and the various kube processes consume less cpu resources compared to when I was running k3s.

Re: K3s – Lightweight Kubernetes

#102
post #17

"Lightweight Kubernetes" and then a graph involving 2 different nodes with 10+ services running on them. Nomad seems to be a truly "lightweight Kubernetes" and for the small amount of time I've been using it, it seems to do it's job really well and it's easy to understand all the moving pieces without spending countless of hours reading docs and source code. Although, it's hard to recommend Nomad for future uses as i…

I've commented on this before in a different k8s thread (one about a k8s outage) but something that bears repeating is that the entire job market is Kubernetes. My personal experience is that it is very, very hard to find a job right now if your professional experience is primarily non-k8s orchestration systems. Most job positions out there require deep Kubernetes knowledge as well as hands-on experience with differe…

A lot of smaller SaaS companies avoid k8s like the plague and only start using it once they scale to a certain size. K8s might be ubiquitous past a certain scale, but there are many jobs operating below the threshold for which the complexity of your system with k8s outweighs the complexity of your system without k8s.

Re: K3s – Lightweight Kubernetes

#103
Kubernetes seems like an "acquired taste".

Either you use it a lot (likely at work) and are therefore comfortable using it outside of work as your one-size-fits-all solution to everything, or else you don't use it a lot and see it as a complexity behemoth that hides all of your system behind esoteric CLIs and config files that just make everything a nightmare to manage.

Re: K3s – Lightweight Kubernetes

#104
post #103

Kubernetes seems like an "acquired taste". Either you use it a lot (likely at work) and are therefore comfortable using it outside of work as your one-size-fits-all solution to everything, or else you don't use it a lot and see it as a complexity behemoth that hides all of your system behind esoteric CLIs and config files that just make everything a nightmare to manage.

I find it very acceptable on my local servers that run my mail, web, mastodon, etc servers. I prefer the configuration in kubenetes templates instead of spread all over my filesystem in /etc (config in one place and fucking unit files in another), /var/lib, /opt, etc.

Re: K3s – Lightweight Kubernetes

#106

Earlier quoted context omitted.

Hashicorp is playing safe here, Nomad can do with far far less resources.

That can be said of many systems, does hashicorp document it though? I’m guessing they must, otherwise that would be the first thing you hear on the other side of a support call.

also with hashicorps new licensing regime...

Re: K3s – Lightweight Kubernetes

#107

Earlier quoted context omitted.

You can have sd and secrets with just nomad now, it is perfect for small projects in that way. K8s also can do secrets! base64 encoded secrets! But in case you need a more secure solution. Please pull in a Vault helm chart or mess around with sops or whatever. Want to scale out? See how long it will take you until you will have to move your etcd to dedicated hw/vm's. And let me tell you - setting up external etcd in…

K8s supports encryption at rest, ACLs and audit logs. What it actually lacks is versioning, and a dynamic secrets engine, though you could build that with an operator, and things like the postgres-operator do. You also don't get the whole sealing thing, but I'd argue that's more annoying than useful.

> You also don't get the whole sealing thing, but I'd argue that's more annoying than useful.

A-fucking-men.

Re: K3s – Lightweight Kubernetes

#108
post #45

Could someone please explain the difference between K0s[1] and K3s? They seem to both target the same minimalist K8s segment. [1] https://k0sproject.io/

K3S includes some extras that make it nice for working in small local clusters, but are not part of the standard k8s codebase. * Traefik daemonset as a load balancer * Helm controller that lets you apply helm manifests without the helm command line * Upgrade controller * Sqlite as the default backing store for the k8s API * Their own local storage provisioner K0S has a lot of the same goals: be light weight and self…

What you've listed for k3s is mostly included in k0s. I wouldnt go far to say k0s isnt convenient.

* A helm controller is included in k0s

* Etcd is bundled and bootstrapped automatically which I perfer because I dont want the overhead of the translation that Kine does. Although Kine is available for a non-etcd datastore if that is preferred.

* Upgrade controller is included (autopilot).

* They have a local storage provider based on OpenEBS.

* Ingress is missing, but due to the built in helm controller that can be boot strapped upon cluster initialisation.

Overall, together with k0sctl and its declarative configuration it is easier to deploy k0s than it was k3s.

Re: K3s – Lightweight Kubernetes

#109

Earlier quoted context omitted.

> "Lightweight Kubernetes" and then a graph involving 2 different nodes with 10+ services running on them. Among its many strengths, core services for running Kubernetes running inside Kubernetes itself is one of its greatest. > it's easy to understand all the moving pieces It's legit to leverage your pre-existing knowledge. Nomad + Linux Pets + Other Hashichorp Pets works well. There are many ways to run an applicat…

"Machine Cattle"?

Treat your machines like cattle, not pets. When I used to run kubernetes in the pre-'kube as a service' days. We had two autoscaling groups, one which had 3 or 5 nodes in it to run the control plane nodes and an open eneded one for workers (which were managed by the cluster autoscaler). Each ASG was set up in such a way that the nodes would come up and join the cluster fully automated and they never needed to be shelled into for anything but troubleshooting the weirdest failures (it was early days, the kubelet and docker had some extra fun bugs).
Post reply on HN