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

Canonical introduces high-availability Micro-Kubernetes

zdnet.com

Post reply on HN
Print view View original

41–50 of 118 posts

Re: Canonical introduces high-availability Micro-Kubernetes

#41

Post by lifty »

candiddevmike wrote: post #6

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…

The one thing I wish upstream K8s would implement is embedded etcd so that the operational complexity becomes a bit more manageable. Luckily k3s has that :)

Re: Canonical introduces high-availability Micro-Kubernetes

#42

Post by merb »

sandGorgon wrote: post #31
koeng wrote: 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

I'm running k3s in production. K3s has hooks to setup Prometheus, autoscaling (for spot instances), etc. I don't see all of these in microk8s. I'm not sure if this is on the roadmap. I'm also not sure how customisable microk8s is. We run k3s with haproxy ingress (which is not the default) and calico for network (again nog the default)

sadly you need to run with kube-proxy and can't use calico's own sauce. but I already raised an issue for that, if I would use it more instead of kubespray (which I will deprecate soon) than I maybe fix it on my own time.

Re: Canonical introduces high-availability Micro-Kubernetes

#43

Post by lifty »

krimeo wrote: post #33
manigandham wrote: post #16

Earlier quoted context omitted.

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, whi…

> Running applications reliably and efficiently is an ongoing challenge Is it? I can take a program written for Windows 95 and run it on Windows 7 (maybe even newer) just fine and it will run reliable and efficiently and integrate better than containers. It is problem only on Linux because user space ABI keeps breaking. Notice that the containers run on the same linux kernel and not in VMs, why? Because "we do not br…

What are you talking about? The Linux ABI is very stable.

Re: Canonical introduces high-availability Micro-Kubernetes

#44

Post by thaeli »

mdaniel wrote: post #9
candiddevmike wrote: post #6

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…

A long wished for feature, but closed wontfix a long time ago: https://github.com/kubernetes/kubernetes/issues/1957 :-(

That's a pretty soft wontfix though. Might be reopenable at this point.

Re: Canonical introduces high-availability Micro-Kubernetes

#45

Post by CameronNemo »

jrockway wrote: post #7
candiddevmike wrote: post #6

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…

fwiw I think k3s also has an option to use canonical's dqlite.

Edit: they deprecated the option https://rancher.com/docs/k3s/latest/en/installation/ha-embed...

Re: Canonical introduces high-availability Micro-Kubernetes

#46

Post by krimeo »

lifty wrote: post #43
krimeo wrote: post #33

Earlier quoted context omitted.

> Running applications reliably and efficiently is an ongoing challenge Is it? I can take a program written for Windows 95 and run it on Windows 7 (maybe even newer) just fine and it will run reliable and efficiently and integrate better than containers. It is problem only on Linux because user space ABI keeps breaking. Notice that the containers run on the same linux kernel and not in VMs, why? Because "we do not br…

What are you talking about? The Linux ABI is very stable.

Linux kernel ABI is stable as rock.

To answer your question, I'm talking about Linux userspace ABI - you can't rely on ABI of essential libraries, openssl for example. That's why docker was born back then.

Re: Canonical introduces high-availability Micro-Kubernetes

#47

Post by koeng »

thor24 wrote: post #18
koeng wrote: post #4

Earlier quoted context omitted.

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).

Yep, it’s a small self hosted cluster on my own server hardware (VMs on Proxmox) I’m sure k8s would work, but k3s made it really easy for me to get going so now just has inertia.

Re: Canonical introduces high-availability Micro-Kubernetes

#48

Post by oso2k »

krimeo wrote: post #37
smarterclayton wrote: post #36

Earlier quoted context omitted.

As the person who has worked on making sure telemetry is useful and valuable for users and customers (helping drive insight into quality of kube and close the loop on fixing persistent issues), can you provide some more details about how we’ve let you down? We tried to be as responsible as possible but obviously we’ve failed along the way - what can be done to improve it?

Make the telemetry opt-in to begin with. The comment I am replying to is complaining about Ubuntu calling home, IBM OpenShift is the same story.

Not to be snarky, but that's easy. Just disconnect your cluster from the internet. We have hundreds of customers that are running disconnected clusters.

Re: Canonical introduces high-availability Micro-Kubernetes

#49

Post by manigandham »

krimeo wrote: post #33
manigandham wrote: post #16

Earlier quoted context omitted.

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, whi…

> Running applications reliably and efficiently is an ongoing challenge Is it? I can take a program written for Windows 95 and run it on Windows 7 (maybe even newer) just fine and it will run reliable and efficiently and integrate better than containers. It is problem only on Linux because user space ABI keeps breaking. Notice that the containers run on the same linux kernel and not in VMs, why? Because "we do not br…

How is that related? Environments and languages change. That's entirely different to running programs with zero-downtime deployments, load-balancing and traffic management, health monitoring, logging and observability, secret and config management, storage volumes, security roles, and much more.

What is your replacement for all that?

Re: Canonical introduces high-availability Micro-Kubernetes

#50

Post by justicezyx »

candiddevmike wrote: post #6

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…

K8s does have a well-defined storage abstraction that wraps the operations it performs.

Surprisingly, Etcd is neither scalable or high performance in our small cluster with But it appears that k8s community do not section a list of compatible storage engine that can plug and play with k8s. Or I might have missed some recent development.

Post reply on HN