針對 Kubernetes 進行疑難解答

文章
01/17/2024

此頁面會逐步解說 Kubernetes 設定、網路和部署的幾個常見問題。

提示

藉由向檔存放庫提出PR來建議常見問題專案。

此頁面細分為下列類別：

一般問題
常見的網路錯誤
常見的 Windows 錯誤
常見的 Kubernetes 主要錯誤

一般問題

如何? 知道 Windows 上的 Kubernetes 已成功完成嗎？

您應該會看到 kubelet、kube-proxy，以及（如果您選擇 Flannel 作為網路解決方案）在節點上執行的 flanneld 主機代理程序進程。除此之外，您的 Windows 節點應該會在 Kubernetes 叢集中列為「就緒」。

我可以設定在背景中執行這一切嗎？

從 Kubernetes 1.11 版開始，kubelet 和 kube-proxy 可以以原生 Windows 服務的形式執行。您也可以一律使用替代的服務管理員，例如 nssm.exe ，在背景中一律為您執行這些進程（flanneld、kubelet 和 kube-proxy）。

常見的網路錯誤

負載平衡器會在叢集節點之間不一致地受到管線

在 Windows 上，kube-proxy 會為叢集中的每個 Kubernetes 服務建立 HNS 負載平衡器。在（預設值） kube-proxy 組態中，包含許多（通常是 100+）負載平衡器之叢集中的節點可能會用盡可用的暫時 TCP 連接埠（亦即動態埠範圍，預設涵蓋埠 49152 到 65535）。這是因為每個（非 DSR）負載平衡器在每個節點上保留的大量埠。此問題可能會透過 kube-proxy 中的錯誤來顯示本身，例如：

Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified port already exists.

用戶可以執行 CollectLogs.ps1 腳本並諮詢 *portrange.txt 檔案來識別此問題。

CollectLogs.ps1也會模擬 HNS 配置邏輯，以在暫時 TCP 連接埠範圍中測試埠集區設定可用性，並在中reservedports.txt報告成功/失敗。腳本會保留 10 個 64 個 TCP 暫時埠的範圍（以模擬 HNS 行為），計算保留成功和失敗，然後釋放配置的埠範圍。小於 10 的成功數位表示暫時集區已用盡可用空間。也會在中 reservedports.txt產生大約有多少 64 個區塊的埠保留專案。

若要解決此問題，可以採取幾個步驟：

針對永久解決方案，kube-proxy 負載平衡應設定為 DSR 模式。 DSR 模式已完全實作，且僅適用於較新的 Windows Server 測試人員組建 18945 （或更新版本）。
因應措施是，使用者也可以使用之類的 netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>命令，增加可用的暫時埠預設 Windows 組態。 警告： 覆寫預設動態埠範圍可能會對主機上依賴非暫時範圍中可用 TCP 連接埠的其他進程/服務產生後果，因此應謹慎選取此範圍。
非 DSR 模式負載平衡器具有延展性增強功能，其使用累積更新 KB4551853 中包含的智慧型手機埠集區共用（以及所有較新的累積更新）。

HostPort 發佈無法運作

若要使用 HostPort 功能，請確定您的 CNI 外掛程式是 v0.8.6 版或更新版本，且 CNI 組態檔具有 portMappings 功能集：

"capabilities": {
    "portMappings":  true
}

我看到「hnsCall 在 Win32 中失敗：磁碟驅動器中有錯誤的磁碟驅動器」之類的錯誤。

對 HNS 物件進行自定義修改或安裝新的 Windows Update 時，可能會發生此錯誤，該更新會引入對 HNS 的變更，而不需卸除舊的 HNS 物件。它表示先前在更新之前建立的 HNS 物件與目前安裝的 HNS 版本不相容。

在 Windows Server 2019（和更早版本）上，使用者可以刪除 HNS.data 檔案來刪除 HNS 物件

Stop-Service HNS
rm C:\ProgramData\Microsoft\Windows\HNS\HNS.data
Start-Service HNS

使用者應該能夠直接刪除任何不相容的 HNS 端點或網路：

hnsdiag list endpoints
hnsdiag delete endpoints <id>
hnsdiag list networks
hnsdiag delete networks <id>
Restart-Service HNS

