共用方式為

通道連線問題

  • 發行項

Microsoft Azure Kubernetes Service （AKS） 會使用特定元件進行節點與控制平面之間的通道、安全通訊。 通道包含控制平面上的伺服器，以及叢集節點端的用戶端。 本文討論如何針對與 AKS 中的通道連線能力相關的問題進行疑難解答和解決。

Azure 受控 AKS 下層、客戶管理的 Azure 虛擬網路和子網，以及從 API 到通道 Pod 的通道圖表。

注意

先前，AKS 通道元件是 tunnel-front。 它現在已移轉至 Konnectivity 服務，這是上游 Kubernetes 元件。 如需此移轉的詳細資訊，請參閱 AKS 版本資訊和變更記錄。

必要條件

徵兆

您收到類似下列埠 10250 範例的錯誤訊息：

伺服器錯誤：取得 “https://< aks-node-name>：10250/containerLogs/<namespace>/<pod-name>/<container-name>”： dial tcp <aks-node-ip>：10250： i/o timeout

伺服器錯誤：撥號後端錯誤：撥號 tcp <aks-node-ip>：10250：i/o 逾時

Kubernetes API 伺服器會使用埠 10250 連線到節點的 kubelet 來擷取記錄。 如果封鎖埠 10250，kubectl 記錄和其他功能只適用於在通道元件排程所在的節點上執行的 Pod。 如需詳細資訊，請參閱 Kubernetes 埠和通訊協定：背景工作節點。

由於無法建立伺服器和客戶端之間的通道元件或連線，因此下列功能無法如預期般運作：

原因 1：網路安全組 （NSG） 封鎖埠 10250

注意

此原因適用於您在 AKS 叢集中可能擁有的任何通道元件。

您可以使用 Azure 網路安全組 （NSG） 來篩選 Azure 虛擬網路中 Azure 資源的網路流量。 網路安全組包含安全性規則，可允許或拒絕數種 Azure 資源類型之間的輸入和輸出網路流量。 針對每個規則，您可以指定來源與目的地、連接埠和通訊協定。 如需詳細資訊，請參閱網路安全性群組如何篩選網路流量。

如果 NSG 封鎖虛擬網路層級的埠 10250，通道功能（例如記錄和程式代碼執行）將僅適用於排程通道 Pod 之節點上排程的 Pod。 其他 Pod 將無法運作，因為它們的節點將無法連線到通道，而且通道會排程在其他節點上。 若要確認此狀態，您可以使用 netcat （nc） 或 telnet 命令來測試連線能力。 您可以執行 az vmss run-command invoke 命令來執行連線測試，並確認它是否成功、逾時或造成一些其他問題：

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
    --output tsv \
    --query 'value[0].message'

解決方案 1：新增 NSG 規則以允許存取埠 10250

如果您使用 NSG，而且有特定限制，請務必新增安全性規則，以允許虛擬網路層級埠 10250 的流量。 下列 Azure 入口網站 影像顯示範例安全性規則：

Azure 入口網站 中 [新增輸入安全性規則] 窗格的螢幕快照。[目的地埠範圍] 方塊會針對新的安全性規則設定為 10250。

如果您想要限制更嚴格，您可以只允許在子網層級存取埠 10250。

注意

  • [優先順序] 欄位必須據以調整。 例如，如果您有拒絕多個埠的規則（包括埠 10250），影像中顯示的規則應具有較低的優先順序數位（較低數位具有較高的優先順序）。 如需優先順序的詳細資訊，請參閱安全性規則。

  • 如果您在套用此解決方案之後未看到任何行為變更，您可以重新建立通道元件 Pod。 刪除這些 Pod 會導致重新建立 Pod。

原因 2：未複雜防火牆 （UFW） 工具封鎖埠 10250

注意

此原因適用於您在 AKS 叢集中擁有的任何通道元件。

