使用高级容器网络服务诊断和解决网络问题

本指南可帮助你导航用作解决 Azure Kubernetes 服务 (AKS) 中真实网络用例的主要解决方案的高级容器网络服务 (ACNS)。 无论是排查 DNS 解决问题、优化入口和出口流量，还是确保符合网络策略，本手册演示如何利用 ACNS 可观测性仪表板、 容器网络日志、 容器网络指标和可视化工具有效诊断和解决问题。

高级容器网络服务是Microsoft全面的企业级网络可观测性和安全性平台 ，提供用于监视、分析和排查 AKS 群集中的网络流量的最高级功能。 它包括预构建的 Grafana 仪表板、实时指标、详细日志和 AI 支持的见解，可帮助你深入了解网络性能、快速识别问题，以及通过完全Microsoft支持优化容器网络环境。

高级容器网络服务仪表板概述

我们创建了高级容器网络服务的示例仪表板，可帮助你可视化和分析 Kubernetes 群集中的网络流量、DNS 请求和数据包丢弃。 这些仪表板旨在提供对网络性能的见解、识别潜在问题并帮助进行故障排除。 若要了解如何设置这些仪表板，请参阅 为 Azure Kubernetes 服务 （AKS） 设置容器网络可观测性 - Azure 托管 Prometheus 和 Grafana。

仪表板套件包括：

• 流日志：显示 Pod、命名空间和外部终结点之间的网络流量流。
• 流日志（外部流量）：显示 Pod 与外部终结点之间的网络流量流。
• 群集：显示群集的节点级指标。
• DNS （群集）：显示群集上的 DNS 指标或节点选择。
• DNS（工作负载）：显示指定工作负载的 DNS 指标，例如 DaemonSet 的 Pod 或 CoreDNS 这样的部署。
• 丢弃(工作负载)：显示传入/传出指定工作负载（例如部署或 DaemonSet 的 Pod）的丢弃。
• Pod 流（命名空间）：显示传入/传出指定命名空间（即命名空间中的 Pod）的 L4/L7 数据包流。
• Pod 流(工作负载)：显示传入/传送出指定工作负载（例如部署或 DaemonSet 的 Pod）的第 4 层/第 7 层数据包流。
• L7 流（命名空间）：应用基于第 7 层的策略时，显示从指定命名空间（即命名空间中的 Pod）传入/传出 HTTP、Kafka 和 gRPC 数据包流。 这仅适用于具有 Cilium 数据平面的群集。
• L7 流（工作负荷）：显示应用基于第 7 层的策略时，HTTP、Kafka 和 gRPC 流向/流出指定工作负荷（例如部署或 DaemonSet 的 Pod）。 这仅适用于具有 Cilium 数据平面的群集。

用例 1：解释域名服务器 (DNS) 问题以进行根本原因分析 (RCA)

Pod 级别的 DNS 问题可能会导致服务发现失败、应用程序响应缓慢或 Pod 之间的通信失败。 这些问题通常来自配置错误的 DNS 策略、有限的查询容量或解决外部域的延迟。 例如，如果 CoreDNS 服务过载或上游 DNS 服务器停止响应，则可能会导致从属 Pod 发生故障。 解决这些问题不仅需要识别，还需要深入了解群集中的 DNS 行为。

假设已在 AKS 群集中设置 Web 应用程序，现在 Web 应用程序无法访问。 当 DNS 服务器解析 Web 应用程序的地址时，你将收到 DNS 错误，例如 DNS_PROBE_FINISHED_NXDOMAIN 或 SERVFAIL。

步骤 1：查看 Grafana 仪表板中的 DNS 指标

我们已经创建了两个用于分析 DNS 指标、请求和响应的 DNS 仪表板：DNS（群集），显示群集或节点选择的 DNS 指标，以及 DNS（工作负载），显示特定工作负载（例如 DaemonSet 或 CoreDNS 的 Pod）的 DNS 指标。

