一. 介绍
在初次接触OpenShift的时候，一定会被DNS搞得晕头转向，本文将对OpenShift中DNS的原理及配置做详细的解析。
DNS在OpenShift中经历了多次改变，但原理是相通的，下面对这些改变做一个简单的说明：
3.2版本以前：OpenShift内部的Skydns监听在master 53端口，负责解析k8s service等域名，需要手动配置dnsmasq完成skydns和外部dns的整合，pod内部DNS直接使用node节点的DNS配置。
3.2版本到3.6版本之前：OpenShift内部的Skydns监听在master 8053端口，自动配置dnsmasq实现skydns和外部dns整合，并且node节点全部使用本机的dnsmasq作为pod内部的DNS。
3.7版本之后：在3.6版本的基础上，将skydns的配置增加到了openshift-node的启动文件中。
本文将对OCP 3.7以上版本进行详细说明。
二. 名词说明
为了后文便于描述，需要明确OpenShift中涉及到的DNS。
1）Skydns:运行在OpenShift进程内部，主要用于解析Service域名的DNS服务器，只是实现了DNS协议，并非真实保存DNS A记录。Service域名格式为..svc.cluster.local。Skydns运行在所有Master节点，监听8053端口。
2）其他上游DNS: 无论是用于解析企业内部自定义域名的内网DNS或者是公网DNS，都归于这一类。
三. 机制说明
本文会涉及到linux dnsmasq服务，如果对该服务不了解，建议先自行搜索学习，本文不再赘述。
OpenShift在安装完成后，master会自动运行skydns的server。每个Node节点都会使用自己的IP地址作为DNS server，pod中也同样使用容器所在节点的IP作为DNS server。OpenShift在安装的时候依赖于NetworkManager服务完成dnsmasq自动配置，请确保该服务保护启动状态，并保证在网卡配置文件中不要添加 NM_CONTROLLED=no参数。
OpenShift节点与DNS相关的重要文件如下：
1) /etc/resolv.conf
2) /etc/sysconfig/network-scripts/ifcfg-eth0（以eth0为例）
3) /etc/dnsmasq.d/node-dnsmasq.conf
4) /etc/dnsmasq.d/origin-dns.conf
5) /etc/dnsmasq.d/origin-upstream-dns.conf
6) /etc/origin/node/node-config.yaml
7) /etc/origin/node/node-dnsmasq.conf
8) /etc/origin/node/resolv.conf
9) /etc/systemd/system/atomic-openshift-node.service
10) /etc/hosts
下面将以OCP计算节点192.168.182.190分别解析上述文件的作用及来源。
1）/etc/resolv.conf
在Linux操作系统中使用/etc/resolv.conf设置本机使用的DNS server。
1 |
# cat /etc/resolv.conf |
该文件由NetworkManager服务自动生成，在重启network或NetworkManager服务的时候都会执行/etc/NetworkManager/dispatcher.d/99-origin-dns.sh重新生成该文件，所以不要手动修改这个文件。可以看到将宿主机的nameserver设置为本机ip地址（该地址为宿主机默认网关的网卡IP地址），也就是宿主机所有DNS解析均通过192.168.182.190的53端口实现。而宿主机的53端口由dnsmasq服务监听。
文件作用：配置宿主机节点的nameserver为本机IP，使得宿主机可以使用本机的dnsmasq服务解析。且该文件在生成后会自动复制到/etc/origin/node/resolv.conf，该文件在pod启动时会被添加为pod中的/etc/resolv.conf。由node节点配置文件/etc/origin/node/node-config.yaml中配置,如下图所示：
2）/etc/dnsmasq.d/*
由resolv.conf配置可知，所有节点使用dnsmasq作DNS server，我们可以查看dnsmasq的配置文件。
Dnsmasq服务作为轻量级DNS server，可以作为DNS的反向代理。在Openshift中dnsmasq代理如下几类DNS（配置文件在目录/etc/dnsmasq.d/下）：
第一类：节点上的/etc/hosts记录，dnsmasq默认行为。
第二类：skydns，解析OCP集群内部的service域名。由/etc/dnsmasq.d/node-dnsmasq.conf文件配置，文件内容如下:
1 |
server=/in-addr.arpa/127.0.0.1 |
该文件由/etc/systemd/system/atomic-openshift-node.service维护，当atomic-openshift-node服务启动时由ExecStartPre将/etc/origin/node/node-dnsmasq.conf拷贝到/etc/dnsmasq.d/下，并通过dnsmasq dbus开启cluster.local两个域名的解析。/etc/origin/node/node-dnsmasq.conf在ansible安装OCP时候生成，绝对不要删除。当atomic-openshift-node服务停止时由ExecStopPost删除/etc/dnsmasq.d/node-dnsmasq.conf，并通过dnsmasq dbus关闭cluster.local两个域名的解析。
该文件将in-addr.arpa和cluster.local两个域的解析转发到127.0.0.1的53端口。而宿主机的127.0.0.1的53端口由atomic-openshift-node服务监听，由node节点配置文件/etc/origin/node/node-config.yaml中配置,如下图所示：
注：node服务监听127.0.0.1:53，dnsmasq监听192.168.182.190:53，并不冲突，如果dnsmasq配置错误，将127.0.0.1的53端口占用，则会导致node服务启动失败。
在节点或者POD内部解析cluster.local和in-addr.arpa两个域的域名，则会通过dnsmasq将解析请求转发到atomic-openshift-node进程，atomic-openshift-node进程与master节点8053端口通信获取解析结果。注意，此时node与master的8053通信会直接连接master ip地址，如果是多个master，默认会轮询，不会经过多个master前面的负载均衡，在开启防火墙规则时需要注意。
第三类：其他上游DNS，上游DNS可以添加多个内部DNS server和外部DNS server。
由文件/etc/dnsmasq.d/origin-upstream-dns.conf配置。该文件由NetworkManager服务自动生成，不要手动修改。
在NetworkManager启动时，会获取/etc/sysconfig/network-scripts/ifcfg-eth0中配置的DNS1、DNS2…DNSn，将这些server配置在/etc/dnsmasq.d/origin-upstream-dns.conf中，这样dnsmasq就可以解析任意的上游DNS server。这些DNS server可以是内网DNS server也可以是外部DNS server。如下图：
另外，还有一个dnsmasq的配置文件/etc/dnsmasq.d/origin-dns.conf，文件内容如下：
1 2 3 4 5 6 7 8 9 10 |
no-resolv domain-needed no-negcache max-cache-ttl=1 enable-dbus dns-forward-max=5000 cache-size=5000 bind-dynamic except-interface=lo # End of config |
该文件中定义了dnsmasq的一些属性，如开启dbus（node服务需要使用），定义cache行为，设置监听地址排除lo等等。
注意：该文件由ansible安装创建，虽然NetworkManager服务也会自动生成该文件，但是由于一个bug（见《五. 目前存在的问题》一章），两者创建的文件内容并不一致！最好不要随便删除该文件，除非你知道该如何配置。
四. 配置说明
在了解了运行机制之后，用户可以灵活配置，如果特殊需求，不排除可以修改默认运行机制。下面描述通常的配置方式。
OCP中需要配置的DNS解析包含：
1）master节点需要解析所有的node节点域名
2）node节点需要能够解析master节点域名，多个master节点需要能解析public hostname
3）所有node节点需要解析registry域名
4）其他任意的上游DNS
实现1和2，3三种域名解析可以最简单的方式是配置本地hosts文件，但是如果服务器数量巨大或者考虑后期扩容带来复杂性，最好能有DNS提供节点域名及registry域名的解析。在安装的时候将这个DNS server配置到网卡配置文件中。
第四种域名解析同样通过网卡配置文件配置。
通常情况下，默认的route域名.apps.example.com不需要在集群内部解析，该域名需要配置在访问OCP应用客户端的DNS server中。但也不排除，如果在OCP内部应用通过域名访问应用，则需要在pod中解析.apps.example.com，此时同样将用于解析*.apps.example.com的DNS server配置到网卡配置文件中。
综上所述，在OCP所有的dns设置都是自动完成的。安装时只需要保证节点域名可以解析（简单的可以使用hosts实现），其他所有的dns server全部通过网卡配置文件传入到dnsmasq，不要手动修改任何的其他文件。
五. 目前存在的问题
1) /etc/dnsmasq.d/origin-dns.conf在使用ansible安装OCP的时候创建，内容如下：
1 |
no-resolv |
如果误删除该文件，则重启network,dnsmasq,NetworkManager都会重新生成该文件，但是自动生成文件的内容与上述不一致，导致dnsmasq或node服务启动失败。下面为自动生成的文件内容：
1 |
no-resolv |
自动生成的文件缺少了最重要的bind-dynamic，except-interface=lo参数，导致dnsmasq启动的话，会监听0.0.0.0:53，导致node服务在启动时候报127.0.0.0:53端口被占用。
解决办法：手动创建文件，并保证文件内容正确。
2) /etc/origin/node/node-dnsmasq.conf在使用ansible安装OCP的时候创建，如果安装完成之后手动删除，无法自动生成，会导致atomic-openshift-node服务启动失败。
解决方法：手动创建/etc/origin/node/node-dnsmasq.conf，保证文件中的内容为
server=/in-addr.arpa/127.0.0.1
server=/cluster.local/127.0.0.1
3) NetworkManager服务必须启动，且网卡配置文件中不能包含NM_CONTROLLED=no参数。
魏新宇
"大魏分享"运营者、红帽资深解决方案架构师
专注开源云计算、容器及自动化运维在金融行业的推广
拥有MBA、ITIL V3、Cobit5、C-STAR、TOGAF9.1（鉴定级）等管理认证。
-
拥有红帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、AIX、HPUX等技术认证