Varidata 新聞資訊

知識庫 | 問答 | 最新技術 | IDC 行業新聞

如何修復跨多個工作節點的Kubernetes服務逾時問題

發布日期：2025-12-23

您可能會注意到kubernetes服務在工作節點之間出現逾時，特別是在日本伺服器租用叢集中，由於地理分布，網路延遲可能更加明顯。這通常是由於網路問題、核心SNAT問題或服務探索失敗造成的。在許多情況下，當叢集面臨DNS問題、網路配置錯誤或資源限制時，kubernetes服務會出現連接中斷或速度減慢 – 這些挑戰在連接到跨不同區域的日本伺服器租用基礎設施時尤為常見。查看下表以了解在日本伺服器租用環境和全球kubernetes部署中最常見的根本原因：

根本原因	描述
DNS問題	DNS解析問題可能導致Kubernetes中的服務逾時。
網路問題	網路配置錯誤或故障可能導致延遲和逾時。
資源分配	分配給pod的資源不足可能導致效能問題。

在升級過程中，如果webhook變得無回應，Kubernetes服務也可能失敗，導致連接錯誤。當您看到間歇性逾時或節點未就緒時，請首先檢查這些問題。快速故障排除有助於恢復kubernetes服務並防止連接問題擴散。

關鍵要點

Kubernetes服務可能由於網路問題、DNS問題或資源不足而逾時。識別這些根本原因對解決問題至關重要。
定期檢查節點和pod的健康狀況。使用’kubectl get pods’等指令監控其狀態並確保它們已準備好處理流量。
檢查網路策略和防火牆規則以確保允許必要的流量。配置錯誤可能會阻止節點之間的通訊並導致逾時。
調整閒置逾時和連接埠限制以有效管理連接。這有助於防止服務中斷並提高整體效能。
使用Prometheus和Grafana等監控工具來追蹤網路指標。定期健康檢查可以幫助您在問題升級之前發現問題。

識別間歇性逾時症狀

Kubernetes服務中的錯誤日誌

您可以通過檢查錯誤日誌和監控連接嘗試來發現Kubernetes服務中的間歇性逾時。許多使用者在與Kubernetes API伺服器互動時會看到API請求逾時。您可能會在應用程式日誌中注意到錯誤或指令失敗。有時，在存取應用程式時會遇到逾時，這可能表明叢集元件存在效能問題。

尋找這些常見跡象：

API請求逾時
存取服務時出現間歇性逾時
叢集元件的效能問題

當您分析錯誤日誌時，經常會發現Kubelet和pod之間的TCP連接無法建立。您可能會看到TCP SYN從Kubelet發送，但預期的TCP ACK從未到達。這通常意味著存在網路問題。有時，連接會卡在SYN-SENT狀態，這表明Kubelet無法正確處理TCP會話。如果您發現來源連接埠被Kubernetes nodeports保留，這種配置錯誤可能會導致健康檢查失敗。

以下是表明跨節點連接問題的日誌模式和錯誤代碼表：

指標類型	描述
連接失敗	連接嘗試未成功
逾時	連接嘗試用時過長
異常系統呼叫序列	與網路相關的系統呼叫中的異常行為

節點未就緒和Pod連接性

您需要特別注意節點狀態。如果您看到節點未就緒，則無法在該節點上排程pod。這直接影響服務可用性。節點未就緒狀態意味著pod無法接受流量或執行其預期功能。當節點標記為未就緒時，它無法正常運行且無法排程新的pod。這會影響pod連接性和服務可用性。無法在未處於就緒狀態的節點上排程pod。如果節點未就緒，它就無法託管新的pod，這會影響整體服務可用性。

命名空間和服務探索問題

命名空間和服務探索問題經常導致服務逾時。您應該檢查服務名稱是否有拼寫錯誤或命名空間是否錯誤。DNS問題也可能造成麻煩。有時可能沒有後端pod，或targetPort不正確。網路限制可能會阻止流量。環境變數可能未被填充，或負載平衡可能配置錯誤。

常見的命名空間和服務探索問題包括：

服務名稱拼寫錯誤
命名空間錯誤
DNS問題
沒有後端pod
targetPort錯誤
網路限制
環境變數未填充
負載平衡配置錯誤

如果您識別出這些症狀，就可以快速縮小根本原因的範圍並恢復服務可用性。

跨節點故障排除Kubernetes服務

當您在kubernetes叢集中遇到服務逾時時，您需要一個清晰的故障排除流程。按照這些步驟可以解決大多數連接問題。每個步驟都有助於您識別根本原因並恢復跨kubernetes節點的服務可用性。

Pod和節點健康檢查

