排解 Google Distributed Cloud 網路問題

本頁說明如何解決 Google Distributed Cloud 的網路問題。我們提供一般疑難排解資訊和指南，以及建議使用的工具。本文也提供 Calico、Seesaw 和 MetalLB 的 DNS 疑難排解資訊和一些常見問題。

排解網路連線問題

GKE Enterprise 網路依賴實體網路基礎架構。舉例來說，Seesaw 或 MetalLB 依賴交換器來遵守無償 ARP，與邊界閘道協定 (BGP) 搭配使用的負載平衡依賴路由器，且所有節點都應能彼此通訊。如果 GKE 叢集發生網路問題，您必須判斷問題是出在 GKE Enterprise 元件，還是您自己的基礎架構。

首先請判斷問題範圍，然後嘗試找出受影響的元件。問題的範圍可分為三類：主體 (來源)、目標 (目的地) 和網路層。

主旨範圍可以是下列任一值：

  • 所有節點 (或 hostNetwork Pod) 叢集範圍。
  • 叢集中的所有 Pod。
  • 單一節點或一組節點上的所有 Pod。
  • 來自相同 Deployment 或 DaemonSet 的所有 Pod。
  • 叢集外部的用戶端。

目標範圍可以是下列一或多個項目：

  • 來自相同叢集的所有其他 Pod IP 位址。
  • 來自相同節點的所有其他 Pod IP 位址。
  • 來自相同叢集的 ClusterIP 服務虛擬 IP。
  • 來自相同叢集的 LoadBalancer Service 虛擬 IP 位址。
  • 第 7 層 LoadBalancer Ingress (Istio)。
  • 同一叢集中的其他節點。
  • 內部 DNS 名稱 (例如 *.svc.cluster.local)。
  • 外部 DNS 名稱 (例如 google.com)。
  • 叢集外部的實體。
  • 網際網路上的實體。

網路層可以是下列一或多項：

  • 第 2 層連結層問題，例如鄰近系統、ARP 或 NDP。
  • 第 3 層 IP 位址路由問題。
  • 第 4 層 TCP 或 UDP 端點問題。
  • 第 7 層 HTTP 或 HTTPS 問題。
  • DNS 解析問題。

瞭解問題範圍有助於找出問題涉及的元件，以及問題發生的層級。在問題發生時收集資訊非常重要，因為有些問題是暫時性的，因此系統復原後的快照不會包含足夠的資訊，供我們分析根本原因。

輸入問題

如果主體是叢集外部的用戶端，且無法連線至 LoadBalancer 服務，則為南北向連線問題。下圖顯示在運作範例中，傳入流量會從左到右通過堆疊，傳回流量則會從右到左通過堆疊。Seesaw 的不同之處在於，回傳流量會略過負載平衡器，直接傳回用戶端：

從使用者到實體基礎架構的連入流量，會先通過負載平衡器，再傳送至 anetd / kube-proxy，然後抵達後端。使用 Seesaw 時，輸出流量會略過負載平衡器。

如果這個流量流程發生問題，請使用下列疑難排解流程圖，找出問題所在：

查看封包在環境中移動時所經過的每個步驟，排解網路連入問題。檢查沿途是否有適當的動作和連線。

在這份流程圖中，下列疑難排解指引有助於判斷問題所在：

  • 封包是否會離開用戶端？如果沒有，可能就是網路基礎架構問題。
  • 你使用的是 Seesaw 負載平衡器嗎？如果是，封包是否會抵達 Seesaw 節點，然後正確傳送 ARP？如果沒有，可能就是網路基礎架構問題。
  • 您是否使用 MetalLB？如果是，封包是否會抵達 LB 節點，然後正確傳送 ARP？如果沒有，可能就是網路基礎架構問題。
  • 你是否使用 F5 BIG-IP？如果是，你是否檢查過 F5 問題？
  • 網路位址轉譯 (NAT) 是否正確執行？如果不是，您可能遇到 kube-proxy / Dataplane V2 問題。
  • 封包是否會傳送到工作站節點？如果沒有，您可能遇到 Calico / Dataplane v2 Pod 對 Pod 的問題。
  • 封包是否會抵達 Pod？如果不是，您可能遇到 Calico / Dataplane v2 本機轉送問題。

