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

131–140 of 189 posts

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

#131

Post by davedx »

JohnMakin wrote: post #17

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…

> a few hundred nodes and maybe 10,000 containers, relatively small

And that's just your CI jobs, right? ;)

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

#132

Post by GoblinSlayer »

justincormack wrote: post #44
miyuru wrote: post #23

Earlier quoted context omitted.

> What specifically do you mean by ipv6 support? This question does not make sense. This is equivalent to asking "What specifically do you mean by ipv4 support" These days both protocols must be supported, and if there is a blocker it should be clearly mentioned.

How do you want to allocate ipv6 addresses to containers? Turns out there are lots of answers. Some people even want to do ipv6 NAT.

Like docker? --fixed-cidr-v6=2001:db8:1::/64

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

#133

Post by everforward »

nullpoint420 wrote: post #6
topspin wrote: post #4

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

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.

It's not the manifests so much as the mountain of infra underlying it. k8s is an amazing abstraction over dynamic infra resources, but if your infra is fairly static then you're introducing a lot of infra complexity for not a ton of gain.

The network is complicated by the overlay network, so "normal" troubleshooting tools aren't super helpful. Storage is complicated by k8s wanting to fling pods around so you need networked storage (or to pin the pods, which removes almost all of k8s' value). Databases are annoying on k8s without networked storage, so you usually run them outside the cluster and now you have to manage bare metal and k8s resources.

The manifests are largely fine, outside of some of the more abnormal resources like setting up the nginx ingress with certs.

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

#134

Post by jauntywundrkind »

tw04 wrote: post #125
jabr wrote: post #18

Earlier 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.

I applaud you for having a specific complaint. 'You might not need it' 'its complex' and 'for some reason it bothers me' are all these vibes based winges that are so abundant. But with nothing specific, nothing contestable.

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

#135

Post by KronisLV »

horsawlarway wrote: post #110
this_user wrote: post #89

Earlier quoted context omitted.

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…

> 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!).

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

Might need to redefine the port range from 30000-32767. Actually, if you want to avoid the ingress abstraction and maybe want to run a regular web server container of your choice to act as it (maybe you just prefer a config file, maybe that's what your legacy software is built around, maybe you need/prefer Apache2, go figure), you'd probably want to be able to run it on 80 and 443. Or 3000 or 8080 for some other software, out of convenience and simplicity.

Depending on what kind of K8s distro you use, thankfully not insanely hard to change though: https://docs.k3s.io/cli/server#networking But again, that's kind of going against the grain.

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

#136

Post by rahkiin »

JohnMakin wrote: post #52
psviderski wrote: post #26

Earlier quoted context omitted.

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…

If you are a small operation and trying to self host k3s or k8s or any number of out of the box installations that are probably at least as complex as docker compose swarms, for any non trivial production case, presents similar problems in monitoring and availability as ones you’d get with off the shelf cloud provider managed services, except the managed solutions come without the pain in the ass. Except you don’t ha…

Price. Data sovereignty. Legal. All are valid reasons to self-host

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

#137

Post by PunchyHamster »

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…

k3s makes it easy to deploy, not to debug any problems with it. It's still essentially adding few hundred thousand lines of code into your infrastructure, and if it is a small app you need to deploy, also wasting a bit of ram

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

#138

Post by yabones »

tontony wrote: post #72
tex0 wrote: post #61

Earlier quoted context omitted.

This is a cool tool, I like the idea. But the way `uc machine init` works under the hood is really scary. Lot's of `curl | bash` run as root. While I would love to test this tool, this is not something I would run on any machine :/

Curious, what would be an ideal (secure) approach for you to install this (or similar) tool?

The correct way would be to publish packages on a proper registry/repository and install them with a package manager. For example, create a 3rd party Debian repository, and import the config & signing key on install. It's more work, sure, but it's been the best practice for decades and I don't see that changing any time soon.

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

#139

Post by JohnMakin »

weitendorf wrote: post #119
JohnMakin wrote: post #17

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…

I'm working on a similar project (here's the v0 of its state management and the libraries its "local control plane" will use to implement a mesh https://github.com/accretional/collector ) and worked on the data plane for Google Cloud Run/Functions: IMO kubernetes is great if your job is to fiddle with Kubernetes. But damn, the overhead is insane. There is this broad swathe of middle-sized tech companies and non-tech…

The experience you are describing has overwhelmingly not been my own, nor anyone in my space I know.

I can only speak most recently for EKS, but the cost is spent almost entirely on compute. I’m a one man shop managing 10,000 containers. I basically only spend on the compute itself, which is not all that much, and certainly far, far less than hiring a sys admin. Self hosted anything would be a huge PITA for me and likely end up costing more.

Yes, you can avoid kubernetes and being a “slave” to cloud providers, but I personally believe you’re making infrastructure tradeoffs in a bad way, and likely spending as much in the long run anyway.

maybe my disconnect here is that I mostly deal with full production scale applications, not hobby projects I am hosting on my own network (nothing wrong with that, and I would agree k8s is overkill for something like that).

Eventually though, at scale, I strongly believe you will need or want a control plane of some type for your container fleets, and that typically ends up looking or acting like k8s.

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

#140

Post by tontony »

yabones wrote: post #138
tontony wrote: post #72

Earlier quoted context omitted.

Curious, what would be an ideal (secure) approach for you to install this (or similar) tool?

The correct way would be to publish packages on a proper registry/repository and install them with a package manager. For example, create a 3rd party Debian repository, and import the config & signing key on install. It's more work, sure, but it's been the best practice for decades and I don't see that changing any time soon.

Sure, but it all boils down to trust at the end of the day. Why would you trust a third-party Debian repository (that e.g. has a different user namespace and no identity linking to GitHub) more than running something from evidently the same user from GitHub, in this specific case?

I'm not arguing that a repository is nice because versioning, signing, version yanking, etc, and I do agree that the process should be more transparent and verifiable for people who care about it.

Post reply on HN