C / Desarrollo · hito despliegue · streamxe5 / lek

Plan de QA — arquitectura, gestión y administración

El objeto de prueba no es el negocio de cada app. Es la cadena de despliegue (Incus → k3s → Caddy), el plano de gestión y que se pueda administrar el piloto sin tocar producción I9.

0/0Casos marcados
Incus + k3sRuntime aislado
CaddyPublicación por path
cost-pilotNamespace de gestión
Qué no es este QA. No evalúes consolidar XLSX, OTP de correo, jobs ETL ni dashboards OTIF con datos de planta. Si una UI abre, basta como evidencia de que el pipeline publicó un workload. El fallo de negocio (MySQL planta, NAS, Outlook) no tumba el hito.

Cadena que estás validando

DNS / WAN streamxe5.fitschile.cl → host lek (192.168.1.210)Publicación y que el host esté vivo
Caddy caddy-apps-admin :80/:443Enrutado por path, healthz, portal vs consola vs apps
NodePorts en CP 10.89.200.21130100 consola · 30095+ apps · sin Ingress
k3s (3 nodos) namespace cost-pilotDeployments, labels C/desarrollo, self-healing
VMs Incus proyecto k8s-pilot sobre bridge incusbr-k8s 10.89.200.0/24Aislado del default de Incus y de I9
Superficies de gestión: Portal /apps-admin/ (entrada humana) · Consola /cluster/ (solo lectura del cluster) · SSH root@streamxe5.fitschile.cl + kubectl con /home/incus-k8s-pilot/runtime/kubeconfig.

Checklist

Mapa de publicación (lo que Caddy debe distinguir)

PathQué esQué comprobar
/apps-admin/ Portal de gestión (HTML estático) Lista de apps + enlace a QA. No debe ser la consola k8s
/cluster/ Consola k8s (NodePort 30100) Apps, nodos, workloads. JSON válido, 3 nodos Ready
/cluster/api/* y /api/* API de la consola /healthz y /cluster/api/cluster responden JSON
/dev/* Workloads publicados (evidencia de pipeline) Cada path llega a su NodePort; 200 y título de la app
/healthz Health del edge Caddy HTTP y HTTPS: ok apps-admin

Inventario mínimo a ver en administración

CapaObjetoEsperado
Incus Proyecto k8s-pilot 3 VMs RUNNING: cp .211, w-01 .137, w-02 .246. incus list sin proyecto se ve vacío
k3s Namespace cost-pilot Nodos Ready 3/3. Deployments de apps + mysql-dev + consola
Clasificación Labels fits.level=C fits.env=desarrollo En los deploy de las apps githubmanuel
Catálogo MANAGED_APPS_JSON en la consola 6 entradas (5 UIs + data-store stub), con public_path
Código piloto /home/incus-k8s-pilot/ Scripts streamxe5-*, manifests k8s/, kubeconfig en runtime/

Comandos de administración (desde lek)

export KUBECONFIG=/home/incus-k8s-pilot/runtime/kubeconfig

incus list --project k8s-pilot -c ns4

kubectl get nodes

kubectl -n cost-pilot get deploy,svc,pods -L fits.level,fits.env

docker ps --filter name=caddy-apps-admin

curl -sS http://127.0.0.1/healthz

Aislamiento (no romper I9)

El piloto no debe listar VMs fuera de k8s-pilot.

No debe depender de 192.168.100.81 para que Caddy y k3s estén UP.

Data Store stub hacia I9 puede fallar: eso es correcto.

No hay cutover a url-host-orchestrator ni a apps-prod-cost.

Criterio de aceptación del hito (arquitectura)

Pasa si

El host publica por DNS, Caddy separa portal / consola / workloads, el cluster Incus+k3s está Ready, las apps aparecen en el catálogo de gestión con labels C/desarrollo, y un restart de pod se recupera solo. Una UI que abre en /dev/... es evidencia de publicación, no de negocio.

No bloquea

Funciones de negocio incompletas, MySQL de planta inalcanzable, OTP sin correo, ETL sin NAS, Data Store stub, certificado interno vs Let’s Encrypt, y que el router a veces corte el WAN.