下列各節提供各階段的疑難排解步驟，協助您判斷流量是否正常流動。

封包是否會離開用戶端？

檢查封包是否正確離開用戶端，並通過實體網路基礎架構中設定的路由器。

  1. 使用 tcpdump 檢查封包是否從用戶端傳送至目的地服務：

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    如果沒有看到流量輸出，這就是問題來源。

封包是否會抵達 Seesaw 節點？

如果您使用 Seesaw，請參閱 1.16 版文件找出主要節點，然後使用 SSH 連線至節點。

  1. 使用 tcpdump 檢查預期封包是否已送達 Seesaw 節點：

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    如果沒有流量進入，這就是問題來源。

封包是否抵達 LoadBalancer 節點？

如果使用 MetalLB 做為負載平衡器：

  1. 查看 metallb-controller 記錄，判斷哪個負載平衡器節點提供服務 VIP：

    kubectl -n kube-system logs -l app=metallb --all-containers=true | grep SERVICE_VIP

  2. 使用 SSH 連線至節點。

  3. 如要查看 MetalLB 節點的流量，請使用 tcpdump：

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    如果是 ManualLB，流量可能會落在任何節點上。視負載平衡器設定而定，您可以選擇一或多個節點。使用 tcpdump 查看流量：

    tcpdump -ni any host NODE_IP and port NODE_PORT

    負載平衡器類型不同，指令也會有所差異，因為 MetalLB 和 Seesaw 不會在將封包轉送至節點前執行 NAT。

    如果沒有任何節點有流量進入，這就是問題的來源。

是否有 F5 BIG-IP 問題？

如要排解 F5 BIG-IP 問題，請參閱「F5 服務未收到流量」一文中的下列任一節。

ARP 是否正確傳送？

MetalLB 或 Seesaw 的負載平衡器節點會透過 ARP 宣傳服務 VIP。如果 ARP 回應已正確傳送，但流量未傳入，表示實體網路基礎架構有問題。造成這個問題的常見原因是，某些進階資料平面學習功能會忽略軟體定義網路 (SDN) 解決方案中的 ARP 回應。

  1. 使用 tcpdump 偵測 ARP 回應：

    tcpdump -ni any arp

    找出宣傳 VIP 的訊息，並確認你遇到的問題。

    • 對於 Seesaw，系統會為所有 VIP 傳送無償 ARP。每隔 10 秒，您應該會看到每個 VIP 的 ARP 訊息。

    • 如果是 MetalLB，則不會傳送無償 ARP。您看到回應的頻率取決於其他裝置 (例如機架頂端 (ToR) 交換器或虛擬交換器) 何時傳送 ARP 要求。

是否執行 NAT？

資料平面 v2 / kube-proxy 會執行目的地網路位址轉譯 (目的地 NAT 或 DNAT)，將目的地 VIP 轉譯為後端 Pod IP 位址。如果您知道哪個節點是負載平衡器的後端，請使用 SSH 連線至該節點。

  1. 使用 tcpdump 檢查服務 VIP 是否已正確轉譯：

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. 如果是 Dataplane v2，您還可以連線至 anetd Pod，並使用內嵌的 Cilium 偵錯工具：

    cilium monitor --type=drop

詳情請參閱下列各節的說明：Dataplane v2 / Cilium 問題。

封包是否會抵達工作站節點？

在工作站節點上，封包會抵達外部介面，然後傳送至 Pod。

  1. 使用 tcpdump 檢查封包是否抵達外部介面 (通常命名為 eth0 或 ens192)：

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

由於一般服務後端包含不同節點的多個 Pod，因此可能難以找出故障的節點。常見的解決方法是擷取問題的時間夠長，讓某些封包最終抵達，或是將後端數量限制為一個。

如果封包從未抵達工作節點，表示網路基礎架構有問題。請洽詢網路基礎架構團隊，瞭解封包在 LoadBalancer 節點和工作站節點之間遭到捨棄的原因。常見問題包括：

  • 檢查軟體定義網路 (SDN) 記錄。有時，SDN 可能會因為各種原因 (例如區隔、總和檢查碼錯誤或防偽) 捨棄封包。
  • 防火牆規則：篩選目的地為後端 Pod IP 位址和通訊埠的封包。

