En pocas palabras
Gateway de APIs con configuración dinámica y plugins para tráfico, seguridad y observabilidad.
Qué problema resuelve
Reglas de acceso y enrutamiento dispersas entre servicios o difíciles de actualizar.
Cuándo utilizarlo
Microservicios y Kubernetes. Ejemplo: autenticar peticiones y aplicar límites por consumidor.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
En el Radar compartido: Trial (valoración de la edición aportada).
Cómo funciona
Basado en OpenResty, combina rutas y plugins con un plano de control dinámico; la configuración tradicional utiliza etcd. Puede integrarse con Kubernetes mediante sus controladores.
Ejemplo de uso
Crear una ruta /pedidos hacia el servicio interno, añadir validación de identidad y limitar peticiones. Publicar métricas para detectar rechazos, latencia y errores del upstream.
Arquitectura
| Plano | Componente | Función |
|---|---|---|
| Datos | Nodos APISIX (Nginx + LuaJIT) | Reciben el tráfico y ejecutan plugins |
| Control | etcd + Admin API | Almacenan y distribuyen rutas y configuración |
| Gestión | Dashboard, ingress controller, ADC | Interfaz y declaración de configuración |
Los cambios se propagan a los nodos en milisegundos sin recargar procesos. En modo standalone la configuración se lee de un archivo YAML, sin etcd, lo que encaja con GitOps.
Ejemplo: ruta con autenticación y límite
curl http://127.0.0.1:9180/apisix/admin/routes/pedidos \
-H "X-API-KEY: $ADMIN_KEY" -X PUT -d '{
"uri": "/pedidos/*",
"plugins": {
"openid-connect": {
"discovery": "https://idp.example.com/.well-known/openid-configuration",
"client_id": "gateway",
"client_secret": "<secreto>",
"bearer_only": true
},
"limit-count": {
"count": 100, "time_window": 60,
"key_type": "var", "key": "consumer_name",
"rejected_code": 429
},
"prometheus": {}
},
"upstream": { "type": "roundrobin", "nodes": { "pedidos.svc:8080": 1 } }
}'
Plugins frecuentes
| Categoría | Plugins |
|---|---|
| Autenticación | key-auth, jwt-auth, openid-connect, basic-auth, hmac-auth |
| Tráfico | limit-count, limit-req, limit-conn, traffic-split (canary), proxy-mirror |
| Seguridad | ip-restriction, cors, csrf, ua-restriction |
| Transformación | proxy-rewrite, response-rewrite, grpc-transcode |
| Observabilidad | prometheus, opentelemetry, http-logger, kafka-logger |
| IA | Plugins de proxy hacia LLM, límites de tokens y balanceo entre proveedores |
Los plugins propios se escriben en Lua o, mediante plugin runners, en Go, Java o Python; también se admite Wasm.
APISIX frente a alternativas
| Gateway | Rasgos |
|---|---|
| Kong | Ecosistema amplio, también sobre Nginx/OpenResty |
| Envoy Gateway / Istio | Basados en Envoy, nativos de Kubernetes y Gateway API |
| Gateways gestionados (Apigee, API Gateway de la nube) | Sin operación propia, menos flexibilidad |
| APISIX | Configuración dinámica, alto rendimiento, open source de la Apache Software Foundation |
Operación
Protege la Admin API (red interna, clave rotada, nunca expuesta). Alta disponibilidad de etcd con al menos tres nodos. Exporta métricas por ruta y upstream, y aplica los patrones de resiliencia (timeouts, reintentos, health checks del upstream) en el propio gateway.
Criterios de implementación
Probar cambios de rutas sin interrumpir tráfico y dimensionar el plano de datos. Verificar soporte del controlador y de Gateway API para la versión desplegada.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.