Integration options with HariKube

[mhmxs]

Hi,

I'm working on an open-core horizontally scalable kubernetes control plane called harikube. I don't want to go into details here, you can find more details here.

Two main advantages:

• hardware limited cluster size
• built-in CNCF PaaS (API, data stream, RBAC, OpenAPI schemas, Audit, validation, migration, versioning, ...)

Currently we support helm+vcluster (to scale number of workloads), and standalone mode (to scale everything).

My question is, does it make sense to integrate harikube and kamaji, to spin up a petabyte-scale, versioned state-machine with kubernetes interface?

I don't want to waste your time with details, until you are interested in, but here is a small benchmark (as part of an open challenge) comparing harikube with vanilla Kubernetes:

Metric	HariKube	Vanilla K8s
Throughput	28 req/s ✅	25 req/s ❌
Success Rate	100% ✅	100% (OOM) ❌
Latency average	708ms ✅	799ms ❌
Latency p95	2480ms ✅	2820ms ❌
Latency p90	1990ms ✅	2470ms ❌
Test Duration	60m ✅	~34m (OOM) ❌
Stability	Completed ✅	KILLED ❌
Objects Handled	50k ✅	~26k (OOM) ❌

As you see, with one single database we weren't able to increase the performance much, but because harikube uses a stateless control plane, no watch-cache, and uses O(1) memory instead of O(n), the stability was uncomparable.

Vanilla Kubernetes has been OOM killed at the half-time.

---

We have a (currently) closed source edition with resource based sharding, and the numbers are totally different with 6 databases:

Metric	HariKube 6 DBs	Vanilla K8s	Gain
Throughput	119 req/s ✅	25 req/s ❌	4.8x
Success Rate	100% ✅	100% (then OOM) ❌	not comparable
Latency average	167ms ✅	799ms ❌	4.8x
Latency p95	543ms ✅	2820ms ❌	5.2x
Latency p90	398ms ✅	2470ms ❌	6.2x
Test Duration	60m ✅	~34m (OOM) ❌	not comparable
Stability	Completed ✅	KILLED ❌	not comparable
Objects Handled	200k+ ✅	~26k (crashed) ❌	4x

Anyway this was the flexing, my vision is openshift manages large application states, on large clusters backed by petabyte-scale harikube. It is cheaper to run multiple databases than multiple clusters.

The future of software development, because this should be the next shift.

• monolit service / monolit state
• micro service / data silo
  to
• CNCF service / monolit data

This combines the advantages of both worlds. My entire app is a versioned state, and bots (functions, operators, aggregation apis, legacy microservices, AI workloads) who speak http and openapi, can give the state life.