Skip to content
CPPS Docs

ADR-005 — GPU em LXC mantido como cluster K3s standalone

Status

Vigente — 2026-05-02. Substitui versão anterior que recomendava migração pra VM.

Histórico

A versão inicial deste ADR recomendava migrar gpu-sp-01 de LXC pra VM com PCIe Passthrough antes de adicionar Cilium, assumindo que Cilium em LXC seria inviável.

Após reavaliação honesta com o time:

  • ADR-002 revisado: Cilium em LXC privileged é o caminho CPPS, com trade-offs aceitos
  • A equação de risco “VM vs LXC” pra GPU mudou: agora ambos são compatíveis com Cilium
  • gpu-sp-01 permanece em LXC, e pode adotar Cilium se houver caso de uso (consistência com cluster principal)

Contexto

gpu-sp-01 hoje é um LXC privileged com nesting=True e keyctl=True (ver infra/proxmox-sp/config.py) rodando K3s standalone + flannel default + A5000 via dispositivos passados ao container (/dev/nvidia*).

LXC + K3s + GPU tem trade-offs reais:

Vantagens:

  • Performance GPU ~zero overhead (vs ~5-15% perda em VM com nested virt)
  • Driver NVIDIA instalado uma vez no Proxmox, LXCs compartilham
  • RAM não é “presa” como em VM (que reserva o total declarado)
  • Live migration via LINSTOR funciona (VM com PCIe Passthrough geralmente não)
  • Setup atual já validado em produção sem incidentes documentados

Desvantagens:

  • Compartilhamento de kernel: erro de driver pode derrubar host (raro em workloads bem-comportadas, real em código CUDA experimental)
  • LXC privileged compromete isolamento de segurança (aceitável em lab single-tenant)
  • Sync de driver NVIDIA entre host e LXC exige disciplina
  • Cilium não roda em LXC com confiabilidade (ADR-002)

A questão crítica: gpu-sp-01 é cluster K3s standalone (a) ou worker node do cluster K3s SP unificado (b)?

  • (a) Standalone: Cilium não toca esse cluster → restrição de ADR-002 não aplica → LXC viável
  • (b) Worker do cluster SP: Cilium tem que rodar nele → LXC inviável → exige migração pra VM

Hoje, o Pulumi provisiona gpu-sp-01 como ContainerLegacy independente, com K3s standalone. Arquitetura (a) é o estado real.

Decisão

gpu-sp-01 mantido como cluster K3s standalone em LXC privileged + flannel default. Sem Cilium nesse cluster.

A decisão é forçada pelo hardware Tier 3 dos hosts SP (ver Tiers de hardware):

  • pve-ippri-31 (host atual de gpu-sp-01) é Tier 3 — Ryzen sem iGPU, A5000 disputada entre display físico e workload
  • VM com PCIe Passthrough faria host perder display
  • Cilium em LXC privileged é território não-suportado upstream (ADR-002)

Implicações:

  1. K3s SP “principal” (em VMs Tier 1/2A/2B) e K3s GPU SP (em LXC Tier 3) são clusters separados, stacks diferentes:
    • Principal: VM + Cilium + Hubble + ClusterMesh com Franca
    • GPU SP: LXC + flannel default + comunicação via Traefik HTTP
  2. Cluster GPU Franca futuro vai pra VM com Cilium (hosts pve-labri-31/32/33 são Tier 2A com iGPU — permite passthrough preservando display)
  3. Assimetria intencional: cluster GPU SP (LXC+flannel) ≠ cluster GPU Franca (VM+Cilium). Não é problema — herança de hardware diferente entre sites.
  4. ArgoCD SP gerencia ambos clusters SP via multi-cluster registration; ArgoCD Franca gerencia clusters Franca

A questão “Cilium ou não no cluster GPU” deixa de existir como escolha — é decidida pelo hardware.

Alternativas rejeitadas

  • Migrar pra VM com PCIe Passthrough (recomendação anterior): rejeitada porque

    • Performance perdida (~5-15%) é significativa pra cargas de IA
    • RAM reservada na VM custa headroom de outros workloads
    • Live migration via LINSTOR fica inviável
    • Setup atual está validado e estável
    • Risco de kernel panic em workloads bem-comportadas é teórico, não observado em prod

  • Forçar Cilium sobre LXC privileged: rejeitada — fragilidade real, contradiz ADR-002

  • vGPU NVIDIA GRID: rejeitada — A5000 não tem suporte oficial vGPU; vgpu-unlock é hack instável

Consequências

Positivas:

  • Performance GPU preservada em produção
  • Estado atual permanece válido — sem migração arriscada
  • Driver NVIDIA self-contained no Proxmox host
  • Live migration funciona via LINSTOR
  • Cilium e seu rationale ficam restritos ao cluster K3s SP “principal”

Negativas:

  • Sem Cilium NetworkPolicy no cluster GPU — segurança intra-K8s mais fraca
  • Sem Hubble — observabilidade de rede do cluster GPU vai pelo OpenObserve sem L7 detalhado
  • Sem ClusterMesh — service discovery cross-cluster manual (via Traefik + DNS)
  • 2 clusters K3s pra operar em SP em vez de 1 — overhead de gestão (mas mitigado por ArgoCD multi-cluster)
  • LXC privileged + nesting compromete isolamento (aceitável pra lab single-tenant)

Riscos aceitos explicitamente:

  • Falha de driver NVIDIA pode derrubar host Proxmox — mitigação: workloads passam por revisão antes de produção, monitoring no host pra detectar early
  • Sync de driver entre host + LXC: documentar procedimento em runbook

Critério de revisão

Revisitar essa decisão se:

  1. gpu-sp-01 sofrer kernel panic real que derrube Proxmox host — gatilho pra migrar pra VM
  2. Self-service GPU multi-tenant virar requisito (pesquisadores rodando código arbitrário) — LXC privileged perde aceitabilidade
  3. Cilium ClusterMesh virar requisito de service discovery cross-cluster (em vez de Traefik HTTP) — exige Cilium nos 2 lados
  4. Compliance institucional exigir isolamento de kernel formal
  5. Aparecer alternativa (containerd direto no Proxmox host? sandbox/gVisor com GPU?) que cubra GPU sem LXC privileged

Notas operacionais

  • Cluster K3s GPU é standalone, não join com cluster SP principal
  • ArgoCD SP registra esse cluster com argocd cluster add gpu-sp apontando pra kubeconfig
  • Apps GPU em apps/sp-gpu/ separados de apps/sp/
  • Driver NVIDIA: documentar versão exata em docs/operacoes/nvidia-driver-sync.md (criar)
  • Quando migrar driver no Proxmox, plano de rollback documentado
  • Monitoring do host Proxmox pra dmesg + nvidia-smi (alerta de erro de driver) — Fase 8 (observability)