未触发 Knative Eventing 死信接收器
Knative Eventing Dead Letter Sink Not Triggered
我的序列在我的 Knative 环境中运行。我们正在尝试配置并确认 DLQ/Dead Letter Sink 正常工作,以便我们可以针对序列编写测试和内容。我不能为我的 get Knative 发送任何东西到 Dead Letter Sink。我已经采用两种方法,第一种是设置 Broker、Trigger、Services 和 Sequence。我在 Broker 中定义了一个用于 DLQ 的服务。然后,我按顺序设置一个服务,以故意 returned 非 200 状态。当我在 knative-eventing 命名空间中查看通道调度程序的日志时,我相信我读到的是它认为发生了故障。
我阅读了一些关于默认 MT Broker 可能无法正确处理 DLQ 的信息,所以我安装了 Kafka。明白了所有的工作,基本上,它似乎在做同样的事情。
我开始怀疑,好吧,也许在一个序列中你不能做 DLQ。毕竟 documentation 只讨论订阅和代理的 DLQ,也许 Knative 认为消息已成功从代理传递到序列,即使它在序列中死亡。所以我手动设置频道和订阅并将数据直接发送到频道,我得到的基本上是同一件事,即:
序列将在没有 return 2XX 状态代码的任何步骤停止,但不会向 DLQ 发送任何内容。我什至让订阅直接转到服务(而不是序列)并且该服务 returned 了 500,但仍然没有 DLQ。
下面的日志项来自 knative-eventing 命名空间中的频道调度程序 pod 运行ning。它与 In memory channel 或 Kafka 基本相同,即预期 2xx 得到 500.
{"level":"info","ts":"2021-11-30T16:01:05.313Z","logger":"kafkachannel-dispatcher","caller":"consumer/consumer_handler.go:162","msg":"Failure while handling a message","knative.dev/pod":"kafka-ch-dispatcher-5bb8f84976-rpd87","knative.dev/controller":"knative.dev.eventing-kafka.pkg.channel.consolidated.reconciler.dispatcher.Reconciler","knative.dev/kind":"messaging.knative.dev.KafkaChannel","knative.dev/traceid":"957c394a-1636-44ad-b024-fb0dde9c8440","knative.dev/key":"kafka/test-sequence-kn-sequence-0","topic":"knative-messaging-kafka.kafka.test-sequence-kn-sequence-0","partition":0,"offset":4,"error":"unable to complete request to http://cetf.kafka.svc.cluster.local: unexpected HTTP response, expected 2xx, got 500"}
{"level":"warn","ts":"2021-11-30T16:01:05.313Z","logger":"kafkachannel-dispatcher","caller":"dispatcher/dispatcher.go:314","msg":"Error in consumer group","knative.dev/pod":"kafka-ch-dispatcher-5bb8f84976-rpd87","error":"unable to complete request to http://cetf.kafka.svc.cluster.local: unexpected HTTP response, expected 2xx, got 500"}
设置注意事项。我几乎将所有内容都部署到同一个名称空间进行测试。在执行 broker/trigger 和部署 Kafka 时,我基本上遵循了指南 here 来设置我的代理。我的经纪人看起来像这样:
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
annotations:
# case-sensitive
eventing.knative.dev/broker.class: Kafka
name: default
namespace: kafka
spec:
# Configuration specific to this broker.
config:
apiVersion: v1
kind: ConfigMap
name: kafka-broker-config
namespace: knative-eventing
# Optional dead letter sink, you can specify either:
# - deadLetterSink.ref, which is a reference to a Callable
# - deadLetterSink.uri, which is an absolute URI to a Callable (It can potentially be
out of the Kubernetes cluster)
delivery:
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: dlq
namespace: kafka
当我手动创建订阅和频道时,我的订阅如下所示:
apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
name: test-sub # Name of the Subscription.
namespace: kafka
spec:
channel:
apiVersion: messaging.knative.dev/v1beta1
kind: KafkaChannel
name: test-channel
delivery:
deadLetterSink:
backoffDelay: PT1S
backoffPolicy: linear
retry: 1
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: dlq
namespace: kafka
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: cetf
无论我做什么,我都没有看到 dlq pod 旋转起来。我已经调整了重试内容,等了又等,使用了默认 channel/broker、Kafka 等。我根本看不到 pod 运行。有什么我想念的吗,到底有什么问题?我可以将订户设置为垃圾 URI,然后 DLQ pod 启动,但如果服务将事件发送到 returns 错误代码,它不应该也启动吗?
任何人都可以提供几个非常基本的 YAML 文件来部署最简单的工作 DLQ 版本来进行测试吗?
在正式发布前的版本中没有传播死信接收器存在一些问题。您能确定您使用的是 Knative 1.0 吗?
使用内存通道,这对我来说如预期的那样有效:
https://gist.github.com/odacremolbap/f6ce029caf4fa6fbb3cc1e829f188788
- curl 向代理生成云事件
- DLS 配置为事件显示的代理
- 作为 DLS 接收器的事件显示服务
- 从代理触发到回复服务
- replier 服务(可以根据传入事件进行 ack 和 nack)
我从未在文档中找到这方面的示例,但是 SequenceStep 的 API 文档确实显示了交付 属性。其中,分配时使用 DLQ。
steps:
- ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: service-step
delivery:
# DLS to an event-display service
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: dlq-service
namespace: ns-name
必须为每个步骤指定交付,而不仅仅是整个序列,这似乎很奇怪。
我的序列在我的 Knative 环境中运行。我们正在尝试配置并确认 DLQ/Dead Letter Sink 正常工作,以便我们可以针对序列编写测试和内容。我不能为我的 get Knative 发送任何东西到 Dead Letter Sink。我已经采用两种方法,第一种是设置 Broker、Trigger、Services 和 Sequence。我在 Broker 中定义了一个用于 DLQ 的服务。然后,我按顺序设置一个服务,以故意 returned 非 200 状态。当我在 knative-eventing 命名空间中查看通道调度程序的日志时,我相信我读到的是它认为发生了故障。
我阅读了一些关于默认 MT Broker 可能无法正确处理 DLQ 的信息,所以我安装了 Kafka。明白了所有的工作,基本上,它似乎在做同样的事情。
我开始怀疑,好吧,也许在一个序列中你不能做 DLQ。毕竟 documentation 只讨论订阅和代理的 DLQ,也许 Knative 认为消息已成功从代理传递到序列,即使它在序列中死亡。所以我手动设置频道和订阅并将数据直接发送到频道,我得到的基本上是同一件事,即:
序列将在没有 return 2XX 状态代码的任何步骤停止,但不会向 DLQ 发送任何内容。我什至让订阅直接转到服务(而不是序列)并且该服务 returned 了 500,但仍然没有 DLQ。
下面的日志项来自 knative-eventing 命名空间中的频道调度程序 pod 运行ning。它与 In memory channel 或 Kafka 基本相同,即预期 2xx 得到 500.
{"level":"info","ts":"2021-11-30T16:01:05.313Z","logger":"kafkachannel-dispatcher","caller":"consumer/consumer_handler.go:162","msg":"Failure while handling a message","knative.dev/pod":"kafka-ch-dispatcher-5bb8f84976-rpd87","knative.dev/controller":"knative.dev.eventing-kafka.pkg.channel.consolidated.reconciler.dispatcher.Reconciler","knative.dev/kind":"messaging.knative.dev.KafkaChannel","knative.dev/traceid":"957c394a-1636-44ad-b024-fb0dde9c8440","knative.dev/key":"kafka/test-sequence-kn-sequence-0","topic":"knative-messaging-kafka.kafka.test-sequence-kn-sequence-0","partition":0,"offset":4,"error":"unable to complete request to http://cetf.kafka.svc.cluster.local: unexpected HTTP response, expected 2xx, got 500"}
{"level":"warn","ts":"2021-11-30T16:01:05.313Z","logger":"kafkachannel-dispatcher","caller":"dispatcher/dispatcher.go:314","msg":"Error in consumer group","knative.dev/pod":"kafka-ch-dispatcher-5bb8f84976-rpd87","error":"unable to complete request to http://cetf.kafka.svc.cluster.local: unexpected HTTP response, expected 2xx, got 500"}
设置注意事项。我几乎将所有内容都部署到同一个名称空间进行测试。在执行 broker/trigger 和部署 Kafka 时,我基本上遵循了指南 here 来设置我的代理。我的经纪人看起来像这样:
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
annotations:
# case-sensitive
eventing.knative.dev/broker.class: Kafka
name: default
namespace: kafka
spec:
# Configuration specific to this broker.
config:
apiVersion: v1
kind: ConfigMap
name: kafka-broker-config
namespace: knative-eventing
# Optional dead letter sink, you can specify either:
# - deadLetterSink.ref, which is a reference to a Callable
# - deadLetterSink.uri, which is an absolute URI to a Callable (It can potentially be
out of the Kubernetes cluster)
delivery:
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: dlq
namespace: kafka
当我手动创建订阅和频道时,我的订阅如下所示:
apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
name: test-sub # Name of the Subscription.
namespace: kafka
spec:
channel:
apiVersion: messaging.knative.dev/v1beta1
kind: KafkaChannel
name: test-channel
delivery:
deadLetterSink:
backoffDelay: PT1S
backoffPolicy: linear
retry: 1
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: dlq
namespace: kafka
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: cetf
无论我做什么,我都没有看到 dlq pod 旋转起来。我已经调整了重试内容,等了又等,使用了默认 channel/broker、Kafka 等。我根本看不到 pod 运行。有什么我想念的吗,到底有什么问题?我可以将订户设置为垃圾 URI,然后 DLQ pod 启动,但如果服务将事件发送到 returns 错误代码,它不应该也启动吗?
任何人都可以提供几个非常基本的 YAML 文件来部署最简单的工作 DLQ 版本来进行测试吗?
在正式发布前的版本中没有传播死信接收器存在一些问题。您能确定您使用的是 Knative 1.0 吗?
使用内存通道,这对我来说如预期的那样有效:
https://gist.github.com/odacremolbap/f6ce029caf4fa6fbb3cc1e829f188788
- curl 向代理生成云事件
- DLS 配置为事件显示的代理
- 作为 DLS 接收器的事件显示服务
- 从代理触发到回复服务
- replier 服务(可以根据传入事件进行 ack 和 nack)
我从未在文档中找到这方面的示例,但是 SequenceStep 的 API 文档确实显示了交付 属性。其中,分配时使用 DLQ。
steps:
- ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: service-step
delivery:
# DLS to an event-display service
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: dlq-service
namespace: ns-name
必须为每个步骤指定交付,而不仅仅是整个序列,这似乎很奇怪。