1. 检查 DNS 群集 仪表板以获取所有 DNS 活动的快照。 此仪表板提供 DNS 请求和响应的高级概述，例如缺少响应的查询类型、最常见的查询和最常见的响应。 它还突出显示了最常见的 DNS 错误和生成大部分错误的节点。

   

2. 向下滚动以找出所有命名空间中具有大多数 DNS 请求和错误的 Pod。

   

   确定导致大多数 DNS 问题的 Pod 后，可以进一步深入了解 DNS 工作负荷 仪表板，以获取更精细的视图。 通过在仪表板内的各个面板上关联数据，可以系统地缩小问题的根本原因。

3. DNS 请求和 DNS 响应部分允许识别趋势，例如响应速率突然下降或缺少响应的增加。 高请求缺失响应百分比表示潜在的上游 DNS 服务器问题或查询重载。 在示例仪表板的以下屏幕截图中，可以看到请求和响应在 15.22 左右突然增加。

   

4. 按类型检查 DNS 错误，并检查特定错误类型中的峰值（例如，不存在的域的 NXDOMAIN）。 在此示例中，查询拒绝错误显著增加，表明 DNS 配置不匹配或查询不受支持。

   

5. 使用“返回的 DNS 响应 IP”等部分来确保正在处理预期的响应。 此图显示每秒处理成功的 DNS 查询速率。 此信息有助于了解为指定工作负荷成功解析 DNS 查询的频率。

   • 增加的速率可能表示流量激增或潜在的 DNS 攻击（例如分布式拒绝服务（DDoS）。
   • 速率降低可能表示到外部 DNS 服务器的连接出现问题、CoreDNS 配置问题，或 CoreDNS 无法访问某些工作负载。

   

6. 检查最常见的 DNS 查询有助于识别网络流量中的模式。 此信息可用于了解工作负荷分布以及检测任何可能需要注意的异常或意外查询行为。

   

7. DNS 响应表通过突出显示查询类型、响应和错误代码（如 SERVFAIL（服务器故障）来帮助解决 DNS 问题的根本原因分析。 它标识有问题的查询、失败模式或配置错误。 通过观察返回代码和响应速率的趋势，可以查明导致 DNS 中断或异常的特定节点、工作负荷或查询。

   以下示例中对于 AAAA (IPV6) 记录没有错误，但 A (IPV4) 记录出现了服务器故障。 有时，DNS 服务器可能会配置为将 IPv6 优先于 IPv4。 这可能会导致 IPv6 地址正确返回，但 IPv4 地址出现问题。

   

8. 当它确认存在 DNS 问题时，下图标识了导致特定工作负荷或命名空间中的 DNS 错误的前十个终结点。 可以使用此选项确定特定终结点的优先级、检测配置错误或调查网络问题。

   

步骤 2：分析容器网络日志的 DNS 解析问题

1. 容器网络日志提供有关 DNS 查询及其响应的详细见解，包括存储和按需模式。 使用容器网络日志，可以分析特定 Pod 的 DNS 相关流量，其中显示了 DNS 查询、响应、错误代码和延迟等详细信息。 若要查看 Log Analytics 工作区中的 DNS 流，请使用以下 KQL 查询：

   RetinaNetworkFlowLogs
   | where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
   | where Layer4.UDP.destination_port == 53
   | where Layer7.type == "REQUEST" 
   | where Reply == false or isnull(Reply)
   | project TimeGenerated, SourcePodName, DestinationPodName, Layer7.dns.query, Layer7.dns.qtypes, Verdict, TrafficDirection, AdditionalFlowData.Summary, NodeName, SourceNamespace, DestinationNamespace
   | order by TimeGenerated desc
   

   将 <start-time> 和 <end-time> 替换为所需的时间范围，其格式为 2025-08-12T00:00:00Z。

   容器网络日志提供对 DNS 查询及其响应的全面见解，这有助于诊断和排查 DNS 相关问题。 每个日志条目都包含查询类型（例如 A 或 AAAA）、查询域名、DNS 响应代码（例如查询拒绝、不存在域或服务器故障）以及 DNS 请求的源和目标等信息。

