ADR-0002 — Nó de Banco Dedicado e Tainted

Status: Aceito · Data: 2026-06-14

Contexto

Os bancos PostgreSQL de GitLab, Nextcloud e Penpot têm perfil de I/O e criticidade distintos das aplicações stateless. Precisávamos decidir onde eles rodam dentro do cluster rke-app.

Opções:

Nó dedicado (rke-db-00), isolado por taint, com NVMe próprio.
Distribuir os bancos entre os nós de aplicação, com discos rápidos em todos.

Decisão

Consolidar todos os bancos em um nó dedicado e tainted (rke-db-00):

Label node-role.kubernetes.io/database=true (atrai os bancos);
Taint dedicated=database:NoSchedule (repele o restante);
StorageClass nvme-local de alta performance só nesse nó.

Justificativa

Performance direcionada — NVMe rápido apenas onde importa, em vez de discos caros em todo o cluster.
Isolamento — cargas stateless não competem por I/O com os bancos.
Menor raio de impacto — dados críticos concentrados e protegidos por scheduling explícito (affinity + tolerations).
Governança clara — qualquer pod no nó de banco que não seja PostgreSQL é um desvio facilmente detectável.

Consequências

O banco torna-se um ponto de atenção: sua durabilidade depende dos backups no R2 e da recriação do nó via IaC.
Sem HA nativo com um único nó de banco; HA multi-nó exigiria novo ADR e mais nós rke-db-*.
Todo manifesto de banco deve incluir o bloco canônico de scheduling, validado em revisão de PR.