升级Kubernetes至1.28.2后Azure AD B2C配置获取失败求助

核心定位 #

报错System.Net.Sockets.SocketException (11): Resource temporarily unavailable明确指向网络层面的连接失败，而非Azure AD B2C的认证配置问题——毕竟降级K8s、浏览器直接访问都能正常获取配置，重点排查Kubernetes 1.25.2到1.28.2版本间的网络栈变更点。

可能原因及解决办法 #

1. CoreDNS配置或解析策略变更 #

K8s 1.26+对CoreDNS的默认配置做了调整，比如新增ready插件、修改缓存逻辑，或者集群DNS的ndots参数设置导致跨域域名解析超时：

• 检查Pod的DNS配置：执行kubectl exec <pod-name> -- cat /etc/resolv.conf，对比新旧集群的nameserver、search、ndots参数。若ndots值过高（比如默认5），会优先在集群内部域名空间查找，延迟跨域解析。
• 手动验证解析：在故障Pod内执行nslookup mydirectory.b2clogin.com，确认是否能正常返回IP。若解析失败，查看CoreDNS Pod的运行日志，排查是否存在DNS转发故障。

2. CNI插件版本不兼容 #

K8s 1.28对容器网络插件（CNI）的版本要求更高，旧版本的Calico、Flannel等插件可能和新K8s版本存在网络转发逻辑冲突：

• 确认CNI适配性：比如Calico需要v3.25+才能兼容K8s 1.28，若使用旧版本插件，同步升级到对应兼容版本。
• 测试出站连通性：在Pod内执行curl -v https://mydirectory.b2clogin.com/mydirectory.onmicrosoft.com/B2C_1A_MYPOLICY/v2.0/.well-known/openid-configuration，观察是否能建立TCP连接，是否出现超时或连接被拒绝的情况。

3. Kube-proxy模式或节点防火墙规则变更 #

K8s 1.25到1.28期间，kube-proxy的默认模式可能从iptables切换到ipvs，或者iptables规则生成逻辑变化，导致出站流量被拦截：

• 检查kube-proxy模式：执行kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode，对比新旧集群的模式。若为ipvs模式，确认节点已安装ipvsadm工具，且ipvs规则正常生成。
• 排查节点防火墙：检查节点的iptables规则，确认是否允许Pod出站到443端口，没有被默认DROP规则拦截。

4. .NET HttpClient的环境适配问题 #

K8s 1.28使用的容器基础镜像可能更新了系统库（如libcurl），导致.NET默认的HttpClient Handler在新环境下出现套接字复用或连接池问题：

• 显式配置HttpClient Handler：在Startup.cs中添加以下代码，强制调整连接池参数：

services.AddHttpClient().ConfigurePrimaryHttpMessageHandler(() =>
{
    return new SocketsHttpHandler
    {
        PooledConnectionLifetime = TimeSpan.FromMinutes(5),
        PooledConnectionIdleTimeout = TimeSpan.FromMinutes(2),
        MaxConnectionsPerServer = 10
    };
});

• 降级容器基础镜像：若使用官方.NET镜像，尝试切换到旧集群使用的同版本镜像（比如从6.0-bookworm-slim降级到6.0-bullseye-slim），验证是否解决问题。

5. 出站网络策略限制 #

K8s 1.28可能默认启用了更严格的网络策略，或管理员新增了出站规则，阻止Pod访问外部HTTPS服务：

• 检查命名空间网络策略：执行kubectl get networkpolicy -n <your-namespace>，确认是否存在拒绝出站到mydirectory.b2clogin.com的规则。
• 临时验证：删除或禁用相关NetworkPolicy，测试服务是否能正常获取OpenID配置。

排查优先级建议 #

优先从DNS解析和容器出站连通性入手，通过Pod内的基础网络诊断（nslookup、curl、telnet）定位具体是解析失败还是连接失败，再针对性解决。

内容的提问来源于stack exchange，提问作者Joe W