這篇文章已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG Instrumentation
可觀測性需要在正確的時間為正確的消費者(人類或軟體)提供正確的數據,以做出正確的決策。在 Kubernetes 的背景下,針對所有 Kubernetes 組件的集群可觀測性制定最佳實踐至關重要。
SIG Instrumentation 透過提供最佳實踐和工具來幫助解決此問題,所有其他 SIG 都使用這些實踐和工具來檢測 Kubernetes 組件,例如API 伺服器、排程器、kubelet 和 kube-controller-manager。
在這次 SIG Instrumentation 焦點報導中,SIG ContribEx-Comms 技術主管 Imran Noor Mohamed 與 SIG Instrumentation 的主席 Elana Hashman 和 Han Kang 討論了 SIG 的組織方式、當前的挑戰以及任何人如何參與和貢獻。
關於 SIG Instrumentation
Imran (INM):您好,感謝您提供這個機會讓我更了解 SIG Instrumentation。您能談談您自己、您的角色以及您是如何參與 SIG Instrumentation 的嗎?
Han (HK):我於 2018 年加入 SIG Instrumentation,並於 2020 年成為主席。我主要參與 SIG Instrumentation 是因為指標的一些上游問題最終對 GKE 產生了不良影響。因此,我們最終發起了一項倡議,以穩定我們的指標並使指標成為適當的 API。
Elana (EH):我也在 2018 年加入了 SIG Instrumentation,並與 Han 同時成為主席。我當時是一名在裸機 Kubernetes 集群上工作的網站可靠性工程師 (SRE),並且正在努力建構我們的可觀測性堆疊。我遇到了一些標籤連接的問題,其中 Kubernetes 指標與 kube-state-metrics (KSM) 不匹配,因此開始參與 SIG 會議以改進這些問題。我幫助測試了 kube-state-metrics 的效能改進,最終與人合著了一份 KEP,用於在 1.14 版本中徹底修改指標以提高可用性。
Imran (INM):有趣!這是否意味著 SIG Instrumentation 涉及很多底層工作?
Han (HK):我不會說它涉及大量的底層工作,但它確實觸及了幾乎每個程式碼庫。我們有自己的專用目錄用於指標、日誌和追蹤框架,我們主要在這些目錄中工作。我們確實需要與其他 SIG 互動才能傳播我們的變更,這使我們更像是一個橫向 SIG。
Imran (INM):談到與其他 SIG 的互動和協調,您能描述一下 SIG 的組織方式嗎?
Elana (EH):在 SIG Instrumentation 中,我們有兩位主席,Han 和我,以及兩位技術主管,David Ashpole 和 Damien Grisonnet。我們都作為 SIG 的領導者一起工作,以便舉行會議、分類問題和 PR、審查和批准 KEP、規劃每個版本、在 KubeCon 和社群會議上發表演講以及撰寫我們的年度報告。在 SIG 內部,我們還有許多重要的子專案,每個子專案都由其子專案所有者管理。例如,Marek Siarkowicz 是 metrics-server 的子專案所有者。
因為我們是一個橫向 SIG,所以我們的一些專案範圍很廣,需要來自專門的貢獻者群體的協調。例如,為了引導 Kubernetes 遷移到結構化日誌記錄,我們成立了由 Marek 和 Patrick Ohly 組織的 結構化日誌記錄工作組 (WG)。WG 不擁有任何程式碼,但協助各種組件(例如 kubelet、排程器 等)將其程式碼遷移到使用結構化日誌。
Imran (INM):僅僅瀏覽 章程 就很清楚 SIG Instrumentation 有很多子專案。您能重點介紹一些重要的子專案嗎?
Han (HK):我們有許多不同的子專案,並且非常需要人們來幫助管理它們。我們最重要的樹內專案(即在 kubernetes/kubernetes repo 內)是指標、追蹤和結構化日誌記錄。我們最重要的樹外專案是 (a) KSM (kube-state-metrics) 和 (b) metrics-server。
Elana (EH):呼應這一點,我們非常希望為 kube-state-metrics 和 metrics-server 引入更多維護者。我們在 WG Structured Logging 的朋友們也在尋找貢獻者。其他子專案包括 klog、prometheus-adapter 和我們剛剛啟動的一個新子專案,用於收集高保真、可擴展的利用率指標,稱為 usage-metrics-collector。所有這些都在尋找新的貢獻者!
當前狀態和持續的挑戰
Imran (INM):對於 1.26 版本,我們可以看到管道中有很多相關的指標、日誌和追蹤 KEP。您是否想指出上個版本的重要事項(可能是 alpha 和 stable 里程碑候選版本?)
Han (HK):我們現在可以為主要 Kubernetes 程式碼庫中的每個指標生成 文件!我們有一個非常精美的靜態分析管道來實現此功能。我們還添加了功能指標,以便您可以查看您的指標以確定在給定時間在您的集群中啟用了哪些功能。最後,我們添加了一個 component-sli 端點,這應該讓人們可以輕鬆地為控制平面組件創建可用性 SLO。
Elana (EH):我們也一直在為 API 伺服器和 kubelet 開發追蹤 KEP,儘管兩者都沒有在 1.26 版本中畢業。我也對 Han 與 WG Reliability 合作擴展和改進我們的指標穩定性框架的工作感到非常興奮。
Imran (INM):您認為 SIG Instrumentation 解決了哪些 Kubernetes 特有的挑戰?未來解決這些挑戰的努力方向是什麼?
Han (HK):SIG instrumentation 過去作為一個橫向 SIG 受到了一些影響。我們沒有明顯的位置來放置我們的程式碼,也沒有好的機制來審核人們隨機添加的指標。我們多年來已經解決了這個問題,現在我們有專門的位置來放置我們的程式碼,並且有一個可靠的機制來審核新的指標。我們現在還為指標提供穩定性保證。我們希望在整個 kubernetes 堆疊中實現全面的追蹤,並透過 exemplars 提供指標支援。
Elana (EH):我認為 SIG Instrumentation 是一個非常有趣的 SIG,因為它提供了與其他 SIG 不同的參與機會。您不必成為軟體開發人員也能為我們的 SIG 做出貢獻!我們所有的組件和子專案都專注於更好地了解 Kubernetes 及其在生產環境中的效能,這使我能夠作為當時少數幾位擔任 SRE 的 SIG 主席之一參與進來。我喜歡我們為新手提供透過使用、測試和提供對我們子專案的回饋來貢獻的機會,這降低了進入門檻。由於這些專案中有許多是樹外的,我認為我們的挑戰之一是弄清楚核心 Kubernetes SIG instrumentation 子專案的範圍是什麼,缺少什麼,然後填補空白。
社群與貢獻
Imran (INM):Kubernetes 重視社群勝於產品。對於任何想要參與 SIG Instrumentation 工作的人,您有什麼建議嗎?他們應該從哪裡開始(SIG 內對新貢獻者友好的領域?)
Han(HK) 和 Elana (EH):參加我們每週兩次的 triage 會議!這些會議沒有錄製,是提出問題和了解我們正在進行的工作的好地方。我們努力成為一個友善的社群,也是最容易入門的 SIG 之一。您可以查看我們最新的 KubeCon NA 2022 SIG Instrumentation 深度解析,以更深入地了解我們的工作。我們也邀請您加入我們的 Slack 頻道 #sig-instrumentation,並隨時直接聯繫我們的任何 SIG 領導者或子專案所有者。
非常感謝您撥冗分享您對 SIG Instrumentation 運作方式的見解!