如何使用 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个部分。其中元数据必定会存在，请求和响应内容是否存在取决于审计级别。元数据包含了请求的上下文信息，例如谁发起的请求，从哪里发起的，访问的 URI 等等；

审计有什么用？

Apiserver 作为 Kubernetes 集群惟一的资源查询、变动入口，审计日志能够说记录了全部对于集群访问的流水， 经过它能够从宏观和微观了解整个集群的运行情况，好比：

• 资源被删掉了，何时删掉的，被“谁”删掉的？
• 服务出现问题，何时作过版本变动？
• Apiserver 的响应延时变长，或者出现大量 5XX 响应 Status Code，Apiserver 负载变高，是什么致使的？
• Apiserver 返回 401/403 请求，到底是证书过时，非法访问，仍是 RBAC 配置错误等。
• Apiserver 收到大量来自外网 IP 对敏感资源的访问请求，这种请求是否合理，是否存在安全风险；

什么是Kubernetes事件？

事件（Event）是 Kubernetes 中众多资源对象中的一员，一般用来记录集群内发生的状态变动，大到集群节点异常，小到 Pod 启动、调度成功等等。咱们经常使用的kubectl describe命令就能够查看相关资源的事件信息。

事件中记录了什么？

• 级别（Type）： 目前仅有“Normal”和“Warning”，可是若是须要，可使用自定义类型。
• 资源类型/对象(Involved Object)：事件所涉及的对象，例如 Pod，Deployment，Node 等。
• 事件源（Source）：报告此事件的组件；如 Scheduler、Kubelet 等。
• 内容（Reason）：当前发生事件的简短描述，通常为枚举值，主要在程序内部使用。
• 详细描述（Message）：当前发生事件的详细描述信息。
• 出现次数（Count）：事件发生的次数。

事件有什么用？

集群内已经翻江倒海，集群外却风平浪静，这多是咱们平常集群运维中经常遇到的状况，集群内的情况若是没法透过事件来感知，极可能会错过最佳的问题处理时间，待问题扩大，影响到业务时才发现每每已经为时已晚；除了早早发现问题，Event 也是排查问题的最佳帮手，因为 Event 记录了全面的集群状态变动信息，因此大部分的集群问题均可经过 Event 来排查。总结一下 Event 在集群中扮演两大重要角色：

• “吹哨人”：当集群发生异常状况时，用户可经过事件第一时间感知；
• “目睹者”：集群中的大小事件都会经过 Event 记录，若是集群中发生意外状况，如:节点状态异常，Pod 重启，均可以经过事件查找发生的时间点及缘由；

TKE 如何发掘审计/事件的价值

传统的经过输入查询语句检索日志的方式来使用审计和事件，当然能够提供很高的灵活性，但也有着较高的使用门槛，不只要求使用者对于日志的数据结构很是了解，还要熟悉 Lucene、SQL 语法。这每每致使使用效率偏低，也没法充分发掘数据的价值。

腾讯云容器服务 TKE 联合腾讯云日志服务CLS，打造出针对 Kubernetes 审计/事件采集、存储、检索、分析的一站式产品级服务， 不只提供了一键开启/关闭功能，免去一切繁琐的配置；并且容器团队还从长期运维海量集群的经验中，总结出对于 Kubernetes 审计/事件的最佳使用实践，经过可视化的图表，以多个维度对审计日志和集群事件进行呈现，使用者只需了解 K8s 的基本概念，就能很“直觉”地在 TKE 控制台上进行各类检索和分析操做，足以涵盖绝大多数常见集群运维场景， 让不管是发现问题仍是定位问题都事半功倍，提高运维效率，真正将审计和事件数据的价值最大化 。

如何使用 TKE 审计/事件服务去排查问题？

关于 TKE 的集群审计/事件简介与基础操做，请参考集群审计、事件存储的官方文档。

场景示例：

下面咱们看几个现实中的典型场景

示例1: 排查一个工做负载消失的问题