2. 确定查询状态：检查“裁定”字段以获取诸如 DROPPED 或 FORWARDED 等响应，这表示网络连接或策略强制实施存在问题。

3. 验证源和目标：确保 SourcePodName 和 DestinationPodName 字段中列出的 Pod 名称正确，并且通信路径应为预期。

4. 跟踪流量模式：查看 “判决 ”字段，了解请求是转发还是已删除。 转发中断可能表示网络或配置问题。

5. 分析时间戳：使用 TimeGenerated 字段将特定 DNS 问题与系统中的其他事件相关联，以便进行全面的诊断。

6. 按 Pod 和命名空间进行筛选：使用 SourcePodName、DestinationPodName 和 SourceNamespace 等字段专注于遇到问题的特定工作负荷。

步骤 3：使用容器网络日志仪表板可视化 DNS 流量

容器网络日志通过 Azure 门户仪表板和 Azure 托管 Grafana 提供丰富的可视化功能。 服务依赖项图和流日志可视化通过提供对 DNS 相关流量和依赖项的视觉见解来补充详细的日志分析：

• 服务依赖项图：可视化哪些 Pod 或服务正在发送大量 DNS 查询及其关系
• 流日志仪表板：实时监视 DNS 请求模式、错误率和响应时间
• 流量流分析：识别 CoreDNS 或外部 DNS 服务的已删除 DNS 数据包和通信路径

可以通过以下方法访问这些可视化效果：

• Azure 门户：导航到 AKS 群集→洞察→网络→流日志
• Azure 托管 Grafana：使用预配置的“流日志”和“流日志(外部流量)”仪表板

借助 Grafana 仪表板、用于历史分析的容器网络日志存储模式和实时故障排除的按需日志的组合功能，可以识别 DNS 问题并有效地执行根本原因分析。

用例 2：识别由于网络策略配置错误或网络连接问题而在群集和 Pod 级别的数据包丢失。

连接和网络策略强制实施问题通常源于配置错误的 Kubernetes 网络策略、不兼容的容器网络接口（CNI）插件、重叠 IP 范围或网络连接降级。 此类问题可能会中断应用程序功能，导致服务中断和用户体验下降。

发生数据包丢弃时，eBPF 程序捕获事件并生成有关数据包的元数据，包括删除原因及其位置。 此数据由用户空间程序处理，该程序分析信息并将其转换为 Prometheus 指标。 这些指标提供有关数据包丢弃的根本原因的关键见解，使管理员能够有效地识别和解决网络策略配置错误等问题。

除了策略强制实施问题外，网络连接问题还可能导致数据包下降，原因包括 TCP 错误或重新传输。 管理员可以通过分析 TCP 重新传输表和错误日志来调试这些问题，这些工具有助于识别网络链接的劣化或瓶颈。 通过利用这些详细的指标和调试工具，团队可以确保网络作顺利，减少停机时间，并保持最佳的应用程序性能。

假设有一个基于微服务的应用程序，前端 Pod 由于过度限制的网络策略阻止了入口流量，因此前端 Pod 无法与后端 Pod 通信。

步骤 1：调查 Grafana 仪表板中的丢弃指标

1. 如果有数据包丢弃，请使用“Pod 流(工作负载)”仪表板开始调查。 此仪表板包含多个面板，可帮助确定具有最高丢弃数的命名空间，然后确定这些命名空间内具有最高丢弃数的 Pod。 例如，让我们查看顶级来源 Pod 的传出流量下降热图或顶级目标 Pod 的传出流量下降热图，以确定哪些 Pod 受影响最大。 更亮的颜色表示下降率较高。 跨时间进行比较，以检测特定 Pod 中的模式或峰值。

   

2. 确定具有最高丢弃数的排名靠前的 Pod 后，转到“丢弃(工作负载)”仪表板。 可以通过识别来自特定 Pod 的传出流量下降模式来使用此仪表板来诊断网络连接问题。 可视化效果突出显示了哪些 Pod 遇到最多的丢弃、这些丢弃率以及它们背后的原因，例如策略拒绝。 通过将下降率峰值与特定的实例或时间范围相关联，可以查明配置错误、服务过载或策略执行问题，这些问题可能会导致连接中断。

   

