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.
I went RKE2, k3s is nice, but a little too minimal for my tastes. With a few hundred MB ram used, I've got an internal container registry, openbao for secrets, caddy for edge TLS, rabbitmq, and powerdns for exposing k8s ingress. Plus all the standard network policies, which while verbose, gets me nearly all the way there of traditional firewalls and networking.
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 fuckup is nice and also helps against bit rot.
Disclaimer: I actually prefer Docker Swarm/Compose over K8s due to simplicity (which matches my deployments and scale), but in the cases where I had to use a variety of K8s, going for K3s was pretty okay.
The cluster isn't that hard to recreate if things go south. Everything is in YAML configs already. And since I'm managed, it's just a few clicks in DigitalOcean to create a new cluster. And actually, I think I can create clusters through their CLI too, so if I did want to automate it, it's already ready to go. So I'd say I'm cattle-ready, but too cheap to pay for more cattle.
I nearly went Docker Compose/Swarm by accident when I was just getting started. I knew I wanted to dockerize my app but then couldn't figure out how to get it into prod. Then I found out people don't actually use Docker Compose for prod it seems and eventually stumbled into Kubernetes. It took a few weeks to wrap my head around, but I'm happy with it now.
Once you have a nice set up, I'd say it's pretty simple to maintain. DevSpace is fantastic for development, and then for deployment I just wrote a little script which builds my images, updates the kustomize with new images and applies the manifests. Pretty simple.
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.
> 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.
I run Minikube in Podman for dev. And then I use kustomize to customize dev, staging and prod environments. The environments are 99% the same, they just have different env vars and memory limits.
If you peel off all the layers in Docker Swarm and K8s, technically it has the same level of complexity. In k8s there are a lot of concepts. I would argue you have the same network, storage, and compute complexities as an operator.
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.
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.
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.
It's applied big brain memetics. k8s turned pet servers into cattle. People then do the next step and want to treat their clusters as cattle as well. Also it has a bit of the "can it run DOOM" vibe to treat whole k8s clusters like this.
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
> you've strayed off the golden path & are attempt to do something the wrong way (in Talos world).
In this case the urge to make a tweak is synonymous with the urge to make the product _function_.
I admire their dedication to the schtick, but the upshot is that since you cannot reach inside to make Talos actually work in environments that aren't supported by that golden path, running the product on many devices is "Talos Wrong".
That's their perrogotive, but it's obnoxious in a "Windows 11 doesn't work on your perfectly functional laptop" kinda way.
I'm early on in my Kubernetes journey and have opted to focus on Talos. Would you be able to share a bit more about the issues and limitations you encountered?
It's basically a k8s operating system of sorts. One that basically boots up as a k8s node and that's all it does. You can't log in to it or interact with it other than as a k8s node. That reduces complexity, attack surface and makes things very repeatable
I used this for a bit a few years ago but eventually needed something that was hard or impossible in k3sup and just went to using the k3s tools directly. My deployment script actually got simpler after removing k3sup.
Also, fun fact, k3sup is pronounced "ketchup" according to the README[0]
I was reading the description trying to figure out what it actually does. I built remote k3s deployment over ssh into a product I worked on, and there really was very little to it. Shell into the machine, run the installer, set the config - and that last part is going to be unique to your situation anyway. It makes perfect sense that your setup got simpler after removing this.
What's the point? You can bootstrap k3s with "curl -sfL https://get.k3s.io | sh -". If you need to do that over ssh it works just fine. If you're doing it on multiple hosts, you should be using Ansible.
I can bootstrap an entire RKE2 VM (VM + RKE2 + join cluster) in like 5 mins with Salt (although I have no reason to think you couldn't do it with Ansible).
It's a cool project, but I didn't think the K3s part was the hard part.
You 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 support various runtimes like docker, containerd etc but also wasm, vms and also jvm.
Architecturally - where do you run Postgres ? I assume it would be external to the cluster ? (doing it internally would create a circular dependency ?)
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 kind of issues when our requirement is fairly straightforward. Therefore we are working towards a strip down version.
There is lot of operation complexity in general and most of us can do without.
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 dedicated interface just for internal k3s communication. It can be a bridge interface on top of a vlan interface - but not the vlan interface itself, or some things will break in very interesting ways. Also, even when using IPv6, just stick with internal IPs and nat everything - touching internal IP ranges is no fun. Plus, if there's a chance you'd ever want to use dual stack, set it up with internal v6 addresses, and just don't use the v6 addresses for now. There's also a lot of unintuitive behaviour around dual stack networking - and lots of areas where documentation is just plain wrong.
I'm scripting our stuff with ansible - one of the more useful things was the realisation that in some areas changes which shouldn't break anything can lead to cluster communication being interrupted, which is a very interesting thing to deal with, especially when you can't pin it to that change that didn't touch anything close to that, and therefore should not be responsible. I've learned, and sprinkled checks to make sure all members can still reach each other in there now, so that at least when I break it on changes I directly know why.
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.
Meanwhile our architecture team that surely supported 0 real life k8s went with no vendor, on premises deployments, claiming it was as easy as booting a VM, after 2y, there is 2 apps running and supposedly all future apps will be deployed on that cluster.
I cannot wait for the end of this month to leave that place.
You have to be careful trying to do this kind of thing. The problems you describe having below are problems with peripheral components, not k3s itself. The runtime handles garbage collection and image pinning. Your embedded runtime is using libcontainer, the same thing containerd uses, so the behavior should be identical. Since you support other runtimes, how they handle image pinning, if they support it at all, will vary. Whether or not you embed the CNI plugins and networking controllers, you're seemingly still using CNI since that's how container runtimes attach containers to a network, so whatever problems you had with CNI before would still happen. The DR VM not wanting to join sounds like it was probably due to etcd storing node IPs in the cluster member metadata. If you transfer that to a new host and it doesn't have the same IP, you need to first correct that metadata out of band, which no Kubernetes distro I'm aware of handles automatically but it's a simple etcdctl one-liner. You also need to make sure the client certificate you're using to authenticate with etcd is reissued with the new host IP in its IP SANs, which k3s does do automatically. If you're not using etcd, well, good in a way because it has a lot of cruft and I'm not a fan, but that will be difficult to support because the entire Kubernetes API and many third-party controllers are all designed around how etcd works. k3s doesn't actually require etcd and can use any SQL-based RDBMS thanks to its kine compatibility shim.
With all respect, "building it because I want to" and "working toward making (it) production grade" doesn't inspire a ton of confidence. k3s has been part of the CNCF for many years and its developer Darren Shepherd was the founding CTO for both cloud.com and Rancher Labs, which were acquired by Citrix and SUSE. It looks like you're running your own B2B company and hoping to swap out k3s as the underlying engine for multitenancy. That's very risky. Surely Claude can help you understand and use k3s just as readily as help you write a replacement, and I'm sure SUSE sells professional services. I have no clue what they charge but typically you're talking like $300 an hour and you'd probably only need 40 hours.
Sure, with full disclosure, I don't expect anyone to run in production until I have. Absolutely understand your trust deficit. Just to give you some context, we run our infrastructure in regulated industries like banking, fintech, and public companies.
Once I have embarked on the journey building this from scratch, there are new innovative ideas I can implement not bound to any foundation or org.
Ps. We do not sell it as product it is 100% free and open-source with MIT license.
used to use this but have opted to do good ol' hand-rolled deployment scripts instead you will run into some niche usecase that k3sup can't express and end up having to do a post script anyway.
the best part of k8s is network, most of agentic systems presume no network , since it's a security concern, what are scenarios when you'd like to spin up k3sup?
I use official ‘ansible-playbook k3s.orchestration.site -i inventory.yml’ and it installs k3s over SSH and adds it into my kubectl context, all under 60s too.
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.
Youtube slop culture. Not even AI. Just nonsense.
I went RKE2, k3s is nice, but a little too minimal for my tastes. With a few hundred MB ram used, I've got an internal container registry, openbao for secrets, caddy for edge TLS, rabbitmq, and powerdns for exposing k8s ingress. Plus all the standard network policies, which while verbose, gets me nearly all the way there of traditional firewalls and networking.
I'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 fuckup is nice and also helps against bit rot.
Disclaimer: I actually prefer Docker Swarm/Compose over K8s due to simplicity (which matches my deployments and scale), but in the cases where I had to use a variety of K8s, going for K3s was pretty okay.
> treat everything as cattle
The cluster isn't that hard to recreate if things go south. Everything is in YAML configs already. And since I'm managed, it's just a few clicks in DigitalOcean to create a new cluster. And actually, I think I can create clusters through their CLI too, so if I did want to automate it, it's already ready to go. So I'd say I'm cattle-ready, but too cheap to pay for more cattle.
I nearly went Docker Compose/Swarm by accident when I was just getting started. I knew I wanted to dockerize my app but then couldn't figure out how to get it into prod. Then I found out people don't actually use Docker Compose for prod it seems and eventually stumbled into Kubernetes. It took a few weeks to wrap my head around, but I'm happy with it now.
Once you have a nice set up, I'd say it's pretty simple to maintain. DevSpace is fantastic for development, and then for deployment I just wrote a little script which builds my images, updates the kustomize with new images and applies the manifests. Pretty simple.
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.
> 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.
I run Minikube in Podman for dev. And then I use kustomize to customize dev, staging and prod environments. The environments are 99% the same, they just have different env vars and memory limits.
If you peel off all the layers in Docker Swarm and K8s, technically it has the same level of complexity. In k8s there are a lot of concepts. I would argue you have the same network, storage, and compute complexities as an operator.
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.
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.
You're cool if you manage your own K8S cluster.
Because they are selling a “pro” version as part of their commercial product SlicerVM. It has more features for operating a k3s cluster.
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.
It's applied big brain memetics. k8s turned pet servers into cattle. People then do the next step and want to treat their clusters as cattle as well. Also it has a bit of the "can it run DOOM" vibe to treat whole k8s clusters like this.
I 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
> you've strayed off the golden path & are attempt to do something the wrong way (in Talos world).
In this case the urge to make a tweak is synonymous with the urge to make the product _function_.
I admire their dedication to the schtick, but the upshot is that since you cannot reach inside to make Talos actually work in environments that aren't supported by that golden path, running the product on many devices is "Talos Wrong".
That's their perrogotive, but it's obnoxious in a "Windows 11 doesn't work on your perfectly functional laptop" kinda way.
I'm early on in my Kubernetes journey and have opted to focus on Talos. Would you be able to share a bit more about the issues and limitations you encountered?
SRE here who has dealt with both. Talos is operating system and Kubernetes management system without a ton of batteries included.
K3s runs on existing operating systems with batteries included.
What is the talos model?
It's basically a k8s operating system of sorts. One that basically boots up as a k8s node and that's all it does. You can't log in to it or interact with it other than as a k8s node. That reduces complexity, attack surface and makes things very repeatable
I used this for a bit a few years ago but eventually needed something that was hard or impossible in k3sup and just went to using the k3s tools directly. My deployment script actually got simpler after removing k3sup.
Also, fun fact, k3sup is pronounced "ketchup" according to the README[0]
[0]: https://github.com/alexellis/k3sup/blob/master/README.md
The pronunciation ketchup is somewhat unfortunate as a popular backup operator for k8s, k8up, also claims this.
I was reading the description trying to figure out what it actually does. I built remote k3s deployment over ssh into a product I worked on, and there really was very little to it. Shell into the machine, run the installer, set the config - and that last part is going to be unique to your situation anyway. It makes perfect sense that your setup got simpler after removing this.
What's the point? You can bootstrap k3s with "curl -sfL https://get.k3s.io | sh -". If you need to do that over ssh it works just fine. If you're doing it on multiple hosts, you should be using Ansible.
I can bootstrap an entire RKE2 VM (VM + RKE2 + join cluster) in like 5 mins with Salt (although I have no reason to think you couldn't do it with Ansible).
It's a cool project, but I didn't think the K3s part was the hard part.
K3s is so easy to install, that k3sup feels like an increase in complexity. Feels like an abstraction that provides negative value.
You 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 support various runtimes like docker, containerd etc but also wasm, vms and also jvm.
[1] https://github.com/debarshibasak/superkube
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.
Yes, it is external to the cluster.
If you want to do a quick setup, it creates a SQLite DB for the metadata.
Do you have a writeup what problems you ran into?
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 kind of issues when our requirement is fairly straightforward. Therefore we are working towards a strip down version.
There is lot of operation complexity in general and most of us can do without.
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 dedicated interface just for internal k3s communication. It can be a bridge interface on top of a vlan interface - but not the vlan interface itself, or some things will break in very interesting ways. Also, even when using IPv6, just stick with internal IPs and nat everything - touching internal IP ranges is no fun. Plus, if there's a chance you'd ever want to use dual stack, set it up with internal v6 addresses, and just don't use the v6 addresses for now. There's also a lot of unintuitive behaviour around dual stack networking - and lots of areas where documentation is just plain wrong.
I'm scripting our stuff with ansible - one of the more useful things was the realisation that in some areas changes which shouldn't break anything can lead to cluster communication being interrupted, which is a very interesting thing to deal with, especially when you can't pin it to that change that didn't touch anything close to that, and therefore should not be responsible. I've learned, and sprinkled checks to make sure all members can still reach each other in there now, so that at least when I break it on changes I directly know why.
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.
Meanwhile our architecture team that surely supported 0 real life k8s went with no vendor, on premises deployments, claiming it was as easy as booting a VM, after 2y, there is 2 apps running and supposedly all future apps will be deployed on that cluster.
I cannot wait for the end of this month to leave that place.
Anything real world tech is hard.
We are hiring, btw.
You have to be careful trying to do this kind of thing. The problems you describe having below are problems with peripheral components, not k3s itself. The runtime handles garbage collection and image pinning. Your embedded runtime is using libcontainer, the same thing containerd uses, so the behavior should be identical. Since you support other runtimes, how they handle image pinning, if they support it at all, will vary. Whether or not you embed the CNI plugins and networking controllers, you're seemingly still using CNI since that's how container runtimes attach containers to a network, so whatever problems you had with CNI before would still happen. The DR VM not wanting to join sounds like it was probably due to etcd storing node IPs in the cluster member metadata. If you transfer that to a new host and it doesn't have the same IP, you need to first correct that metadata out of band, which no Kubernetes distro I'm aware of handles automatically but it's a simple etcdctl one-liner. You also need to make sure the client certificate you're using to authenticate with etcd is reissued with the new host IP in its IP SANs, which k3s does do automatically. If you're not using etcd, well, good in a way because it has a lot of cruft and I'm not a fan, but that will be difficult to support because the entire Kubernetes API and many third-party controllers are all designed around how etcd works. k3s doesn't actually require etcd and can use any SQL-based RDBMS thanks to its kine compatibility shim.
With all respect, "building it because I want to" and "working toward making (it) production grade" doesn't inspire a ton of confidence. k3s has been part of the CNCF for many years and its developer Darren Shepherd was the founding CTO for both cloud.com and Rancher Labs, which were acquired by Citrix and SUSE. It looks like you're running your own B2B company and hoping to swap out k3s as the underlying engine for multitenancy. That's very risky. Surely Claude can help you understand and use k3s just as readily as help you write a replacement, and I'm sure SUSE sells professional services. I have no clue what they charge but typically you're talking like $300 an hour and you'd probably only need 40 hours.
Sure, with full disclosure, I don't expect anyone to run in production until I have. Absolutely understand your trust deficit. Just to give you some context, we run our infrastructure in regulated industries like banking, fintech, and public companies.
Once I have embarked on the journey building this from scratch, there are new innovative ideas I can implement not bound to any foundation or org.
Ps. We do not sell it as product it is 100% free and open-source with MIT license.
used to use this but have opted to do good ol' hand-rolled deployment scripts instead you will run into some niche usecase that k3sup can't express and end up having to do a post script anyway.
the best part of k8s is network, most of agentic systems presume no network , since it's a security concern, what are scenarios when you'd like to spin up k3sup?
Talos is all you need.
I use official ‘ansible-playbook k3s.orchestration.site -i inventory.yml’ and it installs k3s over SSH and adds it into my kubectl context, all under 60s too.
Why not just curl to bash with the official instructions?
I have just been `ssh ... -- k3s.sh ...`, been meaning to ansible my homelab
[flagged]