https://github.com/clastix/kamaji-etcd

Multi-tenant etcd datastore for Kamaji
https://github.com/clastix/kamaji-etcd

Last synced: about 2 months ago
JSON representation

Multi-tenant etcd datastore for Kamaji

• Host: GitHub
• URL: https://github.com/clastix/kamaji-etcd
• Owner: clastix
• Created: 2022-08-06T19:25:36.000Z (over 2 years ago)
• Default Branch: master
• Last Pushed: 2024-08-25T14:37:16.000Z (4 months ago)
• Last Synced: 2024-08-25T15:46:12.938Z (4 months ago)
• Language: Shell
• Homepage:
• Size: 117 KB
• Stars: 14
• Watchers: 3
• Forks: 15
• Open Issues: 3
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# Kamaji etcd

A set of tools to deploy and operate a multi-tenant `etcd` datastore for [Kamaji](https://github.com/clastix/kamaji) control-plane.

## Background

Kamaji turns any Kubernetes cluster into a Management Cluster to orchestrate other Kubernetes clusters called Tenant Clusters. The Control Plane of a tenant cluster is made of regular pods running in a namespace of the Management Cluster instead of a dedicated set of Virtual Machines. This solution makes running control planes at scale cheaper and easier to deploy and operate.

As of any Kubernetes cluster, a Tenant Cluster needs a datastore where to save the state and be able to retrieve data. Kamaji provides multiple options: a multi-tenant `etcd` as well as _MySQL_, and _PostgreSQL_, thanks to the [kine](https://github.com/k3s-io/kine) integration.

A multi-tenant deployment for `etcd` is not common practice. However, `etcd` provides simple and robust APIs for creating users and setting up role based access control (RBAC) policies to define which user have access to what key prefix. However, in Kamaji, you can use multiple `kamaji-etcd` for different tenants. The relationship between tenant clusters and datastore can be many-to-one, one-to-one, depending on the preferencess and use cases. 

## Documentation

Refer to the [etcd documentation](https://etcd.io/docs/v3.5/op-guide). Following sections provide additional procedures to help with a specific setup as it is used into project [Kamaji](https://github.com/clastix/kamaji).

- [Monitoring](docs/monitoring.md)

- [Taking Snapshots](docs/snapshot.md)

- [Recover from Snapshot](docs/snapshot-recovery.md)

- [Velero](docs/velero.md)

- [Rotate Certificates](docs/rotate-certificates.md)

- [Defragmenting Data](docs/defragmentation.md)

- [Performance and Optimization](docs/performance-and-optimization.md)

## Roadmap

- [x] Install High Available `etcd` cluster as StatefulSet

- [x] Provide data persistence through Persistent Volumes

- [x] Multi-tenancy

- [x] Autocompaction

- [x] Scheduled defragmentation

- [x] Auto generate certificates

- [x] Scheduled snapshots

- [x] Metrics Service Monitors

- [x] Alert rules

- [x] Grafana dashboard

- [ ] Benchmarking

## Getting started

To install the multi-tenant `kamaji-etcd` on the Kamaji Management Cluster using the provided Helm Chart, run the following commands:

```bash

helm repo add clastix https://clastix.github.io/charts

helm repo update

helm install kamaji-etcd clastix/kamaji-etcd -n kamaji-etcd --create-namespace

```

The `etcd` certificates are stored as secrets into the same namespace:

- `-certs` contains CA, peers, and server certificates

- `-root-client-certs` contains the user `root` certificates

Ensure the Kamaji controller has access to these secrets.