Send data filter to the storage, can be highly benefitial

[mhmxs]

Hi,

Kubernetes control plane doesn't scale well, you knew this, ETCD and stateful control-plane blocking us to grow cluster size and workloads.

I'm developing a kind fork, and this port is able to filter data storage-side.
We have a patched control plane bundled in vcluster. The patch is stupid simple, it sends filtering data to the storage.

currently, if you read the control plane patch ☝️ the solution is hard-coded into etcd driver, but my plan is to move this to a separated storage driver

I don't want to go into 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.

The question, does it make sense for you - even behind an alternative storage driver - to stepping forward discussing integration options?

---

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.

Show me the architecture