Windows Server 版本 1903 上的使用者可以移至下列登錄位置，並從網路名稱開始刪除任何 NIC（例如 vxlan0 或 cbr0）：

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList

Azure 上 Flannel 主機 gw 部署上的容器無法連線到因特網

在 Azure 上的 host-gw 模式中部署 Flannel 時，封包必須通過 Azure 實體主機 vSwitch。使用者應該針對指派給節點的每個子網，針對類型為「虛擬設備」的使用者定義路由進行程序設計。這可以透過 Azure 入口網站來完成（請參閱這裡的範例），或透過 az Azure CLI 來完成。以下是針對IP 10.0.0.4和個別Pod子網10.244.0.0/24的節點使用 az 命令名稱為 “MyRoute” 的範例 UDR：

az network route-table create --resource-group <my_resource_group> --name BridgeRoute 
az network route-table route create  --resource-group <my_resource_group> --address-prefix 10.244.0.0/24 --route-table-name BridgeRoute  --name MyRoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4

提示

如果您要自行在其他雲端提供者上部署 Kubernetes 或 IaaS VM，您也可以改用 overlay networking 。

我的 Windows Pod 無法 Ping 外部資源

Windows Pod 目前沒有針對 ICMP 通訊協定進行程式設計的輸出規則。不過，支援 TCP/UDP。試著示範與叢集外部資源的連線時，請以對應的curl <IP>命令取代 ping <IP> 。

如果您仍然遇到問題，最有可能是 cni.conf 中的網路設定值得一些額外的注意。您一律可以編輯此靜態檔案，設定將會套用至任何新建立的 Kubernetes 資源。

為什麼？其中一個 Kubernetes 網路需求（請參閱 Kubernetes 模型）是讓叢集通訊在內部不需 NAT 的情況下進行。為了遵守這項需求，我們有一個 ExceptionList ，用於我們不希望輸出 NAT 發生的所有通訊。不過，這也表示您需要從 ExceptionList 排除您嘗試查詢的外部 IP。只有這樣，來自 Windows Pod 的流量才會正確接收來自外部世界的回應。在這方面，您的 ExceptionList cni.conf 看起來應該如下所示：

"ExceptionList": [
  "10.244.0.0/16",  # Cluster subnet
  "10.96.0.0/12",   # Service subnet
  "10.127.130.0/24" # Management (host) subnet
]

我的 Windows 節點無法存取 NodePort 服務

來自節點本身的本機 NodePort 存取可能會失敗。這是使用累積更新KB4571748（或更新版本）來解決的已知功能差距。 NodePort 存取會從其他節點或外部客戶端運作。

當我相應減少 Pod 之後，我的 Windows 節點會停止路由傳送

由於設計限制，必須在 Windows 節點上執行至少一個 Pod，NodePort 轉送才能運作。

經過一段時間之後，容器的 vNIC 和 HNS 端點將會遭到刪除

當參數未傳遞至 kube-proxy 時hostname-override，可能會造成此問題。若要解決此問題，用戶必須將主機名傳遞至 kube-proxy，如下所示：

C:\k\kube-proxy.exe --hostname-override=$(hostname)

在 Flannel （vxlan）模式上，我的 Pod 在重新加入節點之後發生連線問題

每當先前刪除的節點重新加入叢集時，flannelD 會嘗試將新的 Pod 子網指派給節點。使用者應該移除下列路徑中的舊 Pod 子網組態檔：

Remove-Item C:\k\SourceVip.json
Remove-Item C:\k\SourceVipRequest.json

啟動 Kubernetes 之後，Flanneld 會卡在「等待建立網路」中

此問題應使用 Flannel v0.12.0 （及更新版本）來解決。如果您使用舊版 Flanneld，就會發生已知的競爭狀況，使得未設定 Flannel 網路的管理 IP。因應措施是直接手動重新啟動 FlannelD。

PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1

我的 Windows Pod 無法啟動，因為遺漏 /run/flannel/subnet.env

