诊断并解决高级容器网络服务的 AKS 网络问题

本指南指导你使用 Advanced Container Networking Services （ACNS）诊断和解决Azure Kubernetes 服务 (AKS)中的实际网络问题。 每个 playbook 都从症状（DNS 故障、数据包丢弃、流量不平衡、L7 错误）开始，显示先检查哪些信号，并告诉你何时钻取日志。

本指南围绕任务而不是功能进行组织。 阅读心理模型一遍，然后直接跳到与您的症状相匹配的操作手册。

本指南可帮助你解决哪些问题

• Pod 中的 DNS 解析失败（NXDOMAIN、SERVFAIL缺少响应）。
• 由于 网络策略配置不当、连接跟踪或连接降级而导致数据包丢弃。
• Pod 或命名空间之间的流量不平衡（热 Pod、负载分布不均衡）。
• L7 应用程序错误 （HTTP 4xx/5xx、gRPC 故障、Kafka 删除）。
• 群集范围的网络健康状况 监控和容量规划。
• 通过目标指标和日志收集实现可观测性成本控制。

心理模型：指标、日志和筛选如何组合在一起

ACNS 提供三个信号。 每个回答不同的问题。

有关更深入的功能参考，请参阅 容器网络指标、 容器网络日志和 配置指标筛选。

标准故障排除流

将此循环用于任何网络事件：

1. 从指标仪表板开始。 确认异常：丢弃、错误、TCP 重置或 DNS 故障等峰值。 确定受影响的节点、命名空间或工作负荷。
2. 转移到存储日志。 根据步骤 1 中的命名空间和时间窗口筛选ContainerNetworkLogs表格。 日志会告知裁定、丢弃原因、源/目标工作负荷和 L7 状态代码，而指标不包含这些信息。
3. 利用按需访问的日志实时再现。 如果问题是间歇性的或已经在存储的数据中得到修复，请使用 Hubble CLI 或 Hubble UI 捕获工作负荷的实时流量。
4. 验证修复。 重新检查同一指标面板并重新运行相同的 KQL 查询。 异常应消失。
5. 调优集合。 如果在事件期间过度收集，请缩小 ContainerNetworkLog CRD 范围或应用 ContainerNetworkMetric 筛选器，以便仅捕获将来需要的信息。

内置仪表板概览

使用“设置容器网络可观测性”设置这些设置一次。 将在整个 Playbook 中引用这些设置。

Playbook 1：诊断 DNS 解析失败

症状。 Pod 在解析服务名称时会记录类似DNS_PROBE_FINISHED_NXDOMAIN、SERVFAIL的错误，或出现挂起。

目标。 确定故障是上游（CoreDNS 还是外部解析程序）、策略驱动（FQDN 拒绝）还是特定于工作负荷。

步骤 1：确认 DNS 指标中的异常

打开 DNS（群集） 仪表板。 查找请求量、响应量或 请求缺少响应 % 的突然更改。 摘要面板显示最常见的查询、最常见的响应代码和生成最多错误的节点。

要查找的内容： 错误响应持续增加、成功响应下降或控制错误计数的单个节点。 记下异常的时间戳。

步骤 2：识别最嘈杂的 Pod

在同一仪表板上向下滚动到跨所有命名空间按 DNS 错误对 Pod 进行排名的面板。 最上面的条目是最初的怀疑对象。

决策点。

• 如果错误集中在 CoreDNS pods 中，请跳转到 DNS（负载） 仪表板并选择 kube-system / coredns—问题出在 CoreDNS 本身或其上游解析器。
• 如果错误集中在 应用程序工作负荷中，该工作负荷将生成错误的查询或 FQDN 策略拒绝。

步骤 3：深入了解受影响的工作负荷

打开你标识的工作负荷的 DNS（工作负荷） 仪表板。

• DNS 请求/DNS 响应面板。 请求缺失响应率高指向上游超时或查询过载。

  

