Future of k0s, a CNCF project?

[jnummelin]

Hey all,

The team k0s is thinking of submitting k0s as a CNCF Sandbox project. We've not yet made the final go/no-go decision but in order to gather more "evidence" and prep for the potential application we're collecting list of users and adopters that we could utilise for the submission as "supporters".

So if you're a k0s user, which you probably are if you're reading this issue 😄 , please add some details as a reply. Would be awesome if you can share your contact info, some words how you use k0s and in which kind of use case you use it on. If you do not wish to share that kind of details in public you can also reach out to me via email jnummelin [at] mirantis.com. If nothing else, please at least show your support using emoji reactions on this. 😄

What would it mean to have k0s as a CNCF project? (i.e. what's in it for you)

IF k0s would get accepted as a CNCF project we'd be able to create even stronger foundation for the project and bolster both the adoption and community involvement. In the end that means better foundation for YOU to build upon.

[laghoule]

Using it for my home cluster, and evaluating it for OnPrem usage at work.

[ferama]

We started using it in production for very simple scenarios (single node clusters). We have also some multi node development environments and there I feel that I don't have the full control of what is happening on the control plane nodes (it's why I opened this one #3247 for example).

We love the idea of k0s and we also (almost) love k0sctl. I would like to use it for bigger clusters and maybe to go on and use it for bigger production scenarios. We are not there yet, I hope we are some day :)

I would love to read more about experiences on running k0s for bigger clusters, but I'm not able to find almost anything.
A bigger community could help for sure.

Thanks

[laghoule]

An official k0s terraform provisioner should definitively give a good boost to enterprise adoption.

[Starttoaster]

My home 3 node HA cluster runs k0s, deployed with k0sctl. We're also evaluating it for onprem use at my workplace. In the future of the k0s project, I would like to see documentation on running an HA API server load balancer. Currently, the documentation only shows how to set up a single HAProxy instance to load balance the API server.

[CmdrSharp]

We are trialling it as a replacement for clusters currently run via Google Anthos. It offers a similarly neat upgrade experience based on our testing so far. We are still in early testing, but like the concept and if all goes well, we'll do some production-grade trials this autumn.

[Skaronator]

I'm using k0s in my homelab as well. It works great, especially since it's pretty lightweight and doesn't include that many services out of the box (unlike k3s).

Also using it on prem at work. Works just as good. I love k0sctl and the k0sctl.yaml. Works really great for versioning in git. Another feature that k3s doesn't have.

---

I would love to have 2 things to improve:

• Faster release of major version. k3s is sometimes 3 or 4 weeks ahead: First 1.27 release of k3s was April 27 while k0s was on May 23.
• Better handling of changes within the k0sctl.yaml. e.g.
  • allow disabling or re-enabling of components (like metrics server)
  • allow changing role of hosts, sans or externalAddress
  • allow changing of network configuration
  • if a change is not possible with the currently active cluster, then just say that to the user. k0sctl should offer a way to migrate to the new configuration -> e.g. backup the current cluster, reset and run apply. All within the same operation.

[Rohmilchkaese]

We implemented it in Work as Production Cluster! Would definitely support

[jsalgado78]

+1

We've three production clusters running k0s

We implemented it in Work as Production Cluster! Would definitely support

[pschichtel]

I'm using it for my home lab and at work for both development and production clusters on prem. I'm using k0sctl exclusively for all deployments. In the last 3 weeks I introduced 2 additional teams to k0s.

You can find my contact details on my website (linked in my profile).

[djds]

I think this would be really a good move for the health of the project and also demonstrate a commitment to the community from Mirantis. As many high-profile open source projects have recently switched to a source available, non open source license, it would significantly disambiguate the future of any investments community members or organizations make to the project knowing that k0s would remain Apache 2.0. It's simply not viable for many businesses to invest in core infrastructure that might have the rug pulled out from under it at any point in the future, and foundation ownership of the project is a strong bulwark against that risk.

k0s is a great Kubernetes distribution: I run it on a 8 node cluster with 7 Raspberry Pi CM4s and an old Thinkpad to provide one node with x86_64 support, all running Fedora CoreOS as the host OS on my home lab. I work with many of the managed K8s distributions from the hyperscalers at my $dayjob, but k0s is really useful for testing Kubernetes workloads on prem and for hosting all of the cloud native applications that I have to deal with in a professional setting.

Thanks for all of the work that the team has put in! It's nice to be able to get up and running with a simple vanilla Kubernetes distribution with good security defaults.

[vyas-n]

I'm currently using k0s as a part of a Dev cluster at my company.

I'm having it soak for a period of time to prove stability before presenting it to my company as a potential platform for Production.

Having k0s be a CNCF Project will make us much more confident in its production grade use and be able to contribute upstream for bugs we find or docs we'd like for reference later.

[marccampbell]

We are building around the k0s project, and would love to see k0s become a CNCF project. Our use case at Replicated is to enable an embedded appliance experience as part of a distribution mechanism.

If the k0s project was a CNCF project, we'd be able to have more confidence that the license will continue to allow our use case, and being able to participate in the open governance of the project.

[alexdub37]

Hi !
I use k0s on-prem on multiple clusters.
I really like the simplicity. I also operate Openshift and Rancher clusters (as a sysadmin).
They are bloated, and that's where k0s shines.
It follows the unix philosophy of doing one thing, and doing it right.

k0s is a little bit of an outsider but has nothing less powerful than giant names.
Yes, it is vanilla. That's why I prefer it to OCP/Rancher.
No unlimited built-in feature list. Just Kubernetes well-packaged in a bin file.

Then, do what you want with it. Rook, Tekton, ArgoCD, OPA Gatekeeper, ...
Everything is one Helm chart away.

[sombriks]

so far k0s looks simple as kind or k3s, still trying to figure out how they compare to each other.

i need to test things before apply them on eks, therefore k0s looks the tool for the job.

[ams0]

Been using it for a while at home and now on Hetzner bare metal, I recommend it to everyone I speak to. Not huge marketing machine behind, which is a plus. I'm a CNCF Ambassador and I'd love to sponsor/promote the incubation efforts.

[djds]

One of the best parts is that you can use whatever CNI you want (although it's nice to include both Kuberouter and Calico as default options). By setting networkProvider: custom, I was able to get a full Cilium setup working, which I use for my homelab but also to help clients debug networking issues by having a quick environment to stand up. Other small Kubernetes distributions use non-default command-line flags or otherwise implement some DSL that means testing out vanilla Kubernetes features is not as easy.