0

我有以下设置（如附图所示）：

A（java 进程）-> B（kubernetes 大使代理）-> C（kubernetes pod 中的 java 服务）

A 和 B 之间使用 HTTPS 进行通信，然后大使剥离 HTTPS 并继续与 C 进行 HTTP 通信。

我遇到的问题是，有时，正在发送的 HTTP BODY 消息未在 A 和 B 之间 100% 传输，但仅在 B 端跟踪我可以看到它由于某种原因停止了（在 A 上的跟踪中）侧显示为一切都已发送好）。然后，C 中的 java 进程（正在等待 B-pr​​oxy 转发所有数据）只是等待并在 30 秒后超时。

您可以在所附图像中看到，在 A 跟踪中写入了整个 BODY 已发送，但在 B 侧的跟踪中，只有一半 BODY 可见（已交付）。我怀疑这些TCP Previous segment not captured。

您还可以看到，在此之后它只等待 30 秒，然后超时。

它在我的设置中经常发生。有谁知道可能是什么问题？

在此处输入图像描述

大使配置：

getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: TLSContext
      name: tls
      ambassador_id: some-stg
      secret: ambassador-tls-cert
      ---
      apiVersion: ambassador/v1
      kind: Module
      name: ambassador
      ambassador_id: some-stg
      config:
        service_port: 8443
        diagnostics:
          enabled: true
        envoy_log_type: json

      ---
      apiVersion: ambassador/v1
      kind: Module
      name: tls
      ambassador_id: some-stg
      config:
        server:
          enabled: True
          redirect_cleartext_from: 8080
          alpn_protocols: "h2, http/1.1"
          secret: ambassador-tls-cert
      ---
      apiVersion: ambassador/v1
      kind: TracingService
      name: tracing
      service: tracing-jaeger-collector.tracing:9411
      driver: zipkin
      ambassador_id: some-stg
      tag_headers:
        - :authority
        - :path

更新

这里还有关于 cloudshark 的踪迹： A 转储（发送方 - Kubernetes 外部）：https : //www.cloudshark.org/captures/8cfad383c8fb B 转储（kubernetes 大使代理接收器）：https ://www.cloudshark.org/captures /50512920d898

4

2 回答 2

0

Previous segment not captured确切地说，tcp流中的一个段没有被捕获，这是由tcp序列号决定的。如果初始连接发生在捕获之前，则通常在捕获开始时发生，如果捕获主机丢弃了数据包，或者如果存在实际数据包丢失，也会发生这种情况。

此外，始终通过将 ACK 号设置为接收到的有效载荷的最后一个字节来指示数据包丢失。因此，如果有任何东西丢失，ACK 号将停留在最后一个成功的字节上，无论有多少数据包通过。仅当重传到达时才增加 ACK。

发生忽略的未知记录是因为 TLS 解析器不理解数据。在您的情况下，这可能是由于 tcp 段丢失。

注意TCP segment of a reassembled PDU声明。

Wireshark 认为它知道在那个 TCP 段的 TCP 上运行什么协议。该 TCP 段不包含该高级协议的所有“协议数据单元”（PDU），即该高级协议的数据包或协议消息，并且不包含该 PDU 的最后部分，所以它试图重新组装包含更高级别 PDU 的多个 TCP 段。例如，在大多数网络中，包含大量数据的 HTTP 响应不适合单个 TCP 段，因此它将被拆分为多个 TCP 段；除了最后一个 TCP 段之外的所有段都将被标记为TCP segment of a reassembled PDU.

还要看看debug-service：

  • kube 代理是否正常工作

  • 检查iptables

使 pod 能够控制 Kubernetes 中的另一个部署需要什么？

然后确保您已按照这些步骤tls-ambassador特别是创建证书并存储它。

有用的文档：TCP 分析。

于 2019-12-12T12:18:16.730 回答
0

我的同事似乎发现了问题所在。在这个大使 pod 前面有一个 AWS 负载均衡器，当他重新创建它时 - 它现在似乎可以正常工作了。我猜想有人向客户端（A）发送了 ACK，但没有将所有消息传递给大使吊舱（B）。他重新创建了不同类型（NLB）的负载均衡器，因为经典的负载均衡器不起作用。

于 2019-12-16T08:45:58.270 回答