Buenas Prácticas de Envoy Gateway: Hazle un Favor a tu Yo del Futuro Antes de Ir a Producción

"Funciona" y "el sistema es realmente estable" son dos universos completamente distintos. La mayoría de los incidentes en la capa de ingress no son causados por una insuficiencia de Envoy Gateway — son causados por configuraciones establecidas de forma demasiado descuidada, convirtiendo las operaciones en una caja de sorpresas permanente. Este post compila las recomendaciones más prácticas en una lista de verificación.

Prácticas Recomendadas

1. Deja Claro Quién es Dueño del Gateway y Quién es Dueño de las Rutas

Si hay múltiples personas involucradas, divide las responsabilidades:

El equipo de plataforma gestiona GatewayClass, Gateway
Los equipos de aplicación gestionan sus propios HTTPRoute

El beneficio: la superficie de seguridad y exposición de la capa de ingress no queda sujeta a modificaciones aleatorias por parte de cada aplicación que llega, mientras los equipos de aplicación conservan la flexibilidad de routing. Exactamente por eso vale la pena usar el diseño de Gateway API — no lo aplanes de vuelta en un blob YAML monolítico.

2. Trata TLS como el Valor por Defecto desde el Principio

No pienses "primero HTTP, agrego HTTPS después." Ese "después" casi siempre termina en una emergencia de viernes por la noche.

Como mínimo:

Los listeners externos usan HTTPS por defecto
Las fuentes de certificados tienen un proceso de gestión definido
Los flujos de prueba, autofirmado y CA de producción se mantienen separados

Si ya tienes cert-manager, intégralo. La rotación automática de certificados es mucho más confiable que parchear Secrets manualmente en cada ciclo de renovación.

3. Escribe las Reglas de Ruta de Forma Explícita — No Sacrifiques Claridad por Conveniencia

Reglas como esta son convenientes pero tienden a convertirse en agujeros negros:

rules:
  - backendRefs:
      - name: backend
        port: 8080

No está mal — pero a medida que el sistema crece, demasiadas reglas de "captura todo" hacen que el debugging sea doloroso. Si puedes escribir hostnames, si puedes escribir path, escríbelos con claridad.

4. Usa Cortes de Tráfico Pequeños — No Cambies Todo de Golpe

Al lanzar una nueva versión, corta primero un pequeño porcentaje del tráfico:

backendRefs:
  - name: api-v1
    port: 8080
    weight: 90
  - name: api-v2
    port: 8080
    weight: 10

Esto es mucho más suave que "cambiar el selector completo del servicio de una vez." Cuando algo sale mal, hacer rollback también es mucho más rápido — a las 3 de la madrugada, estarás muy agradecido por esto.

5. Construye el Hábito de Revisar `status` y Eventos

Solo leer YAML no es suficiente — necesitas ver si el controlador realmente aceptó tu configuración:

kubectl get gateway -A
kubectl get httproute -A
kubectl describe gateway eg
kubectl describe httproute app-route

Estas categorías de problemas a menudo no se pueden detectar solo desde spec:

Ruta no aceptada
Referencia entre namespaces bloqueada
Anomalías en el estado del listener

Lo peor no es un bug — es "pensé que había tomado efecto, pero nunca fue procesado."

Errores Comunes

Error 1: Tratar Envoy Gateway como una Caja Negra de Reenvío Pasivo

No solo mueve paquetes de A a B. La documentación oficial lo posiciona explícitamente como un API Gateway nativo de Kubernetes con espacio para agregar más políticas de tráfico y seguridad. Si solo lo usas como un reemplazo de Ingress, estás desaprovechando enormemente sus capacidades.

Error 2: Referenciar Certificados Entre Namespaces sin `ReferenceGrant`

Mucha gente ve que certificateRefs soporta un campo namespace y apunta directamente a otro namespace, luego se pregunta por qué nada funciona. La respuesta generalmente no es un misterio — es un ReferenceGrant faltante.

Error 3: Probar Solo el Camino Feliz

No solo pruebes:

curl http://... funciona una vez

También prueba:

Diferentes hostnames
Diferentes paths
Validez del certificado TLS
Si los ratios de división de tráfico se comportan como se espera

La capa de ingress es más peligrosa cuando los caminos felices parecen perfectos pero los casos borde fallan de inmediato.

Error 4: Usar la Configuración del Demo Directamente en Producción

El quickstart oficial es excelente para aprender, pero está pensado como un quickstart. Para producción, agrega como mínimo:

Automatización de certificados
Monitoreo y alertas
Proceso de gestión de cambios
Convenciones de nombres para rutas

De lo contrario, el quickstart de hoy se convierte en el quick-fail de mañana.

Una Lista de Verificación Mínima Antes del Lanzamiento

Usa esto antes de salir a producción:

¿El listener del Gateway separa claramente HTTP / HTTPS?
¿Están bien definidos el Secret del certificado y el proceso de rotación?
¿Tiene el HTTPRoute hostnames / matches claros?
¿Los cambios significativos se despliegan usando cortes pequeños de tráfico?
¿Puedes localizar problemas rápidamente desde status y eventos?

Si los cinco están en orden, ya estás operando a un nivel más alto que "funciona, así que está bien."

Resumen en Una Línea

El valor real de Envoy Gateway no es solo enrutar tráfico — es hacer que la configuración de tu capa de ingress sea más estandarizada, divisible y gobernable. Las funcionalidades son temporales; las operaciones son a largo plazo. Ser amable con tu yo del futuro realmente importa.

Siguiente Paso

Si todavía tienes esta pregunta en el fondo de tu mente:

"Lo entiendo conceptualmente, pero cuando llega un nuevo requerimiento, ¿qué tipo de ruta elijo realmente?"

El siguiente post es tu cheatsheet: 👉 Cheatsheet de Tipos de Ruta