AKS Windows节点池与IIS虚拟机托管应用的性能衰减问题

• 容器运行时的额外开销：Windows容器的containerd运行时本身会带来性能损耗，尤其是进程隔离模式下，资源隔离、容器调度的隐性开销会占用部分处理能力——哪怕节点CPU使用率和原生VM差不多，应用实际能用到的有效算力还是会打折扣。可以试试切换到Hyper-V隔离模式对比（不过Hyper-V隔离的开销可能更高），或者调整containerd的CPU调度优先级参数。

• 网络转发层的损耗：AKS的Service网络转发（比如kube-proxy使用的WinNAT）比原生VM直接访问多一层处理逻辑。虽然单请求延迟看起来接近，但累积下来每请求的网络处理开销会拉低整体吞吐量。可以直接访问节点IP上的容器端口，绕开AKS Service，看看吞吐量能不能接近原生VM的水平，以此验证是不是网络转发环节的问题。

• .NET Framework容器配置优化不足：默认的Windows容器镜像可能没针对.NET Framework 4.8做适配优化，比如ASP.NET注册不完整，或者IIS应用池的队列长度、进程模型等配置和原生VM不一致。可以自定义镜像，执行aspnet_regiis.exe -ir确保ASP.NET正确注册，同时把应用池配置调成和原生VM完全一致。

• Pod资源限制的影响：检查AKS Pod的CPU请求和限制是否和节点实际可用资源匹配。如果Pod的CPU限制设得过低，哪怕节点CPU使用率看起来相近，容器内部的CPU调度也会被限制，导致应用没法充分利用硬件资源。试试移除CPU限制（或者设成和节点可用CPU一致），再重新测试吞吐量。

• 文件系统IO差异：Windows容器使用的存储驱动（比如Windows版overlayfs）比原生VM的NTFS文件系统IO开销更高，如果应用涉及较多文件读写操作，这部分差异会直接影响吞吐量。可以把应用的静态文件、依赖文件挂载到HostPath，使用节点本地的NTFS存储，对比性能变化。

内容的提问来源于stack exchange，提问作者Petr Kozelek