定位模型

EdgeMesh的定位思路具有下面一個(gè)重要模型：

發(fā)起訪問(wèn)的podA->edgemesh-agent(跟podA在同一個(gè)節(jié)點(diǎn))->edgemesh-agent(跟podB在同一個(gè)節(jié)點(diǎn))->被訪問(wèn)的podB

畫(huà)圖所示就是：

舉個(gè)例子，podA是訂單微服務(wù)的后端，另外還有個(gè)數(shù)據(jù)庫(kù)服務(wù)，podB是數(shù)據(jù)庫(kù)服務(wù)的后端實(shí)例。實(shí)際情況中微服務(wù)為了做高可用，可能會(huì)部署多個(gè)后端，也即可能存在podA-0，podA-1，podA-2，podB也是一樣，為了簡(jiǎn)化我們的問(wèn)題，我們還是抽象出上面的定位模型。

大部分問(wèn)題都可以歸納為以下幾種：

圓圈1：podA側(cè)的流量沒(méi)被edgemesh-agent(左)攔截到，比如問(wèn)題三、問(wèn)題十三、問(wèn)題十四

圓圈2：edgemesh-agent(左)發(fā)現(xiàn)不到edgemesh-agent(右)，更甚的是edgemesh-agent(右)根本沒(méi)部署，比如問(wèn)題六、問(wèn)題十六

圓圈3：一般不會(huì)出問(wèn)題

問(wèn)題一：Failed to watch xxx: failed to list xxx: no kind xxx ; Reflector ListAndWatch xxx (total time 10003ms)

1. 如果cloudcore是二進(jìn)制部署的，請(qǐng)你再仔細(xì)按照前言說(shuō)的自檢一下。
2. 如果cloudcore是容器化部署的，也先仔細(xì)按照前言說(shuō)的自檢（注意如果容器部署的話，cloudcore的配置是一個(gè)k8s configmap）。然后再檢查cloudcore的clusterrole是不是跟 cloudcore clusterrole配置文件 里的一致（特別是namespaces和networking.istio.io這兩項(xiàng)配置）。有些用kubesphere的用戶，使用了kubesphere內(nèi)置的kubeedge，其中kubeedge的yaml文件都是上古老版本了，得更新一下。

問(wèn)題二：calico、flannel無(wú)法在邊緣節(jié)點(diǎn)啟動(dòng)

這個(gè)問(wèn)題和edgemesh沒(méi)半毛錢關(guān)系。你想知道到底是為啥，可以閱讀材料：邊緣 Kube-API 端點(diǎn) | EdgeMesh | 背景 。

跑在邊緣節(jié)點(diǎn)的容器，是沒(méi)法通過(guò)訪問(wèn)kubernetes這個(gè)服務(wù)的clusterIP(10.96.0.1)訪問(wèn)到kube-apiserver的，看下方的iptables規(guī)則，對(duì)clusterIP(10.96.0.1:443)的訪問(wèn)最終會(huì)DNAT到192.168.0.229:6443，192.168.0.229是部署kube-apiserver的節(jié)點(diǎn)的IP，你邊緣節(jié)點(diǎn)所處的網(wǎng)絡(luò)和它在不同的子網(wǎng)里，所以訪問(wèn)不到。

$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   307d

$ iptables -t nat -nvL | grep kubernetes:https | grep 10.96.0.1
    0     0 KUBE-MARK-MASQ  tcp  --  *      *      !10.244.0.0/16        10.96.0.1            /* default/kubernetes:https cluster IP */ tcp dpt:443
    0     0 KUBE-SVC-NPX46M4PTMTKRN6Y  tcp  --  *      *       0.0.0.0/0            10.96.0.1            /* default/kubernetes:https cluster IP */ tcp dpt:443
$ iptables -t nat -nvL | grep kubernetes:https | grep DNAT
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* default/kubernetes:https */ tcp to:192.168.0.229:6443

如果你不知道什么是iptables規(guī)則，關(guān)鍵字 Linux iptables、netfilter原理和四表五鏈。如果你不知道處于不同網(wǎng)絡(luò)的含義，關(guān)鍵字計(jì)算機(jī)網(wǎng)絡(luò)、NAT、cidr，查關(guān)鍵字自己學(xué)吧。

不過(guò)通過(guò)修改配置，對(duì)接到edgecore的邊緣kube api endpoint后，像kube-proxy，flannel等組件就能跑起來(lái)了，不過(guò)flannel、calico、cilium等常見(jiàn)的CNI插件，不支持跨子網(wǎng)的pod流量轉(zhuǎn)發(fā)，也即云邊不能通。

問(wèn)題三：curl、telnet、nc卡住; No route to host

1.大多數(shù)原因都是因?yàn)閗ube-proxy根鏈插在了edgemesh根鏈的前面

