Un laboratorio de ingress en Kubernetes que la CI construye desde cero

Por qué este laboratorio

Viene de trabajar con plataformas de contenedores como Red Hat OpenShift y Kubernetes en local. En este laboratorio profundizo en cómo entra hoy el tráfico en un clúster: Gateway API en lugar del Ingress clásico, red con eBPF, y certificados y DNS gestionados por controladores.

Qué he hecho

• kind sin CNI ni kube-proxy, sustituidos por Cilium (LB IPAM, anuncios L2, una política L7 y Hubble).
• Envoy Gateway con Gateway API: redirección, TLS y limitación de peticiones.
• cert-manager con una CA del laboratorio y un certificado wildcard.
• external-dns escribiendo en BIND por RFC 2136 con TSIG y registros TXT de propiedad.
• Denegación por defecto en el namespace de las apps y lista blanca L7 (/env devuelve 403), sin forma de saltarse el gateway.

Cómo se prueba

Un workflow de GitHub Actions construye el clúster desde cero y pasa nueve pruebas de punta a punta. Ha salido en verde en las cuatro últimas ejecuciones.

Siguientes pasos

• Cambiar kind por tu clúster y BIND por tu proveedor de DNS en external-dns.
• Cambiar la CA del laboratorio por ACME o tu PKI interna en cert-manager.
• Contribuir de vuelta: documentación o una good first issue en alguno de estos proyectos es mi siguiente paso.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.