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.
Canonical introduces high-availability Micro-Kubernetes
11–20 of 118 posts
Re: Canonical introduces high-availability Micro-Kubernetes
#12Anyone 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
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
#13Re: Canonical introduces high-availability Micro-Kubernetes
#14Anyone 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
Re: Canonical introduces high-availability Micro-Kubernetes
#15This 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…
Re: Canonical introduces high-availability Micro-Kubernetes
#16writing 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…
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
#17writing 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…
Re: Canonical introduces high-availability Micro-Kubernetes
#18Earlier 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
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
#19This 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…
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.