Live data from Hacker News

Canonical introduces high-availability Micro-Kubernetes

zdnet.com

11–20 of 118 posts

Re: Canonical introduces high-availability Micro-Kubernetes

#11
Microk8s just works, and it's a big reason that I am running a ubuntu derivative rather then RHEL or Centos for my homelab. It's got the right level of feature enablement with the addons, and supports the whole set out of the box.

ETCD is a nice piece of nick, but I am still disappointed that other options haven't displaced it, such as consul. That said, I am not sure I am ready to trust a new distribute store for this. Its hard to get that right.

Re: Canonical introduces high-availability Micro-Kubernetes

#12
post #2

Anyone know how this compares to k3s? I’ve been using k3s for a while, and there have been a few bugs that made me a bit annoyed

This doesn't answer your question, but I'm piggy-backing with comments on k3s.

For me, using k3s for development (not prod), the killer feature is running it in --docker mode where the node uses the local dockerd to run containers (vs. managing its own containerd instance).

This allows building images locally with `docker build` and immediately using them in kubernetes pods _without_ first pushing to a (possibly local) image repository and having k3s pull the images.

Last time I investigated, none of kind, microk8s, or minikube supported this mode. For large images (gigabyte or more, and I've got a handful of these), it's very space-inefficient to have a copy in my docker and in a local registry _and_ in k3s's containerd at the same time. How is this problem typically solved?

(I note the kubernetes included in Docker Desktop on macOS works in the same way: images built with `docker build` are available to kubernetes without going through a registry.)

Re: Canonical introduces high-availability Micro-Kubernetes

#13
writing one application was hard so instead let's assume writing lots of tiny applications will be easier (???) but isolating them is hard so let's put them in containers but running containers is complicated so we need orchestration managers like kubernetes or something but running those things is too hard for someone whose job isn't to run kubernetes for a living so microk8s or minikube or k3s or whatever? that's the gist of the industry? that's really what we're doing these days?

Re: Canonical introduces high-availability Micro-Kubernetes

#14
post #2

Anyone know how this compares to k3s? I’ve been using k3s for a while, and there have been a few bugs that made me a bit annoyed

It uses distributed sqlite (dqlite) vs etcd/RDBMS (postgresql and friends). It's also not part of the CNCF like k3s is (yet?).

Re: Canonical introduces high-availability Micro-Kubernetes

#15
post #7

This is very interesting, we're seeing a lot of Kubernetes "flavors" coming out that remove the etcd requirement. It's no secret that etcd is a key part of why Kubernetes is complex--etcd scaling/securing/recovery is really hard. I think Kubernetes would do well to make swapping out the storage backend possible without having all of these forks. Kubernetes is too tightly coupled to etcd, and for little benefit. I wou…

To some extent, the distributed consensus is kind of the important part. If you have a bunch of components that don't know what state they're supposed to be in, you don't really have a cluster. Looking at the marketing documentation (I didn't read the code), they just wrote their own consensus and datastore instead of using etcd. So the underlying fundamental computer science problems still exist, but nobody has been…

If etcd blows up, your cluster should stay in the same state it was in before etcd blew up.

Re: Canonical introduces high-availability Micro-Kubernetes

#16
post #13

writing one application was hard so instead let's assume writing lots of tiny applications will be easier (???) but isolating them is hard so let's put them in containers but running containers is complicated so we need orchestration managers like kubernetes or something but running those things is too hard for someone whose job isn't to run kubernetes for a living so microk8s or minikube or k3s or whatever? that's t…

No, that's not what we're doing at all. I agree that "microservices" is mostly useless hype but running applications reliably and efficiently is an ongoing challenge which Kubernetes solves pretty well.

Of course it does shift the complexity into the underlying K8S so installing and operating it can be difficult but there are manys to avoid that as a user. Overall you gain much more in productivity and usability, which is why it's taken off so much.

Re: Canonical introduces high-availability Micro-Kubernetes

#17
post #13

writing one application was hard so instead let's assume writing lots of tiny applications will be easier (???) but isolating them is hard so let's put them in containers but running containers is complicated so we need orchestration managers like kubernetes or something but running those things is too hard for someone whose job isn't to run kubernetes for a living so microk8s or minikube or k3s or whatever? that's t…

everybody who doesn't writes thousands of shell scripts/ansible/puppet whatever stuff to emulate a small version of kubernetes

Re: Canonical introduces high-availability Micro-Kubernetes

#18
post #4
post #3

Earlier quoted context omitted.

Same question, but with minikube.

I think minikube is for local usage. I use K3S for deploying an actual production cluster, so I’m more curious about how micro-k8s acts on that scale

> I use K3S for deploying an actual production cluster

You mean when you want to run a small cluster of let's say less than 10 nodes (anything in single digits)?

Why doesn't normal k8 work this way? like same tech but just less scale?

(I should probably read more on the side myself as well, new to this K8 world).

Re: Canonical introduces high-availability Micro-Kubernetes

#19
post #7

This is very interesting, we're seeing a lot of Kubernetes "flavors" coming out that remove the etcd requirement. It's no secret that etcd is a key part of why Kubernetes is complex--etcd scaling/securing/recovery is really hard. I think Kubernetes would do well to make swapping out the storage backend possible without having all of these forks. Kubernetes is too tightly coupled to etcd, and for little benefit. I wou…

To some extent, the distributed consensus is kind of the important part. If you have a bunch of components that don't know what state they're supposed to be in, you don't really have a cluster. Looking at the marketing documentation (I didn't read the code), they just wrote their own consensus and datastore instead of using etcd. So the underlying fundamental computer science problems still exist, but nobody has been…

> I just don't trust Canonical much...

They lost me when I've tried their ubuntu server when I was lazy one day and greeted with their Landscape advertisement in the MOTD display.

Then I installed armbian's ubuntu version because Debian version was not ready and found out that MOTD was downloaded from web every time I log in.

Add analytics (now opt-in), forcing snaps and their silent-ish efforts to monopolize the landscape, I avoid them altogether.

Post reply on HN