Inicio Rápido de Envoy Gateway: Haz Pasar Tu Primera Solicitud en 10 Minutos

El objetivo de este post es simple: omite la filosofía, simplemente pon Envoy Gateway en marcha. Si logras llegar al servicio de ejemplo con éxito, ya has hecho más que todos los que siguen atascados en la página de inicio de la documentación.

Requisitos Previos

Necesitas al menos un clúster de Kubernetes funcionando, como:

• Local: kind, minikube, k3d
• Cloud: EKS, GKE, AKS
• Laboratorio casero: K3s + MetalLB también funciona

También necesitarás:

• kubectl
• helm
• Un clúster que pueda aprovisionar una dirección LoadBalancer, o uno donde estés bien usando port-forward

⚠️ Si tu clúster no tiene soporte de LoadBalancer, la documentación oficial recomienda combinarlo con MetalLB. No tener una dirección externa no es el fin del mundo — simplemente harás las pruebas vía port-forward.

Paso 1: Instalar Envoy Gateway

Instala el plano de control:

helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.7.0 \
  -n envoy-gateway-system \
  --create-namespace

Espera a que esté listo:

kubectl wait --timeout=5m -n envoy-gateway-system \
  deployment/envoy-gateway \
  --for=condition=Available

Una vez que esto se complete, el controlador de Envoy Gateway está corriendo en tu clúster. Ahora puede leer recursos de Gateway API y generar la configuración de Envoy correspondiente.

Paso 2: Aplicar los Recursos de Inicio Rápido Oficiales

El repositorio oficial proporciona un ejemplo empaquetado que incluye:

• GatewayClass
• Gateway
• HTTPRoute
• Una aplicación de backend de muestra

Aplícalo directamente:

kubectl apply -f \
  https://github.com/envoyproxy/gateway/releases/download/v1.7.0/quickstart.yaml \
  -n default

Piensa en esto como el equipo oficial preparando una escena de demostración completa para ti. Ponlo en marcha primero, luego desármalo después.

Paso 3: Verificar Que el Tráfico Fluye

Opción A: El Clúster Tiene un LoadBalancer

Obtén la dirección del Gateway:

export GATEWAY_HOST=$(kubectl get gateway/eg -o jsonpath='{.status.addresses[0].value}')

Envía una solicitud:

curl --verbose \
  --header "Host: www.example.com" \
  http://$GATEWAY_HOST/get

Si obtienes un HTTP 200, significa que:

• El Gateway está funcionando como ingreso activo
• El HTTPRoute se ha adjuntado correctamente
• El servicio de backend está siendo enrutado correctamente

Opción B: Sin LoadBalancer — Usa Port-Forward

Encuentra el servicio de Envoy:

export ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system \
  --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg \
  -o jsonpath='{.items[0].metadata.name}')

Reenvía el puerto local 8888 al puerto 80 del Gateway:

kubectl -n envoy-gateway-system port-forward service/${ENVOY_SERVICE} 8888:80

En otra terminal:

curl --verbose \
  --header "Host: www.example.com" \
  http://localhost:8888/get

Este es el camino de prueba local. Se siente un poco como entrar por la puerta trasera, pero si valida el enrutamiento, está bien — a veces la ingeniería es "hacer que funcione primero, luego hacerlo elegante."

Dónde Mirar Cuando Algo Falla

Los problemas más comunes no son que Envoy Gateway esté roto — es que un segmento de la cadena no se conectó:

Comandos útiles:

kubectl get pods -n envoy-gateway-system
kubectl get gatewayclass
kubectl get gateway -A
kubectl get httproute -A
kubectl get svc,pod -n default

Para profundizar en el estado del Gateway:

kubectl get gateway/eg -o yaml

Cosas clave a verificar:

• status.addresses
• Condiciones del Listener
• Si las rutas fueron aceptadas

Lo Que Acabas de Hacer Realmente

Solo ejecutaste unos pocos comandos, pero completaste toda una cadena de extremo a extremo:

1. Instalaste Envoy Gateway
2. Creaste un GatewayClass para indicarle al clúster qué controlador de gateway usar
3. Creaste un Gateway declarando el puerto y protocolo de ingreso
4. Creaste un HTTPRoute enrutando el tráfico al servicio de backend
5. Envoy Gateway tradujo estas declaraciones en configuración que Envoy Proxy puede ejecutar

Esto es exactamente por qué Gateway API vale la pena usar. Escribes recursos de Kubernetes — no mantienes un montón de archivos de configuración de proxy a mano.

Siguiente Paso

Ahora que tienes tu primera solicitud fluyendo, el próximo post cubre qué hace cada uno de estos recursos en realidad — construyendo el modelo mental: 👉 Core Concepts