A team has an application and needs a way to run it. That ought to be ordinary. I'm building Kube.ist because getting there keeps involving the assembly of a small software industry. Kubernetes gives me a way to describe workloads and keep them running. Around that I still need to decide how traffic arrives, how certificates are issued, where images live, how someone finds out that the application is unhappy and how another person gets the permissions to help. Each decision brings another project to install and understand. Another manual, another set of values to choose....
I enjoy figuring out how those pieces fit together, watching the traffic arrive, getting the certificates issued, but doing the same assembly for another application is getting less interesting. I'd like to spend that time on the application.
Kube.ist bundles those pieces, tools to install them, and a console for the things a team does regularly. I started it in 2019. Installation is the beginning. Can the team use what I've installed?
Here's the difference I mean:
| A team wants to… | The platform needs to arrange… |
|---|---|
| Put an application on the internet | Routing, a hostname and a certificate |
| Deploy a new version | An image source and a repeatable update path |
| Find a problem | Useful logs, measurements and access to them |
| Let another person help | An identity and appropriate permissions |
The defaults give us a setup we can use and change, without assembling this collection afresh for each application. Getting all the processes to start is satisfying, but then somebody needs to use them. Where are the logs? How do they deploy another version? That's work for the console and API too.
A cluster the team can own
Kube.ist integrates vcluster, which creates small virtual Kubernetes clusters inside a larger host cluster. Each has a separate Kubernetes API and control plane, while its workloads run on the host and share the underlying computing resources.
A company could run one large cluster and give each department or team a virtual cluster, which the team can administer, choosing the tools it runs there. Host-cluster policies still govern the shared resources, and looking after the physical machines remains a shared job. Separate control planes, shared machines.
This takes giving developers the keys further. Owning a deployment means more when the team can also manage the place it runs. I find that more appealing than needing somebody else's permission for every useful change.
We intend Kube.ist to work as a cloud service or with a company's on-premises setup. Rook could supply storage there by managing Ceph on Kubernetes. Kubernetes schedules workloads across the machines. Virtual clusters then carve out a separate environment for each team.
The agents inside clusters are in Go, keeping the programs light enough to fit into the cluster they're helping manage. Go also suits the microservices doing heavier work. Goroutines let me split independent jobs up, and the runtime can schedule them across available cores.
Those goroutines share operating-system threads, with much less overhead than creating an operating-system thread for every independent job, so I can organise many pieces of work without managing a thread for each one. That's what I need.
I came to this wanting to build a platform.
A new language has joined the itinerary anyway.
Keep the tools within reach
The console brings the tools' interfaces together. We use iframes and simple rewrite rules in the proxy, which injects the basic CSS needed to fit an application's interface into our layout. The application still supplies its screens and controls.
That lets me move between Argo CD, Argo Workflows, Tekton and observability tools within Kube.ist. We support a lot of applications this way.
Choose a team and cluster, and I can move from a deployment in Argo CD to its workflow and then the observability tools for that setup. Comparing the views is much easier when I can switch between them in the same place. Before that, finding the dashboard URL also meant checking I'd opened the right cluster. Which cluster? Am I looking at the deployment I came here for? Another dashboard URL to remember, another tab to check. That gets tiresome quickly.
We're building the API in Node.js for fast iteration. Familiar ground. That helps when the interface and its supporting API are changing together.
The ordinary route through the console is the one to get right first. Can someone choose their team and cluster, deploy the application and find its logs without me guiding them between tools? Adding another dashboard can wait until that works.