大咖解惑篇：OpenShift中暈頭轉向的DNS解析

一. 介紹

　　在初次接觸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 2 3 4 5

# cat /etc/resolv.conf # nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh # Generated by NetworkManager nameserver 192.168.182.190 search cluster.local

　　該文件由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 2	server=/in-addr.arpa/127.0.0.1 server=/cluster.local/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中配置的DNS一、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 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

若是誤刪除該文件，則重啓network,dnsmasq,NetworkManager都會從新生成該文件，可是自動生成文件的內容與上述不一致，致使dnsmasq或node服務啓動失敗。下面爲自動生成的文件內容：

1 2 3 4 5 6 7

no-resolv domain-needed server=/cluster.local/172.30.0.1 server=/30.172.in-addr.arpa/172.30.0.1 enable-dbus dns-forward-max=5000 cache-size=5000

自動生成的文件缺乏了最重要的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 V三、Cobit五、C-STAR、TOGAF9.1（鑑定級）等管理認證。

• 擁有紅帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、AIX、HPUX等技術認證