要搞懂這個(gè)問(wèn)題你得對(duì) Linux iptables、netfilter原理和四表五鏈 有基本的了解，然后再閱讀：混合代理 | EdgeMesh | 原理。kube-proxy和edgemesh都具有流量代理功能，目前兩者的原理都是通過(guò)iptables去攔截應(yīng)用發(fā)出的流量，再做代理/轉(zhuǎn)發(fā)。

此問(wèn)題一般發(fā)生在kube-proxy和edgemesh共存的云節(jié)點(diǎn)上，如果有不明白，請(qǐng)看問(wèn)題十。

臨時(shí)規(guī)避方式如下：

a. 先卸載edgemesh

b.清理iptables規(guī)則

$ iptables -F
$ iptables -X
$ iptables -t nat -F
$ iptables -t nat -X
$ systemctl restart docker

c. 更新或新建一個(gè)k8s service，這是為了觸發(fā)kube-proxy重建自己的鏈

d.重新部署edgemesh，這一步確保了edgemesh根鏈插入到kube-proxy根鏈前面

你想問(wèn)為啥不讓edgemesh-agent代碼每隔一段時(shí)間檢查一下鏈的順序，如果有誤就插入到kube-proxy鏈前面？我覺(jué)得可以，等有時(shí)間就去優(yōu)化一下。當(dāng)然，我也非常歡迎你能貢獻(xiàn)代碼。

2.少數(shù)原因是因?yàn)閕ptables的版本不對(duì)，低版本的DNAT規(guī)則長(zhǎng)得很怪異，也不能正常攔截流量，原因不明。可以看看edgemesh創(chuàng)建的iptables正常長(zhǎng)成什么樣子（在邊緣節(jié)點(diǎn)上），如下：

$ iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 14272 packets, 1310K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   184 KUBE-PORTALS-CONTAINER  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* handle ClusterIPs; NOTE: this must be before the NodePort rules */
    3   184 KUBE-NODEPORT-CONTAINER  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL /* handle service NodePorts; NOTE: this must be the last rule in the chain */

Chain INPUT (policy ACCEPT 14278 packets, 1311K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 394K packets, 105M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 394K packets, 105M bytes)
 pkts bytes target     prot opt in     out     source               destination         
   48  3769 KUBE-PORTALS-HOST  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* handle ClusterIPs; NOTE: this must be before the NodePort rules */
    7   445 KUBE-NODEPORT-HOST  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL /* handle service NodePorts; NOTE: this must be the last rule in the chain */

Chain EDGEMESH-NODEPORT-CONTAINER (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain KUBE-PORTALS-CONTAINER (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            10.96.0.10           /* kube-system/kube-dns:dns */ udp dpt:53 to:169.254.96.16:41323
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            10.96.0.10           /* kube-system/kube-dns:dns-tcp */ tcp dpt:53 to:169.254.96.16:40877
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            10.96.0.10           /* kube-system/kube-dns:metrics */ tcp dpt:9153 to:169.254.96.16:40041
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            10.96.0.1            /* default/kubernetes:https */ tcp dpt:443 to:169.254.96.16:42665

Chain KUBE-PORTALS-HOST (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            10.96.0.10           /* kube-system/kube-dns:dns */ udp dpt:53 to:169.254.96.16:41323
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            10.96.0.10           /* kube-system/kube-dns:dns-tcp */ tcp dpt:53 to:169.254.96.16:40877
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            10.96.0.10           /* kube-system/kube-dns:metrics */ tcp dpt:9153 to:169.254.96.16:40041
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            10.96.0.1            /* default/kubernetes:https */ tcp dpt:443 to:169.254.96.16:42665

Chain KUBE-NODEPORT-CONTAINER (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain KUBE-NODEPORT-HOST (1 references)
 pkts bytes target     prot opt in     out     source               destination

對(duì)于edgemesh <= v1.11，鏈的名字是EDGEMESH- 開(kāi)頭的，edgemesh >=v1.12，鏈的名字是KUBE-開(kāi)頭的。

問(wèn)題四：env MY_NODE_NAME not exist; /etc/edgemesh/edgemesh-agent.yaml not exists

首先這是因?yàn)閑dgemesh-agent版本存在差異，如下：

EdgeMesh <= v1.11
1.需要部署edgemesh-server和edgemesh-agent兩個(gè)組件
2.配置文件在/etc/kubeedge/config/edgemesh-agent.yaml下，環(huán)境變量叫 MY_NODE_NAME

EdgeMesh >= v1.12 (包括latest)
1.只需要部署edgemesh-agent
2.配置文件在/etc/edgemesh/config/edgemesh-agent.yaml下，環(huán)境變量叫 NODE_NAME

重點(diǎn)來(lái)了：如果你使用kubeedge/edgemesh-agent:latest鏡像還遇到這個(gè)問(wèn)題，那是因?yàn)橛行C(jī)器的docker去拉kubeedge/edgemesh-agent:latest鏡像老是拉到舊的，原因不明。 但kubeedge/edgemesh-agent:latest鏡像我最近是更新過(guò)的，下圖可證：

真不怪我啊，而且每次edgemesh倉(cāng)庫(kù)有commit合入main分支就會(huì)打latest鏡像并push，你得看看自己的docker出啥問(wèn)題了。

解決方法就是別用latest鏡像，通過(guò)指定鏡像版本和helm版本部署edgemesh：

1.如果選用的EdgeMesh版本 >= v1.12.0
$ helm install edgemesh --namespace kubeedge \
--set agent.image=kubeedge/edgemesh-agent:v1.12.0 \
--set agent.relayNodes[0].nodeName=k8s-node1,agent.relayNodes[0].advertiseAddress="{119.8.211.54,2.2.2.2}" \
https://raw.githubusercontent.com/kubeedge/edgemesh/release-1.12/build/helm/edgemesh.tgz

2.如果選用的EdgeMesh版本 <= v1.11.0
$ helm install edgemesh \
--set agent.image=kubeedge/edgemesh-agent:v1.11.0 \
--set server.image=kubeedge/edgemesh-server:v1.11.0 \
--set server.nodeName=k8s-node1 \
--set server.advertiseAddress="{119.8.211.54}" \
https://raw.githubusercontent.com/kubeedge/edgemesh/release-1.11/build/helm/edgemesh.tgz

問(wèn)題五：bad address xxx; Could not resolve host xxx

這是一個(gè)域名解析（DNS request）問(wèn)題。

首先你要搞清楚是在云上節(jié)點(diǎn)(kubelet節(jié)點(diǎn))還是邊緣節(jié)點(diǎn)(edgecore節(jié)點(diǎn))遇到這個(gè)問(wèn)題。如果你是在云上節(jié)點(diǎn)(kubelet節(jié)點(diǎn))遇到這個(gè)問(wèn)題，那和edgemesh沒(méi)有半毛錢關(guān)系，因?yàn)樵粕瞎?jié)點(diǎn)的域名解析是coredns或kube-dns負(fù)責(zé)的，不過(guò)你可以看看有沒(méi)有可能是問(wèn)題六導(dǎo)致的。