3. 查看“工作负载快照”部分，确定具有传出数据包丢弃的 Pod。 重点介绍 最大传出量下降 和 最小传出下降 指标，以了解问题的严重性（此示例显示 1.93 个数据包/秒）。 优先调查数据包丢弃率一直较高的 Pod。

   

4. 使用“丢弃的传入/传出流量按原因排序”图来识别流量下降的根本原因。 在此示例中，原因为策略被拒绝，指示配置错误的网络策略阻止传出流量。 检查任何特定的时间间隔是否显示丢弃峰值，以缩小问题开始的时间范围。

   

5. 使用 主要源/目标 Pod 的下降流量热图 来确定哪些 Pod 受影响最大。 更亮的颜色表示下降率较高。 跨时间进行比较，以检测特定 Pod 中的模式或峰值。

   

6. 使用“按源 Pod 划分的堆叠（总）传出/传入丢弃”图表来比较受影响 Pod 之间的丢弃率。 确定特定 Pod 是否一直显示更高的丢弃（例如 kapinger-bad-6659b89fd8-zjb9k at 26.8 p/s）。 此处，p/s 是指每秒丢包数。 将这些 Pod 与其工作负载、标签和网络策略交叉引用，以诊断潜在的配置错误。

   

步骤 2：使用容器网络日志分析数据包丢失

容器网络日志提供对错误配置网络策略导致的数据包丢弃的全面见解，其中包含详细、实时和历史数据。 可以通过检查特定的丢弃原因、模式和受影响的工作负荷来分析丢弃的数据包。

在 Log Analytics 工作区中使用以下 KQL 查询来识别丢包：

RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED" 
| summarize DropCount = count() by SourcePodName, DestinationPodName, SourceNamespace, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, DropCount desc

若要实时分析丢弃的数据包，还可以按特定 Pod 或命名空间进行筛选：

RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED" 
| where SourceNamespace == "<namespace-name>"
| project TimeGenerated, SourcePodName, DestinationPodName, SourceNamespace, DestinationNamespace, Verdict, TrafficDirection
| order by TimeGenerated desc

将 <start-time> 和 <end-time> 替换为所需的时间范围，其格式为 2025-08-12T00:00:00Z。

容器网络日志提供对丢弃数据包的精细见解，帮助你识别配置错误的网络策略并验证修补程序。 日志包括有关丢弃原因、影响的 Pod 和流量模式的详细信息，这些信息可指导故障排除工作。

步骤 3：使用容器网络日志仪表板可视化丢包

容器网络日志通过 Azure 门户仪表板和 Azure 托管 Grafana 提供流量流与丢弃数据包的直观表示形式。 流日志仪表板展示了在同一命名空间中的 Pod 之间、不同命名空间中的 Pod 之间以及来自集群外部的流量之间的交互。

关键可视化功能包括：

• 按原因删除分析：确定丢弃数据包的原因（策略被拒绝、连接跟踪等）
• 流量映射：允许和拒绝的流量流的可视表示形式
• 命名空间和 Pod 级见解：源与目标关系的详细视图
• 时序分析：数据包丢弃的历史趋势及其原因

此数据有助于查看群集中应用的网络策略，使管理员能够通过全面的日志分析和视觉表示快速识别和解决任何配置错误或有问题的策略。

用例 3：确定工作负载和命名空间中的流量不平衡

与其他人相比，当工作负荷或命名空间中的某些 Pod 或服务处理不成比例的高网络流量时，会发生流量不平衡。 这可能会导致资源争用、重载 Pod 的性能下降，以及其他 Pod 使用率不足。 这种不平衡通常是由于配置不当的服务、负载均衡器的流量分布不均衡或意外的使用模式导致的。 如果没有可观测性，很难确定哪些 Pod 或命名空间被重载或未充分利用。 高级容器网络服务可以通过监视 Pod 级别的实时流量模式，提供带宽使用率、请求速率和延迟的指标，从而轻松查明不平衡。

