當(dāng)前位置：首頁(yè) > news >正文

泰州網(wǎng)站建設(shè)多少錢(qián)北京環(huán)球影城每日客流怎么看

news 2025/7/7 17:55:52

泰州網(wǎng)站建設(shè)多少錢(qián),北京環(huán)球影城每日客流怎么看,wordpress移動(dòng)端底部導(dǎo)航,一個(gè)空間建多個(gè)網(wǎng)站目錄文章目錄目錄本節(jié)實(shí)戰(zhàn)DNS優(yōu)化1、dns 5s 超時(shí)問(wèn)題解決辦法2、NodeLocal DNSCache實(shí)驗(yàn)軟件關(guān)于我最后本節(jié)實(shí)戰(zhàn) 實(shí)戰(zhàn)名稱💘 實(shí)戰(zhàn)：NodeLocal DNSCache-2022.7.30(測(cè)試成功)💘 實(shí)戰(zhàn)：NodeLocal DNSCache-2023.2.21(測(cè)試成功) DNS優(yōu)…

本節(jié)實(shí)戰(zhàn)

實(shí)戰(zhàn)名稱
💘 實(shí)戰(zhàn)：NodeLocal DNSCache-2022.7.30(測(cè)試成功)
💘 實(shí)戰(zhàn)：NodeLocal DNSCache-2023.2.21(測(cè)試成功)

DNS優(yōu)化

前面我們講解了在 Kubernetes 中我們可以使用 CoreDNS 來(lái)進(jìn)行集群的域名解析，但是如果在集群規(guī)模較大并發(fā)較高的情況下我們?nèi)匀恍枰獙?duì) DNS 進(jìn)行優(yōu)化，典型的就是大家比較熟悉的 CoreDNS 會(huì)出現(xiàn)超時(shí)5s的情況。

1、dns 5s 超時(shí)問(wèn)題

DNS 解析出現(xiàn)的 5s 超時(shí)的問(wèn)題，并不是 Kubernertes 的問(wèn)題，而是 conntrack 的一個(gè) bug，也就是連接跟蹤表。Weave works 的工程師 Martynas Pumputis 對(duì)這個(gè)問(wèn)題做了很詳細(xì)的分析：https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts。由于 conntrack 涉及到內(nèi)核的一些知識(shí)，這里我們也不用太深入了，感興趣的可以自行去了解，可以參考文章

https://opengers.github.io/openstack/openstack-base-netfilter-framework-overview/ 進(jìn)行更多了解。

以上2篇文章已下載到本地：

Racy conntrack and DNS lookup timeouts-2023.2.19-剪藏
云計(jì)算底層技術(shù) - netfilter 框架研究 _ opengers-2023.2.19-剪藏

我們簡(jiǎn)單總結(jié)下：當(dāng)加載內(nèi)核模塊 nf_conntrack 后，conntrack 機(jī)制就開(kāi)始工作，對(duì)于每個(gè)通過(guò) conntrack 的數(shù)據(jù)包，內(nèi)核都為其生成一個(gè) conntrack 條目用以跟蹤此連接，對(duì)于后續(xù)通過(guò)的數(shù)據(jù)包，內(nèi)核會(huì)判斷若此數(shù)據(jù)包屬于一個(gè)已有的連接，則更新所對(duì)應(yīng)的 conntrack 條目的狀態(tài)(比如更新為 ESTABLISHED 狀態(tài))，否則內(nèi)核會(huì)為它新建一個(gè)conntrack 條目。所有的 conntrack 條目都存放在一張表里，稱為連接跟蹤表。連接跟蹤表存放于系統(tǒng)內(nèi)存中，可以用cat /proc/net/nf_conntrack 查看當(dāng)前跟蹤的所有 conntrack 條目（Ubuntu 則是 conntrack 命令）。