如果封包抵達節點的外部介面或通道介面，則必須轉送至目的地 Pod。如果 Pod 是主機網路 Pod，則不需要這個步驟，因為 Pod 會與節點共用網路命名空間。否則必須轉送其他封包。

每個 Pod 都有虛擬乙太網路介面對，作用類似管道。傳送至介面一端的封包會從介面另一端接收。其中一個介面會移至 Pod 的網路命名空間，並重新命名為 eth0。另一個介面則保留在主機命名空間中。不同 CNI 的架構不同。如果是 Dataplane v2，介面通常會命名為 lxcxxxx。名稱具有連續介面編號，例如 lxc17 和 lxc18。您可以使用 tcpdump 檢查封包是否抵達 Pod，也可以指定介面：

tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

如果封包抵達節點，但未抵達 Pod，請依下列方式檢查路由表：

ip route

通常每個 Pod 都應有路由項目，將 Pod IP 位址路由至 lxc 介面。如果缺少項目，通常表示 CNI 資料路徑發生錯誤。如要判斷根本原因，請查看 CNI DaemonSet 記錄。

輸出問題

如果流量可以進入 Pod，則流量從 Pod 輸出時可能會有問題。下圖顯示在運作範例中，傳入流量會從左到右通過堆疊：

輸出流量會從 Pod 經過主機的外部介面傳輸至實體基礎架構，然後傳輸至外部服務。

  1. 如要確認外寄封包是否正確偽裝成節點 IP 位址，請檢查外部服務 (第 4 層)。

    封包的來源 IP 位址應透過來源網路位址轉譯 (來源 NAT 或 SNAT)，從 Pod IP 位址對應至節點 IP 位址。在 Dataplane v2 中，這項程序是透過載入外部介面的 ebpf 達成。Calico 使用 iptables 規則。

    使用 tcpdump 檢查來源 IP 位址是否正確從 Pod IP 位址轉換為節點 IP 位址：

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT

    如果 tcpdump 顯示封包已正確偽裝，但遠端服務沒有回應，請檢查基礎架構中與外部服務的連線。

  2. 如果傳出封包正確偽裝成節點 IP 位址，請使用 tcpdump 檢查外部主機 (第 3 層) 連線：

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    執行 tcpdump 的同時，從其中一個 Pod 執行 Ping：

    kubectl exec POD_NAME ping EXTERNAL_IP

    如果沒有看到 Ping 回應，請檢查基礎架構中與外部服務的連線。

叢集內問題

如要解決 Pod 對 Pod 的連線問題，請嘗試將問題範圍縮小至節點。通常，一組節點無法與另一組節點通訊。

  1. 在 Dataplane v2 中，檢查目前節點與同一叢集中所有其他節點的連線。在 anetd Pod 內，檢查健康狀態：

    cilium status --all-health

    Google Distributed Cloud 使用直接路由模式。您應該會看到叢集中每個節點各有一個路由項目，如下例所示：

    # <pod-cidr> via <node-ip> dev <external-interface>
192.168.1.0/24 via 21.0.208.188 dev ens192
192.168.2.0/24 via 21.0.208.133 dev ens192

    如果節點缺少預期路徑，就會與該節點失去連線。

網路層問題

找出連線問題發生的網路層是重要步驟。「來源到目的地的連線問題」這類錯誤訊息提供的資訊不足，無法協助解決問題，因為問題可能是應用程式錯誤、路由問題或 DNS 問題。瞭解問題發生的層級，有助於修正正確的元件。

在許多情況下，錯誤訊息會直接指出問題發生的層級。以下範例可協助您排解網路層問題：

  • HTTP 錯誤表示這是第 7 層的問題。
    • HTTP 程式碼 40x、50x 或 TLS 握手錯誤表示第 4 層一切正常。
  • 「Connection reset by peer」錯誤表示這是第 4 層的問題。
    • 在許多情況下，遠端通訊端無法與連線的目前狀態達成一致，因此會傳送 RESET 封包。這可能是連線追蹤或 NAT 發生錯誤。
  • 「沒有主機路徑」和「連線逾時」錯誤通常是第 3 層或第 2 層的問題。
    • 這些錯誤表示封包無法正確傳送到目的地。