如果在邊緣節(jié)點(diǎn)上遇到這個(gè)問(wèn)題，那么定位思路如下：

1. 先用clusterIP訪問(wèn)，測(cè)試連通性。比如有個(gè)mysql服務(wù)的域名是 my-mysql.default 對(duì)應(yīng)的 clusterIP是10.96.0.25，那就（用curl或telnet或nc，反正別用ping）訪問(wèn)10.96.0.25看看能不能通，能通證明連通性沒(méi)問(wèn)題，至少家保住了！

2. 看發(fā)起訪問(wèn)的pod內(nèi)的/etc/resolv.conf內(nèi)容，有沒(méi)有 nameserver 169.254.96.16。

/etc/resolv.conf是用來(lái)配置主機(jī)(或容器內(nèi))的域名解析服務(wù)器的文件，不懂的話自己搜一下去學(xué)。 169.254.96.16是edgemesh監(jiān)聽(tīng)的網(wǎng)橋IP，其中 169.254.96.16:53 是edgemesh的域名解析模塊監(jiān)聽(tīng)的socket。如果/etc/resolv.conf內(nèi)容里沒(méi)有nameserver 169.254.96.16，那域名解析請(qǐng)求肯定發(fā)不到edgemesh的域名解析模塊里。

注意：請(qǐng)別手動(dòng)修改pod內(nèi)的/etc/resolv.conf，因?yàn)閜od重建后記錄就消失了；當(dāng)然，也別往你宿主機(jī)的/etc/resolv.conf寫(xiě)入nameserver 169.254.96.16，因?yàn)槿绻鹐dgemesh-agent不在你宿主機(jī)上運(yùn)行的話，這條nameserver會(huì)影響到你宿主機(jī)的域名解析。如果你非得改/etc/resolv.conf，你必須非常了解 /etc/resolv.conf 的原理，同時(shí)你得清晰的知道自己為什么這么干。

那為什么你的pod里的/etc/resolv.conf不對(duì)呢？

a.重點(diǎn)來(lái)了，這里有一個(gè)k8s 知識(shí)點(diǎn)，就是關(guān)于pod的DNS策略，請(qǐng)看 Pod 的 DNS 策略。

簡(jiǎn)單的說(shuō)就是，如果你的pod是hostNetwork: true（也即主機(jī)網(wǎng)絡(luò)啟動(dòng)的），那你得配置 dnsPolicy: ClusterFirstWithHostNet，然后重啟你的pod。

