概述
下面幾個問題，相信廣大 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/[email protected]/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日，）
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/231376.html
標籤：其他