如何使用 K8s 两大利器“审计“和“事件“帮你摆脱运维困境？

概述

下面几个问题，相信广大 K8s 用户在日常集群运维中都曾经遇到过:

• 集群中的某个应用被删除了，谁干的？
• Apiserver 的负载突然变高，大量访问失败，集群中到底发生了什么？
• 集群节点 NotReady，是什么原因导致的？
• 集群的节点发生了自动扩容，是什么触发的？什么时间触发的？

以前，排查这些问题，对客户来说并不容易。生产环境中的 Kubernetes 集群通常是一个相当复杂的系统，底层是各种异构的主机、网络、存储等云基础设施，上层承载着大量的应用负载，中间运行着各种原生（例如：Scheduler、Kubelet）和第三方(例如：各种 Operator）的组件,负责对基础设施和应用进行管理和调度； 此外不同角色的人员频繁地在集群上进行部署应用、添加节点等各种操作。在集群运行的过程中，为了对集群中发生的状况能够尽可能的了如指掌，我们通常会从多个维度对集群进行观测。

日志，作为实现软件可观测性的三大支柱之一，为了解系统运行状况，排查系统故障提供了关键的线索，在运维管理中起着至关重要的作用。Kubernetes 提供了两种原生的日志形式——审计（Audit）和事件（Event），它们分别记录了对于集群资源的访问以及集群中发生的事件信息。从腾讯云容器团队长期运维 K8s 集群的经验来看，审计和事件并不是可有可无的东西，善用它们可以极大的提高集群的可观测性，为运维带来巨大的便利。下面让我们先来简单认识一下它们。

什么是 Kubernetes 审计？

Kubernetes 审计日志是 Kube-apiserver 产生的可配置策略的结构化日志，记录了对 Apiserver 的访问事件。审计日志提供 Metrics 之外的另一种集群观测维度，通过查看、分析审计日志，可以追溯对集群状态的变更；了解集群的运行状况；排查异常；发现集群潜在的安全、性能风险等等。

审计来源

在 Kubernetes 中，所有对集群状态的查询和修改都是通过向 Apiserver 发送请求，对 Apiserver 的请求来源可以分为4类

• 控制面组件，例如 Scheduler，各种 Controller，Apiserver 自身
• 节点上的各种 Agent，例如 Kubelet、Kube-proxy 等
• 集群的其它服务，例如 Coredns、Ingress-controller、各种第三方的 Operator 等
• 外部用户，例如运维人员通过 Kubectl

审计中都记录了些什么？

每一条审计日志都是一个 JSON 格式的结构化记录，包括元数据（metadata）、请求内容（requestObject）和响应内容（responseObject）3个部分。其中元数据一定会存在，请求和响应内容是否存在取决于审计级别。元数据包含了请