K8S NFS pod中业务访问、启动变慢排查

已于 2022-08-11 11:04:02 修改
阅读量1.8k 收藏 1
点赞数
CC 4.0 BY-SA版权
分类专栏： 问题排查 文章标签： java 容器 kubernetes
于 2022-08-10 16:35:53 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/m0_37948100/article/details/126268296
本文介绍了一种排查业务性能瓶颈的方法，包括检查CPU、内存及网络状况，通过抓包或日志定位问题，以及针对NFS挂载问题进行深入分析。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

1.排查服务CPU、内存、程序等占用 运行情况，排除程序问题

        建议yaml指定 resources资源，至少指定requests，防止其他应用或业务抢占资源导致业务资源不足

2.通过抓包或nginx日志或者pod内部请求程序服务，排除外部网络影响

        nginx配置 $request_time 、$upstream_response_time 可查看清时间

3.操作PVC nfs挂载目录查看日志，修改部分配置时，发现命令运行很卡顿，但操作非挂载目录不卡顿，可能是nfs访问慢，或nfs主机磁盘慢

5.上nfs服务器排查磁盘空间、读写正常，然后访问业务，查看nfs挂载网络读写请求速度，发现网络峰值停留在100M(其他业务同时使用)，排查对应主机网口网速为100M，但网卡1000M，最后切换网线后，恢复1000M，业务速度恢复；

注：nfs挂载建议最小范围，防止影响程序读写速度