而出現(xiàn)該問(wèn)題的根源在于 DNS 客戶端（ glibc 或 musl libc ）會(huì)并發(fā)請(qǐng)求 A（ipv4 地址）和 AAAA（ipv6 地址）記錄，跟 DNS Server 通信自然會(huì)先 connect 建立 fd，后面請(qǐng)求報(bào)文使用這個(gè) fd 來(lái)發(fā)送，由于 UDP 是無(wú)狀態(tài)協(xié)議，connect 時(shí)并不會(huì)創(chuàng)建 conntrack 表項(xiàng), 而并發(fā)請(qǐng)求的 A 和 AAAA 記錄默認(rèn)使用同一個(gè) fd 發(fā)包，這時(shí)它們?cè)碢ort 相同，當(dāng)并發(fā)發(fā)包時(shí)，兩個(gè)包都還沒(méi)有被插入 conntrack 表項(xiàng)，所以 netfilter 會(huì)為它們分別創(chuàng)建conntrack 表項(xiàng)，而集群內(nèi)請(qǐng)求 kube-dns 都是訪問(wèn)的 Cluster-IP，報(bào)文最終會(huì)被 DNAT 成一個(gè) endpoint 的Pod IP，當(dāng)兩個(gè)包被 DNAT 成同一個(gè) IP，最終它們的五元組就相同了，在最終插入的時(shí)候后面那個(gè)包就會(huì)被丟掉，如果dns 的 pod 副本只有一個(gè)實(shí)例的情況就很容易發(fā)生，現(xiàn)象就是 dns 請(qǐng)求超時(shí)，client 默認(rèn)策略是等待 5s 自動(dòng)重試，如果重試成功，我們看到的現(xiàn)象就是 dns 請(qǐng)求有 5s 的延時(shí)。

netfilter conntrack 模塊為每個(gè)連接創(chuàng)建 conntrack 表項(xiàng)時(shí)，表項(xiàng)的創(chuàng)建和最終插入之間還有一段邏輯，沒(méi)有加鎖，是一種樂(lè)觀鎖的過(guò)程。conntrack 表項(xiàng)并發(fā)剛創(chuàng)建時(shí)五元組不沖突的話可以創(chuàng)建成功，但中間經(jīng)過(guò) NAT 轉(zhuǎn)換之后五元組就可能變成相同，第一個(gè)可以插入成功，后面的就會(huì)插入失敗，因?yàn)橐呀?jīng)有相同的表項(xiàng)存在。比如一個(gè) SYN 已經(jīng)做了NAT 但是還沒(méi)到最終插入的時(shí)候，另一個(gè) SYN 也在做 NAT，因?yàn)橹澳莻€(gè) SYN 還沒(méi)插入，這個(gè) SYN 做 NAT 的時(shí)候就認(rèn)為這個(gè)五元組沒(méi)有被占用，那么它 NAT 之后的五元組就可能跟那個(gè)還沒(méi)插入的包相同。

所以總結(jié)來(lái)說(shuō)，根本原因是內(nèi)核 conntrack 模塊的 bug，**DNS client(在 linux 上一般就是上一般就是 resolver)**會(huì)并發(fā)地請(qǐng)求 A 和 AAAA 記錄，netfilter 做 NAT 時(shí)可能發(fā)生資源競(jìng)爭(zhēng)導(dǎo)致部分報(bào)文丟棄。

只有多個(gè)線程或進(jìn)程，并發(fā)從同一個(gè) socket 發(fā)送相同五元組的 UDP 報(bào)文時(shí)，才有一定概率會(huì)發(fā)生
glibc、musl(alpine 的 libc 庫(kù))都使用 parallel query ，就是并發(fā)發(fā)出多個(gè)查詢請(qǐng)求，因此很容易碰到這樣的沖突，造成查詢請(qǐng)求被丟棄
由于 ipvs 也使用了 conntrack, 使用 kube-proxy 的 ipvs 模式，并不能避免這個(gè)問(wèn)題

解決辦法

要徹底解決這個(gè)問(wèn)題最好當(dāng)然是內(nèi)核上去 FIX 掉這個(gè) BUG，除了這種方法之外我們還可以使用其他方法來(lái)進(jìn)行規(guī)避，我們可以避免相同五元組 DNS請(qǐng)求的并發(fā)。

在 resolv.conf 中就有兩個(gè)相關(guān)的參數(shù)可以進(jìn)行配置：

single-request-reopen：發(fā)送 A 類型請(qǐng)求和 AAAA 類型請(qǐng)求使用不同的源端口，這樣兩個(gè)請(qǐng)求在 conntrack 表中不占用同一個(gè)表項(xiàng)，從而避免沖突。
single-request：避免并發(fā)，改為串行發(fā)送 A 類型和 AAAA 類型請(qǐng)求。沒(méi)有了并發(fā)，從而也避免了沖突。

要給容器的 resolv.conf 加上 options 參數(shù)，有幾個(gè)辦法：