這表示 Flannel 未正確啟動。您可以嘗試重新啟動flanneld.exe，也可以從 Kubernetes 主要C:\run\flannel\subnet.env節點上手動/run/flannel/subnet.env將檔案複製到 Windows 背景工作角色節點上，並將數據列修改FLANNEL_SUBNET為已指派的子網。例如，如果已指派節點子網 10.244.4.1/24：

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.4.1/24
FLANNEL_MTU=1500
FLANNEL_IPMASQ=true

通常，有另一個問題可能會造成此錯誤，而需要先調查。建議您為您 flanneld.exe 產生此檔案。

在 vSphere 上執行的 Kubernetes 叢集上，主機之間的 Pod 對 Pod 連線中斷

由於 vSphere 和 Flannel 都會保留埠 4789（預設 VXLAN 埠）以進行重迭網路，封包最終可能會遭到攔截。如果 vSphere 用於重迭網路功能，則應該設定為使用不同的埠，以釋出 4789。

我的端點/IP 正在外泄

目前有 2 個已知問題可能會導致端點流失。

第一個已知問題是 Kubernetes 1.11 版的問題。請避免使用 Kubernetes 1.11.0 - 1.11.2 版。
造成端點流失的第二個已知問題，是端點記憶體中的並行問題。若要接收修正程式，您必須使用 Docker EE 18.09 或更新版本。

我的 Pod 無法啟動，因為「網路：無法配置範圍」錯誤

這表示節點上的IP位址空間已用到。若要清除任何外洩的端點，請移轉受影響節點上的任何資源，然後執行下列命令：

c:\k\stop.ps1
Get-HNSEndpoint | Remove-HNSEndpoint
Remove-Item -Recurse c:\var

我的 Windows 節點無法使用服務 IP 存取我的服務

這是 Windows 上目前網路堆疊的已知限制。不過，Windows Pod 可以存取服務 IP。

啟動 Kubelet 時找不到網路適配器

Windows 網路堆疊需要虛擬配接器，Kubernetes 網路功能才能運作。如果下列命令未傳回任何結果（在系統管理員殼層中），HNS 網路建立 — Kubelet 運作的必要必要條件 — 失敗：

Get-HnsNetwork | ? Name -ieq "cbr0"
Get-HnsNetwork | ? Name -ieq "vxlan0"
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"

在主機的網路適配器不是「Ethernet」的情況下，通常值得修改 start.ps1 腳本的 InterfaceName 參數。否則，請參閱文本的 start-kubelet.ps1 輸出，以查看虛擬網路建立期間是否有錯誤。

我仍然看到問題。我該怎麼做？

您的網路或主機上可能會有額外的限制，以防止節點之間的特定通訊類型。請確定：

您已正確設定您選擇的網路拓撲（l2bridge 或 overlay）
允許來自 Pod 的流量
如果您要部署 Web 服務，則允許 HTTP 流量
不會卸除來自不同通訊協定的封包（即 ICMP 與 TCP/UDP）

提示

如需其他自助資源，這裡也有適用於 Windows 的 Kubernetes 網路疑難解答指南。

常見的 Windows 錯誤

我的 Kubernetes Pod 卡在 “ContainerCreating”

此問題可能會有許多原因，但最常見的原因之一是暫停映像設定錯誤。這是下一個問題的高階徵兆。

部署時，Docker 容器會持續重新啟動

檢查您的暫停映像是否與您的OS版本相容。 Kubernetes 假設 OS 和容器都有相符的 OS 版本號碼。如果您使用 Windows 的實驗性組建，例如測試人員組建，則必須據以調整映像。如需映像，請參閱Microsoft的 Docker 存放庫。

常見的 Kubernetes 主要錯誤

對 Kubernetes 主機進行偵錯分為三個主要類別（可能性順序）：

Kubernetes 系統容器發生問題。
執行方式 kubelet 有問題。
系統發生錯誤。

執行 kubectl get pods -n kube-system 以查看 Kubernetes 正在建立的 Pod;這可能提供特定 Pod 損毀或無法正確啟動的一些見解。然後，執行 docker ps -a 以查看所有備份這些 Pod 的原始容器。最後，在疑似造成問題的容器上執行 docker logs [ID] ，以查看處理程式的原始輸出。

無法連線到位於的 API 伺服器 `https://[address]:[port]`

