一、功能优势
审计日志功能提供了区别于 metrics 的另一种集群观测维度。开启审计日志后，Kubernetes 可以记录每一次对集群操作的审计日志。每一条审计日志是一个 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":{}, "responseObject":{}, "requestReceivedTimestamp":"2020-04-10T10:47:34.315746Z", "stageTimestamp":"2020-04-10T10:47:34.328942Z", "annotations":{ "authorization.k8s.io/decision":"allow", "authorization.k8s.io/reason":"" }}
三、审计级别（level）
和一般日志不同，Kubernetes 审计日志的级别更像是一种 verbose 配置，用于标示记录信息的详细程度。一共有4个级别，可参考以下表格内容：
| 参数 | 说明 |
| None | 不记录。 |
| Metadata | 记录请求的元数据（例如用户、时间、资源、操作等），不包括请求和响应的消息体。 |
| Request | 除了元数据外，还包括请求消息体，不包括响应消息体。 |
| RequestResponse | 记录所有信息，包括元数据以及请求、响应的消息体。 |
四、审计阶段（stage）
记录日志可以发生在不同的阶段，参考以下表格内容：
| 参数 | 说明 |
| RequestReceived | 一收到请求就记录。 |
| ResponseStarted | 返回消息头发送完毕后记录，只针对 watch 之类的长连接请求。 |
| ResponseComplete | 返回消息全部发送完毕后记录。 |
| Panic | 内部服务器出错，请求未完成。 |
五、审计策略
TKE Serverless 默认收到请求即会记录审计日志，且大部分的操作会记录 RequestResponse 级别的审计日志。但也会存在如下情况：
·get、list 和 watch 会记录 Request 级别的日志。
·针对 secrets 资源、configmaps 资源或 tokenreviews 资源的请求会在 Metadata 级别记录。
以下请求将不会进行记录日志：
·system:kube-proxy 发出的监视 endpoints 资源、services 资源或 services/status 资源的请求。
·system:unsecured 发出的针对 kube-system 命名空间中 configmaps 资源的 get 请求。
·kubelet 发出的针对 nodes 资源或 nodes/status 资源的 get 请求。
·system:kube-controller-manager、system:kube-scheduler 或 system:serviceaccount:endpoint-controller 发出的针对 kube-system 命名空间中 endpoints 资源的 get 和 update 请求。
·system:apiserver 发出的针对 namespaces 资源、namespaces/status 资源或 namespaces/finalize 资源的 get 请求。
·对于 /healthz*、/version 或 /swagger* 匹配的网址发出的请求。
六、开启审计日志
注意：开启审计日志功能需要重启 kube-apiserver，建议不要频繁开关。
1. 登录 容器服务控制台，在左侧导航栏中选择集群。
2. 在集群列表中，单击目标集群 ID，进入集群详情页。
3. 选择左侧导航栏中的日志，在日志采集页签中单击审计日志右侧的开启。如下：
4. 在开启审计日志中，选择日志所在地域，并配置日志集和日志主题。如下：
5. 单击确定，即可开启审计日志。
七、审计日志状态说明
TKE 审计日志涉及两个独立的能力：kube-apiserver 的审计策略配置（决定 apiserver 是否产生审计日志）与 TKE 审计日志采集器（决定审计日志是否被采集并上报到日志服务 CLS）。控制台“日志采集”页签上“审计日志”的状态文案就是这两者组合的综合描述：
| 状态 | 含义 | kube-apiserver 审计策略 | 采集器 |
| 未开启 | 审计日志未启用。 | 未开启。 | 未配置。 |
| 已开启 | 审计日志已启用，正在采集并上报。 | 已开启。 | 已配置，日志集和日志主题均已指定，正在上报。 |
| 已开启未采集 | kube-apiserver 的审计策略仍为开启状态，但采集器已停止采集和上报。 | 已开启。 | 已停止，或日志集／日志主题缺失。 |
八、为什么关闭审计日志后仍显示“已开启未采集”
为避免频繁开启、关闭审计日志触发 kube-apiserver 重建，TKE 在用户关闭审计日志时不会修改 kube-apiserver 的审计策略配置，而是通过删除采集规则等方式让采集器停止采集和上报审计日志。用户再次开启审计日志时，只需恢复采集器采集即可重新上报，apiserver 的审计策略全程保持开启。因此：
·已开启审计日志的集群，在关闭审计后，控制台上“审计日志”的状态会从“已开启”变为“已开启未采集”，这不代表关闭操作失败。
·已开启审计日志后的关闭与再次开启操作不会触发 kube-apiserver 重建。
·首次开启审计日志仍需配置 kube-apiserver 的审计策略，会导致 kube-apiserver 重启，详见上文“开启审计日志”。
九、如何判断关闭审计日志是否生效
关闭操作成功后，刷新集群的日志页面，若审计日志状态显示为“已开启未采集”，即表示采集器已停止采集和上报，关闭操作已生效，无需等待状态变为“未开启”。
此前已经上报到 CLS 的历史审计日志不会被自动删除（历史数据是否删除取决于关闭操作时所选的删除选项），仍可通过 CLS 检索到。判断关闭是否生效应关注关闭操作之后新发生的集群操作是否仍被持续上报，而不是依据历史日志记录。