• 按类型排序的 DNS 错误。 将峰值与代码匹配：

  • NXDOMAIN — 应用配置中存在错误或过时的域名。
  • SERVFAIL — 上游解析器问题。
  • 查询被拒绝 — FQDN 策略或 DNS 配置不匹配。

  

• 返回的 DNS 响应 IP。 确认成功解决问题的比例。 下降通常意味着 CoreDNS 无法访问上游;突然激增可能表示查询风暴。

• DNS 响应表。 使用此模式可以发现“A 记录失败，但 AAAA 记录成功”等模式，通常指向仅 IPv4 环境的堆栈配置错误。

  

步骤 4：使用存储的日志进行确认

在Log Analytics工作区中运行此 KQL 查询，以显示 DNS 错误模式。 聚合行保留 Verdict、命名空间、工作负荷，以及 Layer7.dns.rcode，因此此查询适用于默认（聚合）ContainerNetworkLogs 表。

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L4 = parse_json(Layer4), L7 = parse_json(Layer7)
| where L4.UDP.destination_port == 53
| where Reply == true
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name),
         DnsRcode    = tostring(L7.dns.rcode)
| where DnsRcode != "NOERROR"
| summarize ResponseCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DnsRcode, Verdict
| order by ResponseCount desc

请将<start-time>和<end-time>替换为2026-04-30T15:00:00Z格式的时间戳。

检查结果中的内容：

• 判决。 DROPPED 表示 FQDN 或网络策略正在阻止查询。 FORWARDED 含非 NOERRORDnsRcode（例如，NXDOMAIN、SERVFAIL）表示上游解析程序返回错误。
• 源/目标工作负荷。 确认流量正转向预期的 CoreDNS 工作负载。
• DnsRcode。 DNS 响应代码一目了然地标识故障模式。

可以在Azure门户的AKS 群集>Insights>Networking>Flow Logs下，可视化相同的流。

步骤 5：如果问题间歇性发生，请现场重现

如果峰值已过去且无法在存储的日志中捕获它，可以按需使用Hubble CLI。

hubble observe --namespace <ns> --port 53 --type l7 --follow

步骤 6：验证修补程序

更新 FQDN 策略、修复应用程序配置或缩放 CoreDNS 后，重新打开 DNS（工作负荷） 仪表板。 错误率应在一两分钟内下降。 重新运行同一时间窗口的 KQL 查询，以确认失败的查询已消失。

Playbook 2：调查数据包丢弃

症状。 服务无法相互联系。 探测失败。 连接超时。在仪表板中放置计数器爬升。

目标。 确定丢包是由网络策略、连接跟踪资源耗尽，还是上游连接问题导致的，以及哪个工作负载是原因。

步骤 1：在命名空间级别找到丢析点

打开 Pod 数据流（命名空间）。 热图显示传出和传入丢包率最高的命名空间和 Pod。

较亮的单元格表示较高的下降率。 记下命名空间和时间范围。

步骤 2：深入了解受影响的工作负荷

打开 Drops（工作负荷） 并选择您识别的工作负荷。

• 工作负荷快照 显示每秒包的最大/最小传出丢弃量。使用它用于评估严重程度。

  

• 按原因丢弃的流量 是最重要的面板。 原因告诉你要修复什么：

  • 策略被拒绝 — NetworkPolicy 或 CiliumNetworkPolicy 正在阻止流量。
  • CT：映射插入失败 - 连接跟踪表已满;缩放节点或减少连接变动量。
  • 不支持的 L3 协议/数据包无效 — 应用程序或代理正在发送格式不正确的流量。

  

• 传入/传出下降的热度地图。 标识哪些特定的 Pod 对正在丢失流量。

  

• 按源Pod分类的丢包总数。 对罪犯进行排名排序，以便你知道先查看哪个副本。

  

步骤 3：确认存储日志中的丢包流

查找已删除流量的确切源和目标工作负荷。 Verdict、 DropReason命名空间和工作负荷都位于聚合键中，因此此查询适用于聚合数据：

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DropReason, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, DropCount desc

识别后缩小到一个命名空间：

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| where SourceNamespace == "<namespace-name>"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DestinationNamespace, DstWorkload, DropReason, TrafficDirection
| order by DropCount desc

