这篇文章已超过一年。旧文章可能包含过时的内容。请检查页面中的信息自发布以来是否已失效。
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 同时成为主席。我当时是一名 site reliability engineer (SRE)，负责裸金属 Kubernetes 集群，并致力于构建我们的可观测性堆栈。我遇到了一些 label joins 的问题，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 迁移到结构化日志，我们成立了由 Marek 和 Patrick Ohly 组织的结构化日志工作组 (WG)。工作组不拥有任何代码，但协助各种组件（例如 kubelet、scheduler 等）将其代码迁移以使用结构化日志。
Imran (INM)：仅查看章程就很清楚，SIG Instrumentation 有很多子项目。能否请你们重点介绍一些重要的子项目？
Han (HK)：我们有很多不同的子项目，迫切需要有人来帮助管理它们。我们最重要的 in-tree（即 kubernetes/kubernetes 仓库内）项目是指标、追踪和结构化日志。我们最重要的 out-of-tree 项目是 (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 和 Stable 的里程碑候选项目）？
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 堆栈中实现全面的追踪，并通过 exemplars 支持指标。
Elana (EH)：我认为 SIG Instrumentation 是一个非常有趣的 SIG，因为它提供了与其他 SIG 不同类型的参与机会。你不必是软件开发者也能为我们的 SIG 做出贡献！我们所有的组件和子项目都致力于更好地理解 Kubernetes 及其在生产环境中的性能，这使得我能够参与进来，成为当时少数担任 SIG 主席的 SRE 之一。我喜欢我们为新人提供通过使用、测试和反馈我们的子项目来贡献的机会，这降低了参与门槛。由于这些项目中的许多是 out-of-tree 的，我认为我们的挑战之一是弄清楚核心 Kubernetes SIGs Instrumentation 子项目的范围是什么，缺少什么，然后填补空白。
社区与贡献
Imran (INM)：Kubernetes 重视社区而非产品。对于想要参与 SIG Instrumentation 工作的人，你们有什么建议吗？他们应该从哪里开始（SIG 内对新贡献者友好的领域）？
Han(HK) 和 Elana (EH)：欢迎参加我们每两周一次的分流会议！会议不录制，是提问和了解我们正在进行工作的绝佳场所。我们努力营造一个友好的社区，并且是入门最容易的 SIG 之一。你可以查看我们在 KubeCon NA 2022 上的最新SIG Instrumentation 深度解析，以更深入地了解我们的工作。我们也邀请你加入我们的 Slack 频道 #sig-instrumentation，并随时直接联系我们的任何 SIG 负责人或子项目所有者。
非常感谢你们的时间以及对 SIG Instrumentation 工作的深入见解！