type
status
date
slug
summary
tags
category
icon
password
kuberntes
Kubernetes 生态系统充斥着各种工具,例如监控、可观察性、跟踪、日志记录等,但一般很难真正理解故障排除与这些工具有何联系。
当故障发生时,我们要掌握是从哪里发生,了解所面临的问题,解决眼前的问题,然后修复根本原因。随着系统规模的扩大,这一切会变得越来越复杂。
一名从事现代、复杂、分布式系统工作的软件工程师,会经常发现,每次出现问题或故障时,都需要了解引发问题的原因以及是谁造成的,但是,这并不是一件容易的事。更难的,是弄清楚幕后发生了什么,以及如何防止它再次发生。
一般,我们会这样思考:
究竟发生了什么?哪些事情是相关的?什么与我们试图排除故障的特定症状相关?我们如何确定根本原因?终,我们还要确保将来不再发生此问题或类似问题?
本文中,我们将之简化为3个步骤:
理解管理预防
我将深入探讨如何实施好这三个步,以及它们如何帮助我们对Kubernetes 进行故障排除。我还将回顾哪些生态系统工具适合哪个步,以更好地掌握或使用那些工具。
第一步:理解
毫不奇怪,这是重要的一步。理解系统资源,通常使你能够了解发生了什么、出了什么问题以及我们接下来应该做什么。
为了尝试了解故障原因,开发人员将首先分析系统近的修改以及可能导致此故障发生的更改。
当然,这说起来容易做起来难。在复杂的分布式系统,尤其是基于 Kubernetes 的系统中,这意味着大量使用 kubectl 来对部署日志、跟踪和指标进行故障排除,验证 pod 健康状况和资源上限,以及服务连接,以及其他常见的 pod 错误,检查 YAML 配置文件,验证第三方工具和集成等等。这可能是一行代码、一行配置的更改,触发了故障。
下图一张图,可以帮助我们在排除 K8s 系统进行故障时,缩小问题的范围。
![notion image](https://www.notion.so/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F6f525df7-9eb8-449d-a385-8e7506e1459d%2Fk8s.jpeg?table=block&id=a17e1ba4-98e2-4c01-bd00-ca803dda5555&t=a17e1ba4-98e2-4c01-bd00-ca803dda5555&width=714&cache=v2)
图片来源: 有关 Kubernetes 部署故障排除的指南
接下来,我们将查看事件:系统中实际发生了什么 – 系统是否过载?是否丢失了数据?是否存在服务中断?这与系统的初始变化有何关系?
然后,我们查看一下我们创建的指标、仪表板和数据,以基于数据源对问题进行某种理解。是否不止一个系统表现相同?影响两个系统的服务之一是否存在依赖性?后,我们能否从看似相似的先前事件中学到一些东西,让我们对我们现在正在经历的事情有所了解?
仅就某些情况而言,下面是你需要使用的一些工具的列表,以便对系统中发生的事情有一个基本的了解。
监控工具:Datadog、Dynatrace、Grafana Labs、New Relic
可观察性工具:Lightstep、Honeycomb
实时调试工具:OzCode、Rookout
日志工具:Splunk、LogDNA、Logz.io
第二步:管理
在当今的微服务架构中,很多时候相互依赖的服务由不同的团队管理。发生故障时,解决问题的关键之一是团队之间的沟通与协作。
根据潜在问题的类型,你可能想要采取的操作,包括像重启系统这样简单的操作,或者更’严厉’的措施,例如版本回滚或恢复近的配置,直到更清楚地了解潜在问题。终,你可能需要采取主动措施,如增加内存上限或机器数量的形式增加容量。但是,所有这些都不应该是你实时尝试和弄清楚的。今天有很多工具,从 Jenkins 到 ArgoCD,云提供商的专有工具,甚至更多的 kubectl 来采取这些行动和措施。
一旦更好地理解了潜在问题,补救就不应该是主要是反复试验的临时操作,或者存在于当前团队和实践中的记录。根据公司的技术堆栈和可能的根本原因,应使用定制的运行手册来管理任何给定的事件,并针对每种警报提供具体的任务和操作。
团队中的每一位工程师,无论是还是初级,都可以利用这一份友好的运行手册来实时排除故障。
此阶段的工具包将包括以下一些内容:
事件管理:PagerDuty,Kintaba
项目管理:Jira、Monday、Trello
CI/CD 管理:ArgoCD、Jenkins
后一个步:预防
预防可能是重要的步,以确保类似事件不再发生。防止类似问题的方法是根据每个事件创建定义明确的策略和规则。在“理解”阶段要采取哪些行动,我们如何快速地识别问题并将问题上报给相关团队?
我们如何委派责任,确保团队之间无摩擦的沟通和协作?这包括手头任务和操作的完全透明度,以及进度的实时更新。每种警报和事件的任务的规范顺序是什么?
一旦我们弄清楚了上述所有内容,我们就可以开始考虑如何自动化和协调这些事件,并尽可能接近传说中的“自我修复”系统。
这一步的特点是通过不断将系统推向极限,从而创建更具弹性和适应变化的系统的工具。例如:
Chaos Engineering:Gremlin、Chaos Monkey、ChaosIQ
Auto Remediation:Shoreline、OpsGenie
一步都不能少
我们相信,通过以上三步的结合,可以将故障排除与监控、可观察性、跟踪等区别开来。然而,可能重要的是深入到系统和流程中,以防止它们再次发生。
它们仍然被广泛使用并如此受欢迎的原因是,即使我们在“DevOps 工具”方面取得了巨大进步后,对于实时的问题或故障,很多时候依然捉襟见肘。
因此,我建议将应用程序和运维数据集中到一个平台中,使团队成员能够真正了解他们的系统,并终了解对复杂系统出现的警报如何采取行动。当我们将好的开发人员和运维人员结合在一起时,我们可以通过更好地合作来更快地解决故障。