Azure 门户中的 Flow Logs 仪表板以直观的方式显示相同的数据，其中包括高亮显示受阻路径的服务依赖关系图。

步骤 4：与政策核对

知道源头 Pod 和目标 Pod 后：

kubectl get netpol,cnp -A
kubectl describe cnp -n <namespace> <policy-name>

将失败的流与入口/出口规则对照。 最常见的原因是在未为合法路径添加允许规则的情况下，就添加了默认拒绝策略。

步骤 5：验证修补程序

调整策略后，Dropped Traffic by Reason 图表对于 拒绝策略 应该趋于平稳。 重新运行 KQL 查询 — DROPPED 该源地址/目标地址对的结果不应再显示。

Playbook 3：查找流量不均衡和热 Pod

症状。 部署的一些 Pod 正在饱和 CPU 或网络，而另一些 Pod 则处于空闲状态。 TCP 重置攀登。 延迟报告来自用户（ACNS 指标中不显示延迟本身），请参阅 心理模型中的注释。

目标。 确定哪些 Pod 承载不均衡的流量，以及复位是否表示过载或负载均衡配置不当。

步骤 1：比较 Pod 级流量

打开 Pod 流量（工作负荷）。 工作负载快照汇总了传出和传入流量及丢包情况。

按跟踪类型划分流量的面板显示流量随时间变化的形状。 传出流量和传入流量之间的较大差距通常表明下游瓶颈。

步骤 2：使用热图发现热 Pod

Pod 级热图使不平衡变得明显。 如果一个 Pod（例如，default/tcp-client-0）在传出和传入的热图中出现，并且比其副本的单元格要暗得多，则表明流量集中在那里。

常见原因：

• 将客户端固定到一个 Pod 的服务 sessionAffinity: ClientIP 。
• 具有粘性 DNS 解析的无头服务。
• 低基数字段上的外部负载均衡器哈希。

步骤 3：使用 TCP 重置信号作为饱和信号

打开 TCP 重置指标 面板。

• 源 Pod 传出 TCP RST 的热图。 还生成 RST 的热源 Pod 重载 - 应用程序正在快速关闭连接。

  

• 目标 Pod 传入 TCP RST 的热度地图。 通常来说，从许多源接收 RST 的 Pod 意味着它无法足够快地接受新连接（积压已满，监听器响应缓慢）。

  

• 按源/目标划分的堆叠 RST 总量。 一段时间的趋势会告诉你重启是一次性事件还是新的稳定状态。

步骤 4：使用日志进行确认

按总流量确定最繁忙的工作负荷。 使用聚合的流计数列，而不是count()，因为后者仅对聚合行进行计数，而不是对基础流进行计数。

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend SrcWorkload = tostring(SourceWorkloads[0].name)
| summarize TotalFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload
| top 10 by TotalFlows desc

步骤 5：验证修补程序

扩展工作负荷、重新均衡服务或修复亲和性规则后，热度地图在更多 Pod 上均匀变亮，且 TCP RST 速率应下降。

Playbook 4：监视群集范围的网络运行状况

如果需要车队视图：容量规划、呼叫仪表板或跨多个群集进行快速运行状况检查，请使用此功能。

打开 Kubernetes/网络/群集。

要观看的信号及其含义：

当这张仪表板上显示有问题时，请跳转到相应的操作指南（DNS 用操作指南 1，丢包用操作指南 2，热容器用操作指南 3）。

Playbook 5：诊断应用程序层（L7）错误

症状。 HTTP 4xx/5xx 错误率攀升。 gRPC 调用失败。 Kafka 消费者滞后。 在 启用了 L7 策略强制的 Cilium 群集上可用，其中包含 CiliumNetworkPolicy L7 规则 - 请参阅 “配置第 7 层策略”。

目标。 确定 L7 错误来自配置错误的客户端、服务器端故障还是拒绝流。

步骤 1：打开 L7 仪表板

将 Kubernetes/Networking/第7层（工作负载） 用于单个服务或 第7层（命名空间） 用于整个租户。