實用疑難排解工具

節點上執行的網路相關 DaemonSet 可能會導致連線問題。不過，如果節點、機架頂端 (ToR) 交換器、主幹路由器或防火牆設定有誤，也可能導致問題。您可以使用下列工具，協助判斷問題的範圍或層級，並判斷問題是出在 GKE Enterprise 節點，還是實體基礎架構。

乒乓

Ping 會在第 3 層 (IP 層) 運作，並檢查來源和目的地之間的路線。如果 Ping 無法連線至目的地，通常表示問題出在第 3 層。

不過，並非所有 IP 位址都能執行 Ping 指令。舉例來說，如果是純粹的第 4 層負載平衡器，部分負載平衡器 VIP 就無法 Ping。ClusterIP 服務是 VIP 可能不會傳回連線偵測回應的例子。在第 4 層，只有在指定通訊埠編號 (例如 VIP:port) 時，這項服務才會傳回 Ping 回應。

Google Distributed Cloud 中的 BGPLB、MetalLB 和 Seesaw 負載平衡器都在第 3 層運作。你可以使用 ping 檢查連線。雖然 F5 不同，但它也支援 ICMP。您可以使用 ping 檢查與 F5 VIP 的連線。

Arping

Arping 與 ping 類似，但運作於第 2 層。第 2 層和第 3 層的問題通常會導致應用程式顯示類似的錯誤訊息。Arping 和 ping 有助於區分問題。舉例來說，如果來源和目的地位於同一個子網路，但您無法對目的地執行 arping，就是第 2 層的問題。

如果 arping <ip> 成功，會傳回目的地的 MAC 位址。在第 2 層，這個地址通常表示實體基礎架構問題。這個問題是虛擬交換器設定錯誤。

Arping 也能偵測 IP 位址衝突。如果兩部機器設定為在同一個子網路上使用相同的 IP 位址，或是另一個實體機器使用 VIP，就會發生 IP 位址衝突。IP 位址衝突可能會導致間歇性問題，難以排解。如果 arping <ip> 傳回多個 MAC 位址項目，表示有 IP 位址衝突。

從 arping 取得 MAC 位址後，您可以使用 https://maclookup.app/ 查詢 MAC 位址的製造商。每個製造商都有自己的 MAC 前置字元，因此您可以利用這項資訊，判斷哪個裝置嘗試使用相同的 IP 位址。舉例來說，VMware 擁有 00:50:56 區塊，因此 MAC 位址 00:50:56:xx:yy:zz 是 vSphere 環境中的 VM。

iproute2

iproute2 的 ip CLI 有許多實用的子指令，例如：

  • ip r：列印路徑表
  • ip n：列印 IP 位址到 MAC 位址對應的鄰近資料表
  • ip a：列印機器上的所有介面

節點缺少路徑或鄰近節點表中的項目，可能會導致連線問題。Anetd 和 Calico 都會管理路由表和鄰居表。如果這些表格設定有誤，可能會導致連線問題。

適用於 Dataplane V2 的 Cilium / Hubble CLI

每個 anetd Pod 都有幾項實用的連線問題偵錯工具：

  • cilium monitor --type=drop
    • 列印 anetd / Cilium 捨棄的每個封包記錄。
  • hubble observe
    • 列印通過 anetd eBPF 堆疊的所有封包。
  • cilium status --all-health
    • 列印 Cilium 的狀態，包括節點對節點的連線狀態。每個 anetd Pod 都會檢查叢集中所有其他節點的健康狀態，並協助判斷任何節點對節點的連線問題。

Iptables

許多 Kubernetes 元件和子系統都會使用 iptables。kube-proxy 使用 iptables 實作服務解析。 Calico 使用 iptables 實作網路政策

  1. 如要排解 iptables 層級的網路問題，請使用下列指令：

    iptables -L -v | grep DROP

    查看捨棄規則，並檢查封包計數和位元組計數，瞭解這些計數是否隨時間增加。

Tcpdump

