问题描述
今天早上 10 点正，正准备出门的我接到了一个客户的紧急电话。线上服务出现了问题，App 异常卡顿，报错频繁。客户的后端工程师通过排查发现，部分业务服务不可访问，甚至无法启动。
排查过程
- 打开电脑，直接 ssh 登上堡垒机，查看集群节点和 pod 情况，发现一些服务 termaniting 中，关不掉。 执行删除 pod 没能成功，然后强制删除正在关闭的 pod，观察重启过程，在 creating 状态报错。然后查看在哪个节点上。
- ssh 尝试登录集群的一些节点，发现有一个节点 node-01 登不上，猜想 node-01 出问题，但是直接查看 node 状态和其他节点一样，都是 ready，然后 telnet 测一下端口验证想法。
- 再次查看所有 pod 节点所在的 node ip 相关信息，过滤出一些异常节点，发现都是在 node-01 上，再次验证了猜想。
- 正常情况新创建的 pod 调度算法会均摊到其他服务节点，所以再次强制删除问题 pod，结果重新创建的 pod 还是命中了同一个 node。
- 直接禁用 node-01, 再次强制删除 pod，观察重启后的 pod，落在了其他节点上，然后跟开发确认服务是否已恢复，得到肯定的答案，再一个个删除其他问题的 pod，自动重启后一个个恢复。
整个过程大概用了 10 来分钟，猝不及防，线上出问题用户影响相当大，第一时间应该是以恢复业务为主，后续再排查原因，做方案调整。
后续处理
- 重启 node-01 虚拟机并恢复其节点，以确保部分服务的调度均摊到其他节点，并保持服务的可用状态。
- 后端工程师发现 node-01 这个 IP 之前也出现过类似的问题。通过 SSH 登录并检查了磁盘、内存、CPU、IO、进程、监听端口等状态，同时查询了一系列的日志信息，但未发现异常。
- 为了彻底消除这个隐患，决定采取简单而直接的方法，即迁移服务至一台新的、配置相同的节点，并将其添加到集群中。然后，我们将 node-01 从集群中剔除，并直接删除服务器。最后，观察服务状态以确保其可用性。
- 排查了一些 k8s 的基础配置，查了下调度算法和配置，准备优化意见，还有线上部分服务可以增加 pod 数量。
经验总结
- 线上出现问题用户的容忍度是非常有限的，第一时间应该是以恢复业务为主。
- 需要掌握一定的基础知识和技能，能够迅速排查问题并采取措施，时间就是生命线。
- 防患于未然，在使用 Linux 和 Kubernetes 时，要了解其基本原理和配置，及时调整并优化。
- 事后总结和方案的调整是必要的，以便更好地规避和应对类似问题。
总的来说，线上紧急问题的处理需要快速、有序地进行，同时也需要注重经验积累和总结，以便更好地提高应对能力。