對于新安裝的 Kubernetes，經(jīng)常出現(xiàn)的問題是 Service 無法正常運(yùn)行。你已經(jīng)通過 Deployment（或其他工作負(fù)載控制器）運(yùn)行了 Pod，并創(chuàng)建 Service ， 但是當(dāng)你嘗試訪問它時(shí)，沒有任何響應(yīng)。此文檔有望對你有所幫助并找出問題所在。

在 Pod 中運(yùn)行命令

對于這里的許多步驟，你可能希望知道運(yùn)行在集群中的 Pod 看起來是什么樣的。 最簡單的方法是運(yùn)行一個(gè)交互式的 busybox Pod：

kubectl run -it --rm --restart=Never busybox --image=gcr.io/google-containers/busybox sh

說明：?如果沒有看到命令提示符，請按回車。

如果你已經(jīng)有了你想使用的正在運(yùn)行的 Pod，則可以運(yùn)行以下命令去進(jìn)入：

kubectl exec <POD-NAME> -c <CONTAINER-NAME> -- <COMMAND>

設(shè)置

為了完成本次實(shí)踐的任務(wù)，我們先運(yùn)行幾個(gè) Pod。 由于你可能正在調(diào)試自己的 Service，所以，你可以使用自己的信息進(jìn)行替換， 或者你也可以跟著教程并開始下面的步驟來獲得第二個(gè)數(shù)據(jù)點(diǎn)。

kubectl create deployment hostnames --image=registry.k8s.io/serve_hostname

deployment.apps/hostnames created

kubectl?命令將打印創(chuàng)建或變更的資源的類型和名稱，它們可以在后續(xù)命令中使用。 讓我們將這個(gè) deployment 的副本數(shù)擴(kuò)至 3。

kubectl scale deployment hostnames --replicas=3

deployment.apps/hostnames scaled

請注意這與你使用以下 YAML 方式啟動 Deployment 類似：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: hostnames
  name: hostnames
spec:
  selector:
    matchLabels:
      app: hostnames
  replicas: 3
  template:
    metadata:
      labels:
        app: hostnames
    spec:
      containers:
      - name: hostnames
        image: registry.k8s.io/serve_hostname

"app" 標(biāo)簽是?kubectl create deployment?根據(jù) Deployment 名稱自動設(shè)置的。

確認(rèn)你的 Pod 是運(yùn)行狀態(tài):

kubectl get pods -l app=hostnames

NAME                        READY     STATUS    RESTARTS   AGE
hostnames-632524106-bbpiw   1/1       Running   0          2m
hostnames-632524106-ly40y   1/1       Running   0          2m
hostnames-632524106-tlaok   1/1       Running   0          2m

你還可以確認(rèn)你的 Pod 是否正在提供服務(wù)。你可以獲取 Pod IP 地址列表并直接對其進(jìn)行測試。

kubectl get pods -l app=hostnames \
    -o go-template='{{range .items}}{{.status.podIP}}{{"\n"}}{{end}}'

10.244.0.5
10.244.0.6
10.244.0.7

用于本教程的示例容器通過 HTTP 在端口 9376 上提供其自己的主機(jī)名， 但是如果要調(diào)試自己的應(yīng)用程序，則需要使用你的 Pod 正在偵聽的端口號。

在 Pod 內(nèi)運(yùn)行：

for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do
    wget -qO- $ep
done

輸出類似這樣：

hostnames-632524106-bbpiw
hostnames-632524106-ly40y
hostnames-632524106-tlaok

如果此時(shí)你沒有收到期望的響應(yīng)，則你的 Pod 狀態(tài)可能不健康，或者可能沒有在你認(rèn)為正確的端口上進(jìn)行監(jiān)聽。 你可能會發(fā)現(xiàn)?kubectl logs?命令對于查看正在發(fā)生的事情很有用， 或者你可能需要通過kubectl exec?直接進(jìn)入 Pod 中并從那里進(jìn)行調(diào)試。

假設(shè)到目前為止一切都已按計(jì)劃進(jìn)行，那么你可以開始調(diào)查為何你的 Service 無法正常工作。

Service 是否存在？