在容器的 ENTRYPOINT 或者 CMD 腳本中，執(zhí)行 /bin/echo 'options single-request-reopen' >> /etc/resolv.conf(不推薦)

在 Pod 的 postStart hook 中添加：(不推薦)

lifecycle:postStart:exec:command:- /bin/sh- -c- "/bin/echo 'options single-request-reopen' >> /etc/resolv.conf

使用 template.spec.dnsConfig 配置:

template:spec:dnsConfig:options:- name: single-request-reopen

使用 ConfigMap 覆蓋 Pod 里面的 /etc/resolv.conf：

# configmap
apiVersion: v1
data:resolv.conf: |nameserver 1.2.3.4search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5 single-request-reopen timeout:1
kind: ConfigMap
metadata:name: resolvconf
---
# Pod Spec
spec:volumeMounts:- name: resolv-confmountPath: /etc/resolv.confsubPath: resolv.conf  # 在某個(gè)目錄下面掛載一個(gè)文件（保證不覆蓋當(dāng)前目錄）需要使用subPath -> 不支持熱更新
...volumes:- name: resolv-confconfigMap:name: resolvconfitems:- key: resolv.confpath: resolv.conf

使用 TCP：默認(rèn)情況下 dns 的請(qǐng)求一般都是使用 UDP 請(qǐng)求的, 因?yàn)榱η笮?#xff0c;不需要三握四揮。由于 TCP 沒(méi)有這個(gè)問(wèn)題，我們可以在容器的 resolv.conf 中增加 options use-vc , 強(qiáng)制 glibc 使用 TCP 協(xié)議發(fā)送DNS query。
```
template:spec:dnsConfig:options:- name: use-vc
```
使用 MutatingAdmissionWebhook，用于對(duì)一個(gè)指定的資源的操作之前，對(duì)這個(gè)資源進(jìn)行變更。我們也可以通過(guò) MutatingAdmissionWebhook 來(lái)自動(dòng)給所有 Pod 注入上面第三或第四種方法中的相關(guān)內(nèi)容。

上面的方法在一定程度上可以解決 DNS 超時(shí)的問(wèn)題，但更好的方式是使用本地 DNS 緩存，容器的 DNS 請(qǐng)求都發(fā)往本地的 DNS 緩存服務(wù)，也就不需要走 DNAT，當(dāng)然也不會(huì)發(fā)生 conntrack 沖突了，而且還可以有效提升 CoreDNS 的性能瓶頸。

2、NodeLocal DNSCache

NodeLocal DNSCache 通過(guò)在集群節(jié)點(diǎn)上運(yùn)行一個(gè) DaemonSet 來(lái)提高集群 DNS 性能和可靠性。**處于 ClusterFirst 的 DNS 模式下的 Pod 可以連接到 kube-dns 的 serviceIP 進(jìn)行 DNS 查詢，**通過(guò) kube-proxy 組件添加的 iptables 規(guī)則將其轉(zhuǎn)換為 CoreDNS 端點(diǎn)。通過(guò)在每個(gè)集群節(jié)點(diǎn)上運(yùn)行 DNS 緩存，NodeLocal DNSCache可以縮短 DNS 查找的延遲時(shí)間、使 DNS 查找時(shí)間更加一致，以及減少發(fā)送到 kube-dns 的 DNS 查詢次數(shù)。

在集群中運(yùn)行 NodeLocal DNSCache 有如下幾個(gè)好處：

如果本地沒(méi)有 CoreDNS 實(shí)例，則具有最高 DNS QPS 的 Pod 可能必須到另一個(gè)節(jié)點(diǎn)進(jìn)行解析，使用 NodeLocal DNSCache 后，擁有本地緩存將有助于改善延遲。
跳過(guò) iptables DNAT 和連接跟蹤將有助于減少 conntrack 競(jìng)爭(zhēng)并避免 UDP DNS 條目填滿 conntrack 表（上面提到的5s超時(shí)問(wèn)題就是這個(gè)原因造成的） 注意：這里改成TCP的話，也是可以有效果的
從本地緩存代理到 kube-dns 服務(wù)的連接可以升級(jí)到 TCP，TCP conntrack 條目將在連接關(guān)閉時(shí)被刪除，而 UDP 條目必須超時(shí)過(guò)后(默認(rèn) nfconntrackudp_timeout 是 30 秒)
將 DNS 查詢從 UDP 升級(jí)到 TCP 將減少歸因于丟棄的 UDP 數(shù)據(jù)包和 DNS 超時(shí)的尾部等待時(shí)間，通常長(zhǎng)達(dá) 30 秒（3 次重試+ 10 秒超時(shí)）

