Canonical introduces high-availability Micro-Kubernetes
1–10 of 118 posts
Re: Canonical introduces high-availability Micro-Kubernetes
#2Anyone 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
#3Anyone 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
Same question, but with minikube.
Re: Canonical introduces high-availability Micro-Kubernetes
#4Anyone 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
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
Re: Canonical introduces high-availability Micro-Kubernetes
#5Anyone 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
The first thing I think of with microk8s is their available addons, which are fairly comprehensive, opinionated, "just works" solutions for microk8s. https://microk8s.io/docs/addons#heading--list
As a k3s user (for local dev & my very small personal prod envs), I end up having to assemble a lot of these solutions myself. I prefer my own picks, my own solutions, and learning, but microk8s having these instantly available would be really good for a lot of folks. Until now though it has never felt like those advantages would be useful in a real prod environment, that microk8s was not interested in being in prod, but HA signals to me that they are interested in broader adoption.
Re: Canonical introduces high-availability Micro-Kubernetes
#6This 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 would wager a lot of customers would trade the guarantees etcd provides for a simpler deployment.
Re: Canonical introduces high-availability Micro-Kubernetes
#7This 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 burned by this particular implementation yet. That doesn't inspire much confidence for me; if etcd blows up, at least someone else's cluster has blown up in the same way before. Now if it happens to you, you get to be the first person to debug it. Fun.
In general, I'm not blown away with Canonical's track record. I used microk8s in its early days and it kind of blew up my coworker's computer. Networking stopped working. Making a request to localhost:5000 would return an nginx error page, even though nginx wasn't running anywhere on that machine or the network. It even persisted itself through reboots! We just reinstalled the machine eventually. It was weird stuff and I haven't touched it again. (I prefer kind locally and k3s for small "real" clusters.) Then there's Snap, major breaking changes to Ubuntu for no reason, etc. I just don't trust Canonical much, and I'm not quite ready to take a leap of faith on their new distributed database. But maybe it's great, and we'll all be using this in a year. A stopped clock is right twice a day.
Re: Canonical introduces high-availability Micro-Kubernetes
#8This 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…
For single node sure, but the moment you have some set of jobs requiring a multi node setup, the chance of wanting to find yourself in a situation where the cluster has essentially bricked itself due to a momentary power outage reduces to zero really quickly.
The only place etcd might not pay off is in disposable dev environments or something, but do you really want your prod setup to page only to discover a complete cluster rebuild is necessary to resolve the problem?
Re: Canonical introduces high-availability Micro-Kubernetes
#9This 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…
A long wished for feature, but closed wontfix a long time ago: https://github.com/kubernetes/kubernetes/issues/1957 :-(
Re: Canonical introduces high-availability Micro-Kubernetes
#10This 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…
For single node sure, but the moment you have some set of jobs requiring a multi node setup, the chance of wanting to find yourself in a situation where the cluster has essentially bricked itself due to a momentary power outage reduces to zero really quickly. The only place etcd might not pay off is in disposable dev environments or something, but do you really want your prod setup to page only to discover a complete…
There are various levels of outages you may encounter with an etcd outage, but it shouldn't take your workloads completely offline. The cluster API will be offline, but the workloads will keep on chugging. I think with the decoupling of etcd and the expectation that this might happen, we'd see more improvements on how to (gracefully) handle these situations.
Also, there was a bug with kube api where it wouldn't failover to other etcd members during an outage. So I would say most customers have ran kubernetes with a "single backend" at some point.