0

我有序列在我的 Knative 环境中工作。我们正在尝试配置并确认 DLQ/Dead Letter Sink 工作正常，以便我们可以针对序列编写测试和事物。我一辈子都无法让 Knative 向死信接收器发送任何内容。我有两种方法，第一种是设置代理、触发器、服务和序列。我在 Broker 中定义了一个用于 DLQ 的服务。然后，我按顺序设置了一项服务，以故意返回非 200 状态。当我在 knative-eventing 命名空间中查看通道调度程序的日志时，我相信我读到的是它认为发生了故障。

我阅读了一些关于默认 MT Broker 可能无法正确处理 DLQ 的内容，因此我安装了 Kafka。得到了所有的工作，基本上，它似乎做同样的事情。

我开始怀疑，好吧，也许在你不能做 DLQ 的序列中。毕竟文档只讨论了订阅和代理的 DLQ，也许 Knative 认为消息已成功从代理传递到序列，即使它在序列内死亡。所以我手动设置频道和订阅，然后将数据直接发送到频道，我得到的基本上是一样的，那就是：

序列将在任何不返回 2XX 状态代码的步骤上停止，但不会向 DLQ 发送任何内容。我什至让订阅直接转到服务（而不是序列），该服务返回 500，但对 DLQ 仍然没有。

下面的日志项来自在 knative-eventing 命名空间中运行的通道调度程序 pod。它与 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"}

设置注意事项。我将所有内容部署到同一个名称空间进行测试。在执行代理/触发器和部署 Kafka 时，我基本上遵循了此处的指南来设置我的代理。我的经纪人看起来像这样：

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 吊舱旋转起来。我已经调整了重试的东西，等待了又等待，使用了默认的通道/代理、Kafka 等。我根本看不到 pod 曾经运行过。有什么我想念的吗，到底有什么问题？我可以将订阅者设置为垃圾 URI，然后 DLQ pod 启动，但如果它发送事件的服务返回错误代码，它不应该也启动吗？

任何人都可以提供几个非常基本的 YAML 文件来部署最简单的工作 DLQ 版本来进行测试吗？

4

2 回答 2

0

在 GA 之前的版本中没有传播死信接收器存在一些问题。你能确定你使用的是 Knative 1.0 吗？

使用内存通道，这对我有用：

https://gist.github.com/odacremolbap/f6ce029caf4fa6fbb3cc1e829f188788

  • curl 向代理生成云事件
  • 将 DLS 配置为事件显示的代理
  • 作为 DLS 接收器的事件显示服务
  • 从代理触发到回复服务
  • 回复服务（可以根据传入的事件进行确认和确认）
于 2021-11-30T18:05:14.637 回答
0

我从未在文档中找到这样的示例，但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

必须为每个步骤指定交付，而不仅仅是整个序列，这似乎很奇怪。

于 2021-12-01T15:47:10.690 回答