技术志 - Tony Bai

后VMware时代：为什么Kubernetes正在成为VM的新家？

本文永久链接 – 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技能再上一个新台阶！

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

从“锁”到“channel”：开启你的Go并发心智模型转变之旅

本文永久链接 – https://tonybai.com/2025/08/05/go-concurrency-mental-model

大家好，我是Tony Bai。

如果你曾是 Java、C++ 或 Python 阵营的一员，你一定对 synchronized、std::mutex 或 threading.Lock 这些概念驾轻就熟。它们就像我们工具箱里熟悉的锤子，在处理并发问题时，我们总能下意识地拿起它，去“敲定”那些需要保护的共享资源。

然而，当你满怀期待地步入 Go 的世界，准备大展拳脚时，却发现社区和高手们总在谈论一个看似“绕路”的概念——通道 (Channel)。他们反复强调一句如同“咒语”般的箴言：“不要通过共享内存来通信；相反，要通过通信来共享内存。”

这时，困惑便产生了：

“放着简单直接的锁不用，为什么要用看起来更复杂的 Channel？”
“Channel 和 Mutex 到底该在什么场景下选择？有没有一个万能的法则？”
“我用 Go 写的并发程序，为什么总感觉不地道，甚至比我用 Java 写的还容易出错？”

如果你曾有过这些疑问，那么恭喜你，你已经触及了掌握 Go 并发精髓的核心症结。问题不在于 Go 的语法有多难，而在于我们试图用旧的“心智模型”去套用一个全新的并发范式。这就像试图用拉丁语的语法去理解中文的意境，生硬的翻译只会让你离真相越来越远。

这个微专栏，就是为你——一位从其他编程语言阵营走来，希望真正掌握 Go 并发精髓的开发者——量身打造的“心智模型”转变教程。

在这里，我不会枯燥地罗列 API，也不会给你一堆零散的“最佳实践”。我的目标是带你完成一次思维的“破冰”与“重塑”。在这次由三节课组成的“转变之旅”中，我们将一起：

第一课：心智模型转变。 我们将从根源上剖析 Go 并发哲学的不同，通过一个具象的案例，亲身体验从“加锁”思维到“通道通信”思维的转变是多么酣畅淋漓。你将明白，为何 Channel 才是 Go 并发世界的一等公民。
第二课：心智模型实践。 我们会将新的心智模型应用到工业界最常见的并发模式中，并直面、破解“慢消费者”和“任务调度”这两个经典难题。
第三课：心智模型升华。 我们将探讨并发编程中最容易被忽视，也最致命的一环——Goroutine 的生命周期与工程纪律。你将学会如何避免资源泄漏，如何优雅地控制和关闭你的并发程序。