¿Cómo utilizar el filtro de HCM en Enovy Filter?
¡Hola chicos! Quiero distribuir el flujo de salida utilizando HCM, como:
www.xxx.com:8000(sidecar) -> clusterA(egress)
www.yyy.com:8000(sidecar) -> clusterB(egress)
Solicitud REST (sidecar) -> proceso original (egress)
La solicitud de coincidencia puede ser enrutada correctamente, ¿pero qué pasa con la solicitud no coincidente?
Actualmente, la solicitud no coincidente recibe una respuesta 404.
Quiero que la solicitud no coincidente sea procesada en la ruta original.
Entonces, ¿cómo puedo modificar la configuración YAML para lograr este objetivo? ¿Hay alguna mejor práctica?
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: test
namespace: istio-system
spec:
workloadSelector:
labels:
istio: egressgateway
configPatches:
- applyTo: NETWORK_FILTER
match:
context: GATEWAY
listener:
filterChain:
filter:
name: "envoy.filters.network.http_connection_manager"
patch:
operation: REPLACE
value:
name: envoy.filters.network.http_connection_manager
typed_config:
"@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
codec_type: AUTO
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: local_service1
domains: ["www.xxx.com:8000"]
routes:
- match:
prefix: "/"
route:
host_rewrite_literal: www.xxx.com:80
prefix_rewrite: "/"
cluster: "clusterA"
- name: local_service2
domains: ["www.yyy.com:8000"]
routes:
- match:
prefix: "/"
route:
host_rewrite_literal: www.yyy.com:80
prefix_rewrite: "/"
cluster: "clusterB"
http_filters:
- name: envoy.filters.http.router
typed_config:
"@type": "type.googleapis.com/envoy.extensions.filters.http.router.v3.Router"
#... otros configuraciones aquí.
# configuración de cluster
Espero que esto sea útil. ¡Avísame si tienes alguna otra pregunta!
davy.ai
Para modificar la configuración yaml y lograr tu objetivo de procesar solicitudes no coincidentes en la ruta original, puedes agregar un host virtual adicional con un dominio comodín que coincidirá con cualquier solicitud que no haya sido coincidente con los hosts virtuales anteriores. Luego, puedes configurar este host virtual para redirigir al proceso original en lugar de devolver una respuesta 404. Aquí tienes un ejemplo de configuración yaml que logra esto:
En la configuración anterior, hemos agregado un nuevo host virtual llamado “catch_all” con un dominio de “*”. Este dominio comodín coincidirá con cualquier solicitud que no haya sido coincidente con los hosts virtuales anteriores. Luego, configuramos este host virtual para redirigir a un cluster llamado “original_process” en lugar de devolver una respuesta 404. Debes reemplazar “original_process” con el nombre del cluster que representa tu proceso original.
Ten en cuenta que esta configuración asume que ya has definido un cluster para tu proceso original. Si aún no lo has hecho, deberás agregar una definición de cluster a tu configuración yaml que apunte a tu proceso original.