💘 實(shí)戰(zhàn)：NodeLocal DNSCache-2023.2.21(測(cè)試成功)

實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)環(huán)境：
1、win10,vmwrokstation虛機(jī)；
2、k8s集群：3臺(tái)centos7.6 1810虛機(jī)，1個(gè)master節(jié)點(diǎn),2個(gè)node節(jié)點(diǎn)k8s version：v1.20.0docker://20.10.7  #containerd都是一樣的，次方法也使用k8s1.22/1.25

實(shí)驗(yàn)軟件

2021.12.28-實(shí)驗(yàn)軟件-nodelocaldns

鏈接：https://pan.baidu.com/s/1cl474vfrXvz0hPya1EDIlQ
提取碼：lpz1

nodelocaldns.yaml

1.獲取NodeLocal DNSCache的資源清單

要安裝 NodeLocal DNSCache 也非常簡(jiǎn)單，直接獲取官方的資源清單即可：

wget https://github.com/kubernetes/kubernetes/raw/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml[root@master1 ~]#wget https://github.com/kubernetes/kubernetes/raw/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml
--2021-12-28 16:38:36--  https://github.com/kubernetes/kubernetes/raw/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml
Resolving github.com (github.com)... 20.205.243.166
Connecting to github.com (github.com)|20.205.243.166|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml [following]
--2021-12-28 16:38:36--  https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.108.133, 185.199.111.133, 185.199.109.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5334 (5.2K) [text/plain]
Saving to: ‘nodelocaldns.yaml’100%[===================================================================>] 5,334       --.-K/s   in 0.1s2021-12-28 16:38:37 (51.4 KB/s) - ‘nodelocaldns.yaml’ saved [5334/5334][root@master1 ~]#ll nodelocaldns.yaml
-rw-r--r-- 1 root root 5334 Dec 28 16:38 nodelocaldns.yaml
[root@master1 ~]#

……
#該資源清單文件中我們重點(diǎn)看下 NodeLocalDNS 的配置對(duì)象：
---
apiVersion: v1
kind: ConfigMap
metadata:name: node-local-dnsnamespace: kube-systemlabels:addonmanager.kubernetes.io/mode: Reconcile
data:Corefile: |__PILLAR__DNS__DOMAIN__:53 {errorscache {success 9984 30denial 9984 5}reloadloopbind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__forward . __PILLAR__CLUSTER__DNS__ {force_tcp}prometheus :9253health __PILLAR__LOCAL__DNS__:8080}in-addr.arpa:53 {errorscache 30reloadloopbind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__forward . __PILLAR__CLUSTER__DNS__ {force_tcp}prometheus :9253}ip6.arpa:53 {errorscache 30reloadloopbind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__forward . __PILLAR__CLUSTER__DNS__ {force_tcp}prometheus :9253}.:53 {errorscache 30reloadloopbind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__forward . __PILLAR__UPSTREAM__SERVERS__prometheus :9253}
……

該資源清單文件中包含幾個(gè)變量值得注意，其中：

__PILLAR__DNS__SERVER__ ：表示 kube-dns 這個(gè) Service 的 ClusterIP，可以通過(guò)命令 kubectl get svc -n kube-system | grep kube-dns | awk'{ print $3 }' 獲取（我們這里就是 10.96.0.10）
__PILLAR__LOCAL__DNS__：表示 DNSCache 本地監(jiān)聽(tīng)的 IP 地址，該地址可以是任何地址，只要該地址不和你的集群里現(xiàn)有的 IP 地址發(fā)生沖突。推薦使用本地范圍內(nèi)的地址，例如 IPv4 鏈路本地區(qū)段 169.254.0.0/16 內(nèi)的地址（默認(rèn)一般取 169.254.20.10 即可），或者 IPv6 唯一本地地址區(qū)段 fd00::/8內(nèi)的地址
__PILLAR__DNS__DOMAIN__：表示集群域，默認(rèn)就是 cluster.local

另外還有兩個(gè)參數(shù) __PILLAR__CLUSTER__DNS__ 和 __PILLAR__UPSTREAM__SERVERS__，這兩個(gè)參數(shù)會(huì)進(jìn)行自動(dòng)配置，對(duì)應(yīng)的值來(lái)源于 kube-dns 的 ConfigMap 和定制的 Upstream Server 配置。

