k8s - Tony Bai

本文永久链接 – https://tonybai.com/2025/mm/dd/the-voice-of-k8s-experts-report-2025

大家好，我是Tony Bai。

过去的一年，企业 IT 基础架构领域经历了一场剧烈的地震。震中，正是由博通（Broadcom）对 VMware 的收购所引发。这场地震带来的，不仅仅是技术栈的更迭，更是一场关于成本、信任与未来路线的“大迁徙”。

最近，我读到一份来自 Portworx 的《2025 年 Kubernetes 专家之声报告》，它用翔实的数据，为这场正在发生的大迁徙描绘了一幅清晰的路线图。报告中的数字是惊人的：

95% 的受访企业计划减少其 VMware 份额。
33% 的企业计划完全停止使用 VMware。
44% 的企业在续签 ELA（企业许可协议）时，成本增长超过了 100 万美元。

这已经不是零星的抱怨，而是一场由商业驱动的、不可逆转的技术浪潮。一个核心问题摆在了所有架构师面前：当企业决定“逃离” VMware 时，那些承载着核心业务的虚拟机（VMs），将何去何从？

答案，正日益清晰地指向一个我们既熟悉又陌生的方向：Kubernetes。

云原生的新常态：从“试验田”到“核心区”

在讨论 VM 的“新家”之前，我们必须先认清一个事实：Kubernetes 早已不是那个只运行无状态 Web 应用的“试验田”了。

报告数据显示，云原生已经成为企业构建未来的默认选择。82% 的新应用将在云原生平台上构建，更重要的是，58% 的企业已经开始在 Kubernetes 上运行他们最核心的 Tier 0/1 级别的任务关键型应用。

这意味着，Kubernetes 已经赢得了企业在性能、稳定性和数据安全方面的信任。它已经成功承载了：

69% 的数据库
67% 的实时分析系统
60% 的 AI/ML 应用

可以说，Kubernetes 已经“身经百战”，证明了自己有能力处理最复杂、最重要的数据密集型工作负载。这为它成为传统 VM 的下一个归宿，奠定了坚实的基础。

VM 的两条“出路”：现代化 vs 统一管理

当企业决定将 VM 工作负载迁出 VMware 时，报告揭示了两条并驾齐驱的主要技术路线：

1. 路径一：彻底现代化 (Modernize) – 59% 的选择

这是最“纯粹”的云原生路径：将传统的、运行在 VM 中的单体或分层应用，进行重构，将其彻底容器化。这条路的好处是能最大化地享受云原生带来的弹性、敏捷性和可移植性。但挑战也最大，它需要大量的重构工作，成本高昂且周期漫长。

2. 路径二：统一管理 (Consolidate) – 57% 的选择

这是一条更务实、更具变革意义的路径：不改变 VM 本身，而是将 VM 的管理平面，统一到 Kubernetes 之上。

通过使用 KubeVirt（报告指出 Red Hat OpenShift Virtualization 是市场首选）等技术，开发者可以在同一个 Kubernetes 集群里，像管理 Pod 一样，去声明、部署、运维和监控传统的虚拟机。

这一趋势，标志着 Kubernetes 的角色正在发生一次深刻的进化：它不再仅仅是一个“容器编排器”，而是在向“数据中心的通用控制平面”演进。 它旨在用一套统一的、声明式的 API，来管理数据中心里的一切——无论是现代的容器，还是“陈旧”的虚拟机。

新战场的挑战：当 VM 跑在 K8s 上

这场宏大的技术迁徙，并非一路坦途。报告同样揭示了这条路上最难啃的几块“硬骨头”：