Tcpdump 是功能強大的封包擷取工具，可產生大量網路流量資料。常見做法是從來源和目的地執行 tcpdump。如果在封包離開來源節點時擷取封包，但從未在目的地節點擷取封包，表示封包在兩者之間遭到捨棄。這通常表示實體基礎架構中的某些項目誤將封包捨棄。

指標

Google Distributed Cloud 包含多項指標，可協助您追蹤網路行為。建議您從下列指標著手：

類別 指標 說明
遭捨棄的封包 cilium_drop_bytes_total 依捨棄原因和輸入/輸出方向標記的捨棄位元組總數。這個指標是調查位元組層級下降情形的良好起點。
cilium_drop_count_total 依捨棄原因和輸入/輸出方向標記的封包總數。
container_network_receive_packets_dropped_total 接收時遭捨棄的封包累計數。每 60 秒取樣一次。
container_network_transmit_packets_dropped_total 傳輸時遭捨棄的封包累計數。每 60 秒取樣一次。
轉送的封包 cilium_forward_bytes_total 轉送的位元組總數，並依輸入/輸出方向加上標記。每 60 秒取樣一次。這項指標會提供位元組層級的轉送資訊。
cilium_forward_count_total 轉送的封包總數，並依輸入/輸出方向加上標記。每 60 秒取樣一次。這項指標會提供轉送流量的封包計數。
cilium_policy_l7_forwarded_total 轉送的第 7 層要求總數。
已接收的封包數 cilium_policy_l7_received_total 收到的第 7 層要求/回應總數。每 60 秒取樣一次。
container_network_receive_bytes_total 接收的累計位元組數。每 60 秒取樣一次。
container_network_receive_packets_total 收到的封包累計數量。每 60 秒取樣一次。
container_network_receive_errors_total 接收時發生的錯誤累計次數。每 60 秒取樣一次。
cilium_kubernetes_events_received_total 收到的 Kubernetes 事件數，並依範圍、動作、有效資料和相等性標示。每 60 秒取樣一次。
BPF cilium_bpf_maps_virtual_memory_max_bytes BPF 對應核心記憶體最大用量大小 (以位元組為單位)。
cilium_bpf_progs_virtual_memory_max_bytes BPF 程式核心記憶體用量上限 (以位元組為單位)。
Conntrack node_nf_conntrack_entries 目前為連線追蹤分配的流程項目數量。 每 60 秒取樣一次。
node_nf_conntrack_entries_limit 連線追蹤資料表的大小上限。每 60 秒取樣一次。
連線能力 cilium_node_connectivity_latency_seconds 目前 Cilium 代理程式與其他 Cilium 節點之間最後觀察到的延遲時間 (以秒為單位)。每 60 秒取樣一次。
cilium_node_connectivity_status 目前 Cilium 代理程式與其他 Cilium 節點之間，最近一次觀察到的 ICMP 和 HTTP 連線狀態。每 60 秒取樣一次。
Cilium 運算子 cilium_operator_process_cpu_seconds_total 使用者和系統耗費的 CPU 總時間，以秒為單位。每 60 秒取樣一次。
cilium_operator_process_max_fds 開啟檔案描述元的數量上限。每 60 秒取樣一次。
cilium_operator_process_open_fds 開啟的檔案描述元數量。每 60 秒取樣一次。
cilium_operator_process_resident_memory_bytes 常駐記憶體大小 (以位元組為單位)。每 60 秒取樣一次。
cilium_operator_process_start_time_seconds 自 Unix Epoch 紀元時間開始算起，以秒為單位的程序開始時間。每 60 秒取樣一次。
cilium_operator_process_virtual_memory_bytes 虛擬記憶體大小 (以位元組為單位)。每 60 秒取樣一次。
cilium_operator_process_virtual_memory_max_bytes 可用的虛擬記憶體量上限，以位元組為單位。每 60 秒取樣一次。
cilium_operator_identity_gc_entries 垃圾收集器執行完畢時，有效和已刪除的身分數量。每 60 秒取樣一次。
cilium_operator_identity_gc_runs 身分垃圾收集器執行的次數。每 60 秒取樣一次。