細(xì)心的讀者會注意到我們實(shí)際上尚未創(chuàng)建 Service —— 這是有意而為之。 這一步有時(shí)會被遺忘，這是首先要檢查的步驟。

那么，如果我嘗試訪問不存在的 Service 會怎樣？ 假設(shè)你有另一個(gè) Pod 通過名稱匹配到 Service，你將得到類似結(jié)果：

wget -O- hostnames

Resolving hostnames (hostnames)... failed: Name or service not known.
wget: unable to resolve host address 'hostnames'

首先要檢查的是該 Service 是否真實(shí)存在：

kubectl get svc hostnames

No resources found.
Error from server (NotFound): services "hostnames" not found

讓我們創(chuàng)建 Service。 和以前一樣，在這次實(shí)踐中 —— 你可以在此處使用自己的 Service 的內(nèi)容。

kubectl expose deployment hostnames --port=80 --target-port=9376

service/hostnames exposed

重新運(yùn)行查詢命令：

kubectl get svc hostnames

NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
hostnames   ClusterIP   10.0.1.175   <none>        80/TCP    5s

現(xiàn)在你知道了 Service 確實(shí)存在。

同前，此步驟效果與通過 YAML 方式啟動 Service 一樣：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: hostnames
  name: hostnames
spec:
  selector:
    app: hostnames
  ports:
  - name: default
    protocol: TCP
    port: 80
    targetPort: 9376

為了突出配置范圍的完整性，你在此處創(chuàng)建的 Service 使用的端口號與 Pods 不同。 對于許多真實(shí)的 Service，這些值可以是相同的。

是否存在影響目標(biāo) Pod 的網(wǎng)絡(luò)策略入站規(guī)則？

如果你部署了任何可能影響到?hostnames-*?Pod 的傳入流量的網(wǎng)絡(luò)策略入站規(guī)則， 則需要對其進(jìn)行檢查。

Service 是否可通過 DNS 名字訪問？

通?？蛻舳送ㄟ^ DNS 名稱來匹配到 Service。

從相同命名空間下的 Pod 中運(yùn)行以下命令：

nslookup hostnames

Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      hostnames
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local

如果失敗，那么你的 Pod 和 Service 可能位于不同的命名空間中， 請嘗試使用限定命名空間的名稱（同樣在 Pod 內(nèi)運(yùn)行）：

nslookup hostnames.default

Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      hostnames.default
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local

如果成功，那么需要調(diào)整你的應(yīng)用，使用跨命名空間的名稱去訪問它， 或者在相同的命名空間中運(yùn)行應(yīng)用和 Service。如果仍然失敗，請嘗試一個(gè)完全限定的名稱：

nslookup hostnames.default.svc.cluster.local

Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      hostnames.default.svc.cluster.local
Address 1: 10.0.1.175 hostnames.default.svc.cluster.local

注意這里的后綴："default.svc.cluster.local"。"default" 是我們正在操作的命名空間。 "svc" 表示這是一個(gè) Service。"cluster.local" 是你的集群域，在你自己的集群中可能會有所不同。

你也可以在集群中的節(jié)點(diǎn)上嘗試此操作：

說明：

10.0.0.10 是集群的 DNS 服務(wù) IP，你的可能有所不同。

nslookup hostnames.default.svc.cluster.local 10.0.0.10

Server:         10.0.0.10
Address:        10.0.0.10#53

Name:   hostnames.default.svc.cluster.local
Address: 10.0.1.175

如果你能夠使用完全限定的名稱查找，但不能使用相對名稱，則需要檢查你 Pod 中的?/etc/resolv.conf?文件是否正確。在 Pod 中運(yùn)行以下命令：

cat /etc/resolv.conf

你應(yīng)該可以看到類似這樣的輸出：

nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local example.com
options ndots:5

nameserver?行必須指示你的集群的 DNS Service， 它是通過?--cluster-dns?標(biāo)志傳遞到 kubelet 的。

