可观测性实战：快速定位 K8s CNI 端口冲突问题

本文为云杉网络原力释放 - 云原生可观测性分享会第十七期直播实录中的案例三。回看链接，PPT下载。

0x0: 背景介绍

某车企的车控业务访问账户系统时无规律偶发连接超时（connection timeout），本案例分享利用 DeepFlow 深度剖析如何分钟级定位 K8s CNI 的 SNAT (Source Network Address Translation) 触发 Node 节点源端口冲突，导致连接服务端异常。

DeepFlow 分析定位之前，此问题一直为一个悬案，持续了数月无结论：

• 连接超时为偶发问题，无任何规律可言，问题排障找不到抓手
• 除日志中 connection timeout 的报错，其他监控数据一切正常，问题排障找不到依据
• 业务的访问路径比较复杂，涉及、容器、云服务、云网络及跨集群等因素，增加了问题的复杂性和定位难度

01-topo

0x1: 排障过程

step 1：利用 DeepFlow 网络-路径的建连异常指标量，确定存在建连异常情况

根据路径页面中的网络指标数据，发现偶发的建连失败情况和业务报错的时间是一致的。

02-metrics

step 2: 对比 DeepFlow 网络指标曲线 ，确定为客户端建连失败

通过历史曲线对比，可进一步确定建连失败是由于客户端导致的。

03-line

step 3：利用 DeepFlow 流日志，确定异常原因为客户端端口复用导致

通过查看路径对应的流日志，并过滤status=客户端异常，从中发现异常的原因是客户端（46994）端口的复用导致的。

04-flow

对流日志发起 NAT 追踪，发现在 POD 访问 LB (可通过服务端前面的 ICON 识别) 时，经过 K8s CNI 后，在 Node 网卡采集的数据，源 IP 地址已经为 Node 节点的 IP 了，存在 SNAT 情况。

05-

客户端端口复用的计算方法见下图描述：

06-explanation

step 4：使用端口过滤，存在 SNAT 情况，客户端口被其他服务占用

接下来，继续追查是谁导致了客户端端口的复用。将时间前移了一小段时间后，发现在大约 1 分钟前源端口被另一个服务占用。到此问题已经非常明确，因为 K8s CNI 的 SNAT 触发 Node 节点源端口冲突导致了业务连接超时。

07-root

step 5：问题根因

车企中的业务都部署在公有云上，使用的基础设施都是公有云提供的 VPC 及 K8s 集群，通信分大类

• 同集群内部通信：包含 Pod 之间访问、Pod 与 Node 之间访问、Pod 访问 clusterIP 类型的服务等情况，通过 Pod_IP 直接访问
• 集群外通信：包含跨集群通信、访问外部云服务等情况，在 Node 上做 SNAT，使用 Node_IP 访问

默认配置中，对于集群外通信场景都需要在 Node 的 K8s CNI 上做 SNAT，此案例中的车控业务访问的是另一个集群中的账户业务，因此会存在 SNAT 的场景。

08-config

问题确定根因后，与业务部门及容器网络部门都进行了沟通，以最低代价解决问题的思路，最后使用 DeepFlow 的客户端端口复用的指标量的建立告警，对于高频触发端口复用访问，不进行 SNAT，直接使用 Pod 的真实IP进行通信。

0x2: 问题总结

问：DeepFlow 在整个案例的价值点是什么？

• 利用 DeepFlow 零插码的网络指标，分钟级确定建连异常的路径及时间点
• 利用 DeepFlow 零插码的网络流日志，分钟级确定建连异常的根因

0x3: 什么是 DeepFlow

DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

GitHub 地址：https://github.com/deepflowio/deepflow

访问 DeepFlow Demo，体验零插桩、全覆盖、全关联的可观测性。