51–60 of 189 posts
Earlier 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.
Managing hundreds or thousands of containers across hundreds or thousands of k8s nodes has a lot of operational challenges. Especially in-house on bare metal.
Having spent most of my career in kubernetes (usually managed by cloud), I always wonder when I see things like this, what is the use case or benefit of not having a control plane? To me, the control plane is the primary feature of kubernetes and one I would not want to go without. I know this describes operational overhead as a reason, but how it relates to the control plane is not clear to me. even managing a few h…
Not rude at all. The benefit is a much simpler model where you simply connect machines in a network where every machine is equal. You can add more, remove some. No need to worry about an HA 3-node centralised “cluster brain”. There isn’t one. It’s a similar experience when a cloud provider manages the control plane for you. But you have to worry about the availability when you host everything yourself. Losing etcd qu…
I have managed custom server clusters in a self hosted situation. the problems are hard, but if you’re small, why would you reach for such a solution in the first place? you’d be better off paying for a managed service. What situation forces so many people to reach to self hosted kubernetes?
As a happy user of coolify, what’s the difference between these two? Even coolify lets you add as many machines as you want and then manage docker containers in all machines from one coolify installation.
Earlier quoted context omitted.
Very cool! I think I'll have some opportunity soon to give it a shot, I have just the set of projects that have been needing a tool like this. One thing I think I'm missing after perusing the docs however is, how does one onboard other engineers to the cluster after it has been set up? And similarly, how does deployment from a CI/CD runner work? I don't see anything about how to connect to an existing cluster from a…
There isn't a cli function for adding a connection (independently of adding a new machine/node) yet, but they are in a simple config file (`~/.config/uncloud/config.yaml`) that you can copy or easily create manually for now. It looks like this: current_context: default contexts: default: connections: - ssh: admin@192.168.0.10 ssh_key_file: ~/.ssh/uncloud - ssh: admin@192.168.0.11 ssh_key_file: ~/.ssh/uncloud - ssh: a…
You can either specify one of the machine SSH target in the config.yaml or pass it directly to the 'uc' CLI command, e.g.
uc --connect user@host deploy
How does this compare to k3s?
How does this compare to something like Dokku?
Earlier 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.
Managing hundreds or thousands of containers across hundreds or thousands of k8s nodes has a lot of operational challenges. Especially in-house on bare metal.
Hey, 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…