首先通過檢查pod和節點的健康狀況開始故障排除。您要確保kubelet和kube-proxy在每個kubernetes節點上運行。如果節點未就緒，kubelet就無法排程pod，而kube-proxy就無法路由流量。您應該監控應用程式並使用探針來確認應用程式正在運行並接受流量。

節點狀態檢查：關注OutOfDisk、Ready、MemoryPressure、PIDPressure、DiskPressure和NetworkUnavailable等狀況。
使用kube_deployment_spec_replicas和kube_deployment_status_replicas比較期望的和當前的pod數量。
追蹤可用和不可用的pod以發現就緒探針失敗。
使用存活探針檢查應用程式是否在運行。
使用就緒探針驗證應用程式是否可以接受流量。
使用啟動探針確認容器是否已初始化。

您可以使用這些kubernetes指令來排查節點和pod的健康狀況：

指令	用途
kubectl get pods	顯示pod的STATUS和RESTARTS，表明重複性故障。
kubectl describe pod	提供詳細資訊如LAST STATE、REASON和MESSAGE(例如OOMKilled)。
kubectl get events –sort-by=.metadata.creationTimestamp	列出事件以檢查排程失敗、映像檔拉取錯誤或驅逐。
kubectl logs	獲取最近的日誌以識別應用程式層級的錯誤。
kubectl top pod	顯示即時CPU和記憶體使用情況，有助於解釋OOMKills。
kubectl debug pod/ -it –image=busybox	啟動臨時除錯容器以在命名空間內進行檢查。

在進入下一步故障排除步驟之前，您應該檢查pod的健康狀況並檢查pod的狀態。

網路策略和防火牆審查

網路策略和防火牆規則經常導致kubernetes節點之間的服務逾時。您需要檢查網路配置和安全設定。配置錯誤的路由表、安全清單或閘道可能會阻止kubelet和kube-proxy之間的流量。如果您對同一個目標同時使用網際網路閘道和服務閘道，流量可能會被錯誤路由。

配置錯誤的路由表、安全清單或閘道可能會阻止kubernetes服務到達必要的端點。
對同一目標同時使用網際網路閘道和服務閘道可能導致流量被錯誤路由。

按照以下故障排除步驟檢查防火牆規則：

檢查節點防火牆規則：確保工作節點上的防火牆規則允許必要連接埠的流量，特別是NodePort服務使用的30000-32767連接埠範圍。
安全群組和雲端防火牆：如果您在雲端中運行kubernetes，驗證您的安全群組或雲端防火牆設定允許所需的流量。

您還應該確認kubelet和kube-proxy可以在所有kubernetes節點之間通訊。這有助於維護網路連接並避免網路問題。

服務和端點配置

服務和端點配置錯誤可能導致逾時和連接問題。您需要檢查與部署相關的服務並確保端點正確。如果kubelet或kube-proxy找不到正確的端點，您的應用程式將無法按預期工作。

檢查服務名稱和命名空間是否有拼寫錯誤。
確保targetPort與應用程式連接埠匹配。
確認後端pod存在並正在運行。
檢查環境變數和負載平衡設定。

使用這些kubernetes指令排查服務和端點配置：

kubectl get svc: 列出所有服務及其端點。
kubectl describe pod : 顯示事件和端點詳細資訊。
- kubectl get endpoints: 顯示每個服務的端點映射。

您應該始終檢查與部署相關的服務，並確認kubelet和kube-proxy在每個kubernetes節點上都有正確的配置。

SNAT和核心問題

SNAT和核心問題可能會破壞kubernetes節點之間的網路連接。您需要檢查每個節點上是否載入了br_netfilter核心模組。如果kubelet或kube-proxy無法使用網橋模組，網路流量將會失敗。

一位使用者報告說，他們的工作節點在重新啟動後沒有自動載入br_netfilter核心模組，這導致網橋模組出現故障。手動載入模組後，連接問題得到解決。

您還應該注意iptables和網路策略的問題。這些可能會阻止kubelet和kube-proxy之間的流量。SNAT競爭條件可能導致資料包丟失或連接重置，使得難以追蹤請求和執行策略。

問題	影響
Pod身分遺失	使安全和稽核變得複雜
無法追蹤請求	難以基於pod身分執行策略
資料包丟失或連接重置	表明可能存在SNAT相關問題

您需要排查節點核心模組和網路策略問題，以保持kubelet和kube-proxy在每個kubernetes節點上正常工作。

AKS和雲端特定連接性

Azure Kubernetes Service(AKS)和其他雲端平台有其獨特的連接問題。在存取AKS上的應用程式時，您可能會看到間歇性逾時。這些問題通常來自效能問題、記憶體限制或網路配置錯誤。