假设你在 AKS 群集上运行了一个在线零售平台。 该平台包含多个微服务，包括产品搜索服务、用户身份验证服务和通过 Kafka 进行通信的订单处理服务。 在季节性销售期间，产品搜索服务遇到流量激增，而其他服务仍然处于空闲状态。 负载均衡器无意中将更多请求定向到产品搜索部署中的 Pod 子集，导致搜索查询的拥塞和延迟增加。 同时，同一部署中的其他 Pod 未得到充分利用。

步骤 1. 通过 Grafana 仪表板调查 Pod 流量

1. 查看“Pod 流(工作负载)”仪表板。 “工作负载快照”显示各种统计信息，例如传出和传入流量以及传出和传入丢弃。

   

2. 检查每种跟踪类型的流量波动。 蓝色和绿色线条中的显著变化表示应用程序和服务的流量变化，这可能导致拥塞。 通过识别流量较高的时间段，可以查明拥塞时间并进一步调查。 此外，比较传出和传入流量模式。 如果传出流量与传入流量之间存在严重不平衡，则可能表示网络拥塞或瓶颈。

3. 热力图表示 Kubernetes 群集中 Pod 级别的流量指标。 Top Source Pod 传出流量的热度地图显示来自前 10 个源 Pod 的传出流量，而 Top Destination Pod 传入流量的热度映射显示发往前 10 个目标 Pod 的传入流量。 颜色强度表示流量，深色调代表更高的流量。 一致的模式突出显示生成或接收重要流量的 Pod（例如 default/tcp-client-0），这可能充当中心节点。

   以下热度地图指示更高的流量正在接收和传出单个 Pod。 如果同一 Pod（例如 default/tcp-client-0）出现在两个流量强度较高的热图中，则可能表明它既在发送也在接收大量流量，可能在工作负载中充当中心节点。 Pod 之间的强度变化可能表示流量分布不均衡，某些 Pod 处理的流量比其他 Pod 多。

   

4. 监视 TCP 重置流量对于了解网络行为、排查问题、强制实施安全性和优化应用程序性能至关重要。 它提供有关连接如何管理和终止的有价值见解，使网络和系统管理员能够保持正常运行、高效和安全的环境。 这些指标显示正在发送或接收 TCP RST 数据包的 Pod 数量，这些数据包可能表明连接不稳定，或由于 Pod 配置不当导致网络拥塞。 高重置率表示 Pod 可能会因连接尝试或资源争用而过载。

   

5. 由顶级源 Pod 传出 TCP RST 的热度映射显示哪些源 Pod 生成了大多数 TCP RST 数据包，以及活动高峰时间。 对于以下示例热度地图，如果 pets/rabbitmq-0 在高峰流量时段持续显示高传出重置，则可能表示应用程序或其基础资源（CPU、内存）已过载。 解决方案可能是优化 Pod 的配置、扩展资源或在副本之间均衡分配流量。

   

6. 由 接收最多 TCP RST 数据包的目标 Pod 热图 可以识别出那些接收到最多 TCP RST 数据包的目标 Pod，指出这些 Pod 上可能存在的瓶颈或连接问题。 如果 宠物/mongodb-0 经常接收 RST 数据包，则可能表示数据库连接过载或网络配置出错。 解决方案可能是增加数据库容量、实现速率限制，或调查导致连接过多的上游工作负荷。

   

7. “按源 Pod 划分的堆叠（总）传出 TCP RST”图提供一段时间内传出重置的聚合视图，突出显示趋势或异常。

   

8. “按目标 Pod 划分的堆叠（总）传入 TCP RST”图聚合传入重置，显示网络拥塞如何影响目标 Pod。 例如，pets/rabbitmq-0 的重置持续增加可能表明此服务无法有效处理传入流量，从而导致超时。

   

使用容器网络日志分析流量不平衡

除了使用 Grafana 仪表板之外，还可以使用容器网络日志分析流量模式，并通过 KQL 查询识别不平衡：

