Isolamento
Isolamento por namespace por tenant e os 4 building blocks Crossplane por tenant.
A plataforma isola cada tenant em seu próprio namespace — modelo único. Os ~21 tenants são o mesmo produto operado pela mesma organização (mesmo domínio de confiança), então não há necessidade de isolamento de control plane por tenant.
Isolamento por namespace
- Namespace Kubernetes por tenant com
CiliumNetworkPolicydeny-all entre namespaces. ResourceQuota+LimitRange+ RBAC por namespace.- CloudNativePG
Clustere Redis Sentinel (bsvc + resvc) dedicados, no mesmo namespace do tenant.
Opção futura — isolamento forte (vCluster)
Se algum tenant um dia exigir apiserver/RBAC dedicado e blast radius isolado no nível de control plane, o modelo pode ganhar um tier via vCluster. Não é necessário hoje e foi retirado do escopo para não carregar dois caminhos em cada Composition.
Building blocks Crossplane
O provisionamento por tenant usa 4 XRDs independentes — cada tenant compõe apenas os blocos de que precisa, declarando YAMLs em tenants/<nome>/.
| XRD | API Group | Recursos compostos |
|---|---|---|
TenantNamespace | platform.prophub.tech | Namespace + CiliumNetworkPolicy |
PostgresInstance | data.prophub.tech | CloudNativePG Cluster (PVC 20Gi) |
RedisCache | data.prophub.tech | Redis in-memory, sem PVC (cache bsvc) |
RedisPersistent | data.prophub.tech | Redis AOF + PVC 2Gi + ConfigMap + initContainer (resvc) |
Substitui a Composition monolítica
Esta decomposição (2026-06-21) substitui o XRD monolítico Tenant
(v1alpha1), que criava 6 recursos fixos para todo cliente. Dois XRDs Redis
separados (cache × persistent) porque patch-and-transform não omite um
recurso composto condicionalmente.
Tenants em produção
amigosdamesa · blueberry · euro · forever · horizon · insider · k2 · lvl · nexa · planet · titanium · trade4u · trademakers · traderace · explorer · belive · fyprop · ifinza · furyfunded · fortunesfunding · planet4funded