- New Build and startup procedures for all services, compliant for both docker, podman and k8s

documentation/k8s_migratie_startup_containers_overzicht.md

@@ -0,0 +1,106 @@
+# 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.  
+
+---

documentation/redis_db_best_practices.md

@@ -0,0 +1,48 @@
+# Redis Databases (db=0..15) — Best Practices anno 2025
+
+## Wat zijn Redis DB’s?
+- Redis ondersteunt meerdere logische databases (`0..15`, standaard).
+- Elke DB heeft een eigen keyspace, maar **alles deelt dezelfde instance**:
+  - Geheugen (`maxmemory`)
+  - Eviction-policy
+  - Persistence-bestanden
+  - ACL’s (geen DB-specifieke rechten)
+  - Replicatie
+- In **Redis Cluster** bestaat enkel DB 0.
+
+---
+
+## Nadelen van meerdere DB’s
+- **Geen isolatie**: eviction en memory zijn gedeeld.
+- **Niet cluster-compatibel**: alleen DB 0 werkt.
+- **Meer connection pools**: elke DB → aparte pool → meer sockets.
+- **Moeilijke security**: ACL’s gelden niet per DB, enkel via key-prefixes.
+- **Operationele verwarring**: `SELECT` vergeten → keys zoek je in de verkeerde DB.
+
+---
+
+## Wanneer werden ze gebruikt?
+- Vroeger voor simpele scheiding: bv. DB 0 cache, DB 1 sessions.
+- Mogelijkheid om `FLUSHDB` te doen zonder alle data kwijt te zijn.
+- Legacy clients/tools verwachtten meerdere DB’s.
+
+---
+
+## Moderne best practices
+✅ **Gebruik altijd DB 0** (zeker als je ooit naar Redis Cluster wil).  
+✅ **Organiseer data met key-prefixes** (bv. `cache:`, `sess:`, `celery:`).  
+✅ **Gebruik ACL’s per prefix** voor toegangscontrole.  
+✅ **Splits workloads in aparte instances** als je echte isolatie nodig hebt (cache vs sessions vs Celery).  
+✅ **Monitor eviction en memory** (`used_memory`, `evicted_keys`) in plaats van te vertrouwen op DB-splitsing.  
+
+❌ **Gebruik geen meerdere DB’s** voor isolatie of multi-tenancy.  
+❌ **Verlaat je niet op DB’s** voor security of scaling.  
+❌ **Verwacht geen verschil in eviction/persistence** tussen DB’s.
+
+---
+
+## Conclusie
+- Redis-databases zijn een **historisch artefact**.
+- Ze voegen **geen echte isolatie** toe en schalen niet mee naar Cluster.
+- **Prefix + ACL’s** zijn de moderne manier om te scheiden.
+- Voor echte isolatie: gebruik meerdere Redis-instanties of Redis Cluster.