rio

I've been playing around with k3s myself on Azure: https://github.com/rcarmo/azure-k3s-cluster ...as well on my own ARM cluster, with a private registry: https://taoofmac.com/space/blog/2019/05/18/2034 I find it refreshingly straightforward for personal and testing setups (and more practical than microk8s for me right now), and am waiting for rio to hit a couple of stable milestones: https://github.com/rancher/rio (I try openFaaS now and then, but after contributing a deployment template early in the beginning, I lost my enthusiasm for it - it also ran the gateway and the admin UI on the same process, which I considered a design flaw).

k3s is not intended to be a competitor, but let's say I wanted to build it out to compete with systems. Swarm excels in UX and cluster management. It is easy to run and use. But it is incomplete in features and functionality. So k3s addresses the cluster management issues and has tons of features. It makes k8s easy to run, but it still has Kubernetes UX which is quite difficult. So in the end I think it is a wash between k3s and Swarm. You either get hard to use (k3s) or incomplete (Swarm). I have a different project Rio (https://github.com/rancher/rio) that attempts to address UX (and it's built on k3s). So Rio could possibly be a system that is easy to use, powerful, and simple to run. I think Rio could be something that is better than both raw k8s and Swarm for regular users, but it's a very early.

I created this (I'm the Chief Architect and Co-founder of Rancher Labs, I experiment with stuff like this all the time). The purpose of this project is really to embed in another project (https://github.com/rancher/rio is an example) but as a side effect it's a nice little standalone k8s package. I never had any intention to support it as a standalone project, but hey if somebody is interested who knows. All of the features removed are based off of two basic ideas 1) If there are X ways to do something, I choose the best one (obviously subjective). 2) The features are not commonly used or really shouldn't be in k8s to begin with. The end goal of what I'm working on is basically to use k8s code as a library to do orchestration. Step one was to reduce the footprint of k8s (I'm 80% there with this project), step two is to completely rework