Overview
Table of Contents
📖 Overview
HariKube is an advanced Kubernetes-native platform that enhances how microservices and custom resources are managed by distributing data across multiple databases. It addresses ETCD’s limitations by introducing a powerful multi-layer and vendor database topology. Bringing a cloud-native development experience and turning Kubernetes into a true PaaS.
❓ What is HariKube?
HariKube is a system that simplifies data location management in Kubernetes by offloading microservice data from ETCD into databases like MySQL and PostgreSQL, which are optimized for handling large-scale, high-throughput data workloads. It uses a middleware to handle routing and storage logic, improving scalability, performance, and reliability.
🌐 Benefits of HariKube Architecture
⚠️ Limitations
While HariKube improves over single-ETCD setups, it inherits some Kubernetes design tradeoffs.
| Limitation | Description |
|---|---|
| Eventual Consistency | Updates may not be immediately visible across the system |
| Non-Transactional | No support for ACID transactions |
| Relational Logic | Complex joins or relations between data entities are not supported |
| Limited Data Filtering | No advanced query engine included within Kubernetes |
💡 Don’t worry, the Kubernetes API aggregation layer can help overcome the limitations of the core API server by allowing you to extend the API with custom APIs that are served by a separate backend, or extension API server. This setup enables you to implement specific logic and capabilities that aren’t available in the core API.
🛢️ Supported Databases
HariKube supports multiple backends, each with different capabilities regarding data access and filtering. The table below outlines which storage engines are compatible and whether they support storage-level filtering for efficient querying.
| Database | Storage-Level Filtering | Data isolation | Decreased latency | Increased throughput | Large Dataset Support | Auto GC |
|---|---|---|---|---|---|---|
| ETCD | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ |
| NATS | ❌ | ✅ | ✅ | ✅ | ✅ | ❌ |
| MySQL | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| MariaDB | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| TiDB | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| PostgreSQL | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| CockRoachDB | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| YugabyteDB | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| SQLite | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ |
ℹ️ Storage-level filtering means the database can apply selectors (
label,field) before returning data—reducing memory usage and improving performance at scale.
💼 Common Use Cases
- Multi-tenant Kubernetes platforms
- Per-namespace database isolation
- Regional workload distribution
- Offloading CRDs to scalable and high capacity databases
- Simplifying stateless microservice infrastructure
🧠 How HariKube Works
Here’s a clear bullet-point breakdown of the HariKube Overview diagram:
- User initiates a CRUD operation on a Kubernetes resource (e.g., a Custom Resource).
- The request is passed to Kubernetes API server, which forwards it through the midleware.
- HariKube intercepts the request and determines where the data should be stored based on configured routing policies.
- If a routing policy is found, the request is forwarded to the corresponding database (e.g., MySQL).
- If no routing policy is defined, the request falls back to ETCD (the default Kubernetes data store).
- The selected backend (MySQL or ETCD) processes the CRUD request.
- Once the backend responds, the response is passed back through the chain, returning an
to the user.