K8S Pod读取SQL Server大记录耗时久，IIS环境瞬时完成的原因排查

我在SQL Server中创建了如下表：

CREATE TABLE [dbo].[MyTable]
(
    [Ticket] [uniqueidentifier] NOT NULL,
    [UserID] [int] NOT NULL,
    [Progress] [int] NOT NULL,
    [Created] [datetime2](7) NOT NULL,
    [KeepRes] [bit] NOT NULL,
    [Result] [nvarchar](max) NULL,
    [ResultFetched] [datetime2](7) NULL,
    [CorrelationID] [varchar](100) NULL,

    CONSTRAINT [PK_MyTable] 
        PRIMARY KEY CLUSTERED ([Ticket] ASC)
                    WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
                          IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
                          ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
)

该表的Result字段可存储300MB左右的大数据。我使用.NET6/C#结合Entity Framework Core，通过主键查询该表的代码如下：

public void QueryTable(Guid ticket)
{
    using (MyDBContext db = new MyDBContext())
    {
        var res = db.MyTable.Find(ticket);
        Console.Write("Res found:" + (res != null));
    }
}

应用部署在两个环境，均指向同一SQL Server 2014实例：

• 运行于Windows Server 2014的IIS
• K8S Pod

性能差异表现 #

• 当查询记录的Result字段大于500KB时：IIS环境查询耗时不足1秒，K8S Pod环境耗时超1分钟
• 当Result字段小于500KB（约10KB）时：两个环境查询耗时均不足1秒

环境网络拓扑 #

所有环境均部署在一台Windows Server 2012 Data Center R2物理服务器（IP 10.0.1.1）上，该服务器同时运行SQL Server：

• IIS部署在VMware Workstation 15 Player创建的Windows Server 2016 Datacenter虚拟机（IP 10.0.1.2）中
• K8S环境由3台VMware Workstation 15 Player创建的Ubuntu Server 20.04虚拟机组成，IP分别为10.0.1.10（主节点）、10.0.1.11和10.0.1.12（工作节点）；Pod使用K8S内部IP，连接字符串指向物理服务器IP 10.0.1.1

额外实验结果 #

1. 将应用部署到另一K8S集群，连接另一同配置SQL Server实例，查询性能与IIS环境相当
2. 使用Python的mssql-cli工具：在K8S工作节点上查询耗时不足1秒，在Pod内查询耗时超1分钟

核心结论：当前K8S集群的Pod网络栈存在大流量传输瓶颈 #

从实验结果可明确锁定问题出在当前K8S集群的Pod网络层面，依据如下：

1. 同一K8S集群内的网络位置对比：工作节点直接查询性能正常，但Pod内查询大字段慢——排除SQL Server本身、物理服务器网络、客户端工具/代码通用性的问题（EF Core和mssql-cli在Pod内都慢）
2. 不同K8S集群对比：另一K8S集群性能正常——说明不是K8S本身的问题，而是当前集群的网络配置/插件存在异常
3. 数据量相关性：仅大字段（>500KB）出现性能差异——符合网络传输中MTU配置不合理、TCP窗口大小受限、网络转发开销过大等问题的特征：小数据量可通过单包或少量包传输，延迟不明显；大数据量需大量分包，瓶颈被放大

可能的具体网络问题点 #

• CNI插件配置错误：当前K8S集群使用的网络插件（如Flannel、Calico等）MTU设置过小，导致大数据包频繁分片，大幅增加传输开销
• TCP参数未优化：Pod内的TCP窗口大小、拥塞控制算法未针对大流量场景优化，限制了数据传输速率
• VMware虚拟机网络配置不合理：K8S节点的VMware虚拟机网卡类型、带宽限制、混杂模式设置异常，间接影响Pod网络性能
• 不必要的网络规则：K8S网络策略或防火墙存在多余的拦截、转发规则，增加大流量的处理延迟

验证与解决建议 #

1. 检查Pod的MTU设置：在Pod内执行ip a查看网卡MTU值，对比物理服务器、IIS虚拟机的MTU（通常为1500），若Pod MTU过小，需调整CNI插件的MTU配置
2. 测试Pod与SQL Server的带宽：在Pod内使用iperf3等工具测试与10.0.1.1的带宽，确认是否远低于物理节点到SQL Server的带宽
3. 排查CNI插件日志：查看当前K8S集群网络插件的日志，检查是否存在转发错误、性能告警
4. 临时绕过Pod网络验证：将应用直接部署在K8S工作节点上（而非Pod内），若性能恢复正常，可彻底确认是Pod网络栈的问题

内容的提问来源于stack exchange，提问作者Cristiano Ghersi