search?行必須包含一個(gè)適當(dāng)?shù)暮缶Y，以便查找 Service 名稱。 在本例中，它查找本地命名空間（default.svc.cluster.local）中的服務(wù)和所有命名空間 （svc.cluster.local）中的服務(wù)，最后在集群（cluster.local）中查找服務(wù)的名稱。 根據(jù)你自己的安裝情況，可能會有額外的記錄（最多 6 條）。 集群后綴是通過?--cluster-domain?標(biāo)志傳遞給?kubelet?的。 本文中，我們假定后綴是 “cluster.local”。 你的集群配置可能不同，這種情況下，你應(yīng)該在上面的所有命令中更改它。

options?行必須設(shè)置足夠高的?ndots，以便 DNS 客戶端庫考慮搜索路徑。 在默認(rèn)情況下，Kubernetes 將這個(gè)值設(shè)置為 5，這個(gè)值足夠高，足以覆蓋它生成的所有 DNS 名稱。

是否存在 Service 能通過 DNS 名稱訪問？

如果上面的方式仍然失敗，DNS 查找不到你需要的 Service ，你可以后退一步， 看看還有什么其它東西沒有正常工作。 Kubernetes 主 Service 應(yīng)該一直是工作的。在 Pod 中運(yùn)行如下命令：

nslookup kubernetes.default

Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes.default
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local

如果失敗，? 你可能需要轉(zhuǎn)到本文的 kube-proxy 節(jié)， 或者甚至回到文檔的頂部重新開始，但不是調(diào)試你自己的 Service ，而是調(diào)試 DNS Service。

Service 能夠通過 IP 訪問么？

假設(shè)你已經(jīng)確認(rèn) DNS 工作正常，那么接下來要測試的是你的 Service 能否通過它的 IP 正常訪問。 從集群中的一個(gè) Pod，嘗試訪問 Service 的 IP（從上面的?kubectl get?命令獲?。?。

for i in $(seq 1 3); do 
    wget -qO- 10.0.1.175:80
done

輸出應(yīng)該類似這樣：

hostnames-632524106-bbpiw
hostnames-632524106-ly40y
hostnames-632524106-tlaok

如果 Service 狀態(tài)是正常的，你應(yīng)該得到正確的響應(yīng)。 如果沒有，有很多可能出錯的地方，請繼續(xù)閱讀。

Service 的配置是否正確？

這聽起來可能很愚蠢，但你應(yīng)該兩次甚至三次檢查你的 Service 配置是否正確，并且與你的 Pod 匹配。 查看你的 Service 配置并驗(yàn)證它：

kubectl get service hostnames -o json

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "hostnames",
        "namespace": "default",
        "uid": "428c8b6c-24bc-11e5-936d-42010af0a9bc",
        "resourceVersion": "347189",
        "creationTimestamp": "2015-07-07T15:24:29Z",
        "labels": {
            "app": "hostnames"
        }
    },
    "spec": {
        "ports": [
            {
                "name": "default",
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376,
                "nodePort": 0
            }
        ],
        "selector": {
            "app": "hostnames"
        },
        "clusterIP": "10.0.1.175",
        "type": "ClusterIP",
        "sessionAffinity": "None"
    },
    "status": {
        "loadBalancer": {}
    }
}

• 你想要訪問的 Service 端口是否在?spec.ports[]?中列出？
• targetPort?對你的 Pod 來說正確嗎（許多 Pod 使用與 Service 不同的端口）？
• 如果你想使用數(shù)值型端口，那么它的類型是一個(gè)數(shù)值（9376）還是字符串 “9376”？
• 如果你想使用名稱型端口，那么你的 Pod 是否暴露了一個(gè)同名端口？
• 端口的?protocol?和 Pod 的是否對應(yīng)？

Service 有 Endpoints 嗎？

如果你已經(jīng)走到了這一步，你已經(jīng)確認(rèn)你的 Service 被正確定義，并能通過 DNS 解析。 現(xiàn)在，讓我們檢查一下，你運(yùn)行的 Pod 確實(shí)是被 Service 選中的。

早些時(shí)候，我們已經(jīng)看到 Pod 是運(yùn)行狀態(tài)。我們可以再檢查一下：

kubectl get pods -l app=hostnames