叢集元件的效能問題可能導致逾時。
超出記憶體限制可能會中斷應用程式可用性。
網路配置問題可能會阻止kubelet和kube-proxy之間的流量。

您可以使用這些故障排除步驟用於AKS：

使用kubectl top pods檢查pod的健康狀況。
使用kubectl get pods檢查pod的狀態。
使用kubectl get svc檢查與部署相關的服務。
使用kubectl describe pod my-deployment-fc94b7f98-m9z2l描述pod以檢查事件。

cURL指令結果示例：
成功連接：HTTP/1.1 200 OK
連接逾時：Failed to connect to 20.62.x.x port 80 after 21050 ms: Timed out

您應該監控應用程式並檢查每個kubernetes節點上的kubelet和kube-proxy日誌。這有助於您發現網路問題並恢復網路連接。

通過遵循這些故障排除步驟，您可以解決跨kubernetes節點的服務逾時和連接問題。您需要檢查kubelet、kube-proxy、節點健康狀況、網路策略、服務配置和雲端特定設定。這個過程有助於您維護可靠的kubernetes網路並保持應用程式平穩運行。

常見Kubernetes服務逾時的解決方案

修復網路策略和防火牆規則

您可以通過管理每個節點的網路策略和防火牆規則來防止kubernetes中的服務逾時。當您設置Prometheus和Grafana等監控工具時，您可以追蹤網路指標並接收異常警報。您應該定期進行網路健康檢查以在問題影響叢集之前發現並修復問題。清晰記錄網路配置、策略和故障排除步驟有助於您在問題出現時快速回應。通過遵循網路策略管理的最佳實踐，您可以維護健康和安全的網路環境。

設置監控工具以追蹤網路指標並配置警報。
對每個節點進行定期網路健康檢查。
記錄網路配置和故障排除程序。
應用網路策略管理的最佳實踐。

當您檢查防火牆規則時，檢查每個節點是否允許所需連接埠的流量。您應該驗證安全群組和雲端防火牆是否允許節點之間的流量。這些步驟有助於您維護可靠的網路並防止服務逾時。

解決SNAT和核心競爭條件

您可以通過調整節點配置來解決kubernetes中的SNAT和核心競爭條件。為部署分配更多CPU以加快啟動過程。這確保每個節點上的pod都準備好進行健康檢查。為存活探針和就緒探針設置更長的初始等待時間，並延長失敗期限和測試間隔。這些更改有助於每個節點上的pod通過健康檢查並避免過早驅逐。

按照以下步驟提高核心和SNAT穩定性：

確保每個節點上的Linux核心版本為4.4或更新版本。
配置網路堆疊設定，包括連接追蹤表和通訊端緩衝區，以滿足kubernetes要求。
調整TCP逾時值和積壓佇列，以防止節點之間的連接失敗。

預設核心配置可能會在kubernetes叢集中造成效能瓶頸，特別是當節點承受重負載時。配置錯誤的網路參數可能導致級聯故障，影響pod驅逐和應用程式效能。適當的核心調校有助於kubernetes管理資源並在所有節點上保持穩定。

調整空閒逾時和連接埠限制

您需要調整空閒逾時和連接埠限制以防止kubernetes服務逾時。空閒逾時設定控制連接在沒有活動的情況下可以保持開啟的時間。如果將--streaming-connection-idle-timeout參數設定為0，您就會面臨拒絕服務攻擊和資源耗盡的風險。預設設定4小時對某些環境來說可能太長。您應該調整這個值以有效管理空閒連接。

確保--streaming-connection-idle-timeout參數不設定為0至關重要，因為停用逾時可能會使系統面臨拒絕服務攻擊並導致資源耗盡。預設設定4小時對某些環境來說可能過長，調整這個值可以幫助有效管理空閒連接。

在Azure Kubernetes Service中，負載平衡器的預設空閒逾時為30分鐘。您必須平衡這個持續時間以避免頻繁逾時，這會降低使用者體驗並增加錯誤率。如果您將逾時設定得太長，您會浪費伺服器資源並延遲問題檢測。

在調整AKS中的空閒逾時期間時，平衡持續時間很重要，以避免頻繁逾時導致使用者體驗下降和錯誤率增加，同時也要防止因保持空閒連接時間過長而造成資源消耗。

空閒逾時和連接埠限制設定在不同的雲端提供商之間有所不同。在AKS中，從空閒流回收SNAT連接埠的預設空閒逾時為30分鐘。AKS外部標準SKU負載平衡器的預設逾時為4分鐘。更改這些設定會影響負載平衡器的出站規則行為。

