kubernetes dns 解析超时问题排查

文章目录

@[toc]
事故发起方
事故处理流程
grafana 容器访问 prometheus 的 svc
使用 clusterip 获取请求时间
使用 svc 域名获取请求时间
容器内安装 bind-utils 工具

翻看一系列文档
分析 kubernetes svc 的域名结构

配置 pod 的 dnsConfig

事故发起方

在客户内网机器环境内部署的 grafana 一直获取不到 prometheus 的数据，导致页面一直展示 no data
- 通过 grafana 页面测试 prometheus 数据源验证了这个问题，grafana 一直链接不上 prometheus 数据源

事故处理流程

grafana 容器访问 prometheus 的 svc

配置 curl-format 获取接口访问时间

time_namelookup：DNS 解析时间
time_connect：连接时间，从请求开始到 DNS 解析完毕所用时间。单纯的连接时间 = time_connect - time_namelookup
time_appconnect：建立完成时间，例如 SSL/SSH 等建立连接或者完成三次握手的时间
time_redirect：重定向时间，包括最后一次传输前的几次重定向的 DNS 解析、连接、预传输、传输时间
time_pretransfer： 从开始到准备传输的时间
time_starttransfer：开始传输时间。在 client 发出请求后，服务端返回数据的第一个字节所用的时间

cat <<EOF> curl-format.txt
time_namelookup: %{time_namelookup}\\n
time_connect: %{time_connect}\\n
time_appconnect: %{time_appconnect}\\n
time_redirect: %{time_redirect}\\n
time_pretransfer: %{time_pretransfer}\\n
time_starttransfer: %{time_starttransfer}\\n
----------\\n
time_total: %{time_total}\\n
EOF

使用 clusterip 获取请求时间

获取 prometheus 的 svc 信息(这里理解逻辑就好，namespace 和 svc 的名字大家自己替换成自己的就好)

kubectl get svc -n tool | grep prometheus

返回结果类似下面的样子

prometheus-svc      ClusterIP   10.102.38.55     <none>        9090/TCP             41d

/dev/null 表示空设备，即丢弃一切写入的数据，但显示写入操作成功
-s 表示静默输出

curl -s -w "@curl-format.txt" \
-o /dev/null \
-l "http://10.102.38.55"

返回的结果如下，耗时非常的短

time_namelookup: 0.000
time_connect: 0.000
time_appconnect: 0.000
time_redirect: 0.000
time_pretransfer: 0.000
time_starttransfer: 0.001
----------
time_total: 0.001

使用 svc 域名获取请求时间

curl -s -w "@curl-format.txt" \
-o /dev/null \
-l "http://prometheus-svc.tool.svc.cluster.local"

返回结果如下，耗时 15秒之久

time_namelookup: 15.522
time_connect: 15.522
time_appconnect: 0.000
time_redirect: 0.000
time_pretransfer: 15.522
time_starttransfer: 15.523
----------
time_total: 15.523

容器内安装 bind-utils 工具

bind-utils 工具内有一个 host 命令，可以查看域名解析过程

host -v prometheus-svc.tool.svc.cluster.local

可以看到，总共尝试了五个域名，解析五次才达到我们需要使用的域名

Trying "prometheus-svc.tool.svc.cluster.local.tool.svc.cluster.local"
Trying "prometheus-svc.tool.svc.cluster.local.svc.cluster.local"
Trying "prometheus-svc.tool.svc.cluster.local.cluster.local"
Trying "prometheus-svc.tool.svc.cluster.local.openstacklocal"
Trying "prometheus-svc.tool.svc.cluster.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59444
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;prometheus-svc.tool.svc.cluster.local. IN A

;; ANSWER SECTION:
prometheus-svc.tool.svc.cluster.local. 5 IN A   10.102.38.55

Received 108 bytes from 10.96.0.10#53 in 0 ms
Trying "prometheus-svc.tool.svc.cluster.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26804
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;prometheus-svc.tool.svc.cluster.local. IN AAAA

;; AUTHORITY SECTION:
cluster.local.          30      IN      SOA     ns.dns.cluster.local. hostmaster.cluster.local. 1679994755 7200 1800 86400 30