b.如果你的pod是容器網(wǎng)絡(luò)的（不是主機(jī)網(wǎng)絡(luò)那就是容器網(wǎng)絡(luò)了），但是/etc/resolv.conf的內(nèi)容還是不對(duì)，請(qǐng)你給我再去自檢一遍。自檢完后，如果edgecore的配置修改了，記得重啟你的pod，那樣/etc/resolv.conf才能生效。

3. 如果上述的 1 和 2 都沒(méi)問(wèn)題，那你可以先去宿主機(jī)上測(cè)試一下其他域名通不通：

$ nslookup kubernetes.default.svc.cluster.local 169.254.96.16
Server:		169.254.96.16
Address:	169.254.96.16#53

Name:	kubernetes.default.svc.cluster.local
Address: 10.96.0.1

然后再自己創(chuàng)建一個(gè)test服務(wù)測(cè)一下通不通：

$ nslookup test-svc.default.svc.cluster.local 169.254.96.16
Server:		169.254.96.16
Address:	169.254.96.16#53

Name:	test-svc.default.svc.cluster.local
Address: 10.109.140.60

nslookup是域名解析工具，不懂自學(xué)；中間是服務(wù)的域名；最后是域名解析服務(wù)器的IP（169.254.96.16:53代表edgemesh的域名解析服務(wù)模塊監(jiān)聽(tīng)的socket）

重點(diǎn)來(lái)了，如果nslookup測(cè)試后都是通的，那么我認(rèn)為edgemesh的域名解析沒(méi)任何問(wèn)題，那為啥還是解析不了域名呢？

可能是 KubeEdge issue 3445 導(dǎo)致。因?yàn)閑dgemesh用于域名解析的元數(shù)據(jù)來(lái)自于edgecore的metaserver，metaserver發(fā)送了service 的DELETE事件，edgemesh拿到這個(gè)事件后，就把這個(gè)service的元數(shù)據(jù)從內(nèi)存中刪除了，導(dǎo)致域名解析的時(shí)候查不到元數(shù)據(jù)。

根據(jù)issue里的指導(dǎo)，臨時(shí)規(guī)避方式如下：

a. 刪除service
b. kubectl delete objectsync --all
c. 重啟cloudcore、edgecore，重新部署edgemesh
d. 重新創(chuàng)建service

問(wèn)題六：裝edgemesh后，云上節(jié)點(diǎn)域名解析失效了

裝edgemesh前云上的域名解析好好的，裝edgemesh后，云上的域名解析失敗了。

首先，云上的域名解析服務(wù)是coredns或kube-dns做的（在kube-system命名空間下，clusterIP通常是10.96.0.10）。這是k8s自己的域名解析服務(wù)，云上所有pod的集群域名解析都由他們完成。k8s自己的域名解析服務(wù)也是一個(gè)k8s service，和你自己創(chuàng)建的service沒(méi)任何區(qū)別。

你部署了edgemesh，那默認(rèn)來(lái)說(shuō)edgemesh就會(huì)攔截所有的k8s service，包括k8s自己的域名解析服務(wù)。那么為什么edgemesh攔截后，就不通了呢？

請(qǐng)?jiān)購(gòu)?fù)習(xí)一下定位模型，這大概率是因?yàn)閏oredns-pod所處的節(jié)點(diǎn)，它沒(méi)部署edgemesh-agent，導(dǎo)致發(fā)起端的edgemesh-agent找不到對(duì)端，所以流量送不過(guò)去。這個(gè)情況是非常經(jīng)常出現(xiàn)的，因?yàn)閏oredns一般會(huì)部署在k8s master節(jié)點(diǎn)上，而master節(jié)點(diǎn)一般都有污點(diǎn)，會(huì)驅(qū)逐其他pod，進(jìn)而導(dǎo)致edgemesh-agent部署不上去。這種情況可以通過(guò)去除節(jié)點(diǎn)污點(diǎn)，使edgemesh-agent部署上去解決。

還有一種規(guī)避方法，就是不讓edgemesh去代理k8s自己的域名解析服務(wù)：

先閱讀一下：混合代理 | EdgeMesh | 服務(wù)過(guò)濾，總結(jié)就是：

$ kubectl -n kube-system label services coredns service.edgemesh.kubeedge.io/service-proxy-name=""
或
$ kubectl -n kube-system label services kube-dns service.edgemesh.kubeedge.io/service-proxy-name=""

問(wèn)題七：宿主機(jī)上不能解析集群域名

集群域名格式：service-name.namespace.svc.cluster.local 在pod內(nèi)訪問(wèn)域名時(shí)，后綴 svc.cluster.local 是可逐個(gè)省略的，比如mysql.default.svc.cluster、mysql.default.svc 和 mysql.default

外部域名格式： www.baidu.com, www.jd.com 等等

首先，沒(méi)人說(shuō)過(guò)宿主機(jī)上能解析集群域名啊！不信你試試在云上k8s節(jié)點(diǎn)的宿主機(jī)上，用nslookup解析集群域名試試。

