A Comparative Analysis of K3s, MicroK8s, and Alternatives • Hacker News Board

Re: A Comparative Analysis of K3s, MicroK8s, and Alternatives

#11

Post by mdaniel » Sat, Apr 05, 2025, 4:20 PM UTC

chuckadams wrote: post #9

sofixa wrote: post #5

If Docker Swarm is on the table (it's practically abandonware), I'd like to throw in Nomad by HashiCorp. It's also fairly lightweight, very flexible (can run various types of containers but also exec any executable), decent ecosystem (supports CNI and CSI). It can scale from single node control plane + workloads to tens of thousands of nodes, and the workers can also be geographically spread out (different regions/zo…

Oddly, I'm moving all my stuff to k8s because of how convenient and easy everything is to admin with tooling like k9s. But I've only ever worked with toy clusters with nodes in the single digits, and I can see what a nightmare debugging something like networking or storage at scale can be. Also, helm gave me a loathing for yaml I never knew I had in me. I avoid some of helm's more vulgar gyrations by using helmfile,…

> Also, helm gave me a loathing for yaml I never knew I had in me

If it's the whitespace that jams you up, I wanted to point out that since YAML is a superset of JSON, there's nothing stopping you from using text/template to cook JSON manifests. There is, of course, a toJson function available in helm https://helm.sh/docs/chart_template_guide/function_list/#typ...>

But I'm conceptually with you that the jokers who decided to use a text templating language for a structured output were gravely misguided and now we all suffer

Re: A Comparative Analysis of K3s, MicroK8s, and Alternatives

#12

Post by sofixa » Sat, Apr 05, 2025, 5:21 PM UTC

mdaniel wrote: post #10

sofixa wrote: post #5

If Docker Swarm is on the table (it's practically abandonware), I'd like to throw in Nomad by HashiCorp. It's also fairly lightweight, very flexible (can run various types of containers but also exec any executable), decent ecosystem (supports CNI and CSI). It can scale from single node control plane + workloads to tens of thousands of nodes, and the workers can also be geographically spread out (different regions/zo…

I had a distaste for Nomad before the rug pull[1], but hopefully no serious person would voluntarily choose Nomad after that stunt. Doubly so that going with the Nomad ecosystem mandates self-hosting as one cannot $(aws elastic-nomad create-cluster). I was similarly surprised that HashiCorp didn't even offer "you pay for compute but we will administer your control plane" since both the "community" and the "enterprise…

Agree to disagree on if a license change (to one that impacts nobody but potential resellers) constitutes a rug pull.

BSL and similar are the second best thing (after open source licenses), and still drastically better than proprietary/closed source. If it allows someone to pay the salaries of the people developing it, I'm fine with that. And not only because my own salary is one of them - I had the same view for MongoDB, Elastic, Sourcegraph, etc. In the era where massive behemoths can just ship your software as a service for free, companies need to protect themselves as much as they can. Do you ever wonder why there are very few profitable open source companies? Most people would know Red Hat and that's it.

Re: A Comparative Analysis of K3s, MicroK8s, and Alternatives

#13

Post by ofrzeta » Sat, Apr 05, 2025, 6:08 PM UTC

mdaniel wrote: post #11

chuckadams wrote: post #9

Earlier quoted context omitted.

Oddly, I'm moving all my stuff to k8s because of how convenient and easy everything is to admin with tooling like k9s. But I've only ever worked with toy clusters with nodes in the single digits, and I can see what a nightmare debugging something like networking or storage at scale can be. Also, helm gave me a loathing for yaml I never knew I had in me. I avoid some of helm's more vulgar gyrations by using helmfile,…

> Also, helm gave me a loathing for yaml I never knew I had in me If it's the whitespace that jams you up, I wanted to point out that since YAML is a superset of JSON, there's nothing stopping you from using text/template to cook JSON manifests. There is, of course, a toJson function available in helm https://helm.sh/docs/chart_template_guide/function_list/#typ... > But I'm conceptually with you that the jokers who d…

There is also JSonnet and the appropriate tooling with tanka.dev

Re: A Comparative Analysis of K3s, MicroK8s, and Alternatives

#14

Post by arkaniad » Sat, Apr 05, 2025, 6:10 PM UTC

K3s is truly great - been using it for years for just about everything not warranting a full cluster. MicroK8s feels like it does too much in non-standard ways and when it breaks you're suddenly dealing with Snap related issues and it's a total immersion break.

Lately there's also RKE2 (https://docs.rke2.io/) that I've been growing fondness for and it's only marginally more tricky to setup, with the bonus effect of having a more 'standard' cluster distribution and more knobs to twist.

Not that I'd be shy of running K3s in production, but it seems easier to follow 'standard Kubernetes way' for things without having to diff with some of K3s's default configuration choices - which, again, aren't bad at all for folks who do not need all of the different options.

For edge workloads and smaller clusters / less familiar operators that want to run Kubernetes platforms themselves without depending on a managed provider, K3s is pretty impossible to beat.

Re: A Comparative Analysis of K3s, MicroK8s, and Alternatives

#15

Post by rthnbgrredf » Sat, Apr 05, 2025, 8:05 PM UTC

hdjjhhvvhga wrote: post #6

I'd be curious to know what prompt was used to generate this article. I don't mean any offence, most content on the web is generated by LLMs these days one way or another anyway, I'm just curious about the exact prompt used in this case.

I think something around those lines:

Write a comprehensive technical blog post targeting small and medium-sized businesses that use Hetzner Cloud and are evaluating lightweight Kubernetes alternatives. Compare and analyze the following solutions: k3s, MicroK8s, Docker Swarm, and Minikube.

Structure:

Start with a title and abstract introducing the comparative scope.

Provide sections such as:

Architectural Requirements, Deployment & Lifecycle, Management, Cost Analysis, Security & Compliance, Developer Experience, Strategic Recommendations and end with a clear conclusion and deployment advice.

Style:

Technical but accessible to DevOps engineers or small startup CTOs.

Use citation-style references for data (e.g., [1], [2], etc.).

Incorporate code examples (Terraform, Helm, CLI snippets).

Use tables for cost comparisons or benchmarks where appropriate.

Mention open-source tools specific to Hetzner (e.g., hetzner-k3s, hcloud Terraform provider).

Tone:

Professional, analytical, and informative. No marketing fluff.