Clusters RKE

A plataforma usa três clusters RKE independentes. Mantê-los separados isola falhas, simplifica o modelo de permissão e permite que homologação evolua sem risco para produção.

rke-mngm — Cluster de Gestão

O cluster que sustenta a confiança da plataforma. Roda os serviços de base dos quais todos os outros dependem.

• rke-mngm-00 — Control Plane.
• rke-mngm-01 — Worker de serviços de base: LLDAP (identidade), Headscale (malha de rede) e Vault (segredos).

Por ser a âncora de identidade e segredos, é o cluster com a postura de segurança mais restritiva.

rke-app — Cluster de Aplicações (Produção)

Onde rodam as aplicações da Serigy e seus bancos de dados.

• rke-app-00 — Control Plane.
• rke-app-01, rke-app-02 — Workers stateless (frontends/backends das aplicações).
• rke-db-00 — Worker stateful, tainted, exclusivo para PostgreSQL via CloudNativePG.

O operador CloudNativePG é instalado neste cluster e garante que todo banco seja agendado apenas no rke-db-00. As aplicações stateless se conectam aos bancos por Service (ClusterIP) interno — veja o padrão de deploy.

rke-hml — Cluster de Homologação

Ambiente de homologação (staging) no escritório de Aracaju.

• rke-hml-00 — Control Plane + Worker na mesma máquina (configuração compacta, suficiente para validar mudanças antes de produção).

Control Plane vs. Workers

flowchart TB
    subgraph CP["Control Plane (CP)"]
        API["kube-apiserver"]
        ETCD[(etcd)]
        SCHED["scheduler"]
        CM["controller-manager"]
    end
    subgraph WK["Workers"]
        K1["kubelet + containerd"]
        K2["pods das aplicações"]
    end
    API --- ETCD
    SCHED --> WK
    CM --> WK

Componente	Onde roda	Responsabilidade
Control Plane	rke-*-00 (e rke-hml-00)	API, estado (etcd), agendamento
Workers	rke-app-01/02, rke-db-00, rke-mngm-01	Executar as cargas (pods)

Dica

A regra de ouro: dados críticos só no rke-db-00, serviços de base só no rke-mngm-01, e aplicações stateless nos rke-app-01/02. O agente aplica isso por labels, taints e affinities.