pod內(nèi)能解析域名，是因?yàn)椋?/p>

1. 云上節(jié)點(diǎn)，當(dāng)kubelet啟動(dòng)一個(gè)pod時(shí)，會(huì)往pod的/etc/resolv.conf寫(xiě)入coredns或kube-dns的clusterIP，比如：

$ cat /etc/resolv.conf 
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local openstacklocal
options ndots:5

2.邊緣節(jié)點(diǎn)，當(dāng)edgecore（需要配置過(guò)clusterDNS）啟動(dòng)一個(gè)pod時(shí)，會(huì)往pod的/etc/resolv.conf寫(xiě)入 nameserver 169.254.96.16（169.254.96.16:53就是edgemesh的域名解析模塊監(jiān)聽(tīng)的socket）

kubelet和edgecore會(huì)往pod的/etc/resolv.conf寫(xiě)入什么內(nèi)容，也取決于pod是否是主機(jī)網(wǎng)絡(luò)，以及pod的dnsPolicy，請(qǐng)看 問(wèn)題五的2.a 學(xué)習(xí)一下。

如果你非得在宿主機(jī)上訪問(wèn)集群域名，那你就把域名解析服務(wù)器的ip手動(dòng)寫(xiě)入到宿主機(jī)上的/etc/resolv.conf。 云上是coredns或kube-dns的clusterIP，如10.96.0.10；邊緣是edgemesh的網(wǎng)橋IP 169.254.96.16

問(wèn)題八：Get xxx:10350/containerLogs xxx timeout

你這是想在云上節(jié)點(diǎn)通過(guò) kubectl logs 命令看處于邊緣節(jié)點(diǎn)的pod的日志對(duì)吧？還是想在云上節(jié)點(diǎn)通過(guò) kubectl exec 命令登錄邊緣節(jié)點(diǎn)的pod？

和edgemesh沒(méi)半毛錢關(guān)系，請(qǐng)移步：KubeEdge啟用logs與exec功能

問(wèn)題九：can't open node port for xxx bind: address already in use

一般出現(xiàn)在kube-proxy和edgemesh共存的云節(jié)點(diǎn)上（可以共存，沒(méi)說(shuō)不能共存）。另外，這個(gè)報(bào)錯(cuò)并不會(huì)影響你使用edgemesh。

kube-proxy和edgemesh都會(huì)去代理k8s 的 services，對(duì)于nodePort類型的services，kube-proxy和edgemesh都會(huì)處理它，并會(huì)去主機(jī)上啟動(dòng)一個(gè)監(jiān)聽(tīng)的端口。比如一個(gè)service的type是NodePort，nodePort地址是30001，那么kube-proxy和edgemesh都會(huì)嘗試去主機(jī)上啟動(dòng)并監(jiān)聽(tīng)30001端口。

讀到這你應(yīng)該明白了，其實(shí)就是kube-proxy優(yōu)先處理了這個(gè)NodePort Service，并監(jiān)聽(tīng)在主機(jī)某個(gè)端口。然后edgemesh也想去處理這個(gè)service，也想在主機(jī)監(jiān)聽(tīng)同一個(gè)端口，所以就bind: address already in use。

如果你看這個(gè)日志很煩，可以這么規(guī)避，請(qǐng)閱讀：混合代理 | EdgeMesh | 服務(wù)過(guò)濾 ，把服務(wù)過(guò)濾掉。

如果這個(gè)服務(wù)你就是希望它被edgemesh代理（可能你想跨云邊去訪問(wèn)這個(gè)服務(wù)），請(qǐng)給服務(wù)打上http://service.kubernetes.io/service-proxy-name 標(biāo)簽，使此服務(wù)不被kube-proxy代理。

還有不明白，請(qǐng)看問(wèn)題十

問(wèn)題十：在edgemesh和kube-proxy共存的節(jié)點(diǎn)，服務(wù)會(huì)被誰(shuí)給代理？

請(qǐng)先閱讀：混合代理 | EdgeMesh ，作為擴(kuò)展知識(shí)，還建議你學(xué)習(xí)一下Linux iptables、netfilter原理和四表五鏈。

所以，在edgemesh和kube-proxy共存的節(jié)點(diǎn)上，一個(gè)k8s service會(huì)被誰(shuí)代理，得看發(fā)出的流量?jī)?yōu)先被誰(shuí)給攔截了（即誰(shuí)的根鏈在前，誰(shuí)就更先攔截）。可以結(jié)合 問(wèn)題二、三 再細(xì)品一下。

此外，一個(gè)k8s service：

• 不想讓edgemesh代理的話，請(qǐng)給服務(wù)打上 http://service.edgemesh.kubeedge.io/service-proxy-name 標(biāo)簽
• 不想讓kube-proxy代理的話，請(qǐng)給服務(wù)打上 service.kubernetes.io/service-proxy-name標(biāo)簽

