Kubernetes 調試Service

在 Pod 中運行命令

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

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

Note: 如果沒有看到命令提示符，請按回車。

如果你已經有了你想使用的正在運行的 Pod，則可以運行以下命令去進入：

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

設置 

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

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

deployment.apps/hostnames created

?kubectl ?命令將打印創(chuàng)建或變更的資源的類型和名稱，它們可以在后續(xù)命令中使用。 讓我們將這個 deployment 的副本數擴至 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: k8s.gcr.io/serve_hostname

"app" 標簽是 ?kubectl create deployment? 根據 Deployment 名稱自動設置的。

確認你的 Pods 是運行狀態(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

你還可以確認你的 Pod 是否正在提供服務。你可以獲取 Pod IP 地址列表并直接對其進行測試。

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 上提供其自己的主機名， 但是如果要調試自己的應用程序，則需要使用你的 Pod 正在偵聽的端口號。

在 Pod 內運行：

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

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

假設到目前為止一切都已按計劃進行，那么你可以開始調查為何你的 Service 無法正常工作。

Service 是否存在？

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

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

wget -O- hostnames

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

首先要檢查的是該 Service 是否真實存在：

kubectl get svc hostnames

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

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

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

service/hostnames exposed

重新運行查詢命令：

kubectl get svc hostnames

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

現在你知道了 Service 確實存在。

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

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

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

是否存在影響目標 Pod 的網絡策略入站規(guī)則？

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

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

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

從相同命名空間下的 Pod 中運行以下命令：

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 內運行）：

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

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

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" 表示這是一個 Service。"cluster.local" 是你的集群域，在你自己的集群中可能會有所不同。

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

Note: 10.0.0.10 是集群的 DNS 服務 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 中運行以下命令：

cat /etc/resolv.conf

你應該可以看到類似這樣的輸出：

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? 標志傳遞到 kubelet 的。

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

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

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

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

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

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

Service 能夠通過 IP 訪問么？ 

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

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

輸出應該類似這樣：

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

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

Service 的配置是否正確？

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

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 不同的端口）？
• 如果你想使用數值型端口，那么它的類型是一個數值（9376）還是字符串 “9376”？
• 如果你想使用名稱型端口，那么你的 Pod 是否暴露了一個同名端口？
• 端口的 ?protocol ?和 Pod 的是否對應？

Service 有 Endpoints 嗎？

如果你已經走到了這一步，你已經確認你的 Service 被正確定義，并能通過 DNS 解析。 現在，讓我們檢查一下，你運行的 Pod 確實是被 Service 選中的。

早些時候，我們已經看到 Pod 是運行狀態(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? 參數是在 Service 上配置的標簽選擇器。

"AGE" 列表明這些 Pod 已經啟動一個小時了，這意味著它們運行良好，而未崩潰。

"RESTARTS" 列表明 Pod 沒有經常崩潰或重啟。經常性崩潰可能導致間歇性連接問題。 如果重啟次數過大，通過調試 Pod 了解相關技術。

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

kubectl get endpoints hostnames

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

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

Pod 正常工作嗎？

至此，你知道你的 Service 已存在，并且已匹配到你的Pod。在本實驗的開始，你已經檢查了 Pod 本身。 讓我們再次檢查 Pod 是否確實在工作 - 你可以繞過 Service 機制并直接轉到 Pod，如上面的 Endpoint 所示。

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

在 Pod 中運行：

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

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

kube-proxy 正常工作嗎？

如果你到達這里，則說明你的 Service 正在運行，擁有 Endpoints，Pod 真正在提供服務。 此時，整個 Service 代理機制是可疑的。讓我們一步一步地確認它沒問題。

Service 的默認實現（在大多數集群上應用的）是 kube-proxy。 這是一個在每個節(jié)點上運行的程序，負責配置用于提供 Service 抽象的機制之一。 如果你的集群不使用 kube-proxy，則以下各節(jié)將不適用，你將必須檢查你正在使用的 Service 的實現方式。

kube-proxy 正常運行嗎？

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

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

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

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:53.999055    5063 server.go:255] Tearing down userspace rules. Errors here are acceptable.
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

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

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

Kube-proxy 可以以若干模式之一運行。在上述日志中，?Using iptables Proxier? 行表示 kube-proxy 在 "iptables" 模式下運行。 最常見的另一種模式是 "ipvs"。先前的 "userspace" 模式已經被這些所代替。

Iptables 模式

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

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

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

IPVS 模式

在 "ipvs" 模式中, 你應該在節(jié)點下看到如下輸出：

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
...

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

Userspace 模式

在極少數情況下，你可能會用到 "userspace" 模式。在你的節(jié)點上運行：

iptables-save | grep hostnames

-A KUBE-PORTALS-CONTAINER -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j REDIRECT --to-ports 48577
-A KUBE-PORTALS-HOST -d 10.0.1.175/32 -p tcp -m comment --comment "default/hostnames:default" -m tcp --dport 80 -j DNAT --to-destination 10.240.115.247:48577

對于 Service （本例中只有一個）的每個端口，應當有 2 條規(guī)則： 一條 "KUBE-PORTALS-CONTAINER" 和一條 "KUBE-PORTALS-HOST" 規(guī)則。

幾乎沒有人應該再使用 "userspace" 模式，因此你在這里不會花更多的時間。

kube-proxy 是否在運行?

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

curl 10.0.1.175:80

hostnames-632524106-bbpiw

如果失敗，并且你正在使用用戶空間代理，則可以嘗試直接訪問代理。 如果你使用的是 iptables 代理，請?zhí)^本節(jié)。

回顧上面的 ?iptables-save? 輸出，并提取 ?kube-proxy? 為你的 Service 所使用的端口號。 在上面的例子中，端口號是 “48577”。現在試著連接它：

curl localhost:48577

hostnames-632524106-tlaok

如果這步操作仍然失敗，請查看 ?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? 標志設置為 4 并重新啟動 ?kube-proxy?，然后再查看日志。

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

這聽起來似乎不太可能，但是確實可能發(fā)生，并且應該可行。

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

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

• 確認 ?hairpin-mode? 被設置為 ?hairpin-veth? 或 ?promiscuous-bridge?。 你應該可以看到下面這樣。本例中 ?hairpin-mode? 被設置為 ?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

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

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

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

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

1
1
1
1

• 如果有效的發(fā)卡模式是 ?promiscuous-bridge?, 要保證 ?Kubelet ?有操作節(jié)點上 Linux 網橋的權限。如果 ?cbr0 ?橋正在被使用且被正確設置，你將會看到如下輸出:

ifconfig cbr0 |grep PROMISC

UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1460  Metric:1

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

尋求幫助

如果你走到這一步，那么就真的是奇怪的事情發(fā)生了。你的 Service 正在運行，有 Endpoints 存在， 你的 Pods 也確實在提供服務。你的 DNS 正常，?iptables ?規(guī)則已經安裝，?kube-proxy? 看起來也正常。 然而 Service 還是沒有正常工作。這種情況下，請告訴我們，以便我們可以幫助調查！

通過 Forum 或者 GitHub 聯(lián)系我們。