2.部署資源

?? 這里需要注意的是鏡像版本，本次使用k8s-dns-node-cache:1.21.1版本

直接執(zhí)行如下所示的命令即可安裝：

sed 's/k8s.gcr.io\/dns/cnych/g
s/__PILLAR__DNS__SERVER__/10.96.0.10/g
s/__PILLAR__LOCAL__DNS__/169.254.20.10/g
s/__PILLAR__DNS__DOMAIN__/cluster.local/g' nodelocaldns.yaml |
kubectl apply -f -#注意：這個(gè)使用的是老師的鏡像中轉(zhuǎn)地址cnych。

可以通過(guò)如下命令來(lái)查看對(duì)應(yīng)的 Pod 是否已經(jīng)啟動(dòng)成功：

[root@k8s-master1 ~]#kubectl get po -nkube-system -l k8s-app=node-local-dns -owide
NAME                   READY   STATUS    RESTARTS   AGE   IP            NODE          NOMINATED NODE   READINESS GATES
node-local-dns-bsl2n   1/1     Running   0          35h   172.29.9.32   k8s-node1     <none>           <none>
node-local-dns-gnjnw   1/1     Running   0          35h   172.29.9.31   k8s-master1   <none>           <none>
node-local-dns-z4cpj   1/1     Running   0          35h   172.29.9.33   k8s-node2     <none>           <none>

3.測(cè)試

我們導(dǎo)出來(lái)一個(gè)pod看下情況：

[root@master1 ~]#kubectl get po node-local-dns-6mhj8 -nkube-system -oyaml

這里可以看到顯示從169.254.20.10解析地址，如果沒(méi)有再去找10.96.0.10的。

需要注意的是這里使用 DaemonSet 部署 node-local-dns 使用了 hostNetwork=true，會(huì)占用宿主機(jī)的 8080 端口，所以需要保證該端口未被占用。

4.修改 kubelet 的 --cluster-dns 參數(shù)

先來(lái)確認(rèn)下當(dāng)前kube-proxy組件使用的模式是什么？

[root@master1 NodeLocalDnsCache]#kubectl get cm kube-proxy -nkube-system -oyaml|grep modemode: ipvs

但是到這里還沒(méi)有完，如果 kube-proxy 組件使用的是 ipvs 模式的話，我們還需要修改 kubelet 的 --cluster-dns 參數(shù)，將其指向 169.254.20.10，Daemonset 會(huì)在每個(gè)節(jié)點(diǎn)創(chuàng)建一個(gè)網(wǎng)卡來(lái)綁這個(gè) IP，Pod 向本節(jié)點(diǎn)這個(gè) IP 發(fā) DNS 請(qǐng)求，緩存沒(méi)有命中的時(shí)候才會(huì)再代理到上游集群 DNS 進(jìn)行查詢。

10: nodelocaldns: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group defaultlink/ether 6a:e9:a3:9b:03:a8 brd ff:ff:ff:ff:ff:ffinet 169.254.20.10/32 scope global nodelocaldnsvalid_lft forever preferred_lft foreverinet 10.96.0.10/32 scope global nodelocaldnsvalid_lft forever preferred_lft forever
[root@master1 ~]#

**iptables 模式下 Pod 還是向原來(lái)的集群 DNS 請(qǐng)求，節(jié)點(diǎn)上有這個(gè) IP 監(jiān)聽(tīng)，會(huì)被本機(jī)攔截，再請(qǐng)求集群上游 DNS，所以不需要更改 **--cluster-dns參數(shù)。

由于我這里使用的是 kubeadm 安裝的 1.20 版本的集群，所以我們只需要替換節(jié)點(diǎn)上 /var/lib/kubelet/config.yaml 文件中的 clusterDNS 這個(gè)參數(shù)值，然后重啟即可：

sed -i 's/10.96.0.10/169.254.20.10/g' /var/lib/kubelet/config.yaml
systemctl daemon-reload && systemctl restart kubelet

注意：all節(jié)點(diǎn)均要配置。

5.驗(yàn)證

待 node-local-dns 安裝配置完成后，我們可以部署一個(gè)新的 Pod 來(lái)驗(yàn)證下：

# test-node-local-dns.yaml
apiVersion: v1
kind: Pod
metadata:name: test-node-local-dns
spec:containers:- name: local-dnsimage: busybox:1.28.3command: ["/bin/sh", "-c", "sleep 60m"]

