Visión General de la Serie K8S Envoy Gateway: Un Ingreso de Tráfico Más Moderno que Ingress

Si alguna vez has trabajado con tráfico externo en Kubernetes, lo más probable es que hayas empezado con Ingress. Funciona, y para muchos escenarios es genuinamente suficiente. Pero una vez que te enfrentas a requisitos más complejos — múltiples listeners, propiedad multi-equipo, gRPC, TCP, TLS passthrough, políticas de tráfico de grano fino — inevitablemente llegas a una situación donde "mantenerlo vivo con annotations" se convierte en la norma. El YAML empieza a parecer un conjuro, y las personas que lo mantienen sienten que están rompiendo un sello.

Ahí es donde entra Gateway API + Envoy Gateway — es el nuevo conjunto de herramientas. No complica las cosas; separa de forma limpia las responsabilidades que antes estaban entrelazadas, haciendo que el tráfico de entrada, las reglas de enrutamiento, la configuración de seguridad TLS, los tipos de protocolo y la propiedad de los equipos sean mucho más fáciles de razonar.

Qué Es, Exactamente

Digámoslo claramente en una sola oración:

Envoy Proxy: El plano de datos que realmente recibe el tráfico y reenvía las solicitudes — también conocido como Gateway Proxy
Envoy Gateway: El plano de control que gestiona Envoy Proxy por ti
Gateway API: La interfaz estándar que usas en Kubernetes para declarar reglas de tráfico

Piénsalo así:

Gateway API es donde escribes los requisitos
Envoy Gateway es el gestor que traduce y delega
Envoy Proxy es el guardia real que está en la puerta

La ventaja de esta separación es que no necesitas construir manualmente configuración de bajo nivel de Envoy, ni memorizar cada annotation privada de varios controladores. Declaras recursos de Kubernetes, y Envoy Gateway los traduce en configuración que Envoy Proxy puede ejecutar realmente.

Gateway vs Ingress: Cuál Es la Diferencia

La respuesta corta: Ingress no está obsoleto, pero Gateway API está mejor adaptado para sistemas medianos y grandes que necesitan más gobernanza.

Comparación	Ingress	Gateway API
Modelo de ingreso	Normalmente combina ingreso y enrutamiento en un solo objeto	Separa `GatewayClass`, `Gateway` y `Route`
Expresividad	Principalmente HTTP/HTTPS; las funcionalidades avanzadas dependen de annotations	Soporte nativo para múltiples tipos de ruta y campos más claros
Modelo de extensión	Muchas capacidades dependen de annotations privadas específicas del controlador	Campos estándar, más puntos de extensión mediante CRDs
Soporte de protocolos	Principalmente enfocado en HTTP/Web	Soporta `HTTPRoute`, `GRPCRoute`, `TCPRoute`, `TLSRoute`
Propiedad del equipo	Fácil mezclar configuración de plataforma y de aplicación	Más adecuado para equipos de plataforma gestionando ingreso, equipos de aplicación gestionando rutas
Portabilidad	Las annotations suelen estar ligadas a controladores específicos	Más estandarizado, mejor legibilidad entre implementaciones

Si tus requisitos son simplemente:

Un solo sitio web o API sencilla
Enrutamiento básico por ruta/host
Equipo pequeño

Entonces Ingress sigue siendo válido. Pero si tus requisitos empiezan a incluir:

Un ingreso que sirve múltiples protocolos
Múltiples listeners, dominios o certificados
HTTP y gRPC coexistiendo
Separar los permisos de ingreso de plataforma de los de ruta de aplicación
Configuración que se lee como una API real, no como una lista de deseos de annotations

Entonces Gateway API empezará a resultar muy atractivo.

Por Qué No Usar Simplemente Ingress

El objetivo oficial de Gateway API es abordar varios puntos de dolor comunes con Ingress a escala:

Mejor expresividad: El enrutamiento, TLS, las políticas de tráfico y los tipos de protocolo están definidos de forma más clara
Mejor portabilidad: Menor dependencia de annotations privadas específicas del controlador
Separación de roles más natural: Los equipos de plataforma poseen el ingreso, los equipos de aplicación poseen las rutas

Por ejemplo, las configuraciones de Ingress a menudo lucen así:

metadata:
  annotations:
    some.ingress.controller/rewrite-target: /
    some.ingress.controller/auth-type: basic
    some.ingress.controller/ssl-redirect: "true"

No es que no funcione — pero a medida que crecen los requisitos, las annotations fácilmente se convierten en magia negra de YAML misteriosa. Gateway API traslada estas necesidades a campos apropiados. Se lee como "configuración," no como una "lista de deseos."

La Estructura en Capas

La página de conceptos oficial divide Envoy Gateway en tres capas — vale la pena memorizarlas como mapa mental:

Configuración de usuario: Los recursos de Gateway API y los CRDs de extensión de Envoy Gateway que escribes
Controlador de Envoy Gateway: Lee estos recursos, los traduce en configuración ejecutable
Envoy Proxy: El plano de datos que realmente maneja el tráfico en vivo