最大的挑战是人：技能差距 (Skills Gap) – 61%
传统的 vSphere 管理员面对的是熟悉的图形化界面，而 Kubernetes 的世界则是由 kubectl、YAML 和复杂的命令行构成的。这要求整个基础设施团队进行一次彻底的知识体系和运维模型的迭代，挑战巨大。
最硬的骨头是数据：存储 (Storage) – 69%
这是将有状态应用（包括 VM）迁移到 Kubernetes 上的永恒难题。VM 习惯于稳定、高性能的块存储（如 vSAN、VMFS）。如何在 Kubernetes 的动态环境中，为 VM 提供企业级的存储、数据保护和灾难恢复能力，是最大的技术挑战。报告中提到，85% 的企业希望在 K8s 上能复制他们现有的存储架构，这个需求清晰而迫切。
迁移比想象的更难
报告对比了 2024 年和 2025 年的数据，发现企业完成迁移的预期时间正在普遍推迟。例如，预期在 2027 年前完成迁移的比例，从去年的 83% 下降到了今年的 67%。这 16 个百分点的下降，无声地诉说着这场迁移的复杂性和艰巨性。

小结

由商业决策引发的技术变革，往往最为迅猛和彻底。企业“逃离” VMware，背后是成本压力、现代化需求和摆脱厂商锁定的多重驱动。

在这场浪潮中，Kubernetes 凭借其开放、可扩展和业已成熟的生态，正在成为承接这场“大迁徙”的最终目的地。它正在成为现代基础设施的通用操作系统，统一管理着从最新的云原生应用，到最传统的虚拟机的一切。

对于我们工程师而言，这意味着一个明确的信号：理解如何在 Kubernetes 上管理有状态应用和虚拟机，将不再是一项边缘或小众的技能，它正迅速成为云原生时代一项不可或缺的核心竞争力。 无论你选择帮助企业“现代化”应用，还是选择在 K8s 上“统一管理”VM，未来的机遇，都蕴含在这场波澜壮阔的技术变革之中。

资料链接：https://www.cncf.io/blog/2025/08/02/what-500-experts-revealed-about-kubernetes-adoption-and-workloads/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/07/27/native-prometheus-instrumentation-over-opentelemetry

大家好，我是Tony Bai。

在云原生可观测性的世界里，OpenTelemetry (OTel) 正如日中天。它被誉为“可观测性的未来”，承诺用一个统一的标准，终结 Metrics、Traces、Logs 各自为战的混乱局面。无数的开发者和公司，都在热情地拥抱这个“一次插桩，到处发送”的美好愿景。

但就在这股几乎不可阻挡的浪潮中，一个权威的声音却发出了一个略显刺耳的警告。

这个人，就是 Prometheus 的联合创始人，Julius Volz。

在他最新的博文中，Julius 毫不客气地指出：如果你正在使用 Prometheus 作为你的核心监控系统，并且你真正关心监控的质量和体验，那么，在使用 OpenTelemetry SDK 生成 Metrics 前，请务必三思！

他认为，拥抱 OTel 这个“通用标准”的代价，可能是丢掉 Prometheus 作为一个完整监控系统的“灵魂”，并背上丑陋、低效和复杂的“技术债”。

你正在丢掉 Prometheus 的灵魂

Julius 首先尖锐地指出了一个哲学问题：Prometheus 不仅仅是一个“指标数据库”，它是一个端到端的、有自己思想的监控系统。而 OTel 的“后端无关”设计，恰恰破坏了这种端到端的自洽性。当你选择用 OTel 向 Prometheus 推送数据时，你正在放弃这些至关重要的原生特性：

失去灵魂：Target 健康监控 (up 指标)

Prometheus 最核心的设计之一就是 Pull 模型 + 服务发现。这意味着 Prometheus 主动拉取指标，它清楚地知道“哪些目标应该存在”以及“它们现在是否健康”。如果一个目标拉取失败，Prometheus 会自动生成一个 up{job=”demo”} = 0 的指标。你可以用一条简单的 PromQL 告警规则 up == 0 来发现任何失联的服务。

然而，当你使用 OTel 的 Push 模型时，Prometheus 变成了一个被动的“无情的数据接收器”。它无法再区分一个服务是“正常下线”还是“已经崩溃但没来得及上报”。你可能拥有数百个已经死掉的服务进程，却在监控图表上一无所知。

失去优雅：丑陋的 PromQL 查询

