Features
Performance Infrastructure Flexibility Data Isolation Developer Experience
Docs
Overview Installation Custom Resource Automation Monitoring Future Plans
FAQ
Get Started

Automation

Table of Contents

There are multiple ways to update topology config on the go. You can store configurations in a file and update it’s content, or you can use a webserver as a source of the configurations. An other option is using Kubernetes secret as a source of truth. This documentation is focusing on using HariKube operator to merge multiple configuration sources into the final tree of topology configs.

🔧 Configure Kubernetes with HariKube

Start by installing HariKube and configuring its middleware in your Kubernetes cluster. This will enable the platform to route database requests to different databases, based on configuration.

For installation instruction, please follow the documentation.

For TOPOLOGY_CONFIG environment variable, please use secret://<namespace>/<name> format, and ensure the secret is empty during the initial cluster start.

🛢️ Setup Database Operators

HariKube works alongside existing database operators (e.g., MySQL, PostgreSQL) to provision and manage actual database instances. Install your favorite operators in your cluster for example:

Once installation has finished, create your database instances themselves. Please follow the operator’s manual, how to do it properly.

🔌 Deploy HariKube Operator

Next step is configuring and deploying HariKube Operator. The operator is a standard Kubernetes operator, so if you are familiar with operators, you are good to go.

🗂️ Create your first routing configuration

The operator provides a custom resource type for routing configurations called topologyconfigs.harikube.info. You can bundle TopologyConfig custom resource with your microservice manifests, the operator would fetch all the configs and merge them into a final config for the middleware. Each microservice can declare how its data should be partitioned, what database backend to use, and whether to reuse or isolate instances.

For simplicity this example contains plaintext database endpoint configuration. The operator supports AES-GCM encryption for endpoints. Store your decryption key in a secret, reference it’s namespaced name in spec.endpointDecryptSecret, and use Base64 encoded endpoint secret in the configuration.

topologyconfig-sample.yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

apiVersion: harikube.info/v1
kind: TopologyConfig
metadata:
  name: topologyconfig-sample
spec:
  targetSecret: <namespace>/<name>
  # endpointDecryptSecret: <namespace>/<name>
  position: 1
  backends:
  - name: namespace-sample
    endpoint: mysql://<user>:<password>@tcp(<ip>:<port>)/<namespace_database>
    namespace:
        namespace: <namespace>
  - name: custom-resource-sample
    endpoint: postgres://<user>:<password>@<ip>:<port>/<crd_database>
    customresource:
        group: <group>
        kind: <kind>

!!! Custom resource reconciliation, topology config validation and secret update takes some time. Please make sure the status.deployStatus of the custom resource is Active before you create any resource affected by the policy. Error reason is stored at status.deployStatusReason. Creating resources before the policy has been applied will lead to “data loss” (more specifically they would stuck in the main database, and the middleware never fetch them again).

By automating these steps, HariKube transforms Kubernetes into a true Platform-as-a-Service solution, because HariKube provides full control of data isolation and distributes database requests based on the customer’s needs.

[<– Custom Resource –> | Monitoring –>