最近在研究的時候看到了一篇文章寫到關於OpenShift 內部DNS機制的文章，在讀完之後，覺得應該來筆記一下，原來內部的DNS也是經過層層設計過的，並不是想像中的這麼單純。
先說明一下，以下是我個人的讀後心得，如果有理解錯的，也請指教。1. DNS operator
(1) 在OCP4內部，主要是由DNS operator負責部署與管理coreDNS來提供name resolution的功能給Pod，同時還實作K8S service discovery。
(2) DNS operator在內部利用DaemonSet的方式部署CoreDNS，並建立與設定kubelet讓Pod都使用CoreDNS service ip做為預設的DNS server，我們可以用以下指定查看DNS operator的內容：
$ oc describe clusteroperator/dns
$ oc get dns.operator.openshift.io/default -o yaml
2. CoreDNS
(1) 主要任務：負責在OCP/K8S內提供Pod與Service資源的名稱解析，例如：
- Pod 與 Service的A/AAAA records (A => IPv4 ; AAAA => IPv6)
- Service與Named port的SRV
- Service Discovery
但在OCP4內，又加碼提供：
- 指派DNS name到每個Pod (pod-ip.project-name.pod.cluster.local)
- 指派DNS name到每個Service (svc-name.project-name.svc.cluster.local)
- CoreDNS as DaemonSet
[LAB1: 查看coreDNS實際運行狀態]
------------------------------------------
$ oc get pod -n openshift-dnsNAME
READY STATUS RESTARTS AGE
dns-default-5vfhx 3/3 Running 0 24d
dns-default-8zv9s 3/3 Running 0 24d
dns-default-fvgj2 3/3 Running 0 24d
dns-default-l4mll 3/3 Running 0 24d
dns-default-wnk2q 3/3 Running 0 24d
dns-default-wvtbp 3/3 Running 0 24d
$ oc get ds -n openshift-dns
## 查看coredns使用corefile運行的process ##
$ oc exec -it dns-default-5vfhx -n openshift-dns bash
[root@dns-default-5vfhx]$ px auxwww
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.3 0.3 1429880 35328 ? Ssl Jul11 114:29 coredns -conf /etc/coredns/Corefile
[LAB2: 查看coreDNS實際運行狀態]
------------------------------------------
$ oc get cm/dns-default -n openshift-dns -o yaml
$ oc exec dns-default-5vfhx -n openshift-dns cat /etc/coredns
/Corefile
上圖很好的說明了以下三件事：
(1) “kubernetes cluster.local in-addr.arpa”實作了CoreDNS會基於Service與Pod IP來回應DNS的查詢。
(2) plugin實作出了Kubernetes DNS-based Service discovery，並處理所有關於cluster.local zone內的所有正反解查詢。
(3) 可以看到forward使用節點內預設的/etc/resolve.conf來解析所有不在cluster的domain name，而此處寫的”policy sequential”指的是照順序來查詢。
3. DNS resolution
以下LAB，實際演示一些解析
$ oc debug -t deployment/hello-openshift --image
registry.access.redhat.com/rhel7/rhel-tools
sh-4.2$ dig -v
DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5
[LAB1: 相同Project的解析]
使用netcat測在同在blue-green project下, 從nginx-1到nginx-2的SVC
------------------------------------------------------
$ oc get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-1 1/1 1 1 14d
nginx-2 1/1 1 1 14d
$ oc get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-1 ClusterIP 172.30.249.170 <none> 80/TCP 14d
nginx-2 ClusterIP 172.30.135.175 <none> 80/TCP 14d
$ oc get pod
NAME READY STATUS RESTARTS AGE
nginx-1-787dfb8897-dqzf6 1/1 Running 0 14d
nginx-2-8469bdd655-d8tf4 1/1 Running 0 14d
$ oc debug -t deployment/nginx-1 --image registry.access.redhat.com/rhel7/rhel-tools
Starting pod/nginx-1-debug ...
Pod IP: 10.131.0.182
sh-4.2# nc -zv nginx-2 80
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 172.30.135.175:80.
Ncat: 0 bytes sent, 0 bytes received in 0.02 seconds
解析的流程還可以再拆解成：
S1. 使用dnsPolicy來指定成ClusterFirst
$ oc get pod nginx-2-8469bdd655-d8tf4 -o jsonpath={.spec.dnsPolicy}
ClusterFirst
S2. 此時在容器內看/etc/resolv.conf的內容會是：
sh-4.2# cat /etc/resolv.conf
search blue-green.svc.cluster.local svc.cluster.local cluster.local dc3.ocp.com
nameserver 172.30.0.10
options ndots:5表示這個容器是向172.30.0.10做dns查詢
S3. 查詢將會從CoreDNS pod取得cache data，表示172.30.0.10的project IP為CoreDNS pod service IP
sh-4.2$ nslookup 172.30.0.10
10.0.30.172.in-addr.arpa name = dns-default.openshift-dns.svc.cluster.local.
S4. 確認loadbalance service是誰，並且帶有多個endpoints
$ oc get svc -n openshift-dns
$ oc describe svc -n openshift-dns | grep TargetPort -A1
此時我們隨便找一個endpoint都可以對應到某一個coredns pod
$ oc get pod -n openshift-dns -o wide | grep 10.128.0.34
dns-default-l4mll 3/3 Running 0 25d 10.128.0.34 master01.dc3.ocp.com
S5. CoreDNS還會將nginx-2反解成IP位址，此處我們要確認pod實際上查詢的IP就是CoreDNS svc
$ oc debug -t deployment/nginx-1 --image registry.access.redhat.com/rhel7/rhel-tools
sh-4.2# nslookup nginx-2
$ oc get svc nginx-2
S6. 需要的話，可以再進一步用nslookup debug 模式來確認
$ oc debug -t deployment/nginx-1 --image registry.access.redhat.com/rhel7/rhel-tools
sh-4.2$ nslookup -debug nginx-2
使用.blue-green.svc.cluster.local`domain來做解析
[LAB2: 不同Project的解析]
------------------------------------------------------
Step1. 先解析openshift console SVC
$ oc debug -t deployment/nginx-1 --image registry.access.redhat.com/rhel7/rhel-tools
sh-4.2$ nslookup console
Server: 172.30.0.10
Address: 172.30.0.10#53
Step2. 解不到的原因是因為沒有指定NAMESPACE
sh-4.2$ nslookup console | grep NXDOMAIN
** server can't find console: NXDOMAIN
** server can't find console: NXDOMAIN
** server can't find console: NXDOMAIN
** server can't find console: NXDOMAIN
** server can't find console: NXDOMAIN
Step3. 指到正確的NAMESPACE
sh-4.2# nslookup console.openshift-console
Server: 172.30.0.10
Address: 172.30.0.10#53
Name: console.openshift-console.svc.cluster.local
Address: 172.30.156.103
Step4. 確認一下外部的SVC IP
$ oc get svc -n openshift-console console
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
console ClusterIP 172.30.156.103 <none> 443/TCP 25d
[LAB3: OCP外部的解析]
------------------------------------------------------
Step1. 嘗試解析外部的Domain
sh-4.2$ curl http://www.google.com.tw -I
Step2. 確認一下Flow
sh-4.2$ nslookup -debug www.google.com | grep NXDOMAIN
4. 結論：
DNS在OpenShift內真的是非常重要的存在，樣樣都必須要透過DNS做解析。除了外部的DNS之外，OCP內部的DNS operator同樣也肩負很重要的任務。
所以當CoreDNS嘗試解析輸入的domain時，如果找不到答案，就會將查詢轉到forwarder去做查詢(在/etc/resolv.conf)
更新：
在4.11版本新增了對支援的平台可以再啟用External DNS 的功能，晚點再跟大家分享。
