本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG Instrumentation
可觀測性要求在正確的時間為正確的使用者（人或軟體）提供正確的資料，以做出正確的決策。在 Kubernetes 的背景下，為所有 Kubernetes 元件提供叢集可觀測性的最佳實踐至關重要。
SIG Instrumentation 透過提供最佳實踐和工具來幫助解決這個問題，所有其他 SIG 都使用這些工具來監測 Kubernetes 元件，例如 API server、scheduler、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 的效能改進，並最終在 1.14 版本中共同撰寫了一個 KEP，用於徹底改革指標以提高可用性。
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 遷移到結構化日誌記錄，我們成立了結構化日誌記錄工作組（WG），由 Marek 和 Patrick Ohly 組織。該工作組不擁有任何程式碼，但幫助各種元件，如 kubelet、scheduler 等，將它們的代遷移到使用結構化日誌。
Imran (INM)：僅從章程來看，SIG Instrumentation 顯然有很多子專案。您能重點介紹一些重要的子專案嗎？
Han (HK)：我們有許多不同的子專案，我們急需有人來幫助管理它們。我們在樹內（即在 kubernetes/kubernetes 倉庫內）最重要的專案是指標、追蹤和結構化日誌。我們在樹外最重要的專案是 (a) KSM (kube-state-metrics) 和 (b) metrics-server。
Elana (EH)：附議，我們非常希望為 kube-state-metrics 和 metrics-server 引入更多的維護者。我們在結構化日誌工作組的朋友們也在尋找貢獻者。其他子專案包括 klog、prometheus-adapter，以及我們剛剛啟動的一個新子專案，用於收集高保真、可擴充套件的使用率指標，名為 usage-metrics-collector。所有這些專案都在尋找新的貢獻者！
當前狀態和持續的挑戰
Imran (INM)：對於 1.26 版本，我們可以看到有相當數量的指標、日誌和追蹤的 KEP 正在進行中。您想指出上一個版本的重要事項嗎（也許是 alpha 和穩定里程碑的候選者）？
Han (HK)：我們現在可以為 Kubernetes 主程式碼庫中的每一個指標生成文件了！我們有一個相當高階的靜態分析流水線來實現這個功能。我們還添加了功能指標，這樣你就可以透過檢視指標來確定你的叢集在特定時間啟用了哪些功能。最後，我們添加了一個 component-sli 端點，這應該能讓人們更容易地為*控制平面*元件建立可用性 SLO。
Elana (EH)：我們還一直在為 *API server* 和 *kubelet* 開發追蹤 KEP，儘管在 1.26 版本中都沒有畢業。我也對 Han 與 WG Reliability 合作擴充套件和改進我們的指標穩定性框架的工作感到非常興奮。
Imran (INM)：您認為 SIG Instrumentation 解決了哪些 Kubernetes 特有的挑戰？未來將採取哪些措施來解決這些問題？
Han (HK)：SIG Instrumentation 過去因為是一個橫向 SIG 而受到了一些影響。我們沒有一個明確的位置來放置我們的程式碼，也沒有一個好的機制來審計人們隨機新增的指標。多年來我們已經解決了這個問題，現在我們有了專門的程式碼存放位置和可靠的新指標審計機制。我們現在還為指標提供穩定性保證。我們希望在 Kubernetes 堆疊的上下游都有全面的追蹤，並透過 exemplar 支援指標。
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 運作的見解！