問(wèn)題十一：怎么調(diào)試edgemesh代碼

建議使用Goland IDE，同時(shí)升級(jí)Goland到2022.02后的版本，這個(gè)版本會(huì)自帶ssh功能，你可以ssh到你的服務(wù)器上去調(diào)試代碼。

調(diào)試方法很多，舉例一個(gè)我的調(diào)試方法：

1. 搞一個(gè)服務(wù)器，比如服務(wù)器A，把服務(wù)器A納管成k8s的節(jié)點(diǎn)或者邊緣節(jié)點(diǎn)
2. 在你的k8s集群部署edgemesh，這時(shí)候edgemesh-agent會(huì)部署到服務(wù)器A上
3. 通過(guò)給節(jié)點(diǎn)（服務(wù)器A）添加污點(diǎn)，把服務(wù)器A上的edgemesh-agent的pod驅(qū)逐掉
4. 在服務(wù)器A下載edgemesh源代碼，然后用Goland IDE連接上去，確保能遠(yuǎn)程編譯、運(yùn)行和調(diào)試
5. 準(zhǔn)備edgemesh需要的環(huán)境變量和配置文件，如NODE_NAME、edgemesh-agent.yaml等等（后續(xù)運(yùn)行的時(shí)候缺什么就補(bǔ)什么）
6. 通過(guò)Goland IDE 的ssh功能連接服務(wù)器A上的edgemesh代碼，這時(shí)候?qū)dgemesh的編譯、運(yùn)行和調(diào)試都是發(fā)生服務(wù)器A上的

還有另一個(gè)方式，就是直接進(jìn)k8s pod去調(diào)試，不過(guò)需要給Goland IDE安裝插件，請(qǐng)閱讀 什么是 Nocalhost? | Nocalhost。需要你自己花點(diǎn)時(shí)間琢磨一下，我以前用這個(gè)插件調(diào)試過(guò)kube-proxy的pod，能成功。

問(wèn)題十二：應(yīng)用處于同一個(gè)邊緣網(wǎng)絡(luò)里，卻無(wú)法互相訪問(wèn)

首先edgemesh目前只支持通過(guò)service的clusterIP互訪，暫不支持podIP互訪；其次這個(gè)問(wèn)題得分edgemesh版本討論。

1. 對(duì)于edgemesh <= v1.11的版本

需要部署edgemesh-server和edgemesh-agent。edgemesh-server一般部署在數(shù)據(jù)中心（具有公網(wǎng)IP，服務(wù)器資性能較好），用來(lái)協(xié)助其他edgemesh-agent在建立連接的時(shí)候交換公網(wǎng)信息與協(xié)助打洞；后續(xù)在打洞失敗的時(shí)候也會(huì)作為中繼節(jié)點(diǎn)來(lái)轉(zhuǎn)發(fā)流量。想了解這些信息，可以搜關(guān)鍵字：內(nèi)網(wǎng)穿透、UDP打洞、STUN/TURN和Libp2p。

edgemesh-agent在啟動(dòng)的時(shí)候，會(huì)嘗試和edgemesh-server建立連接，如果多次嘗試后仍無(wú)法建立連接，那么edgemesh-agent就會(huì)掛掉/重啟并重新執(zhí)行上述過(guò)程。此外，edgemesh-agent還會(huì)通過(guò)調(diào)用edgecore的邊緣Kube API Endpoint功能去將自己的peer ID信息，寫(xiě)入到一個(gè)名為edgemeshaddrsecret的configmap里面（kubeedge命名空間下），重點(diǎn)就在于edgecore的邊緣Kube API Endpoint功能需要edgecore和cloudcore是連通的，才能執(zhí)行資源的Update、Add和Delete。

總結(jié)就是：如果edgemesh-agent連接不上edgemesh-server，或者edgecore與cloudcore斷連，那么edgemesh-agent無(wú)法正常工作，所以應(yīng)用就無(wú)法互訪。

2.對(duì)于edgemesh>=1.12版本

在架構(gòu)上不再需要部署edgemesh-server了，內(nèi)網(wǎng)穿透和中繼的能力移植到了edgemesh-agent里面。如果某個(gè)節(jié)點(diǎn)或者某些節(jié)點(diǎn)具有公網(wǎng)IP，你可以讓部署在這些節(jié)點(diǎn)上的edgemesh-agent成為中繼。

edgemesh-agent在啟動(dòng)的時(shí)候，會(huì)多次嘗試連接那些被配置成中繼節(jié)點(diǎn)的relayNodes（我們也稱之為bootstrap節(jié)點(diǎn)）。對(duì)比小于1.12版本的差異是，現(xiàn)在即使連接不上bootstrap節(jié)點(diǎn)，edgemesh-agent也不會(huì)掛掉，緊接著它會(huì)通過(guò)多播(組播)的方式發(fā)送mDNS協(xié)議的數(shù)據(jù)包，在同一個(gè)VLAN網(wǎng)絡(luò)里發(fā)現(xiàn)其他edgemesh-agent并記錄peer ID。