// Identify pods with high traffic volume (potential imbalances)
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend TCP = parse_json(Layer4).TCP
| extend SourcePort = TCP.source_port, DestinationPort = TCP.destination_port
| summarize TotalConnections = count() by SourcePodName, SourceNamespace
| top 10 by TotalConnections desc

// Analyze TCP reset patterns to identify connection issues
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend TCP = parse_json(Layer4).TCP
| extend Flags = TCP.flags
| where Flags contains "RST"
| summarize ResetCount = count() by SourcePodName, DestinationPodName, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, ResetCount desc

将 <start-time> 和 <end-time> 替换为所需的时间范围，其格式为 2025-08-12T00:00:00Z。

这些查询有助于识别在仪表板可视化效果中可能不立即可见的流量不平衡和连接问题。

用例 4：实时监视群集的网络运行状况和性能

在高级别呈现群集的网络运行状况指标对于确保系统的整体稳定性和性能至关重要。 高级指标提供群集网络性能的快速全面视图，使管理员能够轻松识别潜在的瓶颈、故障或效率低下，而无需深入了解精细的详细信息。 这些指标（例如延迟、吞吐量、数据包丢失和错误率）提供群集运行状况的快照，可实现主动监视和快速故障排除。

我们有一个示例仪表板，表示群集的总体运行状况： Kubernetes/网络/群集。 让我们深入了解整个仪表板。

1. 识别网络瓶颈：通过分析 “字节转发 ”和 “数据包转发 ”图，可以确定是否存在任何突然下降或峰值，指示网络中的潜在瓶颈或拥塞。

   

2. 检测数据包丢失： “丢弃的数据包 ”和“ 已丢弃的字节 ”部分有助于确定特定群集中是否存在重大数据包丢失，这可能表示硬件故障或网络设置配置错误等问题。

   

3. 监视流量模式：可以随着时间的推移监视流量模式，了解正常行为与异常行为，这有助于主动进行故障排除。 通过比较最大和最小入口/出口字节数和数据包，可以分析性能趋势，并确定一天中的某些时间或特定工作负荷是否会导致性能下降。

   

4. 丢包原因诊断：“原因丢弃的字节数”和“原因丢弃的数据包数”部分有助于了解数据包丢弃的具体原因，例如策略拒绝或未知协议。

   

5. 特定于节点的分析：节点丢弃的字节数和节点丢弃的数据包数图表提供对哪些节点发生最多数据包丢失的见解。 这有助于查明有问题的节点并采取纠正措施来提高网络性能。

   

6. TCP 连接的分布：此处的图表示跨不同状态分布 TCP 连接。 例如，如果图形显示处于异常高状态的连接 SYN_SENT 数，则可能表示群集节点因网络延迟或配置不当而无法建立连接。 另一方面，在TIME_WAIT状态下的大量连接可能意味着连接未被正确释放，这可能会导致资源枯竭。

   

用例 5：诊断应用程序级网络问题

L7 流量可观测性通过深入了解 HTTP、gRPC 和 Kafka 流量来解决关键的应用程序层网络问题。 这些见解有助于检测错误率高（例如 4xx 客户端或 5xx 服务器端错误）、意外流量下降、延迟高峰、Pod 间流量分布不均衡以及网络策略配置错误等问题。 在复杂的微服务体系结构中，这些问题经常出现，其中服务之间的依赖关系复杂，资源分配是动态的。 例如，丢弃的 Kafka 消息或延迟的 gRPC 调用突然增加可能表明消息处理或网络拥塞出现瓶颈。

假设你在 Kubernetes 群集中部署了一个电子商务平台，其中前端服务依赖于多个后端微服务，包括支付网关（gRPC）、产品目录（HTTP）和通过 Kafka 进行通信的订单处理服务。 最近，用户报告了签出失败次数增加，页面加载时间变慢。 让我们深入了解如何使用预配置的 L7 流量仪表板执行此问题的 RCA：Kubernetes/Networking/L7（命名空间）和 Kubernetes/Networking/L7（工作负荷）。