此錯誤通常表示憑證問題。請確定您已正確產生組態檔、其中的IP位址符合您主機的IP位址，以及您已將它複製到 API 伺服器所掛接的目錄。

尋找此組態檔的好位置如下：

~/kube/kubelet/
$HOME/.kube/config
/etc/kubernetes/admin.conf

否則，請參閱 API 伺服器的指令清單檔來檢查載入點。

分享方式：

針對 Kubernetes 進行疑難解答

一般問題

如何? 知道 Windows 上的 Kubernetes 已成功完成嗎？

我可以設定在背景中執行這一切嗎？

常見的網路錯誤

負載平衡器會在叢集節點之間不一致地受到管線

HostPort 發佈無法運作

我看到「hnsCall 在 Win32 中失敗：磁碟驅動器中有錯誤的磁碟驅動器」之類的錯誤。

Azure 上 Flannel 主機 gw 部署上的容器無法連線到因特網

我的 Windows Pod 無法 Ping 外部資源

我的 Windows 節點無法存取 NodePort 服務

當我相應減少 Pod 之後，我的 Windows 節點會停止路由傳送

經過一段時間之後，容器的 vNIC 和 HNS 端點將會遭到刪除

在 Flannel （vxlan）模式上，我的 Pod 在重新加入節點之後發生連線問題

啟動 Kubernetes 之後，Flanneld 會卡在「等待建立網路」中

我的 Windows Pod 無法啟動，因為遺漏 /run/flannel/subnet.env

在 vSphere 上執行的 Kubernetes 叢集上，主機之間的 Pod 對 Pod 連線中斷

我的端點/IP 正在外泄

我的 Pod 無法啟動，因為「網路：無法配置範圍」錯誤

我的 Windows 節點無法使用服務 IP 存取我的服務

啟動 Kubelet 時找不到網路適配器

我仍然看到問題。我該怎麼做？

常見的 Windows 錯誤

我的 Kubernetes Pod 卡在 “ContainerCreating”

部署時，Docker 容器會持續重新啟動

常見的 Kubernetes 主要錯誤

無法連線到位於的 API 伺服器 `https://[address]:[port]`

意見反映

更多資源

分享方式：

針對 Kubernetes 進行疑難解答

一般問題

如何? 知道 Windows 上的 Kubernetes 已成功完成嗎？

我可以設定在背景中執行這一切嗎？

常見的網路錯誤

負載平衡器會在叢集節點之間不一致地受到管線

HostPort 發佈無法運作

我看到「hnsCall 在 Win32 中失敗：磁碟驅動器中有錯誤的磁碟驅動器」之類的錯誤。

Azure 上 Flannel 主機 gw 部署上的容器無法連線到因特網

我的 Windows Pod 無法 Ping 外部資源

我的 Windows 節點無法存取 NodePort 服務

當我相應減少 Pod 之後，我的 Windows 節點會停止路由傳送

經過一段時間之後，容器的 vNIC 和 HNS 端點將會遭到刪除

在 Flannel （vxlan） 模式上，我的 Pod 在重新加入節點之後發生連線問題

啟動 Kubernetes 之後，Flanneld 會卡在「等待建立網路」中

我的 Windows Pod 無法啟動，因為遺漏 /run/flannel/subnet.env

在 vSphere 上執行的 Kubernetes 叢集上，主機之間的 Pod 對 Pod 連線中斷

我的端點/IP 正在外泄

我的 Pod 無法啟動，因為「網路：無法配置範圍」錯誤

我的 Windows 節點無法使用服務 IP 存取我的服務

啟動 Kubelet 時找不到網路適配器

我仍然看到問題。 我該怎麼做？

常見的 Windows 錯誤

我的 Kubernetes Pod 卡在 “ContainerCreating”

部署時，Docker 容器會持續重新啟動

常見的 Kubernetes 主要錯誤

無法連線到位於的 API 伺服器 https://[address]:[port]

意見反映

更多資源

在 Flannel （vxlan）模式上，我的 Pod 在重新加入節點之後發生連線問題

我仍然看到問題。我該怎麼做？

無法連線到位於的 API 伺服器 `https://[address]:[port]`