步骤 2：区分丢弃的 HTTP 流量与转发的 HTTP 流量

判决面板将 HTTP 流量拆分为转发和丢弃的流。 HTTP 丢弃峰值通常意味着 CiliumNetworkPolicy 正在第 7 层拒绝请求（例如，阻止某条路径或方法）。

步骤 3：跟踪一段时间内的状态代码

状态代码面板会告诉你错误是客户端还是服务器端。 4xx 中的激增指向错误的输入、过期令牌或拒绝路径。 后端故障时的 5xx 点激增。

步骤 4：查找有问题的 Pod

4xx 热力图显示哪些源 Pod 生成了最多失败请求。 单个 Pod 发光通常意味着客户端重试循环停滞或配置错误的副本。

步骤 5：使用 KQL 进行确认

提取按状态代码细分的 HTTP 流量。 Layer7.http.code 是聚合键的一部分，因此这适用于聚合行：

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L7 = parse_json(Layer7)
| where isnotnull(L7.http)
| extend StatusCode  = tostring(L7.http.code),
         SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where StatusCode startswith "4" or StatusCode startswith "5"
| summarize ErrorFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount),
            UniqueCodes = dcount(StatusCode)
    by SrcWorkload, DstWorkload, StatusCode
| order by ErrorFlows desc

对于 gRPC 和 Kafka，Layer7承载特定于协议的有效负载，但仅http.codedns.rcode包含聚合密钥。 在Verdict和工作负载标识上进行筛选，需要 gRPC 方法或 Kafka 主题时使用按需日志：

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where Verdict == "DROPPED"
| summarize DroppedFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DstWorkload
| order by DroppedFlows desc

L7 RCA 期间要关注的内容

• 流量和形状。 使用热力图查找不平衡，因为一个热点副本通常会反映错误率。
• 状态代码趋势。 4xx 与 5xx 将调查范围缩小到客户端或服务器端。
• 判决。丢弃 L7 流意味着 L7 策略正在拒绝请求，读取策略并确认意图。

功能深度解析（何时使用何种功能）

了解剧本后，请将本部分用作快速参考。

容器网络指标

• 用于： 异常情况检测、仪表板、警报、容量规划。
• 跳过：需要识别的 根本原因（哪个 Pod，哪条路径，哪个裁定）。
• 粒度： 所有数据平面上的节点级别;Linux 上的 pod 级。
• 成本敏感的工作负荷： 在 Cilium 群集上应用 指标筛选 ，以仅保留你关注的命名空间、标签和指标类型。 筛选发生在刮伤之前，因此不需要的系列永远不会到达 Prometheus。

容器网络日志（存储）

• 用于： 根本原因分析、历史趋势、合规性/审核。

• 数据平面：仅限于Cilium。非 Cilium 群集不提供存储的日志。

• 必需步骤： 定义一个 CRD 来选定您想要的流量。 没有它，就不会收集日志。 请参阅 设置容器网络日志。

• 日志位于何处： 默认情况下，Cilium 会将流记录写入 /var/log/acns/hubble/events.log 每个节点上（50 MB 旋转缓冲区）。 从这里，您有两个存储路径选择：

  • Azure Log Analytics（托管的、推荐的）- Container Insights 将日志传送到 KQL 查询和内置Azure门户仪表板的 ContainerNetworkLogs 表中。
  • 自带收集器 - 将与 OpenTelemetry 兼容的代理（例如 Splunk、Datadog、Elastic 或任意 OTel 收集器）指向主机日志路径，以将流数据转发到现有的可观测性堆栈，而不是或者和 Log Analytics 一起。

• 成本控制： 流量日志聚合在 30 秒的窗口中将相似的流进行合并，在减少数据量时保留流量模式。 与窄 includeFilters 结合，获得最佳结果。

• 可视化：在Azure的Insights、Containers和>中，使用Flow 日志 - 分析层或>仪表板。

  

  

容器网络日志（按需）

• 用于： 实时事件、间歇性问题、临时调查，而无需更改收集配置。