這邊需要滿足幾個(gè)條件：

a. mDNS協(xié)議本身是基于UDP協(xié)議的，你需要確保你的網(wǎng)絡(luò)放通了UDP數(shù)據(jù)包的傳輸

b. 由于mDNS是多播(組播)協(xié)議，因此要求你的節(jié)點(diǎn)在同一個(gè)網(wǎng)段里面；節(jié)點(diǎn)也必須也得在同一個(gè)VLAN里面，不同VLAN之間是隔離廣播域的

c. edgemesh-agent的tunnel模塊監(jiān)聽(tīng)在20006，確保安全組/防火墻對(duì)20006端口放開(kāi)

d. 所有節(jié)點(diǎn)應(yīng)該具備內(nèi)網(wǎng)IP（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16），否則mDNS的數(shù)據(jù)包會(huì)被丟棄，導(dǎo)致不能互相發(fā)現(xiàn)

滿足上述的條件后，edgemesh就能協(xié)助同一個(gè)邊緣網(wǎng)絡(luò)里應(yīng)用的互訪了；如果不滿足上述條件，你就必須配置relayNodes來(lái)走中繼的方式去通信。relayNodes設(shè)置方式詳細(xì)材料請(qǐng)閱讀：KubeEdge EdgeMesh 高可用架構(gòu)詳解 。

問(wèn)題十三：訪問(wèn)服務(wù)時(shí)出現(xiàn) Connection reset by peer

先復(fù)習(xí)一下定位模型，再確定發(fā)起訪問(wèn)節(jié)點(diǎn)上的 edgemesh-agent 容器是否存在、是否處于正常運(yùn)行中。

使用 kubectl logs 或者 docker logs 查看發(fā)起訪問(wèn)節(jié)點(diǎn)上的edgemesh-agent容器的日志，看看報(bào)什么錯(cuò)。遇到的錯(cuò)誤一般都記錄在此文檔里，找找一定有。

問(wèn)題十四：進(jìn)行服務(wù)訪問(wèn)的時(shí)候，edgemesh-agent沒(méi)任何日志

先復(fù)習(xí)一下定位模型，再確定發(fā)起訪問(wèn)節(jié)點(diǎn)上的 edgemesh-agent(左)容器是否存在、是否處于正常運(yùn)行中。

如果正常，那一般由問(wèn)題三導(dǎo)致。

問(wèn)題十五：ping不通服務(wù)的ClusterIP

服務(wù)的clusterIP就是不能ping的！

你先自學(xué)一下 ping 這個(gè)東西是干什么的，ping一般可以測(cè)試主機(jī)間的連通性和往返時(shí)延，它的原理是往目的主機(jī)發(fā)送一個(gè)ICMP報(bào)文，目的主機(jī)接收并處理此ICMP報(bào)文，然后回復(fù)響應(yīng)給發(fā)起端。

你自己的服務(wù)，比如mysql-service，clusterIP是10.96.0.25，監(jiān)聽(tīng)在3306，這樣一個(gè)只服務(wù)在 10.96.0.25:3306的mysql服務(wù)，憑什么能處理ICMP報(bào)文？

問(wèn)題十六：failed to find any peer in table; failed to connect to an endpoint

此答復(fù)適用于EdgeMesh>v1.12。先復(fù)習(xí)一下定位模型，確定被訪問(wèn)節(jié)點(diǎn)上的edgemesh-agent(右)容器是否存在、是否處于正常運(yùn)行中。

這個(gè)情況是非常經(jīng)常出現(xiàn)的，因?yàn)閙aster節(jié)點(diǎn)一般都有污點(diǎn)，會(huì)驅(qū)逐其他pod，進(jìn)而導(dǎo)致edgemesh-agent部署不上去。這種情況可以通過(guò)去除節(jié)點(diǎn)污點(diǎn)，使edgemesh-agent部署上去解決。

如果訪問(wèn)節(jié)點(diǎn)和被訪問(wèn)節(jié)點(diǎn)的edgemesh-agent都正常啟動(dòng)了，但是還報(bào)這個(gè)錯(cuò)誤，可能是因?yàn)樵L問(wèn)節(jié)點(diǎn)和被訪問(wèn)節(jié)點(diǎn)沒(méi)有互相發(fā)現(xiàn)導(dǎo)致，請(qǐng)這樣排查：

1. 首先每個(gè)節(jié)點(diǎn)上的edgemesh-agent都具有peer ID，比如