如要在任何指標超過或低於特定門檻時收到通知，請建立快訊政策。詳情請參閱 Cloud Monitoring 說明文件中的「建立指標閾值快訊政策」。

如要進一步瞭解這些指標，並查看完整指標清單，請參閱「Google Distributed Cloud 指標」。

DNS 疑難排解

DNS 解析問題主要分為兩大類別：

  • 一般 Pod，使用叢集內 DNS 伺服器。
  • 不使用叢集內 DNS 伺服器的主機網路 Pod 或節點

以下各節提供叢集 DNS 架構的相關資訊，以及開始排解其中一類問題前實用的提示。

叢集 DNS 架構

叢集 DNS 服務會解析叢集中 Pod 的 DNS 要求。Google Distributed Cloud 1.9.0 以上版本會提供這項服務。

每個叢集都有兩個以上的 coredns Pod，以及負責根據叢集大小調整 DNS Pod 數量的自動配置器。此外，還有一個名為 kube-dns 的服務，負責在所有後端 coredns Pod 之間進行負載平衡。

大多數 Pod 的上游 DNS 都設定為 kube-dns 服務 IP 位址，而 Pod 會將 DNS 要求傳送至其中一個 coredns Pod。DNS 請求可歸類至下列其中一個目的地：

  • 如果要求是針對 cluster.local 網域，則這是叢集內 DNS 名稱，會參照叢集中的 Service 或 Pod。
    • CoreDNS 會監控叢集中所有服務和 Pod 的 api-server，並回應有效 cluster.local 網域的要求。
  • 如果要求不是針對 cluster.local 網域，就是針對外部網域。
    • CoreDNS 會將要求轉送至上游名稱伺服器。根據預設，CoreDNS 會使用在節點上設定的上游名稱伺服器。

詳情請參閱 Kubernetes 中 DNS 的運作和設定方式總覽。

DNS 疑難排解提示

如要排解 DNS 問題，可以使用 dig 和 nslookup 工具。這些工具可讓您傳送 DNS 要求，測試 DNS 解析是否正常運作。下列範例說明如何使用 dig 和 nslookup 檢查 DNS 解析問題。

  • 使用 dig 或 nslookup 傳送 google.com 的要求：

    dig google.com
nslookup google.com

  • 使用 dig 將 kubernetes.default.svc.cluster.local 的要求傳送至伺服器 192.168.0.10：

    dig @192.168.0.10 kubernetes.default.svc.cluster.local

  • 您也可以使用 nslookup 執行與先前 dig 指令相同的 DNS 查詢：

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

    查看 dig 或 nslookup 指令的輸出內容。如果收到不正確的回覆或沒有收到回覆，表示 DNS 解析有問題。

一般 Pod

如要偵錯 DNS 問題，首先要判斷要求是否傳送至 coredns Pod。一般叢集連線問題通常會以 DNS 問題的形式呈現，因為 DNS 請求是工作負載傳送的第一種流量。

查看應用程式的錯誤訊息。io timeout 或類似錯誤表示沒有回應，且發生一般網路連線問題。

如果錯誤訊息包含 NXDOMAIN 或 SERVFAIL 等 DNS 錯誤代碼，表示叢集內 DNS 伺服器的連線正常，但伺服器無法解析網域名稱：

  • NXDOMAIN 錯誤表示 DNS 伺服器回報網域不存在。確認應用程式要求的網域名稱是否有效。
  • SERVFAIL 或 REFUSED 錯誤表示 DNS 伺服器傳回了回應，但無法解析網域或驗證網域不存在。詳情請參閱 coredns Pod 的記錄。

您可以使用下列指令找出 kube-dns 服務的 IP 位址：

kubectl -n kube-system get svc kube-dns

從 DNS 無法運作的 Pod，嘗試使用 dig 或 nslookup 將 DNS 要求傳送至這個 IP 位址，詳情請參閱前一節：

  • 如果這些要求無效，請嘗試將要求傳送至每個 coredns Pod 的 IP 位址。
  • 如果部分 Pod 可以運作，但其他 Pod 無法運作，請檢查是否有任何可辨識的模式，例如 DNS 解析適用於與 coredns Pod 位於相同節點的 Pod，但不適用於跨節點的 Pod。這項行為可能表示叢集內有連線問題。

