Cambiar el controlador de Gateway¶

El HomeLab publica sus servicios con Gateway API (Gateway y HTTPRoute), no con Ingress. Hay un solo Gateway, llamado homelab (namespace gateway), con un listener HTTP (80) y uno HTTPS (443) para *.homelab.local. Cada app se engancha con su propio HTTPRoute (argocd/route, vcluster/route).

Quien atiende ese Gateway es un controlador a la vez; los tres comparten las IP 80/443 de MetalLB y no pueden convivir:

Application	Controlador	Notas
`kong` (predeterminado)	Kong Ingress Controller (KIC)	Usa el Kong que instala el chart (modo unmanaged)
`traefik`	Traefik	Solo Gateway API: sin `Ingress` ni `IngressRoute`
`nginx-gateway`	NGINX Gateway Fabric	Necesita también `nginx-gateway-helm-repo` (registro OCI del chart)

El Gateway de cada uno está en gateway/<kong|traefik|nginx>/ del repo gitops; GatewayClass, puertos y anotaciones cambian de uno a otro, los HTTPRoute no.

Cómo funciona el TLS¶

cert-manager (cert-manager) y una CA propia (cert-manager-config, ClusterIssuer homelab-ca) emiten el certificado. El Gateway lleva la anotación cert-manager.io/cluster-issuer: homelab-ca y cert-manager crea solo el Secret homelab-tls.
El Gateway termina el TLS y habla HTTP con los servicios. Por eso argocd-server corre con server.insecure (en argocd/config) y el HTTPRoute apunta a su puerto 80. El diff del pipeline de gitops usa --plaintext por el mismo motivo.

Para que el navegador confíe en la CA, importa su certificado raíz:

kubectl -n cert-manager get secret homelab-ca -o jsonpath='{.data.ca\.crt}' | base64 -d > homelab-ca.crt

Cambiar de controlador¶

En bootstrap/root-appset.yaml (repo gitops), comenta el controlador actual y descomenta el nuevo (y nginx-gateway-helm-repo si es NGINX). Haz push.
Vuelve a aplicar el ApplicationSet (ArgoCD no lo gestiona):
```
kubectl apply -f gitops/bootstrap/root-appset.yaml
```
Las Applications de los controladores llevan el finalizer de ArgoCD: al comentar la app, homelab-root borra la Application y sus recursos (el Gateway y las IP quedan libres para el nuevo). Espera a que desaparezca:
```
kubectl -n argocd get applications
```
Verifica que el Gateway quede programado y con IP:
```
kubectl get gateway homelab -n gateway
kubectl get httproute -A
```
Tiene que mostrar PROGRAMMED=True, una dirección entre 192.168.23.200 y .220, y los HTTPRoute con Accepted.

Primera vez (viniendo de ingress-nginx)¶

ingress-nginx y el Ingress de ArgoCD ya no existen en gitops. Sus Applications desaparecen al volver a aplicar el ApplicationSet, pero lo que crearon queda en el clúster:

kubectl -n argocd delete ingress argocd-server
kubectl delete namespace ingress-nginx
kubectl delete clusterrole,clusterrolebinding,ingressclass,validatingwebhookconfiguration \
  -l app.kubernetes.io/instance=ingress-nginx

Aplica primero el cambio de argocd (activa server.insecure): hasta que el Gateway esté Programmed, entra a ArgoCD con kubectl port-forward svc/argocd-server -n argocd 8080:80 (http://localhost:8080).

Si falla¶

Síntoma	Revisar
`Gateway` sin dirección o `PROGRAMMED=False`	`kubectl describe gateway homelab -n gateway`: GatewayClass inexistente (controlador no activo) o CRDs de Gateway API ausentes (`gateway-api` sin sincronizar)
Dos controladores activos	Comenta uno: se pelean por las IP de MetalLB
El Gateway no tiene certificado (`homelab-tls` no existe)	`kubectl describe certificate -n gateway`; `cert-manager-config` debe estar `Healthy`
`HTTPRoute` sin `Accepted`	`kubectl describe httproute -n argocd argocd-server`: `parentRefs` debe apuntar a `homelab` en `gateway`
Con Kong, el listener queda sin programar	KIC enlaza el Gateway con los puertos del Kong del chart; revisa `kubectl describe gateway` y los puertos del Service `kong-gateway-proxy`
ArgoCD responde `too many redirects` o error de protocolo	`server.insecure` no se aplicó: `kubectl -n argocd get cm argocd-cmd-params-cm -o yaml`