为了兼容 PromQL，OTel 的指标在进入 Prometheus 时，往往需要经过“魔改”。
* 命名冲突： OTel 允许在指标名中使用“.”，而 Prometheus 的传统是不允许的。所以，一个 OTel 指标 k8s.pod.cpu.time 在进入 Prometheus 后，会被翻译成 k8s_pod_cpu_time_seconds_total。这种不一致性会给开发者带来困惑。
* 繁琐的查询语法： 为了支持 OTel 更宽泛的字符集，如果你想查询原始的 OTel 指标名，你的 PromQL 查询会从优雅的 my_metric{…} 变成丑陋的 {“my.metric”, …}。

失去便利：复杂的标签 Join

Prometheus 的 target labels（如 instance, job）会被自动附加到从该目标拉取的所有指标上。而 OTel 的 resource attributes（包含更多非关键元数据）则不会。为了避免高基数问题，大部分 OTel 的资源属性被打包进了一个单独的 target_info 指标里。

这意味着，如果你想在查询时使用这些属性，你必须写出类似下面这样繁琐的 group_left join 查询：

// 想加一个 k8s_cluster_name 标签，查询变得如此复杂
rate(http_server_request_duration_seconds_count[5m])
* on(job, instance) group_left(k8s_cluster_name)
target_info

这些问题，都在不断地增加你的认知负荷和工作复杂度。

性能鸿沟：Go SDK 的“血案”现场

如果说失去优雅和可靠性还不足以让你警醒，那么接下来的硬核性能数据，可能会让你大吃一惊。Julius 特别对比了 Prometheus Go SDK 和 OpenTelemetry Go SDK 在执行最常见操作——计数器递增——时的性能。

结论是毁灭性的。

Julius 的基准测试显示，在不同的并行度和标签缓存条件下：
* 在最坏情况下，Prometheus Go SDK 比 OTel Go SDK 快 26 倍。
* 在有标签缓存的最佳情况下，Prometheus Go SDK 甚至可以比 OTel Go SDK 快 53 倍！
* 更致命的是，Prometheus Go SDK 在所有情况下都实现了零新内存分配，而 OTel SDK 在设置标签时则会持续产生内存分配。

为什么会有如此惊人的差距？
* 复杂性 vs. 专注性： OTel SDK 是一个试图统一三驾马车（Metrics, Traces, Logs）的庞大系统，内部抽象层次多，路径长。而 Prometheus SDK 的目标极其单一和专注：用最高效的方式生成 Prometheus 指标。
* 主观代码体验： Julius 更是用一个生动的例子佐证了这一点——他想在两个 SDK 中找到核心的 Inc() 函数实现。在 Prometheus Go SDK 中，他花了 5 秒；而在 OTel Go SDK 中，他在复杂的抽象和间接调用中迷失了 15 分钟后，最终放弃了。

对于性能至关重要的 Go 后端服务来说，选择 OTel SDK 进行指标插桩，无异于在你的性能快车道上，悄悄地铺上了一层厚厚的沥青。

结论：在“通用标准”与“原生体验”之间做出选择

Julius 的文章并非是否定 OpenTelemetry 的价值。OTel 作为一个中立的、后端无关的“可观测性瑞士”，在构建异构系统、避免厂商锁定的场景中，依然具有不可替代的战略意义。

但他的警告是在提醒我们一个深刻的权衡：
* OpenTelemetry 的世界观： 追求最大的通用性和互操作性。它是一个数据生成和传输的标准，它不关心数据最终如何被使用。
* Prometheus 的世界观： 追求一个深度整合、端到端优化的系统体验。它的每一个设计——从 Pull 模型到 PromQL 语法——都在为最终用户能以最优雅、最高效的方式进行监控和告警服务。

如果你已经选择 Prometheus 作为你的核心监控“城邦”，那么使用它原生的客户端库，并非是选择“封闭”，而是选择一个经过千锤百炼的、高度自洽的、性能卓越的解决方案。

所以，在你为下一个 Go 项目 go get OTel SDK 之前，请先问自己一个问题：我是在追求一个“放之四海而皆准”的通用标准，还是在追求一个能将我的核心工具发挥到极致的原生体验？

答案，可能决定了你未来无数个夜晚的睡眠质量。

资料链接：https://promlabs.com/blog/2025/07/17/why-i-recommend-native-prometheus-instrumentation-over-opentelemetry/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？