作者: Imran Noor Mohamed (Delivery Hero)
译者: Kevin Yang
可观测性需要在合适的时间提供合适的数据，以便合适的消费者（人员或软件）做出正确的决策。
在 Kubernetes 的环境中，拥有跨所有 Kubernetes 组件的集群可观测性最佳实践是至关重要的。
SIG Instrumentation 通过提供最佳实践和工具来解决这个问题， 所有其他 SIG 都可以使用它们来对如
API 服务器、kubelet 和 kube-controller-manager 这类 Kubernetes 组件进行插桩。
在这次 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 集群的站点可靠性工程师（site reliability engineer，SRE），
致力于构建我们的可观测性堆栈。我在标签关联方面遇到了一些问题，具体来说是 Kubernetes 的指标与
kube-state-metrics（KSM）不匹配，
因此我开始参加 SIG 会议以改进这些方面。我帮助测试了 kube-state-metrics 的性能改进，
并最终共同撰写了一个关于在 1.14 版本中彻底改进指标以提高其可用性的 KEP 提案。
Imran (INM): 有趣！这是否意味着 SIG Instrumentation 涉及很多的钻研工作？
Han (HK): 我不会说它涉及大量的钻研工作，但它确实触及了基本上每个代码库。
我们有专门的目录用于我们的 metrics、logs 和 tracing 框架，这些是我们要完成的主要工作。
我们必须与其他 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 组织的
Structured Logging
工作组（Working Group，WG）。这个工作组没有自己的代码，但会帮助各个组件（如 kubelet、scheduler
等）迁移它们的代码以使用结构化日志。
Imran (INM): 从章程（charter）来看，
SIG Instrumentation 显然有许多子项目。你能重点说一下其中一些重要的项目吗？
Han (HK): 我们有许多不同的子项目，我们急需能够来协助推动它们的人员。我们最重要的树内（in-tree）项目（即在
kubernetes/kubernetes 代码仓库中）是 metrics、tracing 和 structured logging。
我们最重要的树外（out-of-tree）项目是：（a）KSM（kube-state-metrics）和（b）metrics-server。
Elana (EH): 与上面所说的相呼应，我们希望为 kube-state-metrics 和 metrics-server
引入更多的维护者。我们在 Structure Logging 工作组的朋友也在寻找贡献者。其他子项目包括 klog、prometheus-Adapter，
以及我们刚刚启动的一个用于收集高保真度、可伸缩利用率指标的新子项目，称为
usage-metrics-collector
，它们都在寻找新的贡献者！
现状和持续的挑战
Imran (INM): 在 1.26
版本中，我们可以在流水线中看到有相当数量的关于 metrics、logs 和 tracing 方面的
KEPs。您可否谈谈上个版本中的重要事项
（例如 alpha 和 stable 里程碑的候选项？）
Han (HK): 现在我们可以为 Kubernetes 的 main 代码库中的所有监控指标生成文档！
我们有一个相当不错的静态分析流水线，使这一功能成为可能。
我们还添加了 feature 指标，这样你可以查看这个指标来确定在给定时间内集群中启用了哪些特性。
最后，我们添加了一个 component-sli 端点，它应该使人们为控制平面（control-plane）
组件制定可用性 SLOs 变得容易。
Elana (EH): 我们还在做关于 API 服务器 和 kubelet 的 tracing 方面的 KEPs 工作，
尽管它们都没有在 1.26 版本中毕业。我对于 Han 与可靠性工作组合作，来扩展和改进我们的指标稳定性框架的工作也感到非常兴奋。
Imran (INM): 您认为 SIG Instrumentation 所应对的 Kubernetes 特有挑战有哪些？未来打算如何来解决它们？
Han (HK): SIG Instrumentation 作为一个横向的 SIG 曾经遇到一些困难，我们没有明确的位置来存放我们的代码，
也没有一个良好的机制来审核随意添加的指标。经过多年努力我们已经解决了这个问题，现在我们有了专门的代码存放位置，
并且有可靠的机制来审核新的指标。我们现在还为指标提供稳定性保证。我们希望在 Kubernetes 堆栈上下游进行全面的跟踪，
并通过示例提供指标支持。
Elana (EH): 我认为 SIG Instrumentation 是一个非常有趣的 SIG，因为与其他 SIG
相比，它提供了不同类型的参与机会。您不必是一名软件开发人员就可以为我们的 SIG 做出贡献！
我们的所有组件和子项目都专注于更好地了解 Kubernetes 及其在生产环境中的性能，
这也使得我当时能参与进来并成为少数几个 SRE 身份的 SIG 主席。
我喜欢我们通过使用、测试和提供反馈意见的方式来为新人提供贡献机会，这降低了加入的门槛。
由于这些项目中许多都是 out-of-tree 的，我认为我们面临的挑战之一是确定 Kubernetes 核心
SIGs Instrumentation 子项目的范围并找出缺失的部分，然后填补这些空白。
社区和贡献
Imran (INM): Kubernetes 重视社区胜过重视产品。如果有人想参与 SIG Instrumentation 的工作，
您有什么建议？他们应该从哪里开始（在 SIG 中适合新贡献者的领域？）
Han(HK) and Elana (EH): 参加我们的双周分类会议！
这些会议不会被录制，它们是一个很好的提问的地方并可以了解我们正在进行的工作。我们致力于打造一个友好的社区，
同时也是最容易入门的 SIG 之一。你可以查看我们最新的 KubeCon NA 2022 SIG Instrumentation Deep Dive，
以更深入地了解我们的工作。我们还邀请你加入我们的 Slack 频道 #sig-instrumentation，并随时与我们的
SIG 负责人或子项目所有者直接联系。
非常感谢你抽出宝贵时间并深入了解了 SIG Instrumentation 的工作！
