Kubernetes 疑难问题排查 - 10s 延迟

现象

首次通过单点登录系统(下称 CAS)访问需求系统, 会等 10s 才能进入到需求系统的页面.

背景概述

1. 单点登录系统位于公司传统环境;

2. 需求系统位于公司 K8S 容器平台(openshift)上;

3. 公司 K8S 容器平台位于公司私有云环境(网络为 SDN);

4. ...

分析过程

该问题比较复杂, 主要是在于网络架构的复杂. 正如上文所述, 这两个系统的交互, 涉及到:

1. 传统网络架构

2. 私有云的 SDN 网络架构

3. 架构在私有云之上的 OpenShift OVS(OpenVSwitch) SDN 网络

举个简单的例子, 如果容器 A 要访问外部系统, 网络流应该是这样的:

eth0(容器 A 的网卡) → vethA → br0→ tun0 → (NAT) 1→ (私有云网络) → (传统网络 F5 -> 传统网络相关虚机)

备注:

br0:

连接到 pod 容器的 OVS 桥设备。OpenShift SDN 还在这个桥上配置一组非子网特定的流规则。

tun0:

OVS 内部端口(br0 上的端口 2)。它被分配给集群子网网关地址，用于外部网络访问。OpenShift SDN 配置 netfilter 和路由规则，允许从集群子网通过 NAT 访问外部网络。

NAT:

网络地址转换

后边的私有云网络和传统环境网络不太熟, 所以就没有详细描述, 实际上网络节点也不少.

目前首先第一步要做的就是缩小范围 -- 尽可能的缩小怀疑点的范围. 方便进一步定位.

具体操作步骤如下:

第一阶段 抓包并分析

经过初步分析，得到如下结论：

1. 用户通过 CAS 的页面点击需求系统, 这时会带着 Ticket 跳转到需求系统:

"GET http://itweb.cloud.example.com.cn/login.jsp?ticket=XX-1144737-F6gZZyxhe0IfKxBJS4zjuf9Csz4-cas2 HTTP/1.1"

2. 我们首先通过 Chrome 的 F12 开发工具来进行查看，发现正是上边的这个请求耗时 10s，且 10s 都是在Waitting(TTFR) 如下图: 

3. 以上请求是在需求系统内进行处理, 且我们之前已经了解到未上容器之前不存在这个问题, 所以基本排除需求系统应用问题的可能性. 那么就需要抓取需求系统的 APP 所在容器(以下简称 pod a)的网络包, 确定是不是网络问题.

4. 通过tcpdump命令抓取 pod a 网卡的所有流量. 并且在这期间复现该问题.

5. 通过 WireShark 打开进行分析, 由于知道是上边的请求有问题, 所以专门看这个请求的 TCP 流. 结果如下:

6. 如上图标红处的时间, 可以明显的看到, pod a(IP 为: 10.131.0.244)收到上述的请求后, 返回了 http code 302, 然后进行 TCP 的 3 次握手. 然后就出问题了, PSH+ACK的动作是在 10s 后才发出的!!!

7. 这一次, 根据源 IP(pod A)和目的 IP(可以理解为 K8S Ingress 的 tun0 的 IP), 初步判定是: 容器 -> Ingress 之间出现了 10s 的延迟.

备注:

关于 K8S 上网络抓包，后续会再写一篇文章: 《K8S 上网络抓包的 3 种方式》. 敬请期待~

第二阶段 细化分析和排除阶段

上一阶段, 初步确定了是: 容器 -> Ingress 之间出现了 10s 的延迟.

那么后续就计划对者之间的网络进一步的进行分析. 为此准备了 2 套方案:

1. 排除法, 由于 pod A 和 Ingress 不在同一台虚机上, 而这两台虚机之间的交互就会牵扯到: OpenShift 的 OVS 网络以及私有云的 SDN 网络. 所以希望通过将 pod A 调度到 Ingress 所在的主机上, 观察结果来进行排除.

    a. 如果调度到同一台主机后, 仍然存在该问题, 则排除私有云 SDN 出问题的可能性;

    b. 如果调度后问题解决, 那么就可能是: OpenShift 的 OVS 网络或私有云的 SDN 网络的问题.

2. 细化分析. 之前只是简单抓了 pod A 的包. 后续计划将涉及到的所有网络节点进行抓包, 包括:

    a. pod A

    b. pod A 所在主机

    c. 私有云 SDN 相关网络设备

    d. Ingress 所在主机

    e. Ingress pod

但是在这一阶段碰到了各种困难, 使得这 2 个方案都没有最终被执行.

所以我们继续希望通过之前的那个网络包, 分析到更多细节, 我们从 2 个方面进行:

1. 请网络组老师看一下这个网络包, 网络组老师的反馈是: 基本断定是 pod A 的问题, 不需要再抓其他包