NAME                        READY     STATUS    RESTARTS   AGE
hostnames-632524106-bbpiw   1/1       Running   0          1h
hostnames-632524106-ly40y   1/1       Running   0          1h
hostnames-632524106-tlaok   1/1       Running   0          1h

-l app=hostnames?參數(shù)是在 Service 上配置的標(biāo)簽選擇器。

“AGE” 列表明這些 Pod 已經(jīng)啟動一個(gè)小時(shí)了，這意味著它們運(yùn)行良好，而未崩潰。

"RESTARTS" 列表明 Pod 沒有經(jīng)常崩潰或重啟。經(jīng)常性崩潰可能導(dǎo)致間歇性連接問題。 如果重啟次數(shù)過大，通過調(diào)試 Pod 了解相關(guān)技術(shù)。

在 Kubernetes 系統(tǒng)中有一個(gè)控制回路，它評估每個(gè) Service 的選擇算符，并將結(jié)果保存到 Endpoints 對象中。

kubectl get endpoints hostnames

NAME        ENDPOINTS
hostnames   10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376

這證實(shí) Endpoints 控制器已經(jīng)為你的 Service 找到了正確的 Pods。 如果?ENDPOINTS?列的值為?<none>，則應(yīng)檢查 Service 的?spec.selector?字段， 以及你實(shí)際想選擇的 Pod 的?metadata.labels?的值。 常見的錯誤是輸入錯誤或其他錯誤，例如 Service 想選擇?app=hostnames，但是 Deployment 指定的是?run=hostnames。在 1.18之前的版本中?kubectl run?也可以被用來創(chuàng)建 Deployment。

Pod 工作正常嗎？

至此，你知道你的 Service 已存在，并且已匹配到你的Pod。在本實(shí)驗(yàn)的開始，你已經(jīng)檢查了 Pod 本身。 讓我們再次檢查 Pod 是否確實(shí)在工作 - 你可以繞過 Service 機(jī)制并直接轉(zhuǎn)到 Pod， 如上面的 Endpoints 所示。

說明：

這些命令使用的是 Pod 端口（9376），而不是 Service 端口（80）。

在 Pod 中運(yùn)行：

for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do
    wget -qO- $ep
done

輸出應(yīng)該類似這樣：

hostnames-632524106-bbpiw
hostnames-632524106-ly40y
hostnames-632524106-tlaok

你希望 Endpoint 列表中的每個(gè) Pod 都返回自己的主機(jī)名。 如果情況并非如此（或你自己的 Pod 的正確行為是什么），你應(yīng)調(diào)查發(fā)生了什么事情。

kube-proxy 正常工作嗎？

如果你到達(dá)這里，則說明你的 Service 正在運(yùn)行，擁有 Endpoints，Pod 真正在提供服務(wù)。 此時(shí)，整個(gè) Service 代理機(jī)制是可疑的。讓我們一步一步地確認(rèn)它沒問題。

Service 的默認(rèn)實(shí)現(xiàn)（在大多數(shù)集群上應(yīng)用的）是 kube-proxy。 這是一個(gè)在每個(gè)節(jié)點(diǎn)上運(yùn)行的程序，負(fù)責(zé)配置用于提供 Service 抽象的機(jī)制之一。 如果你的集群不使用 kube-proxy，則以下各節(jié)將不適用，你將必須檢查你正在使用的 Service 的實(shí)現(xiàn)方式。

