kubecon24/content/day1/10_lessons_learned_from_building_a_db_operator.md

34 lines
958 B
Markdown
Raw Normal View History

2024-03-19 15:16:41 +00:00
---
2024-03-19 15:53:59 +00:00
title: Lessons Learned from Building a Database Operator
2024-03-19 15:16:41 +00:00
weight: 10
2024-03-25 12:45:10 +00:00
tags:
- platform
- db
2024-03-19 15:16:41 +00:00
---
Another talk as part of the Data On Kubernetes Day.
## Baseline
### Hosting Models
* Managed: Atlas
* Semi: Cloud manager
* Selfhosted: Enterprise and community operator
### Mongo on K8s
* Cluster Architecture
* Control Plane: Operator
* Data Plane: MongoDB Server + Agen (Sidecar Proxy)
* Enterprise Operator
* Opsmanager CR: Deploys 3-node operator DB and OpsManager
* MongoDB CR: The MongoDB cLusters (Compromised of agents)
* Advanced Usecase: Data Platform with mongodb on demand
* Control Plane on one cluster (or on VMs/Hardmetal), data plane in tennant clusters
* Result: MongoDB CR can not relate to OpsManager CR directly
## Pitfalls
* Storage: Agnostic, Topology aware, configureable and resizeable (can't be done with statefulset)
* Networking: Cluster-internal (Pod to Pod/Service), External (Split horizon over multicluster)