如果 CoreDNS 無法解析外部網域名稱，請參閱下一節，排解主機網路 Pod 的問題。CoreDNS 的行為類似於主機網路 Pod，並使用節點的上游 DNS 伺服器進行名稱解析。

主機網路 Pod 或節點

主機網路 Pod 和節點會使用節點上設定的名稱伺服器進行 DNS 解析，而非叢集內 DNS 服務。視作業系統而定，這個名稱伺服器會在 /etc/resolv.conf 或 /run/systemd/resolve/resolv.conf 中設定。這項設定表示他們無法解析 cluster.local 網域名稱。

如果主機網路名稱解析發生問題，請按照先前章節的疑難排解步驟，測試上游名稱伺服器的 DNS 是否正常運作。

常見的網路問題

以下各節詳細說明您可能會遇到的常見網路問題。如要解決問題，請按照適當的疑難排解指南操作。如需其他協助，請與 Cloud Customer Care 團隊聯絡。

Calico

常見錯誤： calico/node is not ready: BIRD is not ready: BGP not established

Kubernetes 中出現「未就緒」狀態錯誤，通常表示叢集中無法連線至特定對等互連。確認環境允許兩個對等互連裝置之間的 BGP 連線。

如果為節點對節點網格設定非使用中節點資源，也可能發生這項錯誤。如要修正這個問題，請停用過時的節點。

Dataplane v2 / Cilium

常見錯誤： [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

這項錯誤表示 Pod 建立事件因速率限制而遭 Cilium 代理程式拒絕。每個節點最多只能對 PUT 端點提出四個並行要求。如果某個節點突然收到大量要求，就會出現這種情況。Cilium 代理程式應會趕上延遲的要求。

在 GKE Enterprise 1.14 以上版本中，速率限制會自動調整為節點容量。速率限制器可以收斂至更合理的數字，並為功能更強大的節點設定更高的速率限制。

常見錯誤： Ebpf map size is full

Dataplane v2 會將狀態儲存在 eBFP 對應中。狀態包括服務、連線追蹤、Pod 身分和網路政策規則。如果地圖已滿，代理程式就無法插入項目，導致控制層與資料層之間出現差異。舉例來說，服務地圖的項目上限為 64, 000 個。

  1. 如要檢查 eBFP 對應項目及其目前大小，請使用 bpftool。以下範例會檢查負載平衡器對應：

    bpftool map dump pinned \
/sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | tail -n -1

bpftool map dump pinned \ /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | tail -n -1

  2. 如果地圖即將達到 64K 的限制，請清理地圖。以下範例會清除負載平衡器對應：

    bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5, "0x"$6, "0x"$7, "0x"$8, "0x"$9, "0x"$10, "0x"$11, "0x"$12, "0x"$13}' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 key

bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | \
    awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5 }' | \
    head -n -1 | \
    xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 key

  3. 如要將狀態重新填入 eBFP 地圖，請重新啟動 anetd。

由於 NetworkPluginNotReady 錯誤，節點未就緒

如果 CNI Pod 未在節點上執行，您可能會看到類似下列內容的錯誤：

  "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

節點也可能處於未就緒狀態，並顯示類似下列範例的錯誤：

  "Network plugin not installed"

節點初始化時，kubelet 會等待多個事件發生，然後將節點標示為 Ready。kubelet 檢查的事件之一是容器網路介面 (CNI) 外掛程式是否已安裝。CNI 外掛程式應由 anetd 或 Calico 安裝，方法是使用 init 容器將 CNI 二進位檔和 CNI 設定安裝至必要的主機目錄。

如要排解這個問題，請檢查這些 Pod 無法在節點上執行的原因。通常這類錯誤並非網路問題所致。這些 Pod 會在主機網路上執行，因此沒有網路依附元件。

  1. 檢查 anetd 或 calico-node Pod 的狀態。請參閱下列疑難排解步驟，找出問題原因：

    • 如果 Pod 處於 Crashlooping 狀態，請檢查記錄檔，瞭解 Pod 無法正常執行的原因。
    • 如果 Pod 處於 Pending 狀態，請使用 kubectl describe 並查看 Pod 事件。舉例來說，Pod 可能缺少磁碟區等資源。
    • 如果 Pod 處於 Running 狀態，請檢查記錄和設定。 部分 CNI 實作項目提供停用 CNI 安裝的選項，例如 Cilium。
    • aneta 中有一個名為 custom-cni-conf 的設定選項。如果這項設定設為 true，anetd 就不會安裝 CNI 二進位檔。