直接部署：

[root@master1 ~]#kubectl apply -f test-node-local-dns.yaml
pod/test-node-local-dns created
[root@master1 ~]#kubectl exec -it test-node-local-dns -- sh
/ # cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 169.254.20.10
options ndots:5
/ #

我們可以看到 nameserver 已經(jīng)變成 169.254.20.10 了，當(dāng)然對(duì)于之前的歷史 Pod 要想使用 node-local-dns 則需要重建。

?? 注意

如果擔(dān)心線上環(huán)境修改 --cluster-dns 參數(shù)會(huì)產(chǎn)生影響，我們也可以直接在新部署的 Pod 中通過(guò) dnsConfig 配置使用新的 localdns 的地址來(lái)進(jìn)行解析。

創(chuàng)建yaml文件

#test-node-local-dns-2.yaml
apiVersion: v1
kind: Pod
metadata:name: test-node-local-dns-2
spec:dnsPolicy: None #None的時(shí)候需要配置下面的dnsConfigdnsConfig:nameservers: # 如果dnsPolicy不等于None，則會(huì)將nameservers合并到原有的（dnsPolicy默認(rèn)是ClusterFirst）- 169.254.20.10searches:- default.svc.cluster.local- svc.cluster.local- cluster.localoptions:- name: ndotsvalue: "5"containers:- name: testimage: cnych/jessie-dnsutils:1.3command:- sleep- "infinity"imagePullPolicy: IfNotPresent

部署

[root@master1 ~]#kubectl apply -f test-node-local-dns-2.yaml
root@master1 ~]#kubectl exec -it test-node-local-dns-2 -- bash
#  cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 169.254.20.10
options ndots:5
#

我們可以看到 nameserver 已經(jīng)變成 169.254.20.10 了，同樣簡(jiǎn)單測(cè)試下是否可以正常工作：

[root@k8s-master1 ~]#kubectl exec -it test-node-local-dns-2 -- bash
root@test-node-local-dns-2:/# cat /etc/resolv.conf
nameserver 169.254.20.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
root@test-node-local-dns-2:/# nslookup youdianzhishi.com
Server:		169.254.20.10
Address:	169.254.20.10#53Non-authoritative answer:
Name:	youdianzhishi.com
Address: 39.106.22.102root@test-node-local-dns-2:/# nslookup kubernetes.default
Server:		169.254.20.10
Address:	169.254.20.10#53Name:	kubernetes.default.svc.cluster.local
Address: 10.96.0.1root@test-node-local-dns-2:/#

?? 說(shuō)明：以下步驟是之前實(shí)驗(yàn)測(cè)試保留的數(shù)據(jù)。

6.重建前面壓力測(cè)試 DNS 的 Pod

接下來(lái)我們重建前面壓力測(cè)試 DNS 的 Pod，重新將 testdns 二進(jìn)制文件拷貝到 Pod 中去：

[root@master1 ~]#kubectl delete -f nginx.yaml
deployment.apps "nginx" deleted
[root@master1 ~]#kubectl apply -f nginx.yaml
deployment.apps/nginx created
[root@master1 ~]#kubectl get po
NAME                     READY   STATUS    RESTARTS   AGE
nginx-5d59d67564-kgd4q   1/1     Running   0          22s
nginx-5d59d67564-lxnt2   1/1     Running   0          22s
test-node-local-dns      1/1     Running   0          5m50s[root@master1 ~]#kubectl cp go/testdns nginx-5d59d67564-kgd4q:/root
[root@master1 ~]#kubectl exec -it nginx-5d59d67564-kgd4q -- bash
root@nginx-5d59d67564-kgd4q:/# cd /root/
root@nginx-5d59d67564-kgd4q:~# ls
testdns
root@nginx-5d59d67564-kgd4q:~# cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 169.254.20.10
options ndots:5
root@nginx-5d59d67564-kgd4q:~##自己本次的測(cè)試數(shù)據(jù)
#再次壓測(cè)
#先來(lái)個(gè)200個(gè)并發(fā)，測(cè)試三次
root@nginx-5d59d67564-kgd4q:~# ./testdns -host nginx-service.default -c 200 -d 30 -l 5000
request count：47344
error count：0
request time：min(1ms) max(976ms) avg(125ms) timeout(0n)
root@nginx-5d59d67564-kgd4q:~# ./testdns -host nginx-service.default -c 200 -d 30 -l 5000
request count：49744
error count：0
request time：min(1ms) max(540ms) avg(118ms) timeout(0n)
root@nginx-5d59d67564-kgd4q:~# ./testdns -host nginx-service.default -c 200 -d 30 -l 5000
request count：55929
error count：0
request time：min(2ms) max(463ms) avg(105ms) timeout(0n)
root@nginx-5d59d67564-kgd4q:~#
root@nginx-5d59d67564-kgd4q:~##再來(lái)個(gè)1000個(gè)并發(fā)，測(cè)試三次
root@nginx-5d59d67564-kgd4q:~# ./testdns -host nginx-service.default -c 1000 -d 30 -l 5000
request count：42177
error count：0
request time：min(16ms) max(2627ms) avg(690ms) timeout(0n)
root@nginx-5d59d67564-kgd4q:~# ./testdns -host nginx-service.default -c 1000 -d 30 -l 5000
request count：45456
error count：0
request time：min(29ms) max(2484ms) avg(650ms) timeout(0n)
root@nginx-5d59d67564-kgd4q:~# ./testdns -host nginx-service.default -c 1000 -d 30 -l 5000
request count：45713
error count：0
request time：min(3ms) max(1698ms) avg(647ms) timeout(0n)
root@nginx-5d59d67564-kgd4q:~#
#注意：這個(gè)1000并發(fā)測(cè)試效果就很明顯了

