Iñigo GonzálezIT Operations · Infra

Blog · 06

Un laboratorio de ingress en Kubernetes que la CI construye desde ceroA Kubernetes ingress lab built from zero in every CI run

Cilium, Envoy Gateway, cert-manager y external-dns sobre kind, con nueve pruebas de punta a punta.Cilium, Envoy Gateway, cert-manager and external-dns on kind, with nine end-to-end checks.

Laboratorio cloud y SRECloud & SRE lab · 1 oct 20261 Oct 2026 · 2 min2 min read

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.

Why this lab

Comes from working with container platforms such as Red Hat OpenShift and Kubernetes on premises. In this lab I go deeper into how traffic gets into a cluster today: Gateway API instead of the classic Ingress, eBPF networking, and certificates and DNS handled by controllers.

What I built

  • kind with no CNI and no kube-proxy, replaced by Cilium (LB IPAM, L2 announcements, an L7 policy and Hubble).
  • Envoy Gateway with Gateway API: redirect, TLS and rate limiting.
  • cert-manager with a lab CA and a wildcard certificate.
  • external-dns writing to BIND over RFC 2136 with TSIG, using TXT ownership records.
  • Default deny in the apps namespace and an L7 allow-list (/env returns 403), with no way around the gateway.

How it is tested

A GitHub Actions workflow builds the cluster from scratch and runs nine end-to-end tests. It has been green in the last four runs.

Next steps

  • Replace kind with your own cluster and BIND with your DNS provider in external-dns.
  • Swap the lab CA for ACME or your internal PKI in cert-manager.
  • Contribute back: docs or a good first issue in one of these projects is the next step on my side.

Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.

Apúntate y llévate las 33 ideasSign up and get the 33 ideas →