K8S集群中Pod资源调度失败的故障排查思路
江晓龙的博客
08-25 2063
2、ApiServer将创建Pod的请求告知Scheduler组件，Scheduler组件会通过某种计算方式，将请求的资源进行调度分配，将Pod与Node的调度关系进行绑定并告知ApiServer。在K8S集群中，Pod资源是最小的单元，任何服务都是以Pod的形式部署运行的，Pod资源需要调度到具体的Node节点中运行，在日常运维中，可能会遇到Pod资源无法调度的问题。3）Node节点上的确是存在污点，当Node节点关机无响应后，K8S会为Node节点自动添加一个不可调度的污点，从而使Pod资源无法调度。
K8S集群中Pod挂载Storageclass存储卷异常排查思路
江晓龙的博客
10-09 2137
原因其实也简单，我们虽然只是将存储数据的目录删除了，但是并没有删除Storageclass创建的PVC啊，当Jenkins再次重新部署时，Storageclass发现之前为Jenkins创建过PVC，那么就可以接着使用，没必要再创建一个新的PVC，占用系统资源。3）通过Pod输出的日志，我们基本上就可以定位问题所在了，Pod要挂载Storageclass创建的PVC卷，挂载的这个PVC卷原来可能创建过，但是存储空间被删除了，从而导致无法被挂载，PVC卷，已经存在了。意思是说无法挂载这个。
验证K8S集群pod之间传输速度过慢，导致pod之间业务无法正常交互
weixin_44207346的博客
03-15 936
发现1K的文件可以相互拷贝，大于1K的都不能拷贝，最终原因是K8S集群所在的虚拟化平台的虚拟机的网络模式使用的是vxlan，据我分析，应该是平台有相关策略导致的，并不是vxlan不支持K8S集群。通过启动两个busybox容器，之间进行scp传输文件，验证pod之间tcp连接是否正常。K8S部署完成后，但是pod之间无法进行交互访问，导致pod异常。拷贝文件至busybox1。进入第一个busybox1。进入第二个busybox1。运行第一个busybox。
k8s集群内部服务，调用外部服务出现15秒超时的问题（基于k8s+Istio）
是我的温柔啊
01-29 2426
下面开始处理这个问题。创建完文件，给他 kubectl apply -f ServiceEntry.yaml 执行一下，让他在集群中生成我们自定义的这个服务入口。会有超时时间，这时候处理思路就是创建一个虚拟服务，指向这个外部服务地址，也就是变相的将外部服务放在istio管理下，主要应对超时问题。在deployment中添加对应的配置（此处有问题，每个服务要访问都需要加，因此不推荐使用这个方案，尽量使用上边的正规方案）。1、创建一个 ServiceEntry.yaml 文件，作为外部服务的服务入口。
【K8S系列】Kubernetes 中 Pod(Java服务)启动缓慢的深度分析与解决方案
最新发布
颜淡慕潇
06-09 1364
本文针对 Kubernetes 中 Java 服务启动时间慢的深度分析与解决方案文章，结合了底层原理、常见原因及具体优化策略：
k8s集群内部网络访问慢，curl延时高
RayPick的博客
06-29 4388
我这边的环境是三台机器，均为centos7，节点为master、node1、node2，版本如下 部署方式：helm部署 部署应用： EFK 出现问题： elasticSearch应用副本数为1，被默认调度在node2启动，通过master节点输入命令 kubectl get svc 查看到es的clusterIp地址，在node2上（也就是es所在节点）用 curl clusterIp:9200 能curl通，且速度很快，然后在node1上进行curl操作，非常慢，得等接近1分钟才有反应。 这里我翻
nfs存储IO等待,导致k8s业务系统卡慢问题处理
niuwj666的博客
05-21 659
发现业务系统卡慢,使用top 命令查看.系统负载较高长期保持在60以上,发现wa值的指标参数长期高于15,返现CPU用于写入磁盘IO等待的时间较高,系统的磁盘I/O压力较大.②使用top命令检查业务服务器负载情况,负载异常1分钟,5分钟,15分钟负载高于60,wa的值处于15-20,判断为业务服务器磁盘IO读写压力较大。②使用top命令检查业务服务器负载情况,负载异常1分钟,5分钟,15分钟负载低于20,wa的值低于5,判断为业务服务器磁盘IO读写压力正常。检查nfs业务服务器情况。检查数据库服务器情况。
k8s ingress访问响应慢的问题（阿里云环境）
w184414332的博客
08-11 3497
k8s ingress访问响应慢的问题（阿里云环境）
Kubernetes报错CrashLoopBackOff的Pod启动失败排查
shejizuopin的博客
05-20 671
当Kubernetes中的Pod处于CrashLoopBackOff状态时，通常是由于容器启动后立即崩溃并不断重启。排查步骤包括：首先通过kubectl get pods查看Pod状态，使用kubectl describe pod和kubectl logs获取事件和容器日志。常见故障场景包括应用程序错误、启动命令配置错误、环境变量缺失、依赖服务不可用、资源限制不合理以及存储挂载失败。高级排查技巧包括进入临时调试容器、检查容器文件系统和网络抓包分析。解决方案涉及修复应用程序代码、修正启动命令、补充环境变量、确
【K8S问题系列 | 8】K8S集群资源突然爆满导致 Pod 状态变为 Pending 详细解决方案
颜淡慕潇
11-09 8394
在 Kubernetes 集群中，当 CPU 突然爆满时，Pod 可能无法获得所需的资源，从而导致其状态变为 Pending。以下是更详细的解决方案描述，有效应对这一问题。
K8S集群中Pod资源与其他服务连接超时排查思路
江晓龙的博客
08-05 3209
当出现Pod资源网络连接超时时，都可以按照如上思路镜像排查和分析。如果还是无法解决问题，可以试着在目标端抓包然后进行分析。在目标端进行抓包时会发现请求的源IP都是K8S Node节点的地址，没有Pod资源的IP，这时因为Pod在请求集群之外的服务时，会将IP通过NAT方式转换成Node节点的IP，由Node节点去请求对应的服务。...
Kubernates Pod无法启动问题分析排查
写Bug的小白的博客
06-16 2321
一、问题背景 近期遇到一个特别奇怪的事就是关于 K8s Pod 无法启动的问题，因为平时通过 Jenkins 打包成 Docker 后，再自动触发已经建好的 Pipline 就可以部署到 Kubernates 平台，但这次打包后发现部署应用到 Kubernates 时 Pod 总无法创建成功，然后 Pod 自动重新部署。 二、原因排查 排查问题的路径有： 通过查看 Kubernates 容器组中事件排查 Pod 无法起来的原因，类似于下面这张图 通过查看应用的最后打印日志排查问题；在这要说一句，在通过P
k8s pod java 接口 响应慢，超时 istio timeout
zhang_dianliang的专栏
11-05 1888
4、nginx 转发 配置了 2个 istio ，但是 总共有 11个 istio，整个集群有11个node。5、增加 nginx 转发 的 istio 个数，增加到 4个，发现我方接口趋于正常，观察一夜再说。6、又过了几天，告警出现，悲催，看到jvm监控运行线程15，由此想到，数据源线程默认是15吧。4、增加pod tomcat 线程数，之前是默认值，250吧应该是，改成500，观察一夜。观察监控，静待佳音，优化之路，任重而道远，永无止境。3、情况没有改善，证明瓶颈不在 istio。...
k8s环境下由predis初始化连接缓慢引起的一次问题排查
书山路遥
12-25 1199
背景 最近业务上在做同城双中心。原本的机房使用的是swarm集群，新机房使用的是k8s集群。业务迁移到新机房的主要工作集中在： 库、redis、es等底层服务的迁移； redis由原来的vip单点模式，切换为redis-cluster，由于phpredis1官方版本暂时不支持带auth的cluster模式，所以选择了predis链接redis； 将之前的swarm集群，迁移到k8s集群； 现象...
ES 查询比较慢的原因排查并查看ES节点状态
ajax_beijing_java的博客
09-05 3812
如果数据量过大，每次查询时需要进行大量的遍历和计算，会导致查询时间变长。可以通过对索引进行优化，如添加合适的字段映射，减少不必要的字段存储来缩短查询时间。如果索引设计不合理，也会导致查询时间变长。可以通过检查分片和副本配置、合理设置Mapping和Analazer等方式来优化索引设计。如果硬件资源不足，如CPU、内存、磁盘I/O等方面，也会影响查询性能。可以通过增加硬件资源、调整集群配置等方式来提高查询性能。如果使用的ES版本过低，可能存在一些性能问题和bug，建议升级到最新版本或稳定版本。
nfs版本问题导致挂载失败
Y_JESSE的博客
09-24 734
网上很多经验贴讲述的方法是开启。并不能开启v2版本支持。挂载根文件系统时报错，版本不低，不应该只支持。文档中没有描述如何指定。
K8S 性能优化-K8S Node 参数调优
east4ming的博客
03-11 888
K8S 性能优化系列文章，本文为第四篇：Kubernetes Node 性能优化参数最佳实践。《K8S 性能优化 - OS sysctl 调优》《K8S 性能优化 - K8S APIServer 调优》《K8S 性能优化 - 大型集群 CIDR 配置》
K8S集群中Pod资源常见问题排查思路以及处理方法
江晓龙的博客
05-18 2151
K8S集群中Pod资源常见问题排查思路以及处理方法 文章目录K8S集群中Pod资源常见问题排查思路以及处理方法1.Pod资源的概念2.Pod资源常见问题的排查思路 1.Pod资源的概念 对于Pod资源的核心概念以及配置详解，可以去阅读这篇文章：[《Kubernetes集群Pod资源结构定义及常用配置参数》][https://jiangxl.blog.youkuaiyun.com/article/details/117988304] Pod资源的概念： Pod资源是K8S集群中最小的调度单元，应用程序以容器的身份运行，从
在K8S中，Pod请求另一个Pod偶尔出现超时或延迟，如何排查？
努力变的更强
01-02 909
在Kubernetes中，当Pod请求另一个Pod时偶尔出现超市或延迟，可能是由于多种原因造成的。
K8s中启动pod报错mount. nfs : protocol not supported
06-04
### 问题分析 在 Kubernetes 中启动 Pod 时遇到 `nfs protocol not supported` 错误，通常表明 NFS 协议未被正确支持或配置。这可能是由于以下原因之一引起的： 1. **NFS 客户端未安装**：节点上可能缺少必要的 NFS 客户端工具。 2. **Kubernetes 节点的内核不支持 NFS 协议**：某些自定义内核可能未启用 NFS 支持。 3. **NFS 版本不匹配**：Pod 和 NFS 服务器之间的协议版本可能存在冲突。 以下是解决此问题的详细方法[^1]。 --- ### 解决方案 #### 检查 NFS 客户端是否已安装 确保所有 Kubernetes 节点上都已安装 NFS 客户端工具。可以通过以下命令检查并安装： ```bash # 检查是否已安装 NFS 客户端 dpkg -l | grep nfs-common # 对于基于 Debian 的系统 rpm -qa | grep nfs-utils # 对于基于 RHEL 的系统 # 如果未安装，则执行以下命令进行安装 sudo apt-get install nfs-common # Debian/Ubuntu sudo yum install nfs-utils # CentOS/RHEL ``` 如果 NFS 客户端未安装，安装后需要重启节点以确保生效[^2]。 --- #### 验证内核支持 NFS 协议 某些自定义内核可能未启用 NFS 支持。可以通过以下命令检查当前内核是否支持 NFS： ```bash cat /proc/filesystems | grep nfs ``` 如果没有输出，则说明当前内核不支持 NFS。可以尝试切换到标准内核版本，或者重新编译内核以添加 NFS 支持[^3]。 --- #### 检查 NFS 版本兼容性 NFS 协议有多个版本（如 v3、v4），Pod 和 NFS 服务器之间可能因版本不匹配导致错误。可以在 PersistentVolume (PV) 或 StorageClass 的配置中明确指定 NFS 版本。 以下是一个使用 NFS v4 的 PV 示例配置： ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteMany nfs: server: nfs-server.example.com path: /exports/data readOnly: false mountOptions: - vers=4.0 # 明确指定 NFS 版本 ``` 通过 `mountOptions` 字段，可以强制指定 NFS 协议版本。如果不确定服务器支持的版本，可以从较低版本（如 `vers=3`）开始测试[^4]。 --- #### 使用调试工具验证挂载 在节点上手动尝试挂载 NFS 共享，以排除配置问题： ```bash sudo mkdir -p /mnt/test sudo mount -t nfs -o vers=4.0 nfs-server.example.com:/exports/data /mnt/test df -hT | grep nfs ``` 如果挂载失败，可以根据错误信息进一步排查问题。 --- #### 更新 kubelet 配置 在某些情况下，Kubernetes 的 kubelet 可能需要额外配置以支持 NFS。可以通过以下命令检查 kubelet 是否启用了 `--feature-gates` 参数： ```bash ps aux | grep kubelet ``` 如果未启用相关功能，可以更新 kubelet 配置文件（通常是 `/var/lib/kubelet/config.yaml`），并在其中添加必要的选项[^5]。 --- ### 总结 上述方法涵盖了从客户端工具安装、内核支持验证、NFS 版本兼容性调整到手动调试等多个方面。根据具体情况逐一排查，通常可以有效解决 `nfs protocol not supported` 错误。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值