Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uncloud - Tool for deploying containerised apps across servers without k8s

uncloud.run

Post reply on HN
Print view View original

101–110 of 189 posts

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#101

Post by codegeek »

raw_anon_1111 wrote: post #84

I know just enough about Kubernetes to not sound like an idiot when I’m in the room and mostly I deploy Docker containers to various managed services on AWS - Lambda, ECS, etc. But, as a lead for implementations, I just couldn’t in good conscience permit something that is not an industry standard and not supported by my cloud provider. First from a self interested standpoint, it looks a lot better on their resume to…

With your logic, we will never have any new innovations being tried. This is a Show HN for a product someone built. No one is asking every corporation/company to replace K8s with this. It is a different and simpler take on the complexity of deploying containers without a control plane. I personally welcome these types of post. A lot of great products started out with someone just trying to solve their own problem.

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#102

Post by [deleted] »

this_user wrote: post #89
nullpoint420 wrote: post #6

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.

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…

[deleted]

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#103

Post by [deleted] »

cobolcomesback wrote: post #80
_joel wrote: post #68

Earlier quoted context omitted.

No, it's not. Read the docs[1] - sqlite is the default. "Lightweight datastore based on sqlite3 as the default storage backend. etcd3, MySQL, and Postgres are also available." [1] https://docs.k3s.io/

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

[deleted]

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#105

Post by _joel »

cobolcomesback wrote: post #80
_joel wrote: post #68

Earlier quoted context omitted.

No, it's not. Read the docs[1] - sqlite is the default. "Lightweight datastore based on sqlite3 as the default storage backend. etcd3, MySQL, and Postgres are also available." [1] https://docs.k3s.io/

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.

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#106

Post by mgaunard »

Glemkloksdjf wrote: post #81
psviderski wrote: post #2

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…

So you build an insecure version of nomad/kubernetes and co? If you do anything professional, you better choose proven software like kubernetes or managed kubernetes or whatever else all the hyperscalers provide. And the complexity you are solving now or have to solve, k8s solved. IaC for example, Cloud Provider Support for provisioning a LB out of the box, cert-manager, all the helm charts for observability, logging…

Those are all sub-par cloud technologies which perform very badly and do not scale at all.

Some people would rather build their own solutions to do these things with fine-grain control and the ability to handle workloads more complex that a shopping cart website.

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#107

Post by tevon »

topspin wrote: post #4
psviderski wrote: post #2

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…

"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…

Perhaps it feels so easy given your familiarity with it.

I have struggled to get things like this stood up and hit many footguns along the way

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#108

Post by _joel »

davidgl wrote: post #65
_joel wrote: post #31

Earlier quoted context omitted.

k3s uses sqlite, so not etcd.

It can use sqlite (single master), or for cluster it can use pg, or mysql, but etcd by default

apologies, I misread this and gave a terse reply.

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#109

Post by quectophoton »

this_user wrote: post #89
nullpoint420 wrote: post #6

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.

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…

> Docker Compose is simple: You have a Compose file that just needs Docker (or Podman).

And if you want to use more than one machine then you run `docker swarm init`, and you can keep using the Compose file you already have, almost unchanged.

It's not a K8s replacement, but I'm guessing for some people it would be enough and less effort than a full migration to Kubernetes (e.g. hobby projects).

Re: Uncloud - Tool for deploying containerised apps across servers without k8s

#110

Post by horsawlarway »

this_user wrote: post #89
nullpoint420 wrote: post #6

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.

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…

This is some serious rose colored glasses happening here.

If you have a service with a simple compose file, you can have a simple k8s manifest to do the same thing. Plenty of tools convert right between the two (incl kompose, which k8s literally hands you: https://kubernetes.io/docs/tasks/configure-pod-container/tra...)

Frankly, you're messing up by including kustomize or helm at all in 80% of cases. Just write the (agreed on tedious boilerplate - the manifest format is not my cup of tea) yaml and be done with the problem.

And no - you don't need an ingress. Just spin up a nodeport service, and you have the literal identical experience to exposing ports with compose - it's just a port on the machines running the cluster (any of them - magic!).

You don't need to touch an ingress until you actually want external traffic using a specific hostname (and optionally tls), which is... the same as compose. And frankly - at that point you probably SHOULD be thinking about the actual tooling you're using to expose that, in the same way you would if you ran it manually in compose. And sure - arguably you could move to gateways now, but in no way is the ingress api deprecated. They very clearly state...

> "The Ingress API is generally available, and is subject to the stability guarantees for generally available APIs. The Kubernetes project has no plans to remove Ingress from Kubernetes."

https://kubernetes.io/docs/concepts/services-networking/ingr...

---

Plenty of valid complaints for K8s (yaml config boilerplate being a solid pick) but most of the rest of your comment is basically just FUD. The complexity scale for K8s CAN get a lot higher than docker. Some organizations convince themselves it should and make it very complex (debatably for sane reasons). For personal needs... Just run k3s (or minikube, or microk8s, or k3ds, or etc...) and write some yaml. It's at exactly the same complexity as docker compose, with a slightly more verbose syntax.

Honestly, it's not even as complex as configuring VMs in vsphere or citrix.

Post reply on HN