Kubernetes 故障排除三板斧：理解、管理和预防-技术圈

Kubernetes 生态系统充斥着各种工具，例如监控、可观察性、跟踪、日志记录等，但一般很难真正理解故障排除与这些工具有何联系。

当故障发生时，我们要掌握是从哪里发生，了解所面临的问题，解决眼前的问题，然后修复根本原因。随着系统规模的扩大，这一切会变得越来越复杂。

一名从事现代、复杂、分布式系统工作的软件工程师，会经常发现，每次出现问题或故障时，都需要了解引发问题的原因以及是谁造成的，但是，这并不是一件容易的事。更难的，是弄清楚幕后发生了什么，以及如何防止它再次发生。一般，我们会这样思考：

究竟发生了什么？
哪些事情是相关的？
什么与我们试图排除故障的特定症状相关？
我们如何确定根本原因？
最终，我们还要确保将来不再发生此问题或类似问题？

本文中，我们将之简化为3个步骤：

理解
管理
预防

我将深入探讨如何实施好这三个步，以及它们如何帮助我们对 Kubernetes 进行故障排除。我还将回顾哪些生态系统工具适合哪个步，以更好地掌握或使用那些工具。

1第一步：理解

毫不奇怪，这是重要的一步。理解系统资源，通常使你能够了解发生了什么、出了什么问题以及我们接下来应该做什么。

为了尝试了解故障原因，开发人员将首先分析系统最近的修改以及可能导致此故障发生的更改。当然，这说起来容易做起来难。在复杂的分布式系统，尤其是基于 Kubernetes 的系统中，这意味着大量使用 kubectl 来对部署日志、跟踪和指标进行故障排除，验证 pod 健康状况和资源上限，以及服务连接，以及其他常见的 pod 错误，检查 YAML 配置文件，验证第三方工具和集成等等。这可能是一行代码、一行配置的更改，触发了故障。

下图一张图，可以帮助我们在排除 K8s 系统进行故障时，缩小问题的范围。

图片来源🔗：有关 Kubernetes 部署故障排除的指南^[1]

网上的也有一份国人中文版的 Kubernetes 故障排除指南，供参考

可在 公众号 内回复『Kubernetes故障排除』获取高清原图

接下来，我们将查看事件：系统中实际发生了什么 – 系统是否过载？是否丢失了数据？是否存在服务中断？这与系统的初始变化有何关系？

然后，我们查看一下我们创建的指标、仪表板和数据，以基于数据源对问题进行某种理解。是否不止一个系统表现相同？影响两个系统的服务之一是否存在依赖性？最后，我们能否从看似相似的先前事件中学到一些东西，让我们对我们现在正在经历的事情有所了解？

仅就某些情况而言，下面是你需要使用的一些工具的列表，以便对系统中发生的事情有一个基本的了解。

监控工具：Datadog、Dynatrace、Grafana Labs、New Relic

可观察性工具：Lightstep、Honeycomb

实时调试工具：OzCode、Rookout

日志工具：Splunk、LogDNA、Logz.io

2第二步：管理

在当今的微服务架构中，很多时候相互依赖的服务由不同的团队管理。发生故障时，解决问题的关键之一是团队之间的沟通与协作。

根据潜在问题的类型，你可能想要采取的操作，包括像重启系统这样简单的操作，或者更’严厉’的措施，例如版本回滚或恢复最近的配置，直到更清楚地了解潜在问题。最终，你可能需要采取主动措施，如增加内存上限或机器数量的形式增加容量。但是，所有这些都不应该是你实时尝试和弄清楚的。今天有很多工具，从 Jenkins 到 ArgoCD，云提供商的专有工具，甚至更多的 kubectl 来采取这些行动和措施。

一旦更好地理解了潜在问题，补救就不应该是主要是反复试验的临时操作，或者存在于当前团队和实践中的记录。根据公司的技术堆栈和可能的根本原因，应使用定制的运行手册来管理任何给定的事件，并针对每种警报提供具体的任务和操作。

团队中的每一位工程师，无论是高级还是初级，都可以利用这一份友好的运行手册来实时排除故障。

此阶段的工具包将包括以下一些内容：

事件管理：PagerDuty，Kintaba

项目管理：Jira、Monday、Trello

CI/CD 管理：ArgoCD、Jenkins