Agrega lo que faltaba para desplegar workloads/docs-portal/ (ya existente sin commitear): deployment/service/ingress + kustomization siguiendo el patrón de workloads/nginx, Applications de workload y gobernanza separadas, y el workflow de Gitea Actions (build+push a Gitea Registry, bump de versión en el manifiesto) siguiendo el mismo patrón que build.yaml/build-medusa.yaml.
893 B
893 B
ADR 0001 — Por qué k3d (y no k3s directo, minikube, o un cluster cloud)
TODO (fase 2+): completar contexto/opciones/consecuencias con criterio real (recursos del NAS ZimaOS, necesidad de multi-nodo para reproducir el blackhole de MTU documentado en
known-issues.md, costo cero vs. cluster gestionado).
Estado: aceptada (placeholder — pendiente de redactar) Fecha: TODO
Contexto
TODO
Opciones consideradas
| Opción | A favor | En contra |
|---|---|---|
| k3d | ||
| k3s directo (sin Docker) | ||
| minikube | ||
| Cluster gestionado (cloud) |
Decisión
TODO
Consecuencias
TODO — mencionar explícitamente el blackhole de red cross-node (MTU/PMTUD) como consecuencia real y documentada de correr multi-nodo sobre Docker-in-Docker sin ajuste de MTU (ver playbook del crashloop de Medusa).