未触发死信库

Question

我发现序列在我的本地环境中工作。我们正在尝试配置和确认DLQ/死信水槽的工作，这样我们就可以针对序列编写测试和东西。我不能为了我的生命，让基恩寄任何东西到死信水槽。我使用了两种方法，第一种是设置代理、触发器、服务和序列。我在代理中定义了用于DLQ的服务。然后，我在序列中设置了一个服务，以有意返回一个非200状态。当我在关联事件命名空间中查看通道调度程序的日志时，我相信我所读到的是它认为有一个失败。

我读了一些关于默认MT代理的东西，可能没有正确地处理DLQ，所以我安装了Kafka。这一切都在起作用，本质上，它似乎是在做同样的事情。

我开始怀疑，好吧，也许在一个序列中你不能做DLQ。毕竟，文档只与订阅和代理讨论DLQ，而且可能dies认为消息已经成功地从代理传递到序列，即使它在序列中死亡。因此，我手动设置了通道和订阅，并将数据直接发送到通道，然后，我得到的基本上是相同的东西，即：

无论哪一步没有返回2XX状态代码，序列都会停止，但是没有任何东西被发送到DLQ。我甚至让订阅直接进入服务(而不是序列)，该服务向DLQ返回了一个500，但仍然什么也没有。

下面的日志项来自运行在编织事件命名空间中的通道调度程序荚。它与内存通道或卡夫卡的外观基本相同，即预期的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

不管我做什么，我从来没见过吊舱旋转。我调整了重试的内容，等待和等待，使用默认的频道/经纪人，卡夫卡，等等。我根本看不见吊舱的运行。我是不是错过了什么，到底是怎么回事？我可以将订阅服务器设置为一个垃圾URI，然后DLQ结荚就会加速，但是如果它发送事件的服务返回错误代码，它不应该也旋转吗？

有人能提供几个非常基本的YAML文件来部署最简单的DLQ版本来进行测试吗？

Answer 1

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

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

Answer 2

有一些问题，死信沉没没有被宣传在前GA发行。您能确保您使用的是K本地1.0吗？

正如我所期望的那样，使用内存中的通道可以实现这一点：

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

• 向代理生成云事件的curl
• 将DLS配置为事件显示的代理。
• 事件显示服务作为DLS接收器
• 从代理触发到应答服务。
• 应答服务(根据传入事件的不同，可以进行攻击和nack )