本文翻译自：https://sematext.com/blog/top-10-must-have-alerts-for-kubernetes/
运行 Kubernetes 集群，显然不止是启动，还需要持续监控，以确保 Kubernetes 中的服务能正常运行。真正有价值的 Kubernetes 告警，不是把所有指标都推给值班人员，而是在 CPU、内存、存储、API Server、Pod 副本、节点压力和 ETCD 稳定性出现风险时，尽早提示工程师采取行动。
不过，您不想整天盯着一堆 Kubernetes 仪表板（即便仪表板再多么美观）。您希望使用适当的警报来设置 Kubernetes 警报，对吗？借助 k8s 警报，您将快速发现 Kubernetes 集群中的问题，并希望也能快速修复它们。
核心要点摘要
- Kubernetes 告警应优先覆盖资源耗尽、控制面异常、存储挂载失败、Pod 副本缺失和 ETCD leader 异常等会直接影响可用性的场景。
- CPU 与内存告警的价值不只是“看到使用率高”，而是判断是否存在 limits 配置不合理、应用资源争用或容量不足。
- Pod 状态、重启、镜像拉取失败和 OOMKilled 往往是应用故障的直接信号，应结合日志、事件和资源配置一起排查。
- API Server、Kubelet 卷管理器和 ETCD 告警属于集群基础设施层告警，一旦触发，应优先确认控制面、网络、磁盘和存储链路。
- 告警处置应形成固定动作：定位对象、查看指标、读取日志、检查事件、确认配置，再决定扩容、调参或重启相关组件。
这 10 类 Kubernetes 告警覆盖哪些风险？
本文关注的告警可以分成四类：资源类告警、Pod 生命周期告警、节点与存储告警、控制面与 ETCD 告警。资源类告警用于发现 CPU 使用率过高、CPU limits 被触达、节点 CPU/内存容量异常等问题；Pod 生命周期告警用于发现副本缺失、状态异常、重启和 OOM；节点与存储告警用于发现 Node Under Pressure 和 Kubelet 卷管理器不可用；控制面与 ETCD 告警用于发现 API Server 错误和 ETCD leader 频繁变化。
下面逐一看这些告警为什么重要，以及触发后可以执行哪些排查动作。
1. 过高的 CPU 使用率
为什么这很重要
当 Kubernetes Pod 超出其 CPU 限制时，将触发此警报，表明可能存在资源争用或资源分配效率低下。如果 CPU 限制不断达到，则可能导致应用程序响应时间变慢和潜在的服务中断。简而言之，你不希望看到这种情况发生。
处置方法
调查受影响的 Pod，并考虑调整资源限制或优化应用程序。
使用以下命令检查受影响 Pod 的 CPU 使用率：
kubectl top pod <pod_name> -n <namespace>
要调整 pod 的资源限制，请编辑其 YAML 配置文件：
kubectl edit pod <pod_name> -n <namespace>
在 YAML 文件中，修改“resources”部分以调整 CPU 限制：
resources:
limits:
cpu: <new_cpu_limit>
替换为所需的 CPU 限制值。
2. 已达到 CPU 使用限制
为什么这很重要
与上一个警报类似，当 Pod 达到其 CPU 限制时，此警报会发出通知。
处置方法
分析工作负载的资源需求和扩展要求，以防止性能下降。
运行以下命令以获取与受影响的 Pod 关联的工作负载的 CPU 使用率指标：
kubectl top pod --selector=<selector> -n <namespace>
替换为工作负载的适当标签选择器，例如 app=，以聚合属于工作负载的所有 Pod 的 CPU 使用情况。
3. Kubelet 卷管理器不可用
为什么这很重要
kubelet 卷管理器故障可能会影响 pod 存储，从而可能导致数据丢失。不可用的卷管理器可能会阻止挂载 Pod 卷，从而影响依赖于持久存储的应用程序。
处置方法
调查 kubelet 服务和底层存储基础设施是否存在问题，并在必要时重新启动受影响的组件。
运行以下命令以检查 kubelet 服务的状态：
kubectl get pods -n kube-system | grep kubelet
检查 kubelet pod 的日志，以识别与卷管理器相关的任何错误或警告：
kubectl logs <kubelet_pod_name> -n kube-system
检查存储卷和网络连接的状态：
kubectl get pv,pvc -n <namespace>
确保存储卷已正确连接并由 kubelet 服务访问。
如有必要，请重新启动 kubelet 服务和任何相关组件。此命令强制 Kubernetes 重新创建 kubelet pod，希望能解决卷管理器的任何问题。
kubectl delete pod <kubelet_pod_name> -n kube-system
4. Kubernetes API 服务器错误
为什么这很重要
监视来自 Kubernetes API 服务器的客户端错误 （4XX） 和服务器错误 （5XX），这可能表示通信问题或内部服务器问题。
处置方法
检查网络连接和 API 服务器日志，以识别并解决根本问题。
验证 Kubernetes API 服务器的状态：
kubectl get pods -n kube-system | grep kube-apiserver
检查日志中是否存在与 API 服务器相关的错误或警告：
kubectl logs <kube-apiserver_pod_name> -n kube-system
检查与 API 服务器的网络连接：
kubectl cluster-info
5. Node Under Pressure
为什么这很重要
当 Kubernetes 节点遇到资源压力时发出警报，这可能会影响 Pod 调度和性能。
处置方法
监视 Kubernetes 节点上的资源，以确定承受压力的部分：
kubectl describe node <node_name>
查找可能表明资源压力过高的 CPU、内存或磁盘使用率。
查看节点上运行的工作负载，以识别资源密集的应用程序或容器：
kubectl get pods --all-namespaces -o wide
如果资源压力持续存在，请考虑扩展 CPU、内存或存储等资源：
kubectl scale node <node_name> --cpu=<new_cpu_capacity> --memory=<new_memory_capacity>
根据工作负载要求和可用节点容量调整资源限制。
将工作负载分布在多个节点上，以缓解资源压力：
kubectl drain <node_name> --ignore-daemonsets
6. 异常节点 CPU/内存容量
为什么这很重要
检测 Kubernetes 节点何时使用比平时更多的 CPU 或内存，这可能意味着它们耗尽了资源或无法有效工作。
处置方法
检查资源的使用方式随时间推移，并在必要时更改节点容量或工作负载的分配方式。
监控 Kubernetes 节点上的 CPU 和内存使用情况：
kubectl top nodes
查看一段时间内的资源使用趋势，以识别 CPU 和内存使用率的异常或峰值。
如果节点持续超出 CPU 或内存限制，请考虑纵向扩展节点容量：
kubectl scale node <node_name> --cpu=<new_cpu_capacity> --memory=<new_memory_capacity>
替换为受影响节点的名称、 所需的 CPU 容量和所需的内存容量。
7. 缺少 Deployments/StatefulSet 的 Pod 副本
为什么这很重要
当由 Deployments 或 StatefulSet 控制的 Pod 丢失时发出通知 ，指示部署失败或 Pod 被驱逐。当缺少 Pod 时，这意味着应用程序的基本组件未按预期运行，这可能导致停机、性能不佳和数据丢失。 例如，如果您将集群配置为具有 Pod 的 2 个副本，并且缺少其中一个副本，则您实际上正在运行 Pod 的单个实例，并且具有 SPOF（single point of failure 单点故障）并存在容错问题。
处置方法
检查 Deployment/Statefulset 配置和集群事件，以诊断和解决部署问题。
检查受影响的 Deployment 或 StatefulSet 的配置：
kubectl describe deployment <deployment_name> -n <namespace>
或：
kubectl describe statefulset <statefulset_name> -n <namespace>
查看所需的副本计数和当前副本计数，以确定是否存在任何差异。
查看集群事件，以识别与丢失的 Pod 副本相关的任何事件：
kubectl get events -n <namespace>
查找指示 Pod 逐出或部署失败的事件。
8. Pod 状态问题
为什么这很重要
检查 Pod 状态对于发现应用程序错误、资源不足或调度问题等问题非常重要。例如，如果 Pod 停滞在“等待”状态，则可能表明由于缺少资源或配置问题而无法启动。
处置方法
分析 Pod 日志、事件和配置，以排查和解决影响 Pod 稳定性和性能的根本问题。
查看 Pod 的日志以识别潜在的错误或问题：
kubectl logs <pod_name> -n <namespace>
检查 Pod 事件以了解影响 Pod 状态的最近更改或事件：
kubectl describe pod <pod_name> -n <namespace>
检查容器的配置以验证设置和资源分配：
kubectl describe pod <pod_name> -n <namespace>
9. Pod 重启和失败场景
为什么这很重要
频繁的 Pod 重启、容器崩溃、镜像拉取失败或内存不足 （OOM） 错误可能会影响应用程序的可靠性和用户体验，因此有效的 Kubernetes Pod 监控至关重要。想象一下，一个关键的微服务反复遇到内存不足错误。这可能会导致停机时间延长，从而可能导致收入损失和客户不满。没有人想要那样。
处置方法
如果 Pod 因为内存不足而不断重启，请查看其日志以了解原因：
kubectl logs <pod_name> -n <namespace>
查找 Pod 重启或失败的模式，例如内存不足错误、容器崩溃或镜像拉取失败。
如果 Pod 由于资源限制而重新启动，请考虑增加其资源限制：
kubectl edit pod <pod_name> -n <namespace>
10. ETCD leader 变化频繁或无 leader
为什么这很重要
监控 ETCD 集群的运行状况，在频繁更换领导者或缺少领导者时发出警报，这可能会影响集群的一致性和弹性。频繁更换领导者或缺少领导者表明集群通信或稳定性可能存在问题。就像在恋爱关系中一样，Kubernetes 集群中的良好沟通是其幸福的关键。😉
处置方法
调查 ETCD 集群运行状况、网络连接和磁盘性能，以确保正常运行和稳定性。
检查 ETCD 集群的健康状态并确定当前领导者：
etcdctl endpoint health --endpoints=<etcd_endpoints>
其中 <etcd_endpoints> 替换为你的 ETCD 集群的端点。
监控 ETCD 集群事件，了解领导者的频繁变更：
etcdctl watch --prefix / --rev=<current_revision> --endpoints=<etcd_endpoints>
验证 ETCD 节点之间的网络连通性，并检查 ETCD 节点上的磁盘性能，以防止 I/O 相关问题。
结论
Kubernetes 告警的重点不是数量，而是覆盖关键故障面。CPU、内存、Pod 状态、节点压力、Kubelet 存储、API Server 和 ETCD 这几类信号，分别对应应用性能、工作负载可用性、节点容量、存储链路和控制面稳定性。把这些告警与固定排查命令结合起来，值班人员才能在故障早期快速判断影响范围和下一步动作。
FAQ
Q1：Kubernetes 告警应该先从哪些场景开始配置？ A：可以先覆盖 CPU 使用率过高、CPU limits 触达、Pod 副本缺失、Pod 重启或 OOM、节点资源压力、API Server 4XX/5XX、Kubelet 卷管理器不可用和 ETCD leader 异常。它们都和集群可用性、应用稳定性直接相关。
Q2：CPU 使用率高和 CPU 使用限制被触达有什么区别？ A：CPU 使用率高说明工作负载正在消耗较多 CPU；CPU 使用限制被触达说明 Pod 已经接近或达到配置的 limits，可能出现性能下降。前者偏向容量和负载判断，后者还要检查 limits 是否配置过低。
Q3：Pod 频繁重启时应该先看什么？
A：先用 kubectl logs 查看应用日志，再用 kubectl describe pod 查看事件、退出原因和资源配置。如果看到 OOMKilled、镜像拉取失败或容器崩溃，应分别沿内存、镜像仓库和应用异常方向排查。
Q4：ETCD leader 频繁变化为什么严重？ A：ETCD 负责保存 Kubernetes 集群状态。leader 频繁变化或无 leader，通常意味着 ETCD 集群通信、磁盘性能或稳定性存在问题，可能影响集群一致性和控制面可靠性。
本文是 Flashcat 小伙伴翻译整理，Flashcat 是一家监控/可观测性创业公司，联系 Flashcat 做产品技术交流：https://flashcat.cloud/contact/。
