Bug en chart 0.2.x: AddonClaim era Helm hook pre-install,pre-upgrade
weight -10 SIN hook-delete-policy. El default Helm 3 es
before-hook-creation → borra el claim en cada upgrade → finalizer
cleanup-logical rotaba credenciales + atoraba release en pending-upgrade.
Cambios:
- helm/APP_NAME/templates/addonclaim.yaml eliminado.
- manifests/addonclaim.yaml creado con placeholders sed.
- scripts/pre-helm-detach.sh idempotente para migracion v1.0.0 → 1.1.0.
- .gitea/workflows/APP_NAME-build.yaml: 2 nuevos steps detach + apply
AddonClaim entre kubeconfig y helm upgrade.
- Chart.yaml bump 0.2.0 → 0.3.0.
- README reescrito (3 pasos workflow + tabla hooks sin AddonClaim +
seccion Por que FUERA del chart + opt-out actualizado).
- Comentarios stale del AddonClaim como hook -10 limpiados en
networkpolicy.yaml, role-db-secret-reader.yaml, job-alembic-upgrade.yaml.
ADR-066 del IDP documenta la decision arquitectural completa.
Validacion en cluster tenant DO destapo el issue: el Service `kubernetes` en
ns default tiene endpoint a la IP PUBLICA del Droplet:6443, no a una ClusterIP
intra-cluster. kube-proxy DNATea 10.43.0.1:443 -> public-ip:6443. Calico
aplica las NetworkPolicy egress rules contra la IP de DESTINO POST-DNAT, asi
que namespaceSelector "default" no matchea (no hay pod selector aplicable).
ipBlock 0.0.0.0/0 cubre ambos: apiserver public-ip:6443 + Harbor:443.
Trade-off de seguridad menor (egress permitido a IPs externas por 443/6443)
aceptable para Golden Path: las apps web necesitan llegar a apiserver y
posiblemente a HTTPS externos (APIs publicas). Endurecimiento P3 con
egress NetworkPolicy mas granular cuando haya use cases especificos.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Chicken-and-egg encontrado en smoke E2E DO (cluster 91c93c9c):
- ns 'apps' tiene default-deny NetworkPolicy entregada por stack-deployer.
- Job Alembic (pre-install hook) ejecuta InitContainer wait-for-secret que
hace REST API call al kube-apiserver para chequear Secret.
- La NetworkPolicy del chart (que permite DNS + apiserver egress) estaba como
RESOURCE NORMAL, asi que solo se aplicaba en la FASE PRINCIPAL del helm
install, DESPUES de los hooks.
- Resultado: el InitContainer del hook quedaba bloqueado DNS por
default-deny → curl timeout 240s → helm install fail → NetworkPolicy
nunca se aplica.
Fix:
- Annotations 'helm.sh/hook: pre-install,pre-upgrade' + 'hook-weight: -8'
+ 'hook-delete-policy: before-hook-creation'.
- Weight ordering: -10 AddonClaim → -8 NetworkPolicy → -7 Role/RoleBinding
→ -5 SA → 0 Job Alembic.
- delete-policy: before-hook-creation (no hook-succeeded): el Deployment de
la fase principal necesita la NP viva en runtime.
- Comentario en la regla egress :443 aclarando que cubre kube-apiserver
(10.43.0.1) + Harbor (sin necesidad de regla adicional).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