kube-proxy 正常運(yùn)行嗎？ {#is-kube-proxy working}

確認(rèn)?kube-proxy?正在節(jié)點(diǎn)上運(yùn)行。在節(jié)點(diǎn)上直接運(yùn)行，你將會得到類似以下的輸出：

ps auxw | grep kube-proxy

root  4194  0.4  0.1 101864 17696 ?    Sl Jul04  25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=/var/lib/kube-proxy/kubeconfig --v=2

下一步，確認(rèn)它并沒有出現(xiàn)明顯的失敗，比如連接主節(jié)點(diǎn)失敗。要做到這一點(diǎn)，你必須查看日志。 訪問日志的方式取決于你節(jié)點(diǎn)的操作系統(tǒng)。 在某些操作系統(tǒng)上日志是一個(gè)文件，如 /var/log/messages kube-proxy.log， 而其他操作系統(tǒng)使用?journalctl?訪問日志。你應(yīng)該看到輸出類似于：

I1027 22:14:53.995134    5063 server.go:200] Running in resource-only container "/kube-proxy"
I1027 22:14:53.998163    5063 server.go:247] Using iptables Proxier.
I1027 22:14:54.038140    5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53]
I1027 22:14:54.038164    5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53]
I1027 22:14:54.038209    5063 proxier.go:352] Setting endpoints for "default/kubernetes:https" to [10.240.0.2:443]
I1027 22:14:54.038238    5063 proxier.go:429] Not syncing iptables until Services and Endpoints have been received from master
I1027 22:14:54.040048    5063 proxier.go:294] Adding new service "default/kubernetes:https" at 10.0.0.1:443/TCP
I1027 22:14:54.040154    5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns" at 10.0.0.10:53/UDP
I1027 22:14:54.040223    5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP

如果你看到有關(guān)無法連接主節(jié)點(diǎn)的錯誤消息，則應(yīng)再次檢查節(jié)點(diǎn)配置和安裝步驟。

kube-proxy?無法正確運(yùn)行的可能原因之一是找不到所需的?conntrack?二進(jìn)制文件。 在一些 Linux 系統(tǒng)上，這也是可能發(fā)生的，這取決于你如何安裝集群， 例如，你是手動開始一步步安裝 Kubernetes。如果是這樣的話，你需要手動安裝?conntrack?包（例如，在 Ubuntu 上使用?sudo apt install conntrack），然后重試。

Kube-proxy 可以以若干模式之一運(yùn)行。在上述日志中，Using iptables Proxier?行表示 kube-proxy 在 "iptables" 模式下運(yùn)行。 最常見的另一種模式是 "ipvs"。

Iptables 模式

在 "iptables" 模式中, 你應(yīng)該可以在節(jié)點(diǎn)上看到如下輸出:

iptables-save | grep hostnames

-A KUBE-SEP-57KPRZ3JQVENLNBR -s 10.244.3.6/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-57KPRZ3JQVENLNBR -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.3.6:9376
-A KUBE-SEP-WNBA2IHDGP2BOBGZ -s 10.244.1.7/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376
-A KUBE-SEP-X3P2623AGDH6CDF3 -s 10.244.2.3/32 -m comment --comment "default/hostnames:" -j MARK --set-xmark 0x00004000/0x00004000
-A KUBE-SEP-X3P2623AGDH6CDF3 -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.2.3:9376
-A KUBE-SERVICES -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR

對于每個(gè) Service 的每個(gè)端口，應(yīng)有 1 條?KUBE-SERVICES?規(guī)則、一個(gè)?KUBE-SVC-<hash>?鏈。 對于每個(gè) Pod 末端，在那個(gè)?KUBE-SVC-<hash>?鏈中應(yīng)該有一些規(guī)則與之對應(yīng)，還應(yīng)該 有一個(gè)?KUBE-SEP-<hash>?鏈與之對應(yīng)，其中包含為數(shù)不多的幾條規(guī)則。 實(shí)際的規(guī)則數(shù)量可能會根據(jù)你實(shí)際的配置（包括 NodePort 和 LoadBalancer 服務(wù)）有所不同。

IPVS 模式

在 "ipvs" 模式中, 你應(yīng)該在節(jié)點(diǎn)下看到如下輸出：

ipvsadm -ln

Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
...
TCP  10.0.1.175:80 rr
  -> 10.244.0.5:9376               Masq    1      0          0
  -> 10.244.0.6:9376               Masq    1      0          0
  -> 10.244.0.7:9376               Masq    1      0          0
...

對于每個(gè) Service 的每個(gè)端口，還有 NodePort，External IP 和 LoadBalancer 類型服務(wù) 的 IP，kube-proxy 將創(chuàng)建一個(gè)虛擬服務(wù)器。 對于每個(gè) Pod 末端，它將創(chuàng)建相應(yīng)的真實(shí)服務(wù)器。 在此示例中，服務(wù)主機(jī)名（10.0.1.175:80）擁有 3 個(gè)末端（10.244.0.5:9376、?10.244.0.6:9376?和?10.244.0.7:9376）。

