Readit NewsIMHO, in a modern setting base-16 would be the most convenient. Then I maybe wouldn't struggle to remember that the CIDR range C0.A8.0.0/18 (192.168.0.0/24) consists of 10 (16) blocks of size 10 (16).
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?
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 hundred nodes and maybe 10,000 containers, relatively small - I update once a year and the managed cluster updates machine images and versions automatically. Are people trying to self host kubernetes for production cases, and that’s where this pain comes from?
Sorry if it is a rude question.
I need to run on-prem, so managed k8s is not an option. Experts tells me I should have 2 FTE to run k8s, which I don't have. k8s has so many components, how should I debug that in case of issues without k8s experience? k8s APIs change continuously, how should I manage that without k8s experience?
It's not a k8s replacement. But I do see a sweet spot for such a solution. We still run Docker Swarm on 5 servers, no hyperscalers, no API changes expected ;-)
When you run 'uc deploy' command:
- it reads the spec from your compose.yaml
- inspects the current state of the services in the cluster
- computes the diff and deployment plan to reconcile it
- executes the plan after the confirmation
Please see the docs and demo: https://uncloud.run/docs/guides/deployments/deploy-app
The main difference with Docker Swarm is that the reconciliation process is run on your local/CI machine as part of the 'uc deploy' CLI command execution, not on the control plane nodes in the cluster.
And it's not running in the loop automatically. If the command fails, you get an instant feedback with the errors you can address or rerun the command again.
It should be pretty straightforward to wrap the CLI logic in a Terraform or Pulumi provider. The design principals are very similar and it's written in Go.
I get that putting the declarative spec in the control plane and having the service autoreconcile continuously is another layer but this is great as a start.
In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer to guard against node failures if your ok with a 1 min or 1 sec recovery objective?
Note that a DNS A record with multiple IPs doesn't provide failover, only round robin. But you can use the Cloudflare DNS proxy feature as a poor man's LB. Just add 2+ proxied A records (orange cloud) pointing to different machines. If one goes down with a 52x error, Cloudflare automatically fails over to the healthy one.
Could be something interesting to integrate though.
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 unicorn. I keep seeing teams reach for K8s when they really just need to run a bunch of containers across a few machines with decent networking, rollouts, and HTTPS. The operational overhead of k8s is brutal for what they actually need.
A few things that make it unique:
- uses the familiar Docker Compose spec, no new DSL to learn
- builds and pushes your Docker images directly to your machines without an external registry (via my other project unregistry [1])
- imperative CLI (like Docker) rather than declarative reconciliation. Easier mental model and debugging
- works across cloud VMs, bare metal, even a Raspberry Pi at home behind NAT (all connected together)
- minimal resource footprint (<150MB ram)
I share the same concern as top comments on security but going to check out out in more detail.
I wonder if you integrated some decentralized identity layer with DIDs, if this could be turned into some distributed compute platform?
Also, what is your thinking on high availability and fail failovers?
e^(i*tau) = 1
I won't reproduce https://www.tauday.com/tau-manifesto here, but I'll just mention one part of it. I very much prefer doing radian math using tau rather than pi: tau/4 radians is just one-fourth of a "turn", one-fourth of the way around the circle, i.e. 90°. Which is a lot easier to remember than pi/2, and would have made high-school trig so much easier for me. (I never had trouble with radians, and even so I would have had a much easier time grasping them had I been taught them using tau rather than pi as the key value).
I've been posting the manifesto to friends and colleagues every tau day for the past ten years. Let's keep chipping away at it and eventually we won't obfuscate radians for our kids anymore.
Friends don't let friends use pi!
I’ve evaluated both RustFS and Garage, and here’s the breakdown:
Release Cadence: Garage feels a bit slower, while RustFS is shipping updates almost weekly.
Licensing: Garage is on AGPLv3, but RustFS uses the Apache license (which is huge for enterprise adoption).
Stability: Garage currently has the edge in distributed environments.
With MinIO effectively bowing out of the OSS race, my money is on RustFS to take the lead.
I recently learned that Ceph also has an object store and have been playing around with microceph. Ceph also is more flexible than garage in terms of aggregating differently sized disks. Since it's also already integrated in Proxmox and has over a decade of enterprise deployments, that's my top contender at the moment. I'm just not sure about the level of S3 API compatibility.
Any opinions on Ceph vs RustFS?
1. Developers balked at being required to take on the cognitive load required to allow GC-less memory management
2. Developers wore their ability to take on that cognitive load as a badge of honor, despite it not being in their best interest
I eventually came to the decision to stop developing in Rust, despite its popularity. It is really cool that its creators pulled it off. It was quite an achievement, given how different it was when it came out. I think that if I had to implement a critical library I would consider using Rust for it, but as a general programming language I want something that allows me to focus my mental facilities on the complexities of the actual problem domain, and I felt that it was too often too difficult to do that with Rust.