2. 联系需求系统和 CAS 项目组老师, 进一步了解业务流程细节. 期望获取更多细节.

而这 2 个方面也取得了比较大的收获!

第三阶段 业务流程梳理

备注:

重点关注首次登录需求系统这个业务流程.

有的用户是先访问 CAS, 登录 CAS, 再通过 CAS 跳转进入需求系统;

有的用户是先访问 CAS, 不登陆, 通过 CAS 跳转到需求系统, 再反过来登录验证并进入需求系统;

有的用户是直接访问需求系统, 跳转到单点登录, 登录认证后进入需求系统.

有以上三种情况, 本质上都是一样的. 就是需求系统需要和 CAS 交互.

下边选择一个最常用的流程做说明.

1. 用户访问并登录单点登录系统;

    a. 此时用户会获取到一个 Ticket, 格式实例如下: 

  XX-1144737-F6gZZyxhe0IfKxBJS4zjuf9Csz4-<instancename>

    b. 期间用户并不会访问需求系统

2. 用户通过 CAS 的页面点击需求系统, 这时会带着 Ticket 跳转到需求系统: 

"GET http://itweb.cloud.example.com.cn/login.jsp?ticket=XX-1144737-F6gZZyxhe0IfKxBJS4zjuf9Csz4-cas2 HTTP/1.1"

3. 需求系统收到该请求, 会回访 CAS 验证: 

“GET http://10.1.XX.XX:XXXX/casserver/serviceValidate?hostnameVerifier=org.jasig.cas.client.ssl.AnyHostnameVerifier&ticket= XX-1144737-F6gZZyxhe0IfKxBJS4zjuf9Csz4-cas2&encoding=UTF-8&service=http%3A%2F%2Fitweb.cloud.example.com.cn%2F”

4. CAS 验证后返回结果给需求系统:

    a. 验证通过, 正常登录, 进入需求系统主页面;

    b. 验证不通过, 提示你无权访问该系统.

项目组老师重点提到, 根据他们的日志来看, 是第 3 步慢了 10s.

第四阶段 定位

和网络组老师和项目组老师沟通受益颇多:

• 网络组老师: 基本断定是 pod A 的问题

• 项目组老师: 是第 3 步(需求系统回访 CAS 验证)慢了 10s.

我们决定再次查看之前抓取的网络包, 仔细看一下 CAS 访问单点登录系统后, 网络上都发生了什么. 而这一次, 我们终于抓到了蛛丝马迹!

这次不再关注某一个 TCP 流, 而是关注接收到请求后, 都发生了什么.

1. 收到请求后, pod A 要访问 CAS 10.1.XX.XX, 注意这一次: 不是直接访问 CAS 的 IP, 而是先做反向 DNS 解析!!!

如下图:

2. 第一次反向 DNS 解析, DNS server 没返回任何信息, 5s 超时. (网络流比较长, 就不附图了, 反正接下来 5s 都没有看到 DNS server 有返回信息). 开始进行第二次反向 DNS 解析, 如下图:

3. 两次 DNS 反解析失败后, 第三次就不做反向 DNS 解析了, 而是直接访问, 并快速得到结果. 所以每次都是等待 10s 才进入系统. 如下图:

原因总结

需求系统访问单点登录 10.1.XX.XX:XXXX 花了 10s, 是因为那次请求会进行反向 dns 解析。结果解析 2 次不成功。dns 一次解析超时是 5s… 第三次就不解析了直接访问. 所以就是每次等 10s.

备注:

其实应该不是需求系统会做反向 DNS 解析, 而是它部署在 WebLogic 中间件上, WebLogic 中间件会进行反向 DNS 解析.

我之所以知道这个事情, 是因为有次某寿险公司有一次生产 DNS 出故障了, 排查的时候发现海量的反向 DNS 解析来自 weblogic.

有时间可以再来一篇相关的内容.

解决方案

1. 尝试在需求系统启动项中加入禁止反向解析的参数, 测试不生效.

2. Openshift 每台节点都会启动一个 dnsmasq 进程用作集群内部 dns 处理, 将 worker 节点的 dnsmasq 加入如下配置并重启. 使得反向 DNS 解析成功. 则问题解决.

ptr-record=XX.XX.1.10.in-addr.arpa, 10.1.XX.XX

总结

至此, 我们完整的梳理了需求系统首次登录要等 10s 的问题, 分析过程信息量比较大, 牵涉的环节也比较多. 其实最后定位的原因, 也和 K8S 的网络, 私有云的网络等新技术没啥关系. 问题还是老问题.

1. 强烈不建议将传统软件硬塞入容器内, 坑不止这一个; 

2. K8S 采用后, 网络复杂性会大幅上升, 分析 K8S 上网络问题, 网络分析手段必不可少;

3. 分析问题过程中, 三人行, 必有我师焉, 多与其他老师交流沟通, 发散思维, 避免走入死胡同.