Have they pulled it out of snap yet? Not being able to pin or control when upgrades happen is a nonstarter for us.
Canonical introduces high-availability Micro-Kubernetes
51–60 of 118 posts
Re: Canonical introduces high-availability Micro-Kubernetes
#52Earlier quoted context omitted.
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.
And that applies to Ubuntu just as well. All I'm saying IBM is no better than Canonical in this regard.
Not complaining - If you want me to complain about IBM cluster technology that would be a whole different story.
And no I'm not gonna ask about disconnected clusters :).
Re: Canonical introduces high-availability Micro-Kubernetes
#53Earlier quoted context omitted.
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.
And that applies to Ubuntu just as well. All I'm saying IBM is no better than Canonical in this regard. Not complaining - If you want me to complain about IBM cluster technology that would be a whole different story. And no I'm not gonna ask about disconnected clusters :).
Haha. I still work for Red Hat, and Consulting at that. My pay is determined by how many billable hours I put in and my customer reviews. Not directly by how much you buy.
Re: Canonical introduces high-availability Micro-Kubernetes
#54Anyone 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)
microk8s has a Prometheus add-on that you can enable with one command: https://microk8s.io/docs/addons
I'm using it and it's been great so far.
Re: Canonical introduces high-availability Micro-Kubernetes
#55Earlier 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…
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?
> How is that related?
I thought we were talking about running applications reliably. Why is complete linux userspace bundled separately in each container?
> Environments and languages change. Yes.
> 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.
That's a lot of new requirements in addition to "running applications reliably". Most applications simply do not need that. And I believe this is the point of the original comment you replied to.
- zero-downtime deployments -> not needed for most applications (for example, twitter outages are not a big deal either). Btw how do you do zero-downtime of (websocket) streams with kubernetes? ;)
- load-balancing and traffic management -> in standard k8s you are pushing all traffic through one active LB (nginx) anyway => strip most of the extra layers and you dont even need that LB
- health monitoring, logging etc. -> you can use an existing solution that provides only the functionality you need, most of the work will be in your app anyway (every application needs different metrics ..)
The argument is that most applications do not need to scale at this level (until you need anycast DNS returning per-node IPs or at least geodns, you are not scaling that much anyway) and can be implemented in simpler manner hence easier and cheaper to maintain, audit and secure.
I do not want security roles, storage volumes and config management or observability I want my application to reliably and quickly serve my customers and be easy to maintain and debug.
If you want to discuss how to design architecture for scalable applications which keep all state in distributed databases but based on a platform with stable ABI that would surely be an interesting debate as well.
Re: Canonical introduces high-availability Micro-Kubernetes
#56Earlier quoted context omitted.
And that applies to Ubuntu just as well. All I'm saying IBM is no better than Canonical in this regard. Not complaining - If you want me to complain about IBM cluster technology that would be a whole different story. And no I'm not gonna ask about disconnected clusters :).
Haha. I still work for Red Hat, and Consulting at that. My pay is determined by how many billable hours I put in and my customer reviews. Not directly by how much you buy.
I thought there is no Red Hat anymore.
Re: Canonical introduces high-availability Micro-Kubernetes
#57Anyone 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?).
dqlite is a RDBMS, it's just sqlite + raft
Re: Canonical introduces high-availability Micro-Kubernetes
#58Have they pulled it out of snap yet? Not being able to pin or control when upgrades happen is a nonstarter for us.
Just pin to a channel.
Re: Canonical introduces high-availability Micro-Kubernetes
#59This 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…
If K8S can be made turn-key, it will become possible for some deployments to realize massive cost savings by deploying across clusters of bare metal machines from hosts like OVH, packet.net, datapacket.com, and so on. The cost of bandwidth and processing power is just so much lower.
The only remaining headache would be database. Setting up reliable mission-critical HA Postgres is kind of a pain, and it's nice to not have to worry about it. If that can also be canned, then this kind of rig would be a really compelling alternative to the managed clouds... unless you need other things like S3, etc.
Re: Canonical introduces high-availability Micro-Kubernetes
#60Anyone 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…
A couple of years ago minikube supported this with --vm-driver=none