如何使用 K8s 兩大利器"審計"和"事件"幫你擺脫運維困境？

概述

下面幾個問題，相信廣大 K8s 用戶在平常集羣運維中都曾經遇到過:

• 集羣中的某個應用被刪除了，誰幹的？
• Apiserver 的負載忽然變高，大量訪問失敗，集羣中到底發生了什麼？
• 集羣節點 NotReady，是什麼緣由致使的？
• 集羣的節點發生了自動擴容，是什麼觸發的？什麼時間觸發的？

之前，排查這些問題，對客戶來講並不容易。生產環境中的 Kubernetes 集羣一般是一個至關複雜的系統，底層是各類異構的主機、網絡、存儲等雲基礎設施，上層承載着大量的應用負載，中間運行着各類原生（例如：Scheduler、Kubelet）和第三方(例如：各類 Operator）的組件,負責對基礎設施和應用進行管理和調度； 此外不一樣角色的人員頻繁地在集羣上進行部署應用、添加節點等各類操做。在集羣運行的過程當中，爲了對集羣中發生的情況可以儘量的瞭如指掌，咱們一般會從多個維度對集羣進行觀測。

日誌，做爲實現軟件可觀測性的三大支柱之一，爲了解系統運行情況，排查系統故障提供了關鍵的線索，在運維管理中起着相當重要的做用。Kubernetes 提供了兩種原生的日誌形式——審計（Audit）和事件（Event），它們分別記錄了對於集羣資源的訪問以及集羣中發生的事件信息。從騰訊雲容器團隊長期運維 K8s 集羣的經驗來看，審計和事件並非無關緊要的東西，善用它們能夠極大的提升集羣的可觀測性，爲運維帶來巨大的便利。下面讓咱們先來簡單認識一下它們。

什麼是 Kubernetes 審計？

Kubernetes 審計日誌是 Kube-apiserver 產生的可配置策略的結構化日誌，記錄了對 Apiserver 的訪問事件。審計日誌提供 Metrics 以外的另外一種集羣觀測維度，經過查看、分析審計日誌，能夠追溯對集羣狀態的變動；瞭解集羣的運行情況；排查異常；發現集羣潛在的安全、性能風險等等。

審計來源

在 Kubernetes 中，全部對集羣狀態的查詢和修改都是經過向 Apiserver 發送請求，對 Apiserver 的請求來源能夠分爲4類

• 控制面組件，例如 Scheduler，各類 Controller，Apiserver 自身
• 節點上的各類 Agent，例如 Kubelet、Kube-proxy 等
• 集羣的其它服務，例如 Coredns、Ingress-controller、各類第三方的 Operator 等
• 外部用戶，例如運維人員經過 Kubectl

審計中都記錄了些什麼？

每一條審計日誌都是一個 JSON 格式的結構化記錄，包括元數據（metadata）、請求內容（requestObject）和響應內容（responseObject）3個部分。其中元數據必定會存在，請求和響應內容是否存在取決於審計級別。元數據包含了請求的上下文信息，例如誰發起的請求，從哪裏發起的，訪問的 URI 等等；

審計有什麼用？

Apiserver 作爲 Kubernetes 集羣惟一的資源查詢、變動入口，審計日誌能夠說記錄了全部對於集羣訪問的流水， 經過它能夠從宏觀和微觀瞭解整個集羣的運行情況，好比：

• 資源被刪掉了，何時刪掉的，被「誰」刪掉的？
• 服務出現問題，何時作過版本變動？
• Apiserver 的響應延時變長，或者出現大量 5XX 響應 Status Code，Apiserver 負載變高，是什麼致使的？
• Apiserver 返回 401/403 請求，到底是證書過時，非法訪問，仍是 RBAC 配置錯誤等。
• Apiserver 收到大量來自外網 IP 對敏感資源的訪問請求，這種請求是否合理，是否存在安全風險；

什麼是Kubernetes事件？

事件（Event）是 Kubernetes 中衆多資源對象中的一員，一般用來記錄集羣內發生的狀態變動，大到集羣節點異常，小到 Pod 啓動、調度成功等等。咱們經常使用的kubectl describe命令就能夠查看相關資源的事件信息。

事件中記錄了什麼？

• 級別（Type）： 目前僅有「Normal」和「Warning」，可是若是須要，可使用自定義類型。
• 資源類型/對象(Involved Object)：事件所涉及的對象，例如 Pod，Deployment，Node 等。
• 事件源（Source）：報告此事件的組件；如 Scheduler、Kubelet 等。
• 內容（Reason）：當前發生事件的簡短描述，通常爲枚舉值，主要在程序內部使用。
• 詳細描述（Message）：當前發生事件的詳細描述信息。
• 出現次數（Count）：事件發生的次數。

事件有什麼用？

集羣內已經翻江倒海，集羣外卻風平浪靜，這多是咱們平常集羣運維中經常遇到的狀況，集羣內的情況若是沒法透過事件來感知，極可能會錯過最佳的問題處理時間，待問題擴大，影響到業務時才發現每每已經爲時已晚；除了早早發現問題，Event 也是排查問題的最佳幫手，因爲 Event 記錄了全面的集羣狀態變動信息，因此大部分的集羣問題均可經過 Event 來排查。總結一下 Event 在集羣中扮演兩大重要角色：

• 「吹哨人」：當集羣發生異常狀況時，用戶可經過事件第一時間感知；
• 「目睹者」：集羣中的大小事件都會經過 Event 記錄，若是集羣中發生意外狀況，如:節點狀態異常，Pod 重啓，均可以經過事件查找發生的時間點及緣由；

TKE 如何發掘審計/事件的價值

傳統的經過輸入查詢語句檢索日誌的方式來使用審計和事件，當然能夠提供很高的靈活性，但也有着較高的使用門檻，不只要求使用者對於日誌的數據結構很是瞭解，還要熟悉 Lucene、SQL 語法。這每每致使使用效率偏低，也沒法充分發掘數據的價值。

騰訊雲容器服務 TKE 聯合騰訊雲日誌服務CLS，打造出針對 Kubernetes 審計/事件採集、存儲、檢索、分析的一站式產品級服務， 不只提供了一鍵開啓/關閉功能，免去一切繁瑣的配置；並且容器團隊還從長期運維海量集羣的經驗中，總結出對於 Kubernetes 審計/事件的最佳使用實踐，經過可視化的圖表，以多個維度對審計日誌和集羣事件進行呈現，使用者只需瞭解 K8s 的基本概念，就能很「直覺」地在 TKE 控制檯上進行各類檢索和分析操做，足以涵蓋絕大多數常見集羣運維場景， 讓不管是發現問題仍是定位問題都事半功倍，提高運維效率，真正將審計和事件數據的價值最大化 。

如何使用 TKE 審計/事件服務去排查問題？

關於 TKE 的集羣審計/事件簡介與基礎操做，請參考集羣審計、事件存儲的官方文檔。

場景示例：

下面咱們看幾個現實中的典型場景

示例1: 排查一個工做負載消失的問題

在審計檢索頁面中，單擊【K8s 對象操做概覽】標籤，指定操做類型和資源對象

查詢結果以下圖所示：

由圖可見，是 10001****7138 這個賬號，對應用「nginx」進行了刪除。可根據賬號ID在【訪問管理】>【用戶列表】中找到關於此帳號的詳細信息。

示例2: 排查一個節點被封鎖的問題

在審計檢索頁面中，單擊【節點操做概覽】標籤，填寫被封鎖的節點名

查詢結果以下圖所示：

由圖可見，是10001****7138這個賬號在2020-1-30T06:22:18時對172.16.18.13這臺節點進行了封鎖操做。

示例3: 排查 Apiserver 響應變慢的問題

在審計檢索的【聚合檢索】標籤頁中，提供了從用戶、操做類型、返回狀態碼等多個維度對於 Apiserver 訪問聚合趨勢圖。

由圖可見，用戶tke-kube-state-metrics的訪問量遠高於其餘用戶，而且在「操做類型分佈趨勢」圖中能夠看出大多數都是 list 操做，在「狀態碼分佈趨勢」圖中能夠看出，狀態

碼大多數爲 403，結合業務日誌可知，因爲 RBAC 鑑權問題致使tke-kube-state-metrics組件不停的請求Apiserver重試，致使 Apiserver 訪問劇增。日誌以下所示：

E1130 06:19:37.368981       1 reflector.go:156] pkg/mod/k8s.io/client-go@v0.0.0-20191109102209-3c0d1af94be5/tools/cache/reflector.go:108: Failed to list *v1.VolumeAttachment: volumeattachments.storage.k8s.io is forbidden: User "system:serviceaccount:kube-system:tke-kube-state-metrics" cannot list resource "volumeattachments" in API group "storage.k8s.io" at the cluster scope