1. 确定已删除和转发的 HTTP 请求的模式。 在下图中，传出 HTTP 流量按判决进行分段，突出显示请求是“转发”还是“已删除”。对于电子商务平台，此图可帮助识别结帐过程中的潜在瓶颈或故障。 如果丢失的 HTTP 流明显增加，这可能表明网络策略配置错误、资源受限，或前端与后端服务之间的连接问题。 通过将此图与用户投诉的特定时间范围相关联，管理员可以确定这些下降是否与签出失败相符。

   

2. 以下折线图描述了一段时间内传出 HTTP 请求的速率，按其状态代码（例如 200,403）分类。 可以使用此图来确定错误率（例如 403 禁止 访问错误）的峰值，这可能指示身份验证或访问控制问题。 通过将这些峰值与特定的时间间隔相关联，可以调查并解决根本问题，例如配置错误的安全策略或服务器端问题。

   

3. 以下热力图指示哪些 Pod 发出了导致 4xx 错误的 HTTP 请求。 可以使用此热度地图快速识别有问题的 Pod，并调查错误的原因。 通过在 Pod 级别解决这些问题，可以提高其 L7 流量的整体性能和可靠性。

   

4. 使用以下图形检查哪些 Pod 接收最多的流量。 这有助于识别过度负担的 Pod。

   • “默认的前 10 个源 Pod 的传出 HTTP 请求”表明在一段时间内前 10 个源 Pod 的传出 HTTP 请求数稳定。 这条曲线几乎呈现平稳，表示流量稳定，没有显著的峰值或下降。
   • “默认的前 10 个源 Pod 的已丢弃传出 HTTP 请求的热力地图”使用颜色编码来表示丢弃的请求数。 较深的颜色表示已删除的请求数较高，而较浅的颜色表示请求较少或未删除。 交替的深色和浅色带表明请求减少中的周期性模式。

   这些图提供了对其网络流量和性能的宝贵见解。 第一个图形可帮助你了解其传出 HTTP 流量的一致性和数量，这对于监视和维护最佳网络性能至关重要。 第二个关系图允许识别出现已删除请求的问题时模式或时间段，这对于排查网络问题或优化性能至关重要。

   

L7 流量的根本原因分析期间要关注的关键因素

1. 流量模式和流量：分析流量趋势，以确定流量分布中的激增、下降或不平衡。 重载的节点或服务可能会导致瓶颈或删除的请求。

   

2. 错误率：跟踪 4xx（无效请求）和 5xx（后端失败）错误的趋势。 持久性错误表示客户端配置错误或服务器端资源约束。

3. 丢失的请求：调查特定 Pod 或节点的丢失情况。 丢弃通常表示连接问题或与策略相关的拒绝。

4. 策略强制实施和配置：评估网络策略、服务发现机制以及配置错误的负载均衡设置。

5. 热力图和流量指标：使用热力图等可视化工具快速识别错误多发的节点或流量异常。

使用容器网络日志分析 L7 流量

容器网络日志通过存储的日志和可视仪表板提供全面的 L7 流量分析功能。 使用以下 KQL 查询分析 HTTP、gRPC 和其他应用程序层流量：

// Analyze HTTP response codes and error rates
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7_HTTP"
| extend HTTP = parse_json(Layer4).HTTP
| extend StatusCode = HTTP.status_code
| summarize RequestCount = count() by StatusCode, SourcePodName, bin(TimeGenerated, 5m)
| order by TimeGenerated desc

// Identify pods with high HTTP 4xx or 5xx error rates
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7_HTTP"
| extend HTTP = parse_json(Layer4).HTTP
| extend StatusCode = tostring(HTTP.status_code)
| where StatusCode startswith "4" or StatusCode startswith "5"
| summarize ErrorCount = count(), UniqueErrors = dcount(StatusCode) by SourcePodName, DestinationPodName
| top 10 by ErrorCount desc

// Monitor gRPC traffic and response times
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7_GRPC"
| extend GRPC = parse_json(Layer4).GRPC
| extend Method = GRPC.method
| summarize RequestCount = count() by SourcePodName, DestinationPodName, Method
| order by RequestCount desc

