OpenShift名稱解析(DNS)機制大小事

最近在研究的時候看到了一篇文章寫到關於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 的功能，晚點再跟大家分享。