ARP 項目過時，導致節點 NOT READY

有時，管理員叢集控制層節點中過時的 ARP 項目可能會導致 MAC 位址不符。這個位址不符的問題可能會導致連線逾時，進而影響受管理使用者叢集的控制層虛擬 IP 位址。連線逾時可能會導致系統將具有過時 ARP 項目節點標示為 NOT READY。標示為 NOT READY 的節點可能會導致叢集安裝和升級作業停滯。

在這種情況下，具有過時 ARP 項目節點上的 kubelet 記錄會包含類似下列內容的 TLS 握手逾時錯誤：

failed to get API group resources: unable to retrieve the complete list of server APIs: v1: Get "https://128.160.252.101:443/api/v1": net/http: TLS handshake timeout

請按照下列步驟驗證及解決問題：

  1. 使用 SSH 連線至使用者叢集控制層節點。

  2. 確認 VIP 位址繫結的介面 MAC 位址：

    ip a | grep DEVICE_NAME: -A 6

    將 DEVICE_NAME 替換為控制平面節點的網路裝置名稱。

  3. 使用 SSH 連線至管理員叢集控制層節點。

  4. 在管理員叢集控制層上檢查使用者叢集控制層 VIP 位址的 ARP 快取：

    ip n | grep VIP_ADDRESS

    將 VIP_ADDRESS 替換為使用者叢集控制層 VIP 的 IP 位址 (controlPlaneVIP)。

    如果這兩個 ip 指令傳回的 MAC 位址不同，表示你受到這個問題影響。

  5. 如要解決這個問題，請清除管理員叢集控制層節點上的 ARP 快取：

    ip n flush all

F5 服務未收到流量

如果沒有任何流量傳送至 F5 服務，請按照下列疑難排解步驟操作：

  1. 確認 F5 BIG-IP 中的每個分割區都設定在一個叢集中，無論是管理員叢集或使用者叢集。如果多個不同叢集共用一個分割區，就會發生間歇性連線中斷問題。這是因為兩個叢集嘗試掌控同一個分割區，並從其他叢集刪除服務。

  2. 確認下列兩個 Pod 正在執行。如果 Pod 未執行，表示發生錯誤：

    Load-balancer-f5
K8s-bigip-ctlr-deployment-577d57985d-vk9wj

    Load-balancer-f5，並為每個 LoadBalancer 類型的服務建立 ConfigMap。ConfigMap 最終會由 bigip 控制器取用。

  3. 確認每個服務的每個通訊埠都有 ConfigMap。舉例來說，如果使用下列通訊埠：

    Kube-server-443-tcp     2   31h
Kube-server-8132-tcp        2   31h

    kube-server 服務應如下列範例所示：

    Kube-server LoadBalancer  10.96.232.96  21.1.7.16   443:30095/TCP,8132:32424/TCP  31h

    ConfigMap 中的資料部分應包含前端 VIP 和連接埠，如下列範例所示：

    data: '{"virtualServer":{"backend":{"serviceName":"kube-apiserver","servicePort":443,"healthMonitors":[{"protocol":"tcp","interval":5,"timeout":16}]},"frontend":{"virtualAddress":{"bindAddr":"21.1.7.16","port":443},"partition":"herc-b5bead08c95b-admin","balance":"ratio-member","mode":"tcp"}}}'
  schema: f5schemadb://bigip-virtual-server_v0.1.7.json

  4. 檢查 BIG-IP 執行個體記錄和指標。如果 ConfigMap 設定正確，但 BIG-IP 執行個體無法遵守設定，可能是 F5 的問題。如要解決 BIG-IP 執行個體內發生的問題，請與 F5 支援團隊聯絡，診斷及排解問題。

後續步驟

如需其他協助，請與 Cloud Customer Care 團隊聯絡。

如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：