我有兩個(gè)節(jié)點(diǎn)：k8s-master和ke-edge2
k8s-master節(jié)點(diǎn)上的edgemesh-agent的peer ID是：12D3KooWB5qVCMrMNLpBDfMu6o4dy6ci2UqDVsFVomcd2PfYVzfW
ke-edge2  節(jié)點(diǎn)上的edgemesh-agent的peer ID是：12D3KooWSD4f5fZb5c9PQ6FPVd8Em4eKX3mRezcyqXSHUyomoy8S

注意：
a. peer ID是根據(jù)節(jié)點(diǎn)名稱哈希出來(lái)的，相同的節(jié)點(diǎn)名稱會(huì)哈希出相同的peer ID
b. 另外，節(jié)點(diǎn)名稱不是服務(wù)器名稱，是k8s node name，請(qǐng)用kubectl get nodes查看

2.如果訪問(wèn)節(jié)點(diǎn)和被訪問(wèn)節(jié)點(diǎn)處于同一個(gè)局域網(wǎng)內(nèi)，請(qǐng)看問(wèn)題十二。同一個(gè)局域網(wǎng)內(nèi)edgemesh-agent互相發(fā)現(xiàn)對(duì)方時(shí)的日志是 [MDNS] Discovery found peer: <被訪問(wèn)端peer ID: [被訪問(wèn)端IP列表(可能會(huì)包含中繼節(jié)點(diǎn)IP)]>

3.如果訪問(wèn)節(jié)點(diǎn)和被訪問(wèn)節(jié)點(diǎn)跨子網(wǎng)，這時(shí)候你應(yīng)該看看relayNodes設(shè)置的正不正確，為什么中繼節(jié)點(diǎn)沒(méi)辦法協(xié)助兩個(gè)節(jié)點(diǎn)交換peer信息。詳細(xì)材料請(qǐng)閱讀：KubeEdge EdgeMesh 高可用架構(gòu)詳解。跨子網(wǎng)的edgemesh-agent互相發(fā)現(xiàn)對(duì)方時(shí)的日志是 [DHT] Discovery found peer: <被訪問(wèn)端peer ID: [被訪問(wèn)端IP列表(可能會(huì)包含中繼節(jié)點(diǎn)IP)]>

如果還有不明白，可以根據(jù)問(wèn)題十八，畫(huà)出組網(wǎng)圖來(lái)分析。

問(wèn)題十七：Couldn't find an endpoint for service; missing endpoints

這個(gè)問(wèn)題是因?yàn)槟愕姆?wù)不存在后端pod實(shí)例，可能是后端應(yīng)用實(shí)例沒(méi)啟動(dòng)。

假如你有一個(gè)deployment應(yīng)用叫mysql，同時(shí)還創(chuàng)建了它的service叫mysql-svc：

1.使用kubectl get deploy mysql，看看pod是不是都running起來(lái)了

2.使用kubectl get endpoints mysql-svc，看看ENDPOINTS是不是有數(shù)據(jù)。

如果上述都正常，可能是 KubeEdge issue 3445 導(dǎo)致。根據(jù)issue里的指導(dǎo)，臨時(shí)規(guī)避方式如下：

a. 刪除service
b. kubectl delete objectsync --all
c. 重啟cloudcore、edgecore，重新部署edgemesh
d. 重新創(chuàng)建service

問(wèn)題十八：如何畫(huà)組網(wǎng)圖分析問(wèn)題

當(dāng)你讀完問(wèn)題十二或者問(wèn)題十六后，你還是不清楚為啥失敗，這時(shí)候可以畫(huà)一下組網(wǎng)圖來(lái)分析，以EdgeMesh >= v1.12.0為例。

概念解釋

備注：怎么查看某節(jié)點(diǎn)上運(yùn)行的edgemesh-agent的peerid呢？在edgemesh-agent運(yùn)行后會(huì)有日志，大概前10行附近有形如：I'm /ip4/198.51.100.0/tcp/20006/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N 的日志

組網(wǎng)圖示例

1.k8s-master和k8s-node1是云上節(jié)點(diǎn)，處于同一個(gè)局域網(wǎng)，且k8s-master具有公網(wǎng)IP可以作為中繼節(jié)點(diǎn)

2.ke-edge1和ke-edge2是邊緣節(jié)點(diǎn)，分別處于不同的局域網(wǎng)，且能夠連上k8s-master的公網(wǎng)IP 121.32.11.34

想象一個(gè)場(chǎng)景：如果你ke-edge2想要連接k8s-node1，但是卻發(fā)現(xiàn)failed to find any peer in table的錯(cuò)誤日志，你得排查一下：

1. k8s-node1是否正常運(yùn)行了edgemesh-agent
2. ke-edge2有沒(méi)有類似 [DHT] Discovery k8s-node1的peerid 的日志
3. k8s-master是中繼節(jié)點(diǎn)，你的relayNodes配置對(duì)了嗎