共計 2209 個字符，預計需要花費 6 分鐘才能閱讀完成。
今天就跟大家聊聊有關如何使用容器服務 TKE 集群審計排查問題，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
概述
有時候，集群資源莫名被刪除或修改，有可能是人為誤操作，也有可能是某個應用的 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/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 這樣寫:
* | 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 集群審計排查問題有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
