生产环境中的 Kubernetes 集群通常是一个相当复杂的系统，底层是各种异构的主机、网络、存储等云基础设施，上层承载着大量的应用负载，中间运行着各种原生（Scheduler、Kubelet等）和第三方（例如各种Operator）的组件对基础设施和应用进行管理和调度。此外不同角色的人员频繁地在集群上进行部署应用、添加节点等各种操作。因此在集群运维场景中， 用户常见的问题有：
集群中的某个应用被删除了，谁操作的？
Apiserver 的负载突然变高，大量访问失败，集群中到底发生了什么？
集群节点被封锁了，是谁在什么时候操作的？
日志服务（Cloud Log Service，CLS）与 容器服务（Tencent Kubernetes Engine，TKE） 已打通。 通过 Kubernetes 集群审计日志可以帮助用户快速解决以上这些问题。
前提条件
审计日志简介
审计日志记录了对 kube-apiserver 的访问事件，会按顺序记录每个用户、管理员或系统组件影响集群的活动。每一条审计日志是一个 JSON 格式的结构化记录，包括元数据（metadata）、请求内容（requestObject）和响应内容（responseObject）三个部分。其中元数据（包含了请求的上下文信息，例如谁发起的请求、从哪里发起的、访问的 URI 等信息）一定会存在，请求和响应内容是否存在取决于审计级别。通过日志可以了解到以下内容：
集群里发生的活动。
活动的发生时间及发生对象。
活动的触发时间、触发位置及观察点。
活动的结果以及后续处理行为。
审计日志字段说明
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"RequestResponse","auditID":0a4376d5-307a-4e16-a049-24e017******,"stage":"ResponseComplete",// 发生了什么"requestURI":"/apis/apps/v1/namespaces/default/deployments","verb":"create",// 谁发起的"user":{"username":"admin","uid":"admin","groups":["system:masters","system:authenticated"]},// 从哪里发起"sourceIPs":["10.0.6.68"],"userAgent":"kubectl/v1.16.3 (linux/amd64) kubernetes/ald64d8",// 发生了什么"objectRef":{"resource":"deployments","namespace":"default","name":"nginx-deployment","apiGroup":"apps","apiVersion":"v1"},// 结果是什么"responseStatus":{"metadata":{},"code":201},// 请求及返回具体信息"requestObject":Object{...},"responseObject":Object{...},// 什么时候开始/结束"requestReceivedTimestamp":"2020-04-10T10:47:34.315746Z","stageTimestamp":"2020-04-10T10:47:34.328942Z",// 请求被接收/拒绝的原因是什么"annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
预置仪表盘
CLS 已将常用的审计日志分析方式预置为仪表盘，您可通过这些仪表盘快速了解当前集群状态。
审计总览，观测整个集群 APIserver 操作。
节点操作概览，主要用于排查节点相关问题。
K8S对象操作概览，主要用于排查 K8S 对象（例如某个工作负载）的相关问题。
聚合检索，观测某个维度下审计日志的分布趋势。
在仪表盘右上角单击编辑仪表盘可基于预置仪表盘进行编辑，构建更适用您的专属仪表盘。
排查问题场景示例
场景1：集群中的某个应用被删除了，谁操作的？
1. 打开 K8S 对象操作概览仪表盘，在日志主题中选择需要审计日志存储的日志主题，指定操作类型为 delete 和资源对象 nginx。
2. 查询结果如下图所示：
10001****7138 这个账号，对应用「nginx」进行了删除。可根据账号 ID 在访问管理 > 用户 > 用户列表中找到关于此账号的详细信息。场景2：Apiserver 的负载突然变高，大量访问失败，集群中到底发生了什么？
1. 打开 聚合检索仪表盘，该仪表盘提供了从用户、操作类型、返回状态码等多个维度对于 Apiserver 访问聚合趋势图。
操作用户分布趋势图：
操作类型分布趋势图：
状态码分布趋势图：
2. 通过以上图表得知，用户
tke-kube-state-metrics的访问量远高于其他用户，并且在“操作类型分布趋势”图中可以看出大多数都是 list 操作，在“状态码分布趋势”图中可以看出，状态码大多数为403，根据tke-kube-state-metrics关键词，检索日志。
tke-kube-state-metrics组件不停地请求 Apiserver 重试，导致 Apiserver 访问剧增。场景3：集群节点被封锁了，是谁在什么时候操作的？
1. 打开 节点操作概览仪表盘，填写被封锁的节点名。
2. 查询结果如下图所示：
10001****7138这个账号在2020-11-30T06:22:18时对172.16.18.13这台节点进行了封锁操作。