概述
有時候,集群資源莫名被刪除或修改,有可能是人為誤操作,也有可能是某個應用的bug或惡意程序調(diào)用apiserver接口導致,需要找出"真兇"。這時候,我們需要為集群開啟審計,記錄apiserver的接口調(diào)用,然后根據(jù)條件檢索和分析審計日志來找到原因。
關于TKE的集群審計簡介與基礎操作,請參考官方文檔集群審計[1]。因為集群審計的數(shù)據(jù)存儲在日志服務,所以我們需要在日志服務控制臺去對審計結(jié)果進行檢索和分析,檢索語法請參考日志檢索語法與規(guī)則[2],要進行分析就還需要寫日志服務所支持的SQL語句,請參考日志服務分析簡介[3]。
注:本文僅適用于TKE集群
場景示例
下面給出一些集群審計使用場景和查詢的示例。
找出是誰做的操作
如果節(jié)點被封鎖了,不知道是哪個應用或人為操作的,需要查出來,可以在開啟集群審計后,使用下面的語句來檢索:
objectRef.resource:nodes AND requestObject:unschedulable
版面設置可以設置顯示user.username,requestObject和objectRef.name三個字段,分別表示做操作的用戶、請求內(nèi)容以及節(jié)點名稱:
從上圖可以看出,是10001****958這個子賬號在2020-10-09 16:13:22的時候?qū)ain.63u5qua9.0這臺節(jié)點進行了封鎖操作,我們在訪問管理-用戶-用戶列表[4]里可以根據(jù)賬號ID找到關于這個子賬號的詳細信息。
如果某個工作負載被刪除,想知道是誰刪除的,這里以deployments/nginx為例來查詢:
objectRef.resource:deployments AND objectRef.name:"nginx"AND verb:"delete"
查詢結(jié)果:
揪出導致apiserver限頻的真兇
apiserver會有默認的請求頻率限制保護,避免惡意程序或bug導致對apiserver請求頻率過高,使得apiserver/etcd負載過高,影響正常請求。如果發(fā)生了限頻,我們可以通過審計來找出到底是誰在發(fā)大量請求。
如果我們通過userAgent來分析統(tǒng)計請求的客戶端,首先需要修改下日志主題的鍵值索引,為userAgent字段開啟統(tǒng)計:
通過以下SQL語句進行統(tǒng)計每種客戶端請求apiserver的QPS大小:
*|SELECT CAST((__TIMESTAMP_US__/1000-__TIMESTAMP_US__/1000%1000)as TIMESTAMP)AS time,COUNT(1)AS qps,userAgent GROUP BY time,userAgent ORDER BY time
切換到圖標分析,選擇折線圖,X軸用time,Y軸用qps,聚合列使用userAgent:
可以看到查到數(shù)據(jù)了,但可能結(jié)果太多,小面板顯示不下,點擊添加到儀表盤,放大顯示:
此例中可以看到kube-state-metrics這個客戶端對apiserver請求頻率遠遠高于其它客戶端,這就找到了"真兇"是kube-state-metrics,查看日志可以發(fā)現(xiàn)是因為RBAC權問題導致kube-state-metrics不停的請求apiserver重試,觸發(fā)了apiserver的限頻:
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
同理,如果要使用其它字段來區(qū)分要統(tǒng)計的客戶端,可以根據(jù)需求靈活修改SQL,比如使用user.username來區(qū)分,SQL這樣寫:
*|SELECT CAST((__TIMESTAMP_US__/1000-__TIMESTAMP_US__/1000%1000)as TIMESTAMP)AS time,COUNT(1)AS qps,user.username GROUP BY time,user.username ORDER BY time
顯示效果:
小結(jié)
本文介紹了如何利用TKE的集群審計功能來輔助我們排查問題,給出了一些實踐的例子。
參考資料
[1]集群審計:https://cloud.tencent.com/document/product/457/48346
[2]日志檢索語法與規(guī)則:https://cloud.tencent.com/document/product/614/47044
[3]日志服務分析簡介:https://cloud.tencent.com/document/product/614/44061
[4]訪問管理-用戶-用戶列表:https://console.cloud.tencent.com/cam