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服务(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服务在多个工作节点上超时时,您需要快速采取行动。首先检查每个节点的健康状况。寻找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配置为”失败开放”可防止节点停机期间合规请求被拒绝。

您应该定期测试您的kubernetes集群以确认每个节点都可以处理流量和工作负载。记录您的网络策略和节点配置。培训您的团队识别任何节点上的早期警告信号。通过遵循这些步骤,您可以帮助防止将来的kubernetes服务超时并保持集群健康。

通过遵循系统方法,您可以在每个节点上维护可靠的kubernetes服务连接。自动服务发现和内置负载均衡简化了kubernetes服务之间的通信并在每个节点上均匀分配流量。始终使用kubectl命令验证每个节点上的活动kubernetes服务和端点。一致的标签和就绪探针确保健康的pod在每个节点上接收流量。默认限制公共访问以确保kubernetes集群的安全。定期集群健康检查帮助您及早发现任何节点上的问题。记录您的故障排除步骤并与团队分享解决方案以提高kubernetes的可靠性。