Knative Eventing con el Sink de Correo No Entregado No Fue Disparado.
Tengo secuencias funcionando en mi entorno de Knative. Estamos intentando configurar y confirmar que el DLQ/Dead Letter Sink funcione para que podamos escribir pruebas y cosas contra secuencias. No puedo conseguir que Knative mande nada al Dead Letter Sink. He abordado esto de dos maneras, la primera fue configurar un Broker, un Trigger, Servicios y una Secuencia. En el Broker he definido un servicio para usar con el DLQ. Luego configuré un servicio en la secuencia para que devolviera intencionalmente un estado que no fuera 200. Cuando veo los registros del canal dispatcher en el espacio de nombres knative-eventing, creo que lo que leo es que piensa que hubo un fallo.
Leí algunas cosas sobre el Broker MT predeterminado tal vez no manejando correctamente el DLQ, así que instalé Kafka. Conseguí que todo funcionara y esencialmente, parece que hace lo mismo.
Empecé a preguntarme, vale, tal vez dentro de una secuencia no se pueda hacer el DLQ. Después de todo, la documentación solo habla del DLQ con suscripciones y brokers, y tal vez Knative cree que el mensaje fue entregado correctamente desde el broker a la secuencia, incluso si falla dentro de esta. Así que configuré manualmente un canal y una suscripción y envié los datos directamente al canal y de nuevo, lo que obtuve fue esencialmente lo mismo:
La secuencia se detendrá en cualquier paso que no devuelva un código de estado 2XX, pero nada se envía al DLQ. Incluso hice que la suscripción fuera directamente al servicio (en lugar de una secuencia) y ese servicio devolvió un 500 y aún así nada al DLQ.
El siguiente registro es del pod del canal dispatcher que se ejecuta en el espacio de nombres knative-eventing. Básicamente se ve igual con canal en memoria o con Kafka, es decir, se esperaba un 2xx y se recibió un 500.
Notas sobre la configuración. Desplegué literalmente todo en el mismo espacio de nombres para hacer pruebas. Seguí la guía aquí esencialmente para configurar mi broker cuando hice el broker/trigger y para desplegar Kafka. Mi broker se veía así:
Cuando creé manualmente la suscripción y el canal, mi suscripción se veía así:
No importa lo que haga, NUNCA veo a la pod dlq encender. He ajustado cosas de reintentos, esperé y esperé, usé el canal/broker por defecto, Kafka, etc. Simplemente no puedo ver a la pod ejecutándose nunca. ¿Hay algo que me falte, qué demonios podría estar mal? Puedo configurar el suscriptor para que sea una URI falsa, y luego se ejecuta la pod DLQ, pero ¿no debería ejecutarse también si el servicio al que envía eventos devuelve códigos de error?
¿Podría alguien proporcionar un par de archivos YAML muy básicos para desplegar la versión más simple de un DLQ funcionando para hacer pruebas?
davy.ai
Parece que el problema podría estar en la configuración de su sink de lettera muerta.
En primer lugar, es importante tener en cuenta que DLQ solo funciona con suscripciones y brokers, no con secuencias. Esto se debe a que el broker o la suscripción es responsable de enviar el evento al destino, y si la entrega falla, entonces puede usar DLQ para manejar la entrega fallida. En una secuencia, cada paso es responsable de su propia entrega, por lo que no hay un punto central para manejar una entrega fallida.
Suponiendo que esté utilizando una suscripción, deberá asegurarse de que el deadLetterSink esté configurado correctamente en el archivo YAML de la suscripción. Aquí hay un ejemplo:
``apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
name: my-subscription
namespace: my-namespace
spec:
channel:
apiVersion: messaging.knative.dev/v1beta1
kind: InMemoryChannel
name: my-channel
entrega:
deadLetterSink:
backoffDelay: PT1S
backoffPolicy: linear
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: my-dlq-service
namespace: my-namespace
suscriptor:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: my-service
namespace: my-namespace
En este ejemplo, estamos usando un canal en memoria (puede cambiar esto por un KafkaChannel si lo prefiere) y hemos especificado un deadLetterSink que hace referencia a un servicio llamado my-dlq-service en el mismo espacio de nombres. Asegúrese de que el servicio al que hace referencia en el deadLetterSink tenga un nombre y espacio de nombres coincidentes.
También deberá asegurarse de que el servicio que especifique en el deadLetterSink pueda recibir los mensajes fallidos. Si no se está ejecutando o no se configura correctamente, los mensajes no irán a ninguna parte.
Por último, si aún tiene problemas para hacer que DLQ funcione, es posible que desee intentar configurar un escenario de prueba simple para asegurarse de que todo funcione como se espera. Aquí hay un archivo YAML de ejemplo para crear una prueba DLQ simple:
“ `
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: my-test-service
namespace: my-namespace
spec:
molde:
especies:
contenedores:
– name: mi contenedor
image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display
tráfico:
– revisionName: my-test-service
porcentaje: 100
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
name: my-test-broker
namespace: my-namespace
spec:
config:
apiVersion: v1
kind: ConfigMap
name: config-kafka
namespace: knative-eventing
entrega:
deadLetterSink:
backoffDelay: PT1S
backoffPolicy: linear
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: my-dlq-service
namespace: my-namespace
apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
name: my-test-subscription
namespace: my-namespace
spec:
channel:
apiVersion: messaging.knative.dev/v1beta1
kind: InMemoryChannel
name: my-test-channel
entrega:
deadLetterSink:
backoffDelay: PT1S
backoffPolicy: linear
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: my-dlq-service
namespace: my-namespace
suscriptor:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: my-test-service
namespace: my-namespace
“ `
Esto creará un broker, una suscripción y un servicio simple que solo muestra el evento que recibe. Deberá asegurarse de que el servicio ‘dlq-service’ esté configurado correctamente, pero una vez que lo tenga en ejecución, puede probar DLQ rompiendo deliberadamente el servicio (por ejemplo, devolviendo un código de estado no 200). Debería ver el evento fallido aparecer en DLQ, que luego puede procesar según sea necesario.