Would this be a good use case for docker swarm replacement? Right now I have about 100 containers on prem and need to find something to replace swarm
Canonical introduces high-availability Micro-Kubernetes
71–80 of 118 posts
Re: Canonical introduces high-availability Micro-Kubernetes
#72Earlier quoted context omitted.
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 lan…
You can only install it via snap is a no no, it's that simple.
Re: Canonical introduces high-availability Micro-Kubernetes
#73Earlier quoted context omitted.
> 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).
It does. Upstream kubeadm - authentic kubernetes - can even run on a single node. Not sure why people choose k3s or microk8s when you can just as easily deploy the real thing.
For smaller needs, K3s runs fast/stable on servers with 1-2 GB of RAM, whereas K8s proper tends to be a little shaky until you go to 2-4 GB, minimum.
Re: Canonical introduces high-availability Micro-Kubernetes
#74Earlier 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.
that's what they call 'opinionated default configuration'; then they tie in subscription management with telemetry so that opting out of it isn't an option to begin with; https://docs.openshift.com/container-platform/4.1/telemetry/... Several further tie ins and the system as a whole becomes barely usable. But then integration is the whole point of openshift, isn't it?
Re: Canonical introduces high-availability Micro-Kubernetes
#75How is this different from multi-node k3s (aside from minor differences in CLI and, obviously, different development teams)?
Re: Canonical introduces high-availability Micro-Kubernetes
#76Anyone 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 loca…
it's a bit more troublesome with microk8s https://microk8s.io/docs/registry-images
Re: Canonical introduces high-availability Micro-Kubernetes
#77Earlier quoted context omitted.
> 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).
It does. Upstream kubeadm - authentic kubernetes - can even run on a single node. Not sure why people choose k3s or microk8s when you can just as easily deploy the real thing.
kubeadm is very bare bones though; it gives you a running node but you are still responsible for configuring network and storage providers, an ingress controller and probably a load balancer.
Re: Canonical introduces high-availability Micro-Kubernetes
#78I am all for this trend. Microk8s and k3s are both a joy to develop with (though I have ran into a few bugs with k3s so tend to prefer Microk8s). How many folks are running self-managed k8s in production though, out of curiosity? It seems so economical to deploy k3s or use something like Rancher on dirt cheap VPS's from some place like Hetzner -- but what's the ops burden and failure risk like? Never tried it myself…
Maybe not the answer you are looking for, but for small and not that critical workloads, I've so far been happy with docker swarm workloads on cheap cloud/VPS.
Re: Canonical introduces high-availability Micro-Kubernetes
#79I am all for this trend. Microk8s and k3s are both a joy to develop with (though I have ran into a few bugs with k3s so tend to prefer Microk8s). How many folks are running self-managed k8s in production though, out of curiosity? It seems so economical to deploy k3s or use something like Rancher on dirt cheap VPS's from some place like Hetzner -- but what's the ops burden and failure risk like? Never tried it myself…
Maybe not the answer you are looking for, but for small and not that critical workloads, I've so far been happy with docker swarm workloads on cheap cloud/VPS.
We run our platform in different cities and they are all on-prem(custom server or managed hypervisor). After hearing horror stories about kubernetes on prem, we are happy that we decided to go with docker swarm.
Re: Canonical introduces high-availability Micro-Kubernetes
#80Some Microsoft teams also dislike k8s complexity for .NET backend development, hence Project Tye.
https://devblogs.microsoft.com/aspnet/introducing-project-ty...