示例4:排查節點異常的問題

一臺 Node 節點出現異常，在事件檢索頁面，點擊【事件總覽】，在過濾項中輸入異常節點名稱

查詢結果顯示，有一條節點磁盤空間不足的事件記錄查詢結果以下圖：

進一步查看異常事件趨勢

能夠發現，2020-11-25號開始，節點172.16.18.13因爲磁盤空間不足致使節點異常，此後 kubelet 開始嘗試驅逐節點上的 pod 以回收節點磁盤空間；

示例5: 查找觸發節點擴容的緣由

開啓了節點池「彈性伸縮」的集羣，CA（cluster-autoscler）組件會根據負載情況自動對集羣中節點數量進行增減。若是集羣中的節點發生了自動擴（縮）容，用戶可經過事件檢索對整個擴（縮）容過程進行回溯。

在事件檢索頁面，點擊【全局檢索】，輸入如下檢索命令：

event.source.component : "cluster-autoscaler"

在左側隱藏字段中選擇event.reason、event.message、event.involvedObject.name、event.involvedObject.name進行顯示，將查詢結果按照日誌時間倒序排列，結果以下圖所示：

經過上圖的事件流水，能夠看到節點擴容操做在2020-11-25 20:35:45左右，分別由三個 nginx Pod(nginx-5dbf784b68-tq8rd、nginx-5dbf784b68-fpvbx、nginx-5dbf784b68-v9jv5) 觸發，最終擴增了3個節點，後續的擴容因爲達到節點池的最大節點數沒有再次觸發。

總結

本文介紹了在 Kubernetes 中兩個常常被忽略的元素--「審計日誌」和「集羣事件」，並討論了它們在賦能集羣運維和提高系統可觀測性方面的價值。騰訊雲容器團隊在長期運維海量 Kubernetes 集羣經驗總結的基礎上，在 TKE 中發佈了基於審計和事件的產品服務，幫助用戶可以快速高效解決平常集羣運維中遇到的問題，將用戶從繁雜的集羣問題中解放出來。

最後咱們從實戰角度出發，經過幾個經典問題來演示經過 TKE 審計/事件服務來定位排查問題。因爲篇幅有限，咱們的演示只是產品功能的冰山一角，更多的功能須要用戶去探索使用，最後歡迎用戶體驗 。（騰訊雲日誌服務 CLS 對於 TKE 產生的全部審計/事件數據提供免費服務至 2021年6月1日。）