Inventario de Hardware¶

Los hostnames siguen la serie Invincible — ver categoría de personajes. deborah fue antes orangepi5plus.

Datos medidos con playbook-discovery.yml (2026-07-10). Donde el valor nominal difiere del medido, la columna Medido es la fuente de verdad para planificación.

invincible x86_64

Lenovo M920q · i3-6100T 2c/4t

RAM: 7.6 GB

IP actual: 192.168.23.162 · IP estática: 192.168.20.6

Incus: Bootstrap / leader (pendiente) · K3s: Worker (agent)

oliver x86_64

Lenovo M700 · i7-8700T 6c/12t

RAM: 15.5 GB

IP actual: 192.168.20.87 · IP estática: 192.168.20.7

Incus: Miembro (scheduler manual) · K3s: Worker (agent)

deborah ARM64

Orange Pi 5 Plus · RK3588 8c

RAM: 31.0 GB

IP actual: 192.168.21.211 · IP estática: 192.168.20.5

Incus: Miembro (grupo arm64) · K3s: Control-plane (server)

Specs nominales vs medidas

La documentación anterior intercambiaba RAM entre invincible (16 GB nominal → 7.6 GB medidos) y oliver (8 GB nominal → 15.5 GB medidos). Actualizar cualquier presupuesto que use los valores viejos.

Esquema de IPs¶

Concepto	invincible	oliver	deborah
IP SSH hoy (`ansible_host`)	`192.168.20.6`	`192.168.20.7`	`192.168.20.5`
IP estática en `br0`	`192.168.20.6`	`192.168.20.7`	`192.168.20.5`
Interfaz física → bridge	`eno2`	`eno1`	`enP4p65s0`

Tras playbook-set-static-ip.yml, actualizar ansible_host en inventory.ini si la IP de conexión cambió.

Almacenamiento e I/O (discovery 2026-07-10)¶

Nodo	Disco principal	Escritura 4k (dd/fio)
invincible	TECLAST 120GB SSD	85.5 MB/s
oliver	Kingston SA400 224GB	1.8 GB/s
deborah	mmcblk0 boot + NVMe WDC 250GB (`nvme0n1`)	pendiente (benchmark en `/srv` o NVMe)

Presupuesto de RAM (recalculado)¶

invincible (7.6 GB): K3s (distribución ligera de Kubernetes) agent + ArgoCD controller + futuro Incus leader. RAM ajustada — evitar CAPN (Cluster API Provider for Incus) management + Longhorn simultáneos sin límites de pods.
oliver (15.5 GB): K3s agent (CoreDNS, metrics-server) + Incus en scheduler.instance manual. Más margen del documentado; I/O superior a invincible.
deborah (31 GB): control-plane K3s + BIND (rol bind_dns). Root en eMMC; NVMe (disco SSD por PCIe) disponible para datos/etcd.

Decisión: control-plane en deborah¶

Estado: el API (Application Programming Interface) server responde en 192.168.20.5:6443 (deborah). Workers en invincible (192.168.20.6) y oliver (192.168.20.7). Se instala con K3s v1.36.5+k3s1 (k3s_install.core.version); después el SUC (System Upgrade Controller) lo actualiza solo (Actualizar K3s). Versión real: kubectl get nodes.

Análisis de trade-offs

A: deborah elegida

31 GB RAM, ARM64, NVMe disponible

SBC; throttling térmico; servicios extra en el mismo nodo

B: oliver

I/O 1.8 GB/s; 15.5 GB RAM; i7-8700T

Reservado quorum Incus; migración CP costosa

C: invincible

Ya corre ArgoCD controller

Solo 7.6 GB RAM; I/O lento

Pendiente: ejecutar fio en deborah sobre NVMe (/srv o partición dedicada) para validar latencia fsync antes de considerar migración a oliver.

deborah tras reboot

El discovery detectó el binario k3s pero sin servicio k3s activo ni puerto :6443 en un escaneo con uptime ~2.6 h. Verificar systemctl enable --now k3s y logs si el CP (control plane) no responde.