【DNS】k8s pod 无法解析域名导致接口调用失败问题处理

某个接口调用失败，在pod中无法解析被调用域名

$  kubectl  get pods  -n  test | grep  test-service

test-service-5fd6cdb54c-n2x8c              1/1     Running   0          81d
test-service-5fd6cdb54c-v8t84              1/1     Running   0          81d

$ kubectl exec -it  test-service-5fd6cdb54c-n2x8c      -n yzj  --  cat   /path/to/logs/server.log |   grep  "/api/xxx"

[2023-11-01 12:39:15.146] ERROR [push-pool-1-thread-14] c.y.c.p.p.Notification - 推送异常 url:https://www.example.com/api/xxx?key=123456，header:{Content-Type=application/json}，payload:xxxxxx，param:null

$ kubectl exec -it  test-service-5fd6cdb54c-n2x8c     -n  test  --  bash

curl   -X  GET   -H "Content-Type: application/json"   -d  'XXX'   https://www.example.com/api/xxx?key=123456    -vvv

* Could not resolve host: www.example.com
* Closing connection 0
curl: (6) Could not resolve host: www.example.com

从输出可知： 在pod中无法解析 www.example.com

在pod 中 cat /etc/resolv.conf 确认 DNS 主备 ，无法解析 www.example.com

nameserver   192.168.1.52
nameserver   192.168.1.51

需要在 pod 使用的 DNS 主备中添加对 www.example.com 解析

如何检测 修改后bind9配置文件语法？

要检测bind9配置文件的语法，可以使用以下命令：

named-checkconf    /etc/named.conf

这个命令会检查指定的配置文件（在上面的例子中是/etc/named.conf）的语法是否正确。如果配置文件中存在语法错误，它将显示相应的错误消息。

在运行该命令之前，请确保你对bind9服务进行了适当的安装和配置，并且将实际的配置文件路径替换为你的配置文件的路径。

通过使用named-checkconf命令来检测语法错误，你可以在重新启动bind9服务之前先确保配置文件的正确性，这样可以避免由于语法错误导致的服务启动问题。

如果在运行 named-checkconf /etc/named.conf 命令后没有任何输出，这表示你的配置文件中没有语法错误。

当配置文件中没有语法错误时，named-checkconf 命令不会输出任何内容。这是因为该命令仅在发现配置文件中的语法错误时才会输出相应的错误消息。

因此，如果你没有看到任何输出，说明你的 /etc/named.conf 配置文件中的语法是正确的，可以放心地重启 bind9 服务。请确保你已经进行了适当的配置和修改。

DNS 从节点要多久才能解析？

DNS 主节点：

nslookup  www.example.com  192.168.1.51
Server:         192.168.1.51
Address:        192.168.1.51#53

Name:   www.example.com
Address: 192.168.1.110

DNS 从节点：

nslookup   www.example.com 192.168.1.52
Server:         192.168.1.52
Address:        192.168.1.52#53

** server can't find www.example.com: NXDOMAIN

根据提供的信息，主节点可以成功解析 www.example.com，而从节点无法解析，返回 NXDOMAIN 错误。这可能是由于从节点尚未同步到最新的 DNS 数据。

通常情况下，DNS 从节点会定期从主节点同步最新的 DNS 数据。这个同步的频率可以通过配置文件中的参数进行设置。默认情况下，从节点会定期尝试与主节点同步，通常是每几分钟或每几小时一次。

因此，从节点要多久才能解析取决于从节点的同步频率设置以及最后一次同步的时间。如果从节点刚刚启动或最后一次同步时间较久，可能需要等待一段时间才能完成同步并获取最新的 DNS 数据。

你可以检查从节点的配置文件，查看同步频率的设置，并确保从节点能够正确连接到主节点。另外，可以手动触发从节点执行一次立即同步，以加快获取最新数据的过程。具体的配置和操作可能因为你使用的 DNS 软件而有所不同，请参考相关文档或手册进行操作。

如何在从节点，手动触发一次同步？

在从节点上手动触发一次同步的方法取决于你使用的 DNS 软件。以下是一些常见的 DNS 软件及其对应的手动触发同步的方法：

1. BIND
   对于 BIND DNS 软件，可以使用 rndc 命令手动触发同步。首先，确保 rndc 配置文件中指定了正确的主节点的 IP 地址和密钥。然后，运行以下命令触发同步：

rndc sync

或者：

rndc retransfer <zone>

其中 <zone> 是要触发同步的区域名称。

2. PowerDNS
   对于 PowerDNS，可以使用 pdns_control 命令手动触发同步。运行以下命令触发同步：

pdns_control notify <zone>

其中 <zone> 是要触发同步的区域名称。

3. Knot DNS
   对于 Knot DNS，可以使用 knotc 命令手动触发同步。运行以下命令触发同步：

knotc zone-notify <zone>

其中 <zone> 是要触发同步的区域名称。

请注意，上述命令中的 <zone> 是需要手动同步的区域名称。根据你的配置，可能需要指定正确的区域名称。
另外，确保从节点能够与主节点建立正常的通信和连接，以便触发同步操作。

DNS 主从添加对 www.example.com解析后，在pod中做接口调用测试

$ kubectl exec -it  test-service-5fd6cdb54c-n2x8c     -n  test  --  bash

 curl  -sSL   -X   POST  -H "Content-Type: application/json" --resolve   www.example.com:443:192.168.1.110  -d  'XXX'   https://www.example.com/api/xxx?key=123456

* Added www.example.com:443:192.168.1.110 to DNS cache
* Hostname www.example.com was found in DNS cache
*   Trying 192.168.1.110:443...
* Connected to www.example.com (192.168.1.110) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
  ....
 Host: www.example.com
> User-Agent: curl/7.79.1
> Accept: */*
> Content-Type: application/json
> Content-Length: 5740
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Wed, 01 Nov 2023 06:07:15 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Expires: 0
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< X-XSS-Protection: 1; mode=block
< Pragma: no-cache
< X-Frame-Options: DENY
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< X-Content-Type-Options: nosniff
< Cache-Control: no-cache
< Cache-Control: private
< Server: elb
<
* Connection #0 to host cpcdz.conch.cn left intact

{"success":true,"data":null,"variables":{},"message":"发送成功","code":200,"url":null,"errorStackTrack":null,"time":"2023-11-01T06:06:48.831Z"}