对 K8s 异常事件的定时 SQL 分析

K8s 事件简介

K8s 是基于状态机的设计，在不同状态之间迁移时会生成事件。正常的状态间转换会生成 Normal 事件，从正常状态转换为异常状态则会生成 Warning 事件。

使用 K8s 集群，我们关注业务、容器、集群三个层面稳定性，最基础的依赖是 K8s node 要稳定。可能影响 pod 运行的节点问题包括：

基础设施：ntp 服务不可用、网络故障等。硬件：例如 CPU、内存、磁盘故障，使用 IaaS 会大大降低这类问题发生概率。OS：Kernel deadlock，文件系统损坏等。Container Runtime：例如 docker engine hang。其它。

阿里云容器服务（ACK）提供开箱即用的容器场景事件监控方案，通过 NPD（node-problem-detector）以及 kube-eventer 提供容器节点的事件采集、存储能力。

NPD 是 K8s 集群节点异常事件监控组件，可以将 NPD 以 DaemonSet 或独立守护程序运行。用于监视和报告节点的健康状况，并将事件报告给 API Server。kube-eventer 是 ACK 维护的 K8s 事件开源工具，可以将集群事件转储到钉钉、SLS、EventBridge 等系统，并提供不同等级的过滤条件，实现事件的实时采集、定向告警、异步归档。

阿里云日志服务（SLS）是云原生观测分析平台，为 Log/Metric/Trace 等数据提供大规模、低成本、实时平台化服务，支持数据采集、加工、分析、告警可视化与投递功能，帮助提升研发、运维、运营和安全等场景数字化能力。

使用 ACK 事件中心，设置 Sink 参数将 K8s 事件数据采集到 SLS，样例如下：

k8s.io/api/core/v1/types.go 对事件结构进行了定义，其中几个重要的字段是：

Message：当前操作对应状态的详细描述。Reason：事件描述的简短枚举值。Involved Object：事件所关联的对象，例如 Pod，Deployment，Node 等。Source：汇报事件的模块，例如 kube-scheduler、kubelet 等。Type：目前只有两种类型，Normal 或 Warning。Count：事件发生的次数。异常事件分析

以一个中型（~100 台） K8s 生产集群的为例，在 SLS 上通过 SQL 代码统计一天里 Pod 创建、启动次数的时间趋势：

eventId.reason:Created or eventId.reason:Started | select from_unixtime(__time__ - __time__ % 60) as dt, "eventId.reason" as action, sum(cast("eventId.count" as bigint)) as event_count group by dt, action order by dt asc limit 10000

看到会有 burst 情况，对于 K8s 集群稳定性是一个挑战：

通过 SQL 代码统计不同事件类型关联的 Pod 数目分布：

* | select reason, count(DISTINCT "eventId.involvedObject.name") as object_count group by reason order by object_count desc limit 100

发现有少量 Failed、DeadlineExceeded、FailedMount、FailedCreatePodSandBox 等异常事件，这些需要引起关注：

如何将这类事件分析操作变成一种常态化的工作，本文介绍一种周期性 SQL 计算方案。要实现：

优化事件中心长期存储（3个月以上）成本，对冷数据做降精度存储。对长周期（例如时间跨度 1 个月以上）统计分析做响应延时优化，将全量数据计算拆分为多次增量计算。

具体来说，是将 SQL 分析从控制台上的交互式操作转变为后台任务的周期性运行，得到一个个时间区间的统计值，将这些统计结果写入存储库，达到如下效果：

统计结果直接存储下来，可被多种下游系统直接使用，例如可视化大盘、告警监控、入库数仓等。通过周期性计算任务相当于预先构建了 Cube，查询引擎在目标库的数据上计算，由于要处理的数据量大大降低，达到秒开的效果。全量 K8s 事件随着时间推移，需要的存储量持续增加。在有了降维后的目标库数据后，如果不需要原文做问题调查，存储原文的日志库可以缩短存储周期。Scheduled SQL 实践

Scheduled SQL 是一项由 SLS 全托管的功能，解决场景需求包括：

定时分析数据：根据业务需求设置 SQL 语句或查询分析语句，定时执行数据分析，并将分析结果存储到目标库中。全局聚合：对全量、细粒度的数据进行聚合存储，汇总为存储大小、精度适合的数据，相当于一定程度的有损压缩数据。

本节演示通过 Scheduled SQL 完成对 K8s 异常事件的定时分析及结果存储。

分析预览

在 k8s-event 日志库上，过滤 Normal 级别事件，按照 namespace、object 类型、事件类型分组统计：关联的 object 数目、事件数目、关联的节点数目。

SQL 代码如下：

* not level : Normal | select "eventId.involvedObject.namespace" as namespace, "eventId.involvedObject.Kind" as kind, reason, arbitrary(message) as msg, count(DISTINCT "eventId.involvedObject.name") as object_count, sum(cast("eventId.count" as bigint)) as event_count, count(distinct hostname) as host_count group by namespace, kind, reason order by event_count desc

在 SLS 控制台上分析预览：

确认结果符合预期后，点击按钮创建 Scheduled SQL 作业。

计算配置

资源池有免费（Project 级别 15 并行度）、增强型（收费，但资源可扩展，适用于大量计算且有 SLA 要求的业务场景）两种，按照你的需求来设置即可。

关于目标库（k8s_event_errors），注意提前为目标库准备好索引：

调度配置

设置 SQL 每天执行一次，查询前一天零点到当前零点时间窗口内的数据。因为上游事件数据到来可能延迟，这里设置 120 秒延迟等待来保证计算数据的完整性。

实例查看、管理

在控制台上查看刚才创建的 Scheduled SQL 作业，作业管理页面内可以查看到每一次执行的实例列表。

每个实例信息中有 SQL 查询区间，如果任务失败（权限、SQL 语法等原因）或 SQL 处理行数指标为 0（数据迟到或确实没有数据），可以对指定实例做重试。

效果

通过 Scheduled SQL 计算后的数据格式如下：

结果数据集的规模大大降低了，做一年时间范围的数据分析也没有压力，这里有两个例子。

按 namespace 统计异常事件的时间趋势

SQL 代码：

* | select from_unixtime(__time__) as dt, namespace, sum(object_count) as objects group by dt, namespace order by dt asc limit 100000

可视化图表：

按 object 类型统计异常事件的时间趋势

SQL 代码：

* | select from_unixtime(__time__) as dt, kind, sum(object_count) as objects group by dt, kind order by dt asc limit 100000

可视化图表：

更多内容请参考：

使用Kubernetes事件中心，采集事件到 SLS

使用 Scheduled SQL 定时分析事件数据

本文转自网络，原文链接：https://developer.aliyun.com/article/786158
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！