AKS從空閒流回收SNAT連接埠的預設空閒逾時為30分鐘。
AKS外部的標準SKU負載平衡器預設逾時為4分鐘。
更改空閒逾時和連接埠限制設定會顯著影響負載平衡器的出站規則行為。

修復服務探索和命名空間問題

您可以通過檢查服務選擇器和pod標籤來修復kubernetes中的服務探索和命名空間問題。確保服務選擇器匹配pod標籤以在每個節點上建立流量路由的端點。檢查叢集內的DNS解析失敗。驗證網路策略不會阻止命名空間之間的流量。確認就緒探針沒有失敗，這可能會從服務輪換中移除pod。調查Istio或Envoy sidecar代理中的任何配置錯誤，並檢查mTLS問題。

確保服務選擇器匹配pod標籤以建立端點。
檢查叢集中的DNS解析失敗。
驗證網路策略不會阻止命名空間之間的流量。
確認每個節點上的就緒探針都在通過。
調查Istio/Envoy sidecar代理或mTLS中的配置錯誤。

您可以使用監控工具來早期檢測服務探索和命名空間問題。Kubewatch監視資源變化並觸發通知。它追蹤部署狀態變化、pod生命週期事件和服務端點可用性。Dynatrace提供跨kubernetes事件的可見性，並幫助您在問題影響節點之前檢測問題。

工具	功能
Kubewatch	監視資源變化、部署狀態通知、pod生命週期追蹤、配置警報、服務端點監控、命名空間配額違規檢測
Dynatrace	跨kubernetes事件的全面可見性，早期檢測服務探索和命名空間問題

Kubernetes監控涉及在叢集、節點、pod和容器中收集和審查操作資料。通過監控您的kubernetes環境，您可以識別問題、追蹤應用程式效能並防止問題升級。

通過遵循系統方法，您可以在每個節點上維護可靠的kubernetes服務連接。自動服務探索和內建負載平衡簡化了kubernetes服務之間的通訊並在每個節點上均勻分配流量。始終使用kubectl指令驗證每個節點上的活動kubernetes服務和端點。一致的標籤和就緒探針確保健康的pod在每個節點上接收流量。預設限制公共存取以確保kubernetes叢集的安全。定期叢集健康檢查幫助您及早發現任何節點上的問題。記錄您的故障排除步驟並與團隊分享解決方案以提高kubernetes的可靠性。

使用kubectl get services和kubectl get endpoints檢查每個節點上的kubernetes服務活動。
監控資源使用情況並驗證每個節點的配置檔案。
分享知識並保留記錄以幫助將來在任何節點上進行kubernetes故障排除。

提示：系統除錯和主動配置可以保持kubernetes服務在每個節點上的穩定性。

快速故障排除清單

Kubernetes服務的即時操作

當您注意到kubernetes服務在多個工作節點上逾時時，您需要快速採取行動。首先檢查每個節點的健康狀況。尋找CPU或記憶體不足的跡象。如果節點資源耗盡，kubernetes服務可能無法回應。您應該監控每個節點的資源使用情況以儘早發現問題。檢查每個節點上kubelet和kube-proxy的日誌。這些日誌通常會顯示指向根本原因的錯誤或警告。確保所有kubernetes元件都在每個節點上按預期運行。從cAdvisor收集指標以獲取每個節點上容器使用情況的詳細資訊。檢查工作負載的事件和日誌以發現可能影響kubernetes服務可用性的應用程式問題。

監控每個節點的資源使用情況以避免CPU和記憶體不足。
檢查每個節點上kubelet和kube-proxy的日誌是否有錯誤或警告。
確保所有kubernetes元件在每個節點上都正常工作。
從cAdvisor收集指標以獲取每個節點上詳細的容器使用情況。
檢查工作負載的事件和日誌以識別任何節點上的應用程式問題。

提示：您可以使用kubectl top node和kubectl logs快速從每個節點收集資源和錯誤資訊。

未來穩定性的預防步驟

通過遵循多節點叢集的最佳實踐，您可以降低kubernetes服務逾時的風險。下表列出了保持kubernetes環境在每個節點上穩定可靠的關鍵步驟。

預防步驟	描述
設置較小的逾時值	准入webhook應快速評估以最小化每個節點上的API請求延遲。
使用負載平衡器	通過在節點間分配流量確保webhook可用性並提高效能。
使用高可用性模型	在節點停機或故障期間維持服務，降低任何節點逾時的風險。
失敗開放並驗證最終狀態	將webhook配置為「失敗開放」可防止節點停機期間合規請求被拒絕。