Received 148 bytes from 10.96.0.10#53 in 0 ms
Trying "prometheus-svc.tool.svc.cluster.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2668
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;prometheus-svc.tool.svc.cluster.local. IN MX

;; AUTHORITY SECTION:
cluster.local.          30      IN      SOA     ns.dns.cluster.local. hostmaster.cluster.local. 1679994764 7200 1800 86400 30

Received 148 bytes from 10.96.0.10#53 in 0 ms

翻看一系列文档

k8s 官方文档中，看到一句话：

DNS 查询可以使用 Pod 中的 /etc/resolv.conf展开。 Kubelet 为每个 Pod 配置此文件。例如，对data的查询可能被展开为data.test.svc.cluster.local。 search 选项的取值会被用来展开查询。要进一步了解 DNS 查询，可参阅 resolv.conf 手册页面

在 resolv.conf 手册中，看到一个参数：

ndots:n
Sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made.
The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it.
The value for this option is silently capped to 15.
意思就是，在进行绝对查询前，必须要为出现的点数设置一个阈值
这个阈值默认为1，意味着优先当前域名先做解析，也就是绝对查询
这个选项的值，默认上限为 15

分析 kubernetes svc 的域名结构

kubernetes 默认的 svc 域名结构为：

<svc-name>.<namespace>.svc.cluster.local
<pod-name>.<svc-name>.<namespace>.svc.cluster.local

可以看到，不带 pod 名称时，域名中有四个点，带 pod 名称时，域名中有五个点

在容器内，通过查看 /etc/resolv.conf 文件可以看到当前的 ndots 设定的值

nameserver 10.96.0.10
search tool.svc.cluster.local svc.cluster.local cluster.local openstacklocal
options ndots:5

在容器内尝试访问来验证

host -v prometheus-f9dd6964b-wzbk4.prometheus-svc.tool.svc.cluster.local

当域名内出现的点数和 ndots 设定的值一致时，走的绝对查询
当域名内出现的点数小于 ndots 设定的值，就会走 /etc/resolv.conf 文件内 search 指定的 dns 服务器，并且逐一拼接到域名后面，最后才会进行绝对查询

Trying "prometheus-f9dd6964b-wzbk4.prometheus-svc.tool.svc.cluster.local"
Received 175 bytes from 10.96.0.10#53 in 0 ms
Trying "prometheus-f9dd6964b-wzbk4.prometheus-svc.tool.svc.cluster.local.tool.svc.cluster.local"
Trying "prometheus-f9dd6964b-wzbk4.prometheus-svc.tool.svc.cluster.local.svc.cluster.local"
Trying "prometheus-f9dd6964b-wzbk4.prometheus-svc.tool.svc.cluster.local.cluster.local"
Trying "prometheus-f9dd6964b-wzbk4.prometheus-svc.tool.svc.cluster.local.openstacklocal"
Host prometheus-f9dd6964b-wzbk4.prometheus-svc.tool.svc.cluster.local.openstacklocal not found: 2(SERVFAIL)
Received 97 bytes from 10.96.0.10#53 in 2 ms

配置 pod 的 dnsConfig

既然问题出在 ndots 参数上，那就尝试修改 pod 的 yaml 文件，通过 kubernetes 官网可以看到 dns 相关的策略

Pod 的 DNS 策略 [ 这些策略可以在 Pod 规约中的 dnsPolicy 字段设置 ]
Default: Pod 从运行所在的节点继承名称解析配置
ClusterFirst: 与配置的集群域后缀不匹配的任何 DNS 查询（例如"www.kubernetes.io"）都会由 DNS 服务器转发到上游名称服务器。
集群管理员可能配置了额外的存根域和上游 DNS 服务器

ClusterFirstWithHostNet: 对于以 hostNetwork 方式运行的 Pod，应将其 DNS 策略显式设置为 ClusterFirstWithHostNet
否则，以 hostNetwork 方式和 ClusterFirst 策略运行的 Pod 将会做出回退至 “Default” 策略的行为
注意：这在 Windows 上不支持

None: 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置
Pod 会使用其 dnsConfig 字段所提供的 DNS 设置