En la práctica, pasarás la mayor parte de tu tiempo modificando la "capa declarativa," no conectándote por SSH a instancias de proxy para ajustar configuración de bajo nivel. Esta es la elegancia de ser nativo de Kubernetes.

Qué Aprenderás en Esta Serie

Esta serie sigue un orden de "construir primero, profundizar después" — 10 publicaciones incluyendo esta visión general:

Quick Start: Instala Envoy Gateway y ejecuta tu primera solicitud HTTP de extremo a extremo
Conceptos Principales: Comprende GatewayClass, Gateway, Listener y Envoy Proxy
Enrutamiento HTTP en la Práctica: Análisis profundo de HTTPRoute — host, ruta, cabecera, filtro, timeout
TLS y Seguridad: Configura HTTPS, comprende certificateRefs, la terminación TLS y TLSRoute
Buenas Prácticas: Hábitos clave antes de ir a producción
Hoja de Referencia de Tipos de Ruta: Decide rápidamente entre HTTPRoute, GRPCRoute, TCPRoute y TLSRoute
Guía de Diseño de Listener: Patrones de diseño multi-puerto, multi-hostname y multi-ingreso
Multi-Namespace y Propiedad de Equipos: Domina allowedRoutes, ReferenceGrant y la gobernanza de ingreso compartido
Manual de Estado y Depuración: Lee Accepted, ResolvedRefs, Programmed y sigue el camino de resolución de problemas más corto

Si solo quieres probar cómo se siente Envoy Gateway, ve directamente al siguiente post. Ponerlo en marcha supera memorizar cada término primero — igual que ir al gimnasio, aparecer de verdad supera ver 30 videos de YouTube primero.

Recursos Principales que Encontrarás

Los principiantes suelen tropezar porque asumen que Gateway API solo tiene Gateway y HTTPRoute. En realidad es toda una familia de recursos.

`GatewayClass`

Define "qué implementación de Gateway usar en este clúster." Para Envoy Gateway, la clave es que controllerName apunte al controlador correcto.

`Gateway`

Define "cómo luce el ingreso." Por ejemplo: qué puertos abrir, en qué protocolos escuchar, cómo se adjunta TLS, qué rutas están permitidas.

`Listener`

Listener es una de las unidades más importantes dentro de un Gateway. Piénsalo como una ranura orientada hacia el exterior del Gateway — cada ranura define:

puerto
protocolo
hostname
configuración TLS
allowedRoutes

Mucha gente piensa en Gateway como una caja negra, pero lo que realmente determina el comportamiento del ingreso es cada listener individual dentro de él.

La Familia de Route

HTTPRoute: Tráfico HTTP/HTTPS — el más común
GRPCRoute: Tráfico gRPC — puede coincidir en servicio/método
TCPRoute: Tráfico TCP puro — no analiza semántica HTTP
TLSRoute: Enruta basándose en TLS SNI — común para TLS passthrough

Lo que todos los routes comparten: No "abren la puerta" — deciden "cómo enrutar el tráfico una vez que entra."

Modelo Mental Mínimo

Guarda este mapa en tu cabeza:

GatewayClass  # Which Gateway implementation to use in this cluster
Gateway       # Which listeners this ingress opens
Listener      # A port / protocol / hostname / TLS slot
Route         # How to distribute traffic once it enters
Service       # The backend actually serving requests in the cluster
Envoy Proxy   # The data plane that ultimately handles the traffic

Un ejemplo mínimo luce así:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo
spec:
  parentRefs:
    - name: eg
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - name: backend
          port: 3000

No necesitas memorizar cada campo ahora. Solo comprende qué está haciendo:

parentRefs: A qué Gateway se adjunta esta regla
hostnames: Qué dominio debe coincidir con esta regla
backendRefs: A qué Service enviar el tráfico

De un Vistazo: Cuándo Usar Qué Route

Requisito	Recurso Recomendado
Sitios web, REST APIs, enrutamiento por cabecera/ruta	`HTTPRoute`
Enrutamiento por servicio/método gRPC	`GRPCRoute`
Servicios TCP puros (protocolo personalizado o no HTTP)	`TCPRoute`
Preservar TLS de extremo a extremo, no descifrar en el Gateway	`TLSRoute`

Esta matriz de decisión es muy práctica. Antes de escribir YAML, pregúntate:

"¿Estoy trabajando con tráfico HTTP, gRPC o TCP/TLS puro?"

Resumen en Una Línea

Envoy Gateway no es solo otro término que tienes que memorizar — es una forma de elevar el tráfico externo de Kubernetes de "suficientemente bueno" a "algo que se parece a un sistema de ingeniería."

💡 Si es tu primera vez con esta pila, no intentes aprender cada CRD de una vez. Instálalo, haz pasar tu primera solicitud, luego revisa los conceptos — la tasa de absorción es mucho más rápida de esa manera.

Siguiente Paso

En el próximo post, nos ponemos manos a la obra — instala Envoy Gateway en tu clúster y ejecuta tu primer Gateway + HTTPRoute: 👉 Quick Start