未複雜的防火牆 （UFW） 是用來管理 netfilter 防火牆的 命令行程式。 AKS 節點使用Ubuntu。 因此，預設會在 AKS 節點上安裝 UFW，但 UFW 已停用。

根據預設，如果已啟用UFW，則會封鎖所有埠的存取，包括埠10250。 在此情況下，不太可能使用安全殼層 （SSH） 連線 到 AKS 叢集節點以進行疑難解答。 這是因為UFW可能也會封鎖埠22。 若要進行疑難解答，您可以執行 az vmss run-command invoke 命令來叫 用 ufw 命令 ，以檢查是否已啟用 UFW：

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw status" \
    --output tsv \
    --query 'value[0].message'

如果結果指出已啟用 UFW，且未特別允許埠 10250，該怎麼辦？ 在此情況下，通道功能（例如記錄和程式代碼執行）不適用於已在已啟用UFW的節點上排程的Pod。 若要修正此問題，請在UFW上套用下列其中一個解決方案。

重要

使用此工具進行任何變更之前，請先檢閱 AKS 支持原則 （特別是 節點維護和存取權），以防止叢集進入不支援的案例。

注意

如果您在套用解決方案之後未看到任何行為變更，您可以重新建立通道元件 Pod。 刪除這些 Pod 會導致重新建立這些 Pod。

解決方案 2a：停用未複雜的防火牆

執行下列 az vmss run-command invoke 命令以停用 UFW：

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw disable" \
    --output tsv \
    --query 'value[0].message'

解決方案 2b：設定未複雜防火牆以允許存取埠 10250

若要強制 UFW 允許存取埠 10250，請執行下列 az vmss run-command invoke 命令：

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw allow 10250" \
    --output tsv \
    --query 'value[0].message'

原因 3：iptables 工具封鎖埠 10250

注意

此原因適用於您在 AKS 叢集中擁有的任何通道元件。

iptables 工具可讓系統管理員設定Linux防火牆的IP封包篩選規則。 您可以設定 iptables 規則來封鎖埠 10250 上的通訊。

您可以檢視節點的規則，以檢查埠 10250 是否已遭到封鎖或已卸除相關聯的封包。 若要這樣做，請執行下列 iptables 命令：

iptables --list --line-numbers

在輸出中，數據會分組成數 個鏈結，包括鏈 INPUT 結。 每個鏈結都包含下列資料列標題下的規則資料表：

  • num （規則編號）
  • target
  • prot （通訊協定）
  • opt
  • source
  • destination

鏈 INPUT 結是否包含目標為 DROP、通訊協定為 tcp的規則，而目的地為 tcp dpt:10250？ 如果這樣做， iptables 則會封鎖對目的地埠 10250 的存取。

解決方案 3：刪除封鎖埠 10250 存取的 iptables 規則

執行下列其中一個命令來刪除 iptables 防止存取埠 10250 的規則：

iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250

iptables --delete INPUT <input-rule-number>

若要解決您的確切或潛在案例，建議您執行 命令來檢查 iptables 手動。iptables --help

重要

使用此工具進行任何變更之前，請先檢閱 AKS 支持原則 （特別是 節點維護和存取權），以防止叢集進入不支援的案例。

原因 4：輸出埠 1194 或 9000 未開啟

注意

此原因僅適用於 tunnel-front 和 aks-link Pod。

是否有任何輸出流量限制，例如來自 AKS 防火牆？ 如果有，則需要埠 9000 才能啟用 Pod 的正確功能 tunnel-front 。 同樣地，Pod 需要 aks-link 埠 1194。

Konnectivity 依賴埠 443。 根據預設，此埠為開啟狀態。 因此，您不需要擔心該埠上的連線問題。

解決方案 4：開啟埠 9000