• 数据平面：仅限 Cilium。

• 工具： 用于终端筛选的 Hubble CLI;可视化服务到服务映射的 Hubble UI。

• 没有持久性存储，无需额外费用，也无需设置 ACNS。

  

指标筛选（Cilium 集群）

应用 ContainerNetworkMetric CRD 来控制每个节点上导出的 Hubble 指标。 在一些关键命名空间上需要广泛的可观测性，但不希望为所有这些命名空间中的高基数流系列付费时非常有用。

常见模式：

• 保留 DNS 并删除群集范围的指标;将流指标限制为生产命名空间。
• 从流量指标中排除高使用量的系统命名空间 kube-system。
• 将每个租户命名空间的范围限定为自己的筛选器块。

有关完整的 CRD 示例，请参阅 “配置容器网络指标筛选”。

最佳做法

• 开始宽泛，然后缩小。 在几天内启用广泛的日志/指标，查看实际使用的内容，然后收紧 ContainerNetworkLog 和 ContainerNetworkMetric 筛选。
• 使指标和日志时间窗口保持一致。 调查事件时，请在仪表板和 KQL 查询中使用相同的开始/结束时间，以便信号完全关联。
• 首选预生成的仪表板。 它们涵盖了最常见的问题。 自定义面板通常在经过初步筛选后才需要。
• 根据需要分层 ContainerNetworkLogs 。 切换到“基本”层以应对成本敏感的工作负荷，使用匹配的基本层仪表板。 请参阅Log Analytics 表计划。
• 将聚合日志和按需日志视为补充。 聚合日志非常适合趋势和模式检测，但跳过每个流的详细信息。 使用按需服务（Hubble）进行精细化检查。
• 验证修复程序时，请使用发现问题的同一面板。 如果更改后同一面板失效，你就有一个真正的解决方案。

常见陷阱

• 忘记 ContainerNetworkLog CRD。 在群集中启用容器网络日志不会收集任何内容，直到应用至少一个选择流量的 CRD。
• 尝试使用存储日志来处理已经发生的实时事件。 如果在事件发生之前未启用日志，或者日志未在捕获的筛选器范围内，请在下次事件发生时切换到按需使用的 Hubble 流。
• Cilium 集群中的 L7 仪表板为空。 L7 指标需要群集--acns-advanced-networkpolicies L7 和 同时具备 L7 规则。 CCNP 不支持 L7 规则。 请参阅 “应用 L7 策略”。
• Cilium 上的 DNS 指标为空。 DNS 可见性需要CiliumNetworkPolicy与dns规则（通常与toFQDNs一起使用）。
• matchPattern: "*" 阻止所有 DNS 请求。 不支持裸通配符。 使用前导通配符模式，例如 *.example.com 或 app*.example.com。 请参阅 应用 FQDN 筛选策略。

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 上下文配置深度流量分析、为高级故障排除启用分布式数据包捕获，以及针对特定用例使用基于插件的体系结构自定义功能。

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

了解更多信息

高级容器网络服务 (ACNS)

• 平台概述：什么是 AKS 的高级容器网络服务？
• 设置可观测性：设置容器网络可观测性
• 容器网络指标：容器网络指标概述
• 容器网络日志：容器网络日志概述 和 设置容器网络日志
• 指标筛选（Cilium）：配置容器网络指标筛选

容器网络安全 （Cilium）

• FQDN 筛选：概念 和 应用 FQDN 筛选策略
• 第 7 层策略：概念 和 应用 L7 策略
• 相互TLS（Cilium）：概念 和 配置相互TLS
• 传输中加密：WireGuard 加密概念

数据平面和平台

• 由 Cilium 支持的 Azure CNI:配置由 Cilium 支持的 Azure CNI
• eBPF 主机路由性能：使用 eBPF 主机路由的容器网络性能
• Log Analytics表计划：根据数据使用情况选择表计划

开源工具

• Retina：retina.sh 和 Microsoft Retina GitHub 存储库
• Hubble （Cilium 项目）：Hubble 文档