将 <start-time> 和 <end-time> 替换为所需的时间范围，其格式为 2025-08-12T00:00:00Z。

这些查询通过提供有关跨微服务体系结构的应用程序层性能、错误模式和流量分布的详细见解来补充视觉仪表板。

Azure 监视随附的网络可观测性

在 AKS 群集上为 Prometheus 启用 Azure Monitor 托管服务时，默认通过 networkobservabilityRetina 目标收集基本节点网络监视指标。 这提供：

• 基本节点级网络指标：节点级别的基本网络流量可见性
• 默认 Prometheus 目标：Azure Monitor 自动抓取的网络可观测性指标
• Azure Monitor 集成：与 Azure Monitor 无缝集成;指标会自动收集，可以在 Grafana 中可视化
• 无需其他设置：配置 Azure Monitor 托管 Prometheus 时自动启用
• Microsoft支持：在 Azure Monitor 和 AKS 中受支持

注意：这要求在 AKS 群集上启用 Prometheus 的 Azure Monitor 托管服务，这可能会产生相关的成本。

入门：通过 Azure 门户或 CLI 在 AKS 群集上为 Prometheus 启用 Azure Monitor 托管服务。 将自动收集网络可观测性指标，并可在 Azure 托管的 Grafana 中进行可视化展示。

使用 Retina OSS 增强网络可观测性

虽然高级容器网络服务（ACNS）是一种提供全面的网络可观测性功能的付费产品，Microsoft还支持 Retina OSS 的网络可观测性，这是一个提供基本网络监视功能的开源网络可观测性平台。

Retina OSS 是在 retina.sh 和 GitHub 上提供的开源可观测性平台。 它提供：

• 基于 eBPF 的网络可观测性：利用 eBPF 技术以最少的开销收集见解
• 使用 Kubernetes 上下文进行深入流量分析：使用完整的 Kubernetes 集成全面捕获和分析网络流量流
• 高级指标收集：第 4 层指标、DNS 指标和分布式数据包捕获功能
• 基于插件的扩展性：通过插件体系结构自定义和扩展功能
• Prometheus 兼容的指标：使用可配置指标模式导出 Prometheus 格式的综合网络指标
• 分布式数据包捕获：跨多个节点的按需数据包捕获，以进行深度故障排除
• 平台和 CNI 无关：适用于任何 Kubernetes 群集（AKS、启用 Arc 的、内部部署）、任何操作系统（Linux/Windows），以及任何 CNI。
• 社区支持：具有社区驱动的支持和贡献的开源
• 自我管理：完全控制部署和配置
• Hubble 集成：与 Cilium 的 Hubble 集成以获取更深入的网络洞察

开始使用：从官方 Retina 存储库使用 Helm 图表或 Kubernetes 部署 Retina OSS。 设置 Prometheus 和 Grafana 以可视化指标、使用 Kubernetes 上下文配置深度流量分析、为高级故障排除启用分布式数据包捕获，以及针对特定用例使用基于插件的体系结构自定义功能。

网络可观测性产品/服务的比较

了解详细信息

若要开始使用 AKS 中的网络可观测性，

高级容器网络服务 (ACNS)

• 设置容器网络日志：了解如何配置 容器网络日志，以便实现全面的网络可观测性
• 浏览高级容器网络服务：有关完整平台的详细信息，请参阅 什么是适用于 Azure Kubernetes 服务的高级容器网络服务（AKS）？
• 配置监控：设置 Grafana Azure 托管集成以实现高级可视化
• 了解网络安全：探索用于策略强制和威胁检测的容器网络安全功能

网络可观测性 （Azure Monitor）

• Azure Monitor 集成：设置 用于容器的 Azure Monitor 以查看基本网络指标

Retina OSS

• 官方文档：访问 retina.sh 以获取全面的文档和指南
• GitHub 存储库：访问 Microsoft Retina GitHub 存储库 ，以获取安装指南、示例和社区支持
• 社区支持：加入 Retina 社区讨论 以获取帮助和最佳做法