kube-proxy 是否在執(zhí)行代理操作?

假設(shè)你確實(shí)遇到上述情況之一，請重試從節(jié)點(diǎn)上通過 IP 訪問你的 Service ：

curl 10.0.1.175:80

hostnames-632524106-bbpiw

如果這步操作仍然失敗，請查看?kube-proxy?日志中的特定行，如：

Setting endpoints for default/hostnames:default to [10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376]

如果你沒有看到這些，請嘗試將?-v?標(biāo)志設(shè)置為 4 并重新啟動?kube-proxy，然后再查看日志。

邊緣案例: Pod 無法通過 Service IP 連接到它本身

這聽起來似乎不太可能，但是確實(shí)可能發(fā)生，并且應(yīng)該可以工作。

如果網(wǎng)絡(luò)沒有為“發(fā)夾模式（Hairpin）”流量生成正確配置， 通常當(dāng)?kube-proxy?以?iptables?模式運(yùn)行，并且 Pod 與橋接網(wǎng)絡(luò)連接時(shí)，就會發(fā)生這種情況。??kubelet 提供了 hairpin-mode 標(biāo)志。 如果 Service 的末端嘗試訪問自己的 Service VIP，則該端點(diǎn)可以把流量負(fù)載均衡回來到它們自身。?hairpin-mode?標(biāo)志必須被設(shè)置為?hairpin-veth?或者?promiscuous-bridge。

診斷此類問題的常見步驟如下：

• 確認(rèn)?hairpin-mode?被設(shè)置為?hairpin-veth?或?promiscuous-bridge。 你應(yīng)該可以看到下面這樣。本例中?hairpin-mode?被設(shè)置為?promiscuous-bridge。

  ps auxw | grep kubelet
  

  root      3392  1.1  0.8 186804 65208 ?        Sl   00:51  11:11 /usr/local/bin/kubelet --enable-debugging-handlers=true --config=/etc/kubernetes/manifests --allow-privileged=True --v=4 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --configure-cbr0=true --cgroup-root=/ --system-cgroups=/system --hairpin-mode=promiscuous-bridge --runtime-cgroups=/docker-daemon --kubelet-cgroups=/kubelet --babysit-daemons=true --max-pods=110 --serialize-image-pulls=false --outofdisk-transition-frequency=0
  

• 確認(rèn)有效的?hairpin-mode。要做到這一點(diǎn)，你必須查看 kubelet 日志。 訪問日志取決于節(jié)點(diǎn)的操作系統(tǒng)。在一些操作系統(tǒng)上，它是一個(gè)文件，如 /var/log/kubelet.log， 而其他操作系統(tǒng)則使用?journalctl?訪問日志。請注意，由于兼容性， 有效的?hairpin-mode?可能不匹配?--hairpin-mode?標(biāo)志。在 kubelet.log 中檢查是否有帶有關(guān)鍵字?hairpin?的日志行。應(yīng)該有日志行指示有效的?hairpin-mode，就像下面這樣。

  I0629 00:51:43.648698    3252 kubelet.go:380] Hairpin mode set to "promiscuous-bridge"
  

• 如果有效的發(fā)夾模式是?hairpin-veth, 要保證?Kubelet?有操作節(jié)點(diǎn)上?/sys?的權(quán)限。 如果一切正常，你將會看到如下輸出:

  for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done
  

  1
  1
  1
  1
  

• 如果有效的發(fā)卡模式是?promiscuous-bridge, 要保證?Kubelet?有操作節(jié)點(diǎn)上 Linux 網(wǎng)橋的權(quán)限。如果?cbr0?橋正在被使用且被正確設(shè)置，你將會看到如下輸出:文章來源地址http://www.zghlxwxcb.cn/news/detail-548764.html

  ifconfig cbr0 |grep PROMISC
  

  UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1460  Metric:1
  

• 如果以上步驟都不能解決問題，請尋求幫助。

到了這里，關(guān)于Kubernetes 應(yīng)用故障排除—調(diào)試 Service的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！