This is a scam. Bootstrapping k3s is extremely easy. This tool lies to you giving you the impression that it's difficult or that you need a script, and tries to sell you monthly pro subscription, the features of which are also completely trivial.
K3sup – bootstrap K3s over SSH in < 60s
41–50 of 55 posts
Re: K3sup – bootstrap K3s over SSH in < 60s
#42I'm trying to understand why people are spinning up so many k8s clusters that they need a tool to do it for them? I have one. And it's managed. I don't think there's significant cost savings to going unmanaged, but maybe. Even so, why would I need a ton of them?
Well, for hobby purposes I terraformed a completely free cluster on OCI today. It's a "toy" of course, but k3s + OCI "Always free" tier includes Oracle Heatwave mysql which k3s can use in place of etcd. I'm deploying 2x (2 CPU / 12GB mem) VMs to run workloads. Also get an internal load balancer so nodes can find each other an external network load balancer for Traefik. It's quite usable.
Re: K3sup – bootstrap K3s over SSH in < 60s
#43I'm trying to understand why people are spinning up so many k8s clusters that they need a tool to do it for them? I have one. And it's managed. I don't think there's significant cost savings to going unmanaged, but maybe. Even so, why would I need a ton of them?
I was managing k8s cluster for a CDN, we had small clusters in each of our ~120 datacenters around the world, plus a number of larger clusters in our redundant back offices.
We couldn't use managed clusters because these were running on our own hardware, and they needed to run on the same infrastructure as the CDN itself.
The point of the local clusters was for workloads that needed to run in each data center, and then multiple clusters in the back office for both compliance and operational reasons.
I would not have used a tool like this, though. We used Rancher to manage our clusters.
Re: K3sup – bootstrap K3s over SSH in < 60s
#44Earlier quoted context omitted.
We do, let me check with my team and post it here. There were many issues. On top of my mind was, after a DR drill where in a VM was booted, node did not join the cluster. Apart from that bunch of issues due to etcd, longhorn. Another major one was the CNI stopped work for a particular node. Garbage collection for images was another, we labelled the images, it would still remove then from the node. Bunch of these kin…
I've found a lot of issues come through somewhat naive networking setup - which is encouraged by the "just yolo it" installation instruction in the documentation. If you want to start understanding what's going on you'll end up in very weird corners very quickly. Also, if you don't want the API endpoints available to the world the documentation is not much help. I've found things more stable if you can give a dedicat…
Thats might be true.
In enterprise setup when you are dpeloying on customer, airgapped, no access to internet and repositories, you generally dont have control over the infrastructure. It can be as hostile as you can think of.
Re: K3sup – bootstrap K3s over SSH in < 60s
#45I'm trying to understand why people are spinning up so many k8s clusters that they need a tool to do it for them? I have one. And it's managed. I don't think there's significant cost savings to going unmanaged, but maybe. Even so, why would I need a ton of them?
> And it's managed. Can’t use cloud stuff on-prem and also if your clients have a server room of their own. Same for homelab. Also it’s nice not to shift the pets attitude from servers to clusters and instead treat everything as cattle - provided you have backups of persistent data and the config versioned in a Git repo and there’s maybe some Ansible in the mix, being able to recreate an environment in the case of a…
Glad to hear you prefer Docker Swarm/Compose, I feel it’s a solid tool for when you need some of the more complex multi server deployments, and helps you avoid all the costs and complexities around K8s. Plus, running docker compose in development and docker swarm in production feels like the closest you can get to having your development environment match your production environment.
Re: K3sup – bootstrap K3s over SSH in < 60s
#46You can pretty install it without ssh under 60s. The fun starts after it has been installed. We have been running into lot of issues at production with k3s. There I embarked on journey to writing a kubernetes compliant and equivalent platform in rust with the help of claude [1]. It is a fun little project for now, still figuring out stuff, idea is to keep it minimal and single binary every embedded including CNI, and…
Very interesting! Architecturally - where do you run Postgres ? I assume it would be external to the cluster ? (doing it internally would create a circular dependency ?)
The dual clusters which run each others' control plane is also a perennial classic.
Re: K3sup – bootstrap K3s over SSH in < 60s
#47I do think the Talos model has kinda superseded this when it comes to repeatable deployment tbh
My primary use case for K3s is small machines, cheap VPS, Pi, etc. Would love to hear from folks who have had success with Talos in those spaces but last time I gave it a shot the welded shut hood prevented me from doing the little tweaks necessary to get running in those environments. In the cloud or on prem I suspect folks are having better luck than I did, but also open to being wrong about this.
>prevented me from doing the little tweaks necessary to get running in those environments.
It's a bit of a mindshift change but essentially whenever you feel the urge to make such a tweak...you've strayed off the golden path & are attempt to do something the wrong way (in Talos world).
I came from k3s so was very used to the whole tweaks spiel too.
Where you do need a custom config pipe in patch commands, not modify the OS. i.e. any and all changes you're feeding in via API so that can be repeatably scripted. The Talos OS is immutable.
It's similar how you'd control a k8s cluster with kubectl...except you're doing that model at OS level. You control it by sending API commands no modifying settings in files. So you don't "tweak" anything. It's a bit of mindset shift I know
Re: K3sup – bootstrap K3s over SSH in < 60s
#48This is a scam. Bootstrapping k3s is extremely easy. This tool lies to you giving you the impression that it's difficult or that you need a script, and tries to sell you monthly pro subscription, the features of which are also completely trivial.
Youtube slop culture. Not even AI. Just nonsense.
Re: K3sup – bootstrap K3s over SSH in < 60s
#49I'm trying to understand why people are spinning up so many k8s clusters that they need a tool to do it for them? I have one. And it's managed. I don't think there's significant cost savings to going unmanaged, but maybe. Even so, why would I need a ton of them?
Well, for hobby purposes I terraformed a completely free cluster on OCI today. It's a "toy" of course, but k3s + OCI "Always free" tier includes Oracle Heatwave mysql which k3s can use in place of etcd. I'm deploying 2x (2 CPU / 12GB mem) VMs to run workloads. Also get an internal load balancer so nodes can find each other an external network load balancer for Traefik. It's quite usable.
Huh... 2x(2CPU/12GB) for free is pretty good!! I'm paying $40/mo for 2vCPU & 4GB 1-node cluster on DigitalOcean.
I might have to look more into that... not very keen on Oracle though.
Re: K3sup – bootstrap K3s over SSH in < 60s
#50I'm trying to understand why people are spinning up so many k8s clusters that they need a tool to do it for them? I have one. And it's managed. I don't think there's significant cost savings to going unmanaged, but maybe. Even so, why would I need a ton of them?
I implemented a system that included the OP functionality (plus a whole lot more.) It was for on-premise deployment at customers. It can also be used to spin up stand-alone instances of our system in the cloud, for development, testing, etc. While you could, in theory, do many deployments on a single k8s cluster, there are some benefits to the automatic isolation you get from deploying on a standalone VM.
I'm doing many deployments in my single k8s cluster. I just put them each in a different namespace.
The only piece that's maybe a little dicey is the single load balancer/gateway. If there's a hiccup in that, then everything goes down.
But I've only blown up my cluster once in like 8 years or something, that's not too bad. It was a learning experience :-)
What other kinds of isolation do you want? I can see maybe a separate staging environment if you want to test gnarly things like that ahead of rolling them out to prod. And I guess maybe they can eat eachother's resources if you don't have request limits nor auto-scaling enabled.
But I'm cheap and managing more clusters sounds like a pain. Then I'd have to deal with more kubectl credentials and what not too.