概述
有時候，集群資源莫名被洗掉或修改，有可能是人為誤操作，也有可能是某個應用的 bug 或惡意程式呼叫 apiserver 介面導致，需要找出 "真兇"，這時候，我們需要為集群開啟審計，記錄 apiserver 的介面呼叫，然后根據條件檢索和分析審計日志來找到原因，
關于 TKE 的集群審計簡介與基礎操作，請參考官方檔案 集群審計，因為集群審計的資料存盤在日志服務，所以我們需要在日志服務控制臺去對審計結果進行檢索和分析，檢索語法請參考 日志檢索語法與規則，要進行分析就還需要寫日志服務所支持的 SQL 陳述句，請參考 日志服務分析簡介，
注: 本文僅適用于 TKE 集群
場景示例
下面給出一些集群審計使用場景和查詢的示例，
找出是誰做的操作
如果節點被封鎖了，不知道是哪個應用或人為操作的，需要查出來，可以在開啟集群審計后，使用下面的陳述句來檢索:
objectRef.resource:nodes AND requestObject:unschedulable
版面設定可以設定顯示 user.username, requestObject 和 objectRef.name 三個欄位，分別表示做操作的用戶、請求內容以及節點名稱:
從上圖可以看出，是 10001****958 這個子賬號在 2020-10-09 16:13:22 的時候對 main.63u5qua9.0 這臺節點進行了封鎖操作，我們在 訪問管理-用戶-用戶串列 里可以根據賬號 ID 找到關于這個子賬號的詳細資訊，
如果某個作業負載被洗掉，想知道是誰洗掉的，這里以 deployments/nginx 為例來查詢:
objectRef.resource:deployments AND objectRef.name:"nginx" AND verb:"delete"
查詢結果:
揪出導致 apiserver 限頻的真兇
apiserver 會有默認的請求頻率限制保護，避免惡意程式或 bug 導致對 apiserver 請求頻率過高，使得 apiserver/etcd 負載過高，影響正常請求，如果發生了限頻，我們可以通過審計來找出到底是誰在發大量請求，
如果我們通過 userAgent 來分析統計請求的客戶端，首先需要修改下日志主題的鍵值索引，為 userAgent 欄位開啟統計:
通過以下 SQL 陳述句進行統計每種客戶端請求 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:
可以看到查到資料了，但可能結果太多，小面板顯示不下，點擊添加到儀表盤，放大顯示:
此例中可以看到 kube-state-metrics 這個客戶端對 apiserver 請求頻率遠遠高于其它客戶端，這就找到了 "真兇" 是 kube-state-metrics，查看日志可以發現是因為 RBAC 權問題導致 kube-state-metrics 不停的請求 apiserver 重試，觸發了 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/[email protected]/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 這樣寫:
* | 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
顯示效果:
小結
本文介紹了如何利用 TKE 的集群審計功能來輔助我們排查問題，給出了一些實踐的例子，
參考資料
- 集群審計官網檔案: https://cloud.tencent.com/document/product/457/48346
- 日志服務檢索語法規則: https://cloud.tencent.com/document/product/614/47044
- 日志服務分析簡介: https://cloud.tencent.com/document/product/614/44061
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/208642.html
標籤：其他
上一篇：容器技術（三）鏡像小結【16】