roc,腾讯高级工程师,Kubernetes Contributor,热爱开源,专注云原生领域。目前主要负责腾讯云TKE 的售中、售后的技术支持,根据客户需求输出合理技术方案与最佳实践,为客户业务保驾护航。
概述
有时候,集群资源莫名被删除或修改,有可能是人为误操作,也有可能是某个应用的 bug 或恶意程序调用 apiserver 接口导致,需要找出 "真凶"。这时候,我们需要为集群开启审计,记录 apiserver 的接口调用,然后根据条件检索和分析审计日志来找到原因。
关于 TKE 的集群审计简介与基础操作,请参考官方文档 集群审计[1]。因为集群审计的数据存储在日志服务,所以我们需要在日志服务控制台去对审计结果进行检索和分析,检索语法请参考 日志检索语法与规则[2],要进行分析就还需要写日志服务所支持的 SQL 语句,请参考 日志服务分析简介[3]。
注: 本文仅适用于 TKE 集群
场景示例
下面给出一些集群审计使用场景和查询的示例。
找出是谁做的操作
如果节点被封锁了,不知道是哪个应用或人为操作的,需要查出来,可以在开启集群审计后,使用下面的语句来检索:
代码语言:javascript复制objectRef.resource:nodes AND requestObject:unschedulable
版面设置可以设置显示 user.username
, requestObject
和 objectRef.name
三个字段,分别表示做操作的用户、请求内容以及节点名称:
从上图可以看出,是 10001****958
这个子账号在 2020-10-09 16:13:22
的时候对 main.63u5qua9.0
这台节点进行了封锁操作,我们在 访问管理-用户-用户列表[4] 里可以根据账号 ID 找到关于这个子账号的详细信息。
如果某个工作负载被删除,想知道是谁删除的,这里以 deployments/nginx
为例来查询:
objectRef.resource:deployments AND objectRef.name:"nginx" AND verb:"delete"
查询结果:
揪出导致 apiserver 限频的真凶
apiserver 会有默认的请求频率限制保护,避免恶意程序或 bug 导致对 apiserver 请求频率过高,使得 apiserver/etcd 负载过高,影响正常请求。如果发生了限频,我们可以通过审计来找出到底是谁在发大量请求。
如果我们通过 userAgent 来分析统计请求的客户端,首先需要修改下日志主题的键值索引,为 userAgent 字段开启统计:
通过以下 SQL 语句进行统计每种客户端请求 apiserver 的 QPS 大小:
代码语言:javascript复制* | SELECT CAST((__TIMESTAMP_US__ /1000-__TIMESTAMP_US__ /100000) as TIMESTAMP) AS time, COUNT(1) AS qps,userAgent GROUP BY time,userAgent ORDER BY time
切换到图标分析,选择折线图,X 轴用 time,Y 轴用 qps,聚合列使用 userAgent:
可以看到查到数据了,但可能结果太多,小面板显示不下,点击添加到仪表盘,放大显示:
此例中可以看到 kube-state-metrics 这个客户端对 apiserver 请求频率远远高于其它客户端,这就找到了 "真凶" 是 kube-state-metrics,查看日志可以发现是因为 RBAC 权问题导致 kube-state-metrics 不停的请求 apiserver 重试,触发了 apiserver 的限频:
代码语言:javascript复制I1009 13:13:09.760767 1 request.go:538] Throttling request took 1.393921018s, request: GET:https://172.16.252.1:443/api/v1/endpoints?limit=500&resourceVersion=1029843735
E1009 13:13:09.766106 1 reflector.go:156] pkg/mod/k8s.io/client-go@v0.0.0-20191109102209-3c0d1af94be5/tools/cache/reflector.go:108: Failed to list *v1.Endpoints: endpoints is forbidden: User "system:serviceaccount:monitoring:kube-state-metrics" cannot list resource "endpoints" in API group "" at the cluster scope
同理,如果要使用其它字段来区分要统计的客户端,可以根据需求灵活修改 SQL,比如使用 user.username 来区分,SQL 这样写:
代码语言:javascript复制* | SELECT CAST((__TIMESTAMP_US__ /1000-__TIMESTAMP_US__ /100000) as TIMESTAMP) AS time, COUNT(1) AS qps,user.username GROUP BY time,user.username ORDER BY time
显示效果:
小结
本文介绍了如何利用 TKE 的集群审计功能来辅助我们排查问题,给出了一些实践的例子。
参考资料
[1]
集群审计: https://cloud.tencent.com/document/product/457/48346
[2]
日志检索语法与规则: https://cloud.tencent.com/document/product/614/47044
[3]
日志服务分析简介: https://cloud.tencent.com/document/product/614/44061
[4]
访问管理-用户-用户列表: https://console.cloud.tencent.com/cam