Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing K3s with vanilla Kubernetes

hoelzel.it

Post reply on HN
Print view View original

51–60 of 90 posts

Re: Comparing K3s with vanilla Kubernetes

#51

Post by glotzerhotze »

jhoelzel wrote: post #36
user61129028 wrote: post #33

Earlier quoted context omitted.

"vanilla kubernetes" isn't a distribution either. > Kubernetes and k3s are both container orchestration platforms Your article makes it seem like k3s and k8s are different platforms which is simply incorrect. A more useful comparison would have been to compare k3s with another distribution like EKS, GKE, OKD etc.

i kindly ask again, what is the distribution called that you setup with kubeadm?

you might be fooled by the meaning of the word „distribution“ in the kubernetes vs. linux context.

in the linux context, a distribution would be an opinionated build of user-land tools around the linux kernel which might also bring patches done to the kernel by the distributor.

in the (cloud) kubernetes context, a distribution would be an opinionated (cloud) implementation of core kubernetes binaries (EKS/AKS/etc.pp.) on top of a linux-distribution of your liking.

to my humble understanding k3s is a stripped down and optimized (IMHO opinionated) build of kubernetes binaries derived from the official source.

kubeadm is the official projects (opinionated?) idea of arriving at a vanilla cluster, leaving you with the freedom to make choices for lots of the needed components involved.

in the linux context, „linux from scratch“ would be an analogy I suppose.

more knowledgeable people should please correct me if I‘m wrong in my understanding here.

Re: Comparing K3s with vanilla Kubernetes

#52

Post by dang »

kamikazechaser wrote: post #39

Title is misleading. k3s is a deployment stack/distribution that builds off various Kubernetes modules. It must pass a certain test suite to conform to Kubernetes standards. What you might be trying to compare is kubeadm which is the official deployment stack provided by Kubernetes.

Ok, I've stuffed "default" in the title above. If someone wants to suggest a better (i.e. more accurate and neutral) title, we can change it again.

Re: Comparing K3s with vanilla Kubernetes

#53

Post by Rantenki »

tinco wrote: post #48
davidkuennen wrote: post #41

Earlier quoted context omitted.

Sounds like Digital Ocean was the problem, not Kubernetes. Been running managed Kubernetes in GCP for years without any issues. They are bugging me to update for some time now, but I don't think they would force an update on me.

I hope you're right, I haven't had time to look at the same warning for 6 months now. There was a hard deadline on it in February and it came and went. The backwards incompatible Kubernetes api updates are a PITA. I know they said "beta", but if you literally have a version field in your manifest format, why ever deprecate a way of configuring something? They could just have operators translate the configs automatica…

>They could just have operators translate the configs automatically on the fly

How do they test that across the infinite number of permutations of configurations and deployments of K8S in the field though? It'll work for some people on the happy path, but it's really hard to maintain over time. Worse, it'll break randomly at some point in the future that is hard to predict, instead of at some publicly announced point in time where the breaking change is deployed (how it happened this time).

Re: Comparing K3s with vanilla Kubernetes

#54

Post by fellowniusmonk »

zzyzxd wrote: post #31

I tried k3s several times in the past few years but I still can't use it in my homelab: 1. the project claims to be production ready and support HA control plane setup, but there's no solution for API load balancing out of box. How do you bring up a new node(either control plane or worker node)? You write down the join token produced by the first control plane node, and hardcode the token and the existing control pla…

Thank you for sharing this and saving me time in exploring k3, it's shocking how common it is that an evangelized tool is impractical to setup and use in even a simple homelab configuration.

Knowing what NOT to investigate because it isn't "ready" can be one of the biggest time sucks.

Re: Comparing K3s with vanilla Kubernetes

#55

Post by joshmanders »

infogulch wrote: post #49
mulmen wrote: post #11

Earlier quoted context omitted.

What are the three letters? It only makes sense for being confusing, which is the base state of Kubernetes. "Our name is literally a complex joke about complexity" doesn't inspire confidence in a project that supposedly simplifies complexity.

kubernetes -> k8s k8s -> k3s Double numeronym'd

Wouldn't k8s -> k1s then?

Re: Comparing K3s with vanilla Kubernetes

#56

Post by tetraodonpuffer »

paddw wrote: post #2

K3s seems like a terrible name, given how people will be confused with the numeronym for Kubernetes.

It is a pretty decent name since you can easily search for information about it, unlike say “kind” (which I typically use for development) which is absolutely un-googleable

Re: Comparing K3s with vanilla Kubernetes

#57

Post by atmosx »

bithavoc wrote: post #25
wouldbecouldbe wrote: post #8

It was 01:30. About to go to bed. Next day would fly with my daughter to holidays. I checked the apps of a bunch of clients. None of them loaded. I was like what... I checked the server. Everything down. I'd been running Kubernetes on Digital Ocean. And Digital Ocean forced a Kubernetes update that was incompatitable with mine at night. Took me 8 hours to fix it. No sleep. Ended up moving it back to a good old VPS. A…

DigitalOcean also cordons Nodes for no reason at random times. Currently moving to EKS exactly for this reason

Can you share more details please? How did you find out it was DO, did you open a support ticket?

Re: Comparing K3s with vanilla Kubernetes

#58

Post by wouldbecouldbe »

Rantenki wrote: post #53
tinco wrote: post #48

Earlier quoted context omitted.

I hope you're right, I haven't had time to look at the same warning for 6 months now. There was a hard deadline on it in February and it came and went. The backwards incompatible Kubernetes api updates are a PITA. I know they said "beta", but if you literally have a version field in your manifest format, why ever deprecate a way of configuring something? They could just have operators translate the configs automatica…

>They could just have operators translate the configs automatically on the fly How do they test that across the infinite number of permutations of configurations and deployments of K8S in the field though? It'll work for some people on the happy path, but it's really hard to maintain over time. Worse, it'll break randomly at some point in the future that is hard to predict, instead of at some publicly announced point…

I don't know any software library that introduces breaking changes as often as kubernetes does. Devops used to be leaning more to stability then devs, it's weird. Kubernetes devops are very expensive so I guess they love being able to spend more time on their tool

Re: Comparing K3s with vanilla Kubernetes

#59

Post by kobalsky »

davidkuennen wrote: post #41
wouldbecouldbe wrote: post #8

It was 01:30. About to go to bed. Next day would fly with my daughter to holidays. I checked the apps of a bunch of clients. None of them loaded. I was like what... I checked the server. Everything down. I'd been running Kubernetes on Digital Ocean. And Digital Ocean forced a Kubernetes update that was incompatitable with mine at night. Took me 8 hours to fix it. No sleep. Ended up moving it back to a good old VPS. A…

Sounds like Digital Ocean was the problem, not Kubernetes. Been running managed Kubernetes in GCP for years without any issues. They are bugging me to update for some time now, but I don't think they would force an update on me.

gke is pretty good at that, if there is a forced upgrade coming they will let you know months in advance.

Re: Comparing K3s with vanilla Kubernetes

#60

Post by MuffinFlavored »

zzyzxd wrote: post #31

I tried k3s several times in the past few years but I still can't use it in my homelab: 1. the project claims to be production ready and support HA control plane setup, but there's no solution for API load balancing out of box. How do you bring up a new node(either control plane or worker node)? You write down the join token produced by the first control plane node, and hardcode the token and the existing control pla…

> but there's no solution for API load balancing out of box

Why do you need this in a homelab?

Post reply on HN