默认情况下，OpenShift节点是否提供dns服务？

Question

我有一个OpenShift，集群，并且在访问日志时定期获得：

worker1-sass-on-prem-origin-3-10 on 10.1.176.130:53: no such host" kube doing a connection to 53 on a node.

我也经常会不时在Pod中看到tcp: lookup postgres.myapp.svc.cluster.local on 10.1.176.136:53: no such host错误，这又让我认为，当访问内部服务端点时，pod，客户端和其他与Kubernetes相关的服务实际上会与DNS服务器通信假定该虚拟机在运行了这些Pod的给定节点上运行。

更新

在给定节点上查看我的一个pod，我在resolv.conf中找到了以下内容（我必须ssh并运行docker exec才能获得此输出-由于oc exec由于此问题而无法正常工作）。

/etc/cfssl $ cat /etc/resolv.conf 
nameserver 10.1.176.129
search jim-emea-test.svc.cluster.local svc.cluster.local cluster.local bds-ad.lc opssight.internal
options ndots:5

因此，看来在我的集群中，容器具有自引用的resolv.conf条目。该集群是使用 openshift-ansible 创建的。我不确定这是否是特定于基础的，或者它是否确实是openshift节点如何工作的基本方面，但是我怀疑是后者，因为我没有从上游openshift-ansible对我的可完成工作流程进行任何重大自定义食谱。

Answer 1

是的，openshift中每个节点上的DNS都是正常的。

对于openshift ansible部署来说，在每个节点上部署dnsmasq服务似乎是正常的。

详细信息。

下面的https://github.com/openshift/openshift-ansible/pull/8187是有启发性的，以举例说明如何影响事物。无论如何，如果本地节点的dnsmasq由于某种原因在起作用，这将阻止在该节点上运行的容器正确解析群集中其他容器的地址。

深入了解dnsmasq“吸烟枪”

检查单个节点后，我发现实际上确实有一个进程绑定到端口53，它是dnsmasq。因此，

[enguser@worker0-sass-on-prem-origin-3-10 ~]$ sudo netstat -tupln | grep 53 tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 675/openshift

而且，dnsmasq在本地运行：

[enguser@worker0-sass-on-prem-origin-3-10 ~]$ ps -ax | grep dnsmasq 4968 pts/0 S+ 0:00 grep --color=auto dnsmasq 6994 ? Ss 0:22 /usr/sbin/dnsmasq -k [enguser@worker0-sass-on-prem-origin-3-10 ~]$ sudo ps -ax | grep dnsmasq 4976 pts/0 S+ 0:00 grep --color=auto dnsmasq 6994 ? Ss 0:22 /usr/sbin/dnsmasq -k

最后一个线索，resolv.conf本身甚至将本地IP地址添加为名称服务器...而且显然是借用到了可启动的容器中。

 nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh
 Generated by NetworkManager
search cluster.local bds-ad.lc opssight.internal
 NOTE: the libc resolver may not support more than 3 nameservers.
 The nameservers listed below may not be recognized.
nameserver 10.1.176.129

解决方案（在我的具体情况下）

在我的情况下，发生这种情况是因为本地名称服务器正在使用

的ifcfg（您可以在/ etc / sysconfig / network-scripts /中看到这些文件）。

[enguser@worker0-sass-on-prem-origin-3-10 network-scripts]$ cat ifcfg-ens192 
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=ens192
UUID=50936212-cb5e-41ff-bec8-45b72b014c8c
DEVICE=ens192
ONBOOT=yes

但是，我内部配置的虚拟机无法解析PEERDNS记录提供给它们的IP。

最终，解决方法是与我们的IT部门合作，以确保我们对kube集群的权威域可以访问数据中心中的所有IP地址。

对：53查找错误的通用修复...

如果您尝试kubectl或OC日志/ exec时看到：53记录错误，那么您的apiserver可能无法通过其IP地址与kubelet连接 。

如果您看到：53在其他位置记录错误，例如 pod内部，则这是因为您的pod使用其自己的本地DNS无法解析内部群集IP地址。这可能仅仅是因为您有一个过时的控制器正在寻找不再存在的服务，否则，您在kubernetes dns实现级别上会感到疲倦。