在审计检索页面中，单击【K8s 对象操做概览】标签，指定操做类型和资源对象

查询结果以下图所示：

由图可见，是 10001****7138 这个账号，对应用「nginx」进行了删除。可根据账号ID在【访问管理】>【用户列表】中找到关于此帐号的详细信息。

示例2: 排查一个节点被封锁的问题

在审计检索页面中，单击【节点操做概览】标签，填写被封锁的节点名

查询结果以下图所示：

由图可见，是10001****7138这个账号在2020-1-30T06:22:18时对172.16.18.13这台节点进行了封锁操做。

示例3: 排查 Apiserver 响应变慢的问题

在审计检索的【聚合检索】标签页中，提供了从用户、操做类型、返回状态码等多个维度对于 Apiserver 访问聚合趋势图。

由图可见，用户tke-kube-state-metrics的访问量远高于其余用户，而且在“操做类型分布趋势”图中能够看出大多数都是 list 操做，在“状态码分布趋势”图中能够看出，状态

码大多数为 403，结合业务日志可知，因为 RBAC 鉴权问题致使tke-kube-state-metrics组件不停的请求Apiserver重试，致使 Apiserver 访问剧增。日志以下所示：

E1130 06:19:37.368981       1 reflector.go:156] pkg/mod/k8s.io/client-go@v0.0.0-20191109102209-3c0d1af94be5/tools/cache/reflector.go:108: Failed to list *v1.VolumeAttachment: volumeattachments.storage.k8s.io is forbidden: User "system:serviceaccount:kube-system:tke-kube-state-metrics" cannot list resource "volumeattachments" in API group "storage.k8s.io" at the cluster scope

示例4:排查节点异常的问题

一台 Node 节点出现异常，在事件检索页面，点击【事件总览】，在过滤项中输入异常节点名称

查询结果显示，有一条节点磁盘空间不足的事件记录查询结果以下图：

进一步查看异常事件趋势

能够发现，2020-11-25号开始，节点172.16.18.13因为磁盘空间不足致使节点异常，此后 kubelet 开始尝试驱逐节点上的 pod 以回收节点磁盘空间；

示例5: 查找触发节点扩容的缘由

开启了节点池「弹性伸缩」的集群，CA（cluster-autoscler）组件会根据负载情况自动对集群中节点数量进行增减。若是集群中的节点发生了自动扩（缩）容，用户可经过事件检索对整个扩（缩）容过程进行回溯。

在事件检索页面，点击【全局检索】，输入如下检索命令：

event.source.component : "cluster-autoscaler"

在左侧隐藏字段中选择event.reason、event.message、event.involvedObject.name、event.involvedObject.name进行显示，将查询结果按照日志时间倒序排列，结果以下图所示：

经过上图的事件流水，能够看到节点扩容操做在2020-11-25 20:35:45左右，分别由三个 nginx Pod(nginx-5dbf784b68-tq8rd、nginx-5dbf784b68-fpvbx、nginx-5dbf784b68-v9jv5) 触发，最终扩增了3个节点，后续的扩容因为达到节点池的最大节点数没有再次触发。

总结

本文介绍了在 Kubernetes 中两个常常被忽略的元素--「审计日志」和「集群事件」，并讨论了它们在赋能集群运维和提高系统可观测性方面的价值。腾讯云容器团队在长期运维海量 Kubernetes 集群经验总结的基础上，在 TKE 中发布了基于审计和事件的产品服务，帮助用户可以快速高效解决平常集群运维中遇到的问题，将用户从繁杂的集群问题中解放出来。

最后咱们从实战角度出发，经过几个经典问题来演示经过 TKE 审计/事件服务来定位排查问题。因为篇幅有限，咱们的演示只是产品功能的冰山一角，更多的功能须要用户去探索使用，最后欢迎用户体验 。（腾讯云日志服务 CLS 对于 TKE 产生的全部审计/事件数据提供免费服务至 2021年6月1日。）