Earlier quoted context omitted.
This thread is about using multi-machine clusters, and sqlite cannot be used for multi-machine clusters in k3s. etcd is the default when starting k3s in cluster mode [1]. [1] https://docs.k3s.io/datastore
No, this thread is about multiple containers across machines. What you describe is multi-master for the server . You can run multple agents across serveral nodes therefore clustering the container workload across multiple container hosting servers. Multi-master is something different.
Uncloud - Tool for deploying containerised apps across servers without k8s
121–130 of 189 posts
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#122If not K8S, why not Nomad ( https://github.com/hashicorp/nomad )?
You can't really do anything with it except work for Hashicorp for free, or create a fork that nobody is allowed to use unless they self-host it.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#123BTW just looking at other variations on the theme:
Feel free to add more.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#124Earlier quoted context omitted.
I took some inspiration from Kamal, e.g. the imperative model but kamal is more a deployment tool. In addition to deployments, uncloud handles clustering - connects machines and containers together. Service containers can discover other services via internal DNS and communicate directly over the secure overlay network without opening any ports on the hosts. As far as I know kamal doesn’t provide an easy way for servi…
This is neat, regarding clustering - can this work with distributed erlang/elixir?
Basically just configure it with `{service-name}.internal` to find other instances of the service.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#125Earlier quoted context omitted.
"I keep seeing teams reach for K8s when they really just need to run a bunch of containers across a few machines" Since k8s is very effective at running a bunch of containers across a few machines, it would appear to be exactly the correct thing to reach for. At this point, running a small k8s operation, with k3s or similar, has become so easy that I can't find a rational reason to look elsewhere for container "orche…
I can only speak for myself, but I considered a few options, including "simple k8s" like [Skate]( https://skateco.github.io/ ), and ultimately decided to build on uncloud. It was as much personal "taste" than anything, and I would describe the choice as similar to preferring JSON over XML. For whatever reason, kubernetes just irritates me. I find it unpleasant to use. And I don't think I'm unique in that regard.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#126Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#127Earlier quoted context omitted.
100%. I’m really not sure why K8S has become the complexity boogeyman. I’ve seen CDK apps or docker compose files that are way more difficult to understand than the equivalent K8S manifests.
Docker Compose is simple: You have a Compose file that just needs Docker (or Podman). With k8s you write a bunch of manifests that are 70% repetitive boilerplate. But actually, there is something you need that cannot be achieved with pure manifest, so you reach for Kustomize. But Kustomize actually doesn't do what you want, so you need to convert the entire thing to Helm. You also still need to spin up your k8s clust…
That’s not bad, but I want to spend more time trying new things or enjoying the results of my efforts than maintaining the underlying substrates. For that purpose, K8s is consistently too complicated for my own ends - and Uncloud looks to do exactly what I want.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#128Earlier quoted context omitted.
I can only speak for myself, but I considered a few options, including "simple k8s" like [Skate]( https://skateco.github.io/ ), and ultimately decided to build on uncloud. It was as much personal "taste" than anything, and I would describe the choice as similar to preferring JSON over XML. For whatever reason, kubernetes just irritates me. I find it unpleasant to use. And I don't think I'm unique in that regard.
How many flawless, painless major version upgrades have you had with literally any flavor of k8s? Because in my experience, that’s always a science experiment that results in such pain people end up just sticking at their original deployed version while praying they don’t hit any critical bugs or security vulnerabilities.
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#129Earlier quoted context omitted.
Try it on bare metal where you're managing the distributed storage and the hardware and the network and the upgrades too :)
Why would you want to do that though? On cloud, in my experience, you are mostly paying for compute with managed kubernetes instances. The overhead and price is almost never kubernetes itself, but the compute and storage you are provisioning, which, thanks to the control plane, you have complete control over. what am i missing? I wouldn’t dare try to with a small shop try to self host a production kubernetes solution…
Now I almost finished the setting up part using a single-node (for now) Kubernetes cluster running with Talos Linux, and all of the manifest files managed with Cue lang (seriously, I would have abandoned it if I had not discovered Cue to generate and type check all of the yaml).
I think Kubernetes is the right solution for the complexity of what I'm running, but even though it was a hassle to manage the storage, the backups, the auth, the networking and so on, I much prefer having all of this hosted at my house.
But I agree with the control plane part, just pointing out my use case for self-hosting k8s
Re: Uncloud - Tool for deploying containerised apps across servers without k8s
#130Hey, creator here. Thanks for sharing this! Uncloud[0] is a container orchestrator without a control plane. Think multi-machine Docker Compose with automatic WireGuard mesh, service discovery, and HTTPS via Caddy. Each machine just keeps a p2p-synced copy of cluster state (using Fly.io's Corrosion), so there's no quorum to maintain. I’m building Uncloud after years of managing Kubernetes in small envs and at a unicor…
But I wonder what this solves?
Because I stopped abusing k8s and started using more container hosts with quadlets instead, using Ansible or Terraform depending on what the situation calls for.
It works just fine imho. The CI/CD pipeline triggers a podman auto-update command, and just like that all containers are running the latest version.
So what does uncloud add to this setup?