本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
聚焦 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 运作的见解！