Last Updated on 2024-11-14 by likun.gong

记录遇到的相关问题。

阿里云slb 5xx和4xx波动

现象：

1. 告警平台发生 slb 5xx 和 4xx 波动告警

排查过程：

1. 通过 slb 日志过滤，5xx 中主要是 502 占比很高，4xx 中主要是 499 的占比很高，只有一个域名出现此状况
2. 通过 502 状态码初步判断是后端服务不可用，然后客户端在不断重试，导致 499 状态码的请求增多
3. 根据域名和 slb 的监听定位后端服务，检查最底层后端服务，发现 nginx error log 中提示 upstream 无法连接
4. upstream 的后端是 php 的服务，查看运行状态正常，服务没有挂掉
5. 判断是服务处理不过来，可能是配置的线程数可能太少，影响了服务的处理能力
6. 检查配置文件，发现 pm.max_children 配置仅有 5
7. 提升 pm.max_children 值到 10 倍到 50，重启 php-fpm
8. 观察 nginx error log，发现错误已恢复

后续：

1. 仅配置 pm.max_children 并不是一个合理的做法，同时还需要调整 pm.start_servers, pm.min_spare_servers, pm.max_spare_server
   pm.start_servers(初始进程值) 一般是 max_children 值的 20%
   pm.min_spare_servers(至少保持空闲的进程值) 一般是 pm.start_servers 的 50%
   pm.max_spare_servers(最大保持空闲值) 一般是 pm.start_servers 的 2 倍
2. 需要注意的是，pm.max_children 需要根据服务器的资源情况来决定

总结：

1. 需要根据请求量来评估中间件中关键的参数配置，避免配置过低导致问题
2. 架构太过繁琐，接了快 3 层 Nginx，太过重复

Java服务被k8s不断重启问题记录

现象：

1. 告警发现服务的 Deployment available 值和配置的不匹配
2. 查看服务，发现服务被重启了多次，并且遗留了很多 Error 状态的 Pod

排查过程：

1. 查看 Error 状态 Pod 的详细信息 kubectl describe pod xxx
   发现 Pod 是因为节点磁盘不够导致被驱逐了
2. 进入正在运行的 Pod 中，发现应用目录下很多内存 Dump 文件，观察一段时间，发现数量还在持续增加，进而使磁盘使用率不断升高，导致被驱逐
3. 查看服务的 JVM 参数，发现配置了 -XX:+HeapDumpBeforeFullGC
   正是此参数导致 Dump 文件不断产生
4. 查看监控，发现 FullGC 经常发生
5. 评估此参数的合理性，去掉重启服务，恢复正常

总结：

1. 配置自动 Dump 时需要慎重考虑，因为 GC 过程会导致服务中断
2. 对于需要使用内存 Dump 来排查问题，建议在低峰期手动导出，或者使用
   -XX:HeapDumpOnOutOfMemoryError 参数，仅在发生 OOM 时进行导出，避免频繁自动 Dump ，影响服务正常运行

Karpenter GPU机器调度失败问题记录

现象：

使用 GPU 节点池的 Pod 一直调度失败，发现没有符合要求的节点，并且 Karpenter 自动调度 GPU 节点一直调度不起来。

解决过程：

1. 检查 Karpenter pod 日志，发现 AWS 对 GPU 类型的机器，限额了 vCPU 的数量，默认为 0，导致机器调度不起来
   "message":"creating instance, insufficient capacity, with fleet error(s), VcpuLimitExceeded: You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the specified instance type belongs to.
2. 提 case 给 AWS ，申请额度（每个可用区的额度是单独的），审核通过后，机器正常调度，也可以通过 Service Quota 提升额度，主要审批时间一般要 24 小时，尽量预估好用量，提前申请

Rancher组件启动失败问题

现象：

rancher 的组件在半夜自动更新，但是由于网络原因，镜像拉取失败，导致一直启动失败。

解决过程：

1. 无法在 K8S 的节点中配置代理，放弃此方法
2. 可以在设置中，配置 Rancher 从其他公开仓库拉取镜像。Rancher 在阿里云有上传镜像，但是不知道为什么，新的镜像版本发布比较慢，还是阿里云获取不到，也会出现拉取失败的问题
3. Rancher 中配置使用自己的公开仓库，再手动推送镜像到仓库
4. 推上去之后，发现镜像能拉取到了，但是启动失败
5. 原来是镜像的构架导致，本地用的 M 系列的 Mac 拉取的镜像，自动匹配成 arm 架构的镜像，再推送到仓库也是 arm 架构的镜像，但是 K8S 的节点是 x86 的机器
6. 在 Mac 中拉取镜像时，加上 --platform 参数 。
   docker pull --platform=linux/amd64 rancher/rancher-webhook:v0.4.7
   查看镜像架构确认
   docker inspect --format '{{ .Architcture }}' rancher/rancher-webhook:v0.4.7
7. 确认好拉取到的镜像是 x86 的之后，再推上去，就能成功启动了。注意目前 K8S 是使用的 containerd 引擎，在导入镜像时要注意指定 namespace
   ctr -n k8s.io images import xxx.tar
8. 排查为什么自动更新，发现是 Rancher 当前版本的 bug，在 issue 中有人讨论，预计在下一稳定版本修复

其他：

1. 随着 arm 架构的快速发展，但是现在很多服务器还是 x86 的架构，在使用时要注意保持环境的一致
2. arm 下也可以通过交叉编译，得到 x86 的镜像，后续可以了解下这方面的内容

Karpenter节点漂移问题

现象：

Karpenter 是一个开源的、可自动调度 worker 节点的工具，它可以在 AWS EKS 中使用。

我们发现 Karpenter 自动调度的节点，在过一段时间后，就会更新一次，启动新的节点替代旧的节点，导致服务自动重启。

解决过程：

1. 排查发现 karpenter 调度出来的节点有一个 ttl 机制，在 ttl 到期之后，会自动替换节点
2. Karpenter 支持配置 Pod、Node 不进行漂移，一直保持常驻，通过添加对应的注解可实现
3. 如果需要对整个 NodePool 配置不漂移，需要升级到 0.36.0 版本
4. 升级 Karpenter 版本
5. 配置 NodePool 策略，观察一段时间之后不再发生漂移

其他：

这个事件更多的是对 Karpenter 组件的不熟悉，文档查看的不完善，后续需要改进。