Pod 的 DNS 配置 [dnsConfig 字段是可选的，它可以与任何 dnsPolicy 设置一起使用。但是，当 Pod 的 dnsPolicy 设置为 “None” 时，必须指定 dnsConfig 字段 ]
nameservers：将用作于 Pod 的 DNS 服务器的 IP 地址列表。
最多可以指定 3 个 IP 地址
当 Pod 的 dnsPolicy 设置为 “None” 时，列表必须至少包含一个 IP 地址，否则此属性是可选的。
所列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址

searches：用于在 Pod 中查找主机名的 DNS 搜索域的列表。
此属性是可选的
指定此属性时，所提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中
重复的域名将被删除
Kubernetes 最多允许 6 个搜索域

options：可选的对象列表，其中每个对象可能具有 name 属性（必需）和 value 属性（可选）
此属性中的内容将合并到从指定的 DNS 策略生成的选项
重复的条目将被删除

通过 dnsConfig 来控制 ndots 的值，可以先设定到 4 来验证

dnsConfig:
  options:
    - name: ndots
      value: "4"

重启完容器后，再次进入容器查看 /etc/resolv.conf 文件的内容，可以看到 ndots 的值被修改成 4 了

nameserver 10.96.0.10
search tool.svc.cluster.local svc.cluster.local cluster.local openstacklocal
options ndots:4

继续用 host 命令查看域名解析过程

host -v prometheus-svc.tool.svc.cluster.local

可以看到，直接就走了绝对查询

Trying "prometheus-svc.tool.svc.cluster.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45608
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;prometheus-svc.tool.svc.cluster.local. IN A

;; ANSWER SECTION:
prometheus-svc.tool.svc.cluster.local. 30 IN A  10.102.38.55

Received 108 bytes from 10.96.0.10#53 in 0 ms
Trying "prometheus-svc.tool.svc.cluster.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10840
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;prometheus-svc.tool.svc.cluster.local. IN AAAA

;; AUTHORITY SECTION:
cluster.local.          30      IN      SOA     ns.dns.cluster.local. hostmaster.cluster.local. 1680002970 7200 1800 86400 30

Received 148 bytes from 10.96.0.10#53 in 0 ms
Trying "prometheus-svc.tool.svc.cluster.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48585
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;prometheus-svc.tool.svc.cluster.local. IN MX

;; AUTHORITY SECTION:
cluster.local.          30      IN      SOA     ns.dns.cluster.local. hostmaster.cluster.local. 1680002961 7200 1800 86400 30

Received 148 bytes from 10.96.0.10#53 in 0 ms

用 curl 查看请求时间 [ 容器重启后，之前配置的 curl-format 记得重新生成一次 ]

curl -s -w "@curl-format.txt" \
-o /dev/null \
-l "http://prometheus-svc.tool.svc.cluster.local"

这个时候就跟吃了德福一样丝滑了

time_namelookup: 0.004
time_connect: 0.004
time_appconnect: 0.000
time_redirect: 0.000
time_pretransfer: 0.005
time_starttransfer: 0.006
----------
time_total: 0.006

这个时候，再去 grafana 去测试 prometheus 的数据源就不会报错了

posted @ 2024-09-12 22:54 月巴左耳东阅读(13) 评论(0) 编辑收藏举报来源

刷新页面返回顶部

月巴左耳东

以梦为马|越骑越傻

kubernetes dns 解析超时问题排查

文章目录 @[toc]事故发起方事故处理流程grafana 容器访问 prometheus 的 svc使用 clusterip 获取请求时间使用 svc 域名获取请求时间容器内安装 bind-utils 工具 翻看一系列文档分析 kubernetes svc 的域名结构 配置 pod 的 dnsConfig

文章目录

事故发起方

事故处理流程

grafana 容器访问 prometheus 的 svc

使用 clusterip 获取请求时间

使用 svc 域名获取请求时间

容器内安装 bind-utils 工具

翻看一系列文档

分析 kubernetes svc 的域名结构

配置 pod 的 dnsConfig

文章目录

@[toc]
事故发起方
事故处理流程
grafana 容器访问 prometheus 的 svc
使用 clusterip 获取请求时间
使用 svc 域名获取请求时间
容器内安装 bind-utils 工具

翻看一系列文档
分析 kubernetes svc 的域名结构

配置 pod 的 dnsConfig