雖然 tunnel-front 已移至 Konnectivity 服務，但某些 AKS 叢集仍會使用 tunnel-front，依賴埠 9000。 請確定虛擬設備或任何網路裝置或軟體允許存取埠 9000。 如需必要規則和相依性的詳細資訊，請參閱 Azure 全域必要網路規則。

原因 5：來源網路位址轉換 （SNAT） 埠耗盡

注意

此原因適用於您在 AKS 叢集中擁有的任何通道元件。 不過，它不適用於 私人 AKS 叢集。 只有公用通訊才會發生來源網路位址轉換 （SNAT） 埠耗盡。 針對私人 AKS 叢集，API 伺服器位於 AKS 虛擬網路或子網內。

如果 SNAT 埠耗盡（SNAT 埠失敗），節點就無法連線到 API 伺服器。 通道容器位於 API 伺服器端。 因此，不會建立通道連線。

如果 SNAT 埠資源用盡，輸出流程會失敗，直到現有的流程釋放一些 SNAT 埠為止。 Azure Load Balancer 會在流程關閉時回收 SNAT 埠。 它會使用四分鐘的閑置逾時，從閑置流程回收 SNAT 埠。

您可以從 AKS 負載平衡器計量或服務診斷檢視 SNAT 埠，如下列各節所述。 如需如何檢視 SNAT 埠的詳細資訊，請參閱 如何? 檢查我的輸出連線統計數據？。

AKS 負載平衡器計量

若要使用 AKS 負載平衡器計量來檢視 SNAT 埠，請遵循下列步驟：

  1. 在 Azure 入口網站 中，搜尋並選取 [Kubernetes 服務]。

  2. 在 Kubernetes 服務清單中，選取叢集的名稱。

  3. 在叢集的功能表窗格中，尋找 [ 設定 ] 標題，然後選取 [ 屬性]。

  4. 選取 [基礎結構資源群組] 底下所列的名稱。

  5. 選取 kubernetes 負載平衡器。

  6. 在負載平衡器的功能表窗格中，尋找 [監視] 標題，然後選取 [ 計量]。

  7. 針對計量類型，選取 [SNAT 連線計數]。

  8. 選取 [套用分割]。

  9. 將 [分割依據] 設定為 [連線狀態]。

服務診斷

若要使用服務診斷來檢視 SNAT 埠，請遵循下列步驟：

  1. 在 Azure 入口網站 中，搜尋並選取 [Kubernetes 服務]。

  2. 在 Kubernetes 服務清單中，選取叢集的名稱。

  3. 在叢集的功能表窗格中，選取 [ 診斷並解決問題]。

  4. 選取 [ 連線問題]。

  5. 在 [SNAT 連線和埠配置] 下，選取 [檢視詳細數據]。

  6. 如有必要，請使用 [ 時間範圍 ] 按鈕來自定義時間範圍。

解決方案5a：確定應用程式使用連線共用

此行為可能會因為應用程式未重複使用現有的連線而發生。 建議您不要為每個要求建立一個輸出連線。 這類設定可能會導致連線耗盡。 檢查應用程式程式代碼是否遵循最佳做法和使用連線共用。 大部分的連結庫都支持連線共用。 因此，您不需要為每個要求建立新的輸出連線。

解決方案 5b：調整配置的輸出埠

如果應用程式內的所有專案都沒問題，您必須調整配置的輸出埠。 如需輸出埠配置的詳細資訊，請參閱 設定配置的輸出埠。

解決方案 5c：當您建立叢集時，請使用受控網路位址轉換 （NAT） 閘道

您可以設定新的叢集，以針對輸出連線使用受控網路位址轉換 （NAT） 閘道。 如需詳細資訊，請參閱 使用受控 NAT 閘道建立 AKS 叢集。

協力廠商連絡資訊免責聲明

Microsoft 提供協力廠商連絡資訊，以協助您尋找有關此主題的其他資訊。 此連絡資訊可能會變更而不另行通知。 Microsoft 不保證協力廠商連絡資訊的準確性。

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。