107 lines
5.0 KiB
Markdown
107 lines
5.0 KiB
Markdown
# Overzicht Kubernetes Migratie — eveai_app & eveai_workers
|
||
|
||
Dit document bundelt de belangrijkste inzichten en keuzes rond het migreren van je applicatiecomponenten naar Kubernetes.
|
||
(⚠️ Build-optimalisaties zijn hier **niet** meegenomen — die volgen eventueel later.)
|
||
|
||
---
|
||
|
||
## 1. Conceptuele inzichten
|
||
|
||
### 1.1 Webcomponenten (eveai_app)
|
||
- **Gunicorn workers**
|
||
- `-w` = aantal processen (CPU-parallelisme).
|
||
- `--worker-connections` = max. aantal gelijktijdige connecties *per worker* (bij async workers zoals `gevent`).
|
||
- **Memory**
|
||
- Elke replica = eigen Pod = eigen memory footprint.
|
||
- Binnen een Pod: elke workerproces neemt (bijna) z’n eigen geheugenruimte.
|
||
- Image-grootte ≠ runtime memory (grote image → trager deployen, maar geen direct effect op RAM).
|
||
- **Schaalstrategie**
|
||
- In Kubernetes hou je `-w` laag (1–2), en schaal je horizontaal met replicas.
|
||
- Extern verkeer gaat via Ingress (poort 80/443, hostnames/paths).
|
||
- Geen nood meer om per service aparte poorten te kiezen zoals in Docker.
|
||
|
||
### 1.2 Database migratie & startup-acties
|
||
- **Huidige situatie**: migrations + cache-acties gebonden aan container startup.
|
||
- **Aanbevolen aanpak**:
|
||
- Gebruik **Kubernetes Jobs** voor eenmalige taken (bv. DB-migraties, cache-invalidate, re-index).
|
||
- Gebruik **CronJobs** voor geplande taken (bv. nachtelijke purges, periodieke warm-ups).
|
||
- **Jobs vs. Helm Hooks**
|
||
- *Job*: los uit te voeren, flexibel, manueel of via CI/CD te triggeren.
|
||
- *Helm Hook*: gekoppeld aan een release, garandeert volgorde, maar minder flexibel.
|
||
- Aanbevolen: **Jobs** voor flexibiliteit en onderhoud.
|
||
|
||
### 1.3 Backendcomponenten (eveai_workers met Celery)
|
||
- **Worker Pods**
|
||
- Eén rol per Pod:
|
||
- Workers (prefork pool, concurrency afgestemd op CPU).
|
||
- Beat (scheduler) als apart Deployment **indien nodig**.
|
||
- Flower (monitoring) als aparte Deployment (optioneel).
|
||
- **Betrouwbaarheid**
|
||
- Gebruik `acks_late`, `task_reject_on_worker_lost`, en `visibility_timeout`.
|
||
- Prefetch multiplier = 1, fairness inschakelen.
|
||
- Time limits per taak instellen.
|
||
- Taken idempotent maken.
|
||
- **Queues & Routing**
|
||
- Verdeel workload over meerdere queues (bv. `high`, `default`, `low`).
|
||
- Start gespecialiseerde workers die alleen luisteren naar de relevante queue.
|
||
- **Autoscaling**
|
||
- Kubernetes HPA (CPU/memory) is beperkt.
|
||
- Gebruik **KEDA** → schaalt workers op basis van queue-lengte.
|
||
- **Graceful shutdown**
|
||
- terminationGracePeriodSeconds ≥ task timeout.
|
||
- Celery stopt intake en werkt lopende taken af.
|
||
|
||
### 1.4 Flower
|
||
- Flower is een **monitoring UI voor Celery** (geen onderdeel van je app).
|
||
- Kan standalone worden gedeployed via een generieke container (mher/flower).
|
||
- Configuratie via Helm chart mogelijk (zelfgemaakt of community chart).
|
||
- Overhead van Airflow is niet nodig — enkel Flower volstaat in jouw setup.
|
||
|
||
### 1.5 RBAC (conceptueel)
|
||
- **Role-Based Access Control** = mechanisme om te bepalen wie wat mag doen in k8s.
|
||
- Componenten:
|
||
- *Role/ClusterRole* = welke acties op welke resources.
|
||
- *RoleBinding/ClusterRoleBinding* = koppelt Role aan gebruikers/ServiceAccounts.
|
||
- *ServiceAccount* = identiteit die een Pod gebruikt.
|
||
- Belangrijk: principe van *least privilege* → Jobs/Workers krijgen enkel de rechten die ze nodig hebben.
|
||
|
||
---
|
||
|
||
## 2. Praktische aandachtspunten
|
||
|
||
### Webcomponent (eveai_app)
|
||
- Bind port via env var (`PORT=8080`), niet hardcoded.
|
||
- Voeg health endpoints toe (`/healthz`) voor readiness/liveness probes.
|
||
- Logs naar stdout/stderr.
|
||
- Resources instellen voor pods (requests/limits).
|
||
- Migrations verplaatsen naar Job/Hook.
|
||
|
||
### Backendcomponent (eveai_workers)
|
||
- Startscript aanpassen met veilige defaults:
|
||
```bash
|
||
celery -A scripts.run_eveai_workers worker --loglevel=INFO --concurrency=2 --max-tasks-per-child=1000 --prefetch-multiplier=1 -O fair
|
||
```
|
||
- Beat enkel gebruiken als je periodieke Celery-taken nodig hebt.
|
||
- Flower los deployen (Deployment + Service + optioneel Ingress).
|
||
- Overweeg KEDA voor autoscaling op queue-lengte.
|
||
- Voeg een PodDisruptionBudget toe om altijd workers beschikbaar te houden.
|
||
|
||
### Jobs & CronJobs
|
||
- Gebruik Jobs voor DB-migraties en startup-actions (cache invalidatie, warmup).
|
||
- Gebruik CronJobs voor geplande onderhoudstaken.
|
||
- Maak taken idempotent en stel deadlines/backoff limits in.
|
||
- Opruimen met `ttlSecondsAfterFinished`.
|
||
|
||
---
|
||
|
||
## 3. Samenvattende aanbevelingen
|
||
1. **Haal startup-acties uit je app-containers** → verplaats naar Jobs/CronJobs.
|
||
2. **Hou app-containers slank en simpel** → 1–2 workers per pod, schaal met replicas.
|
||
3. **Beheer Celery-taken betrouwbaar** → acks_late, visibility_timeout, idempotentie.
|
||
4. **Scheiding van verantwoordelijkheden** → workers, beat (indien nodig), flower los deployen.
|
||
5. **Monitoring & autoscaling** → gebruik health probes, resource limits, en KEDA voor workers.
|
||
6. **Security** → gebruik RBAC & Secrets om toegang netjes te beperken.
|
||
7. **Flower** → volstaat standalone, geen Airflow nodig.
|
||
|
||
---
|