AKS中Retina Agent导致节点网络吞吐量下降30%的问题分析

AKS中Retina Agent导致节点网络吞吐量下降30%的问题分析

AKS Azure Kubernetes Service 项目地址: https://gitcode.com/gh_mirrors/ak/AKS

问题背景

在Azure Kubernetes Service(AKS)环境中，用户在进行控制平面升级后，发现部分集群出现了网络吞吐量显著下降的情况。经过排查，发现问题与Retina Agent的自动安装有直接关联。当Retina Agent被部署到节点后，网络密集型Pod的带宽性能下降至原有水平的30%左右。

技术现象

通过观测数据可以清晰地观察到：

1. Retina Agent部署后，节点网络吞吐量立即出现明显下降
2. 移除Retina Agent后，网络性能恢复到正常水平
3. 问题在Kubernetes 1.29及以上版本中较为突出

根本原因分析

Retina Agent是AKS中与Azure Monitor集成的一个组件，主要用于网络可观测性。它基于eBPF技术实现，能够提供深入的网络观测能力。然而，eBPF程序在内核层面的运行会带来一定的性能开销：

1. 内核处理开销：eBPF程序需要在内核空间对每个网络包进行处理，增加了CPU使用率
2. 锁竞争：网络数据包处理路径上的额外锁可能导致性能瓶颈
3. 缓存失效：额外的处理步骤可能导致CPU缓存效率降低

微软内部测试数据显示：

• 同一节点内Pod间通信(INTRA节点流量)性能下降约20%
• 跨节点Pod间通信(INTER节点流量)影响较小

解决方案

目前官方提供的解决方案包括：

1. 禁用Azure Monitor Metrics： 通过AKS CLI工具执行命令可禁用观测功能，这也会连带移除Retina Agent。但此方案会同时失去控制平面观测能力。

2. 使用准入控制Webhook： 通过自定义准入控制器添加节点选择器，阻止Retina Agent调度到节点。这种方法可以保留观测功能的同时避免性能影响。

3. 等待官方修复： 微软Retina团队正在构建性能测试管道，未来版本可能会优化eBPF程序的性能影响。

最佳实践建议

对于生产环境中的网络敏感型应用：

1. 在升级到Kubernetes 1.29+版本前，评估网络观测需求
2. 如果必须使用观测功能，考虑在非关键节点部署Retina Agent
3. 密切观测节点网络性能指标，建立性能基线
4. 关注AKS更新日志，及时获取Retina Agent的性能优化版本

未来展望

随着eBPF技术的不断成熟和优化，预计此类性能问题将逐步缓解。微软已公开表示正在建设专门的性能测试管道，未来Retina Agent的性能特性将更加透明和可预测。

AKS Azure Kubernetes Service 项目地址: https://gitcode.com/gh_mirrors/ak/AKS