老師筆記的測(cè)試數(shù)據(jù)：

# 拷貝到重建的 Pod 中
$ kubectl cp testdns svc-demo-546b7bcdcf-b5mkt:/root
$ kubectl exec -it svc-demo-546b7bcdcf-b5mkt -- /bin/bash
root@svc-demo-546b7bcdcf-b5mkt:/# cat /etc/resolv.conf
nameserver 169.254.20.10  # 可以看到 nameserver 已經(jīng)更改
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
root@svc-demo-546b7bcdcf-b5mkt:/# cd /root
root@svc-demo-546b7bcdcf-b5mkt:~# ls
testdns
# 重新執(zhí)行壓力測(cè)試
root@svc-demo-546b7bcdcf-b5mkt:~# ./testdns -host nginx-service.default -c 200 -d 30 -l 5000
request count：16297
error count：0
request time：min(2ms) max(5270ms) avg(357ms) timeout(8n)
root@svc-demo-546b7bcdcf-b5mkt:~# ./testdns -host nginx-service.default -c 200 -d 30 -l 5000
request count：15982
error count：0
request time：min(2ms) max(5360ms) avg(373ms) timeout(54n)
root@svc-demo-546b7bcdcf-b5mkt:~# ./testdns -host nginx-service.default -c 200 -d 30 -l 5000
request count：25631
error count：0
request time：min(3ms) max(958ms) avg(232ms) timeout(0n)
root@svc-demo-546b7bcdcf-b5mkt:~# ./testdns -host nginx-service.default -c 200 -d 30 -l 5000
request count：23388
error count：0
request time：min(6ms) max(1130ms) avg(253ms) timeout(0n)

7.總結(jié)

從上面的結(jié)果可以看到無(wú)論是最大解析時(shí)間還是平均解析時(shí)間都比之前默認(rèn)的 CoreDNS 提示了不少的效率，NodeLocal DNSCache 可以提升 DNS 的性能和可靠性的，所以也非常推薦用在生產(chǎn)環(huán)境，唯一的缺點(diǎn)就是由于LocalDNS 使用的是 DaemonSet 模式部署，所以如果需要更新鏡像則可能會(huì)中斷服務(wù)（不過(guò)可以使用一些第三方的增強(qiáng)組件來(lái)實(shí)現(xiàn)原地升級(jí)解決這個(gè)問(wèn)題，比如 openkruise）。

阿里云也是比較推薦線上去部署這個(gè)的。

測(cè)試結(jié)束。😘

關(guān)于我

我的博客主旨：

排版美觀，語(yǔ)言精煉；
文檔即手冊(cè)，步驟明細(xì)，拒絕埋坑，提供源碼；
本人實(shí)戰(zhàn)文檔都是親測(cè)成功的，各位小伙伴在實(shí)際操作過(guò)程中如有什么疑問(wèn)，可隨時(shí)聯(lián)系本人幫您解決問(wèn)題，讓我們一起進(jìn)步！

🍀 微信二維碼
x2675263825 （舍得）， qq：2675263825。