对于今天的基础设施工程团队来说，太多的监控和告警疲劳是一个真正的问题。现在有很多开源和第三方的工具提供了过滤噪音的能力。这听起来总是很好，而且很可能是真的。但是，如果我告诉你，我最喜欢的替代品之一就在你面前，而且几乎可以立即从 Kubernetes 的 API 中获得呢？我说的是 Kubernetes 事件反馈。
Kubernetes 事件提供了对集群健康和性能的独特而清晰的见解。而在数据过多的时代，我发现 Kubernetes 事件提供了清晰的洞察力，而没有太多的噪音。
在这篇文章中，我们将了解 Kubernetes 事件类型，帮助你访问和存储事件，并建议一些大多数团队，无论大小，发现有帮助的告警。
什么是 Kubernetes 事件？类型和示例
Kubernetes 事件是一个对象，它显示集群、节点、pod 或容器内发生的事情。这些对象通常是为了响应 K8s 系统内部发生的变化而生成的。该 Kubernetes API 服务器使所有核心组件来创建这些事件。通常，每个事件还伴随着一条日志消息。但是，这两者非常不同，不会以任何其他方式相互影响。
关于 Kubernetes 事件需要注意的一件重要事情是，它们会在一段时间后被默认删除，通常在一个小时内。因此，您必须注意并收集发生的重要事件。
要访问 Kubernetes 事件，您可以运行以下命令：
kubectl get event
结果如下所示：
如您所见，许多 Kubernetes 事件是由节点中的状态更改引起的。每个事件都有一个 Reason 字段。您可以使用此字段来确定 K8s 事件对象的类型。以下是一些基于事件原因的标准分类。
失败的事件
当 K8s 无法创建一个容器或其他资源时，就会产生失败事件。这可能是由于错误的镜像、输入错误、没有预料到的原因以及许多不同的原因。几乎可以肯定的是，失败的事件将导致你的应用程序的功能被破坏；因此监测这些类型的事件是非常重要的。
FailedToCreateContainer、FailedToStartContainer、FailedToPullImage、FailedToKillPod等是一些失败事件的例子。
驱逐事件
驱逐事件经常发生，因为 K8s 经常介入并驱逐恶意容器和 pod（那些不必要地消耗大量资源的容器）。虽然这是预期的行为，但你仍然需要注意这些事件的发生。大量的驱逐事件表明，你没有在系统中设置适当的阈值。更多的时候，K8s 可能无法识别要驱逐的最佳实体，导致不相关的驱逐，从而导致服务流量损失。
节点特定事件
许多 K8s 事件都是基于节点及其生命周期活动。您可能已经注意到NodeHasSufficientMemory、NoteHasSufficientPID、NodeReady和上面示例中的其他事件。这些事件传达了节点相关的状态变化，并在寻找系统不稳定行为的根源时派上用场。
存储特定事件
所有基于云的应用程序都以一种或另一种方式利用存储。K8s 主要连接 AWS、GCP 等外部服务，或者 Docker 内部资源进行存储。在某些情况下，Pod 可能无法挂载存储资源。您应该注意FailedMount、FailedAttachVolume事件以识别错误存储安装的情况。
调度事件
调度事件提供了对资源管理策略效率的洞察。如果您没有很好地管理您的资源，则可能没有任何剩余的资源可以分配给新的 Pod。内存或 CPU 不足通常是罪魁祸首，在大多数情况下，您会收到FailedScheduling事件，并清楚说明为什么无法进行调度。
获取 Kubernetes 事件
要访问 Kubernetes 事件，您可以为 Pod 运行以下命令：
kubectl describe <podname>
或者，如果您想根据事件类型或任何其他字段查看更大的事件集合，您可以运行以下命令：
kubectl get events –field-selector type!=Normal
虽然这些命令为您提供命令行上的最新事件，但它们对需要历史数据分析的大规模部署没有帮助。您可以使用以下命令从 Kubernetes API 导出事件数据以进行详细分析：
kubectl get events -o json
这会将最新事件导出到 JSON 文件中，您可以将其导入到您最喜欢的可视化工具中以获得更多信息。
如何收集和存储事件
上面讨论的最后一种方法是从 Kubernetes 导出事件的最原始方法之一。您可以使用多种其他技术来安全地收集和存储事件。
本地观看和导出事件
Kubectl 提供了另一个方便的命令来观察系统中发生的事件：
kubectl get events –watch
这将开始将事件流式传输到您的终端。同样，这对于分析和可视化不是很有用。所以你应该考虑将它与像 Banzai Cloud 这样的第三方日志收集器结合起来进行分析。
KubeWatch
KubeWatch 是一个很棒的开源工具，用于观看 K8s 事件并将其流式传输到第三方工具和 webhook。您可以将其配置为在 Slack 通道中发送重要状态更改的消息。您还可以使用它向 Prometheus 等分析和告警工具发送事件。
您可以通过您最喜欢的 Kubernetes 工具（如 kubectl 或 helm）安装 KubeWatch。以下是 KubeWatch 的 Slack 通知快照信息：
KubeWatch 提供了一个简单的设置过程，但不提供独立的存储或管理功能。此外，您不会获得任何指标或日志记录功能。
Events Exporter
该 Kubernetes Events Exporter https://github.com/caicloud/e... 是在 K8S 本地观看的一个很好的替代。它允许您持续监控 K8s 事件并在需要时列出它们。它还从收集的数据中提取了大量指标，如事件计数、唯一事件计数等，并为您提供基本的监控设置。它非常易于安装，并且可以成为在使用更全面的工具安顿下来之前尝试的绝佳替代方案。
EventRouter
EventRouter https://github.com/heptiolabs...是另一个收集 Kubernetes 事件的伟大开源工具。它的设置毫不费力，旨在将 Kubernetes 事件流向多个源或汇，正如其文档中所说的那样。然而，就像 KubeWatch 一样，它也不提供查询或持久性功能。你需要将它与第三方存储和分析工具连接起来，以获得全面的体验。
一旦你了解了你的监控目标并制定了策略，你可以考虑转移到一个专门的、付费的 K8s 事件监控服务。你会得到强大的查询功能和跨平台的警报。
对常见的警告事件发出告警
实时观察 K8s 事件对了解系统中发生的情况至关重要。然而，你也需要建立一个强大的警报策略，在出现异常或紧急情况时通知你。
作为一个经验法则，你应该密切关注失败和调度事件，因为忽视这些事件会破坏你的应用程序的功能。你可以将被驱逐的事件设置为低优先级，因为它们通常是由于 K8s 的常规清理而产生的。节点特定的事件和存储特定的事件必须告警（虽然 NodeReady 是一个很好的事件，但你不需要每次都为它发出警报）。
大多数工具允许通过 webhooks 或 Slack 等常用协作平台发送告警。虽然这很简单，也很容易设置，但你可以通过把你的监控工具连接到一个更高级的告警平台上，使它更进一步。Prometheus 的 AlertManager 也是一个不错的选择。你也可以考虑使用基于 SaaS 的解决方案，比如 ContainIQ，它有专门的接口来创建告警事件，在广泛的平台上发送，并能够将事件与其他指标联系起来。
最后的想法
Kubernetes 事件是监控 K8s 集群运行状况和活动的好方法。但是，当与实用的策略和广泛的工具集相结合时，它们会变得更加强大。本指南帮助您了解 Kubernetes 事件的重要性以及如何从中获取最大价值。
