Kubernetes - Tony Bai

标签 Kubernetes 下的文章

Go 2025云原生与可观测年度报告：底层性能革新与生态固防

十二月 3, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/12/03/go-2025-cloud-native-observability-report

大家好，我是Tony Bai。

2025年，对于 Go 语言和云原生生态来说，是充满挑战与变革的一年。

凭借务实的并发模型、极快的编译速度和极简的部署体验，Go 语言在过去十年间毫无争议地坐稳了现代云原生基础设施的“铁王座”。从 Kubernetes 到 Docker，从 Prometheus 到 etcd，CNCF 生态中那些最耀眼的明星项目，几乎都流淌着 Go 的血液。

但技术世界没有永远的王座。2025年，面对日益复杂的云原生挑战——如容器资源的极致限制、大规模并发状态管理，以及来自 Rust 等追求极致性能的新生代语言的“围剿”——Go 语言并非高枕无忧。

面对挑战，Go 在 2025 年交出了一份怎样的答卷？它是如何通过 Go 1.25 的底层性能革新、Kubernetes 的架构演进以及 OpenTelemetry 的生态防御来巩固壁垒的？

本文将带你全景式复盘 Go 语言在 2025 年的硬核反击战。

底层突破：Go 1.25 为云原生带来的“性能红利”

所有上层应用的性能飞跃，都源自底层的坚实支撑。面对“性能不够极致”的质疑，2025年8月发布的 Go 1.25 祭出了近年来针对云原生场景最“贴心”的三大杀招，直接回击了对 Go 运行时的效率诟病。

Cgroup 智能感知：终于读懂了容器的心

长期以来，Go 应用在容器中运行时有一个痛点：GOMAXPROCS 默认会“误以为”自己拥有宿主机的所有逻辑 CPU 资源。当容器被 Cgroup V2 严格限制了 CPU 配额（Quota）时，Go 运行时仍会创建过多的系统线程，导致严重的上下文切换（Context Switching）和性能抖动。

Go 1.25 终于引入了 Cgroup-Aware GOMAXPROCS。Go 运行时现在能周期性地自动检测容器的 Cgroup CPU 配额，并动态调整内部的并发级别。这直接减少了无谓的线程争用，让运行在 Kubernetes Pod 中的 Go 服务（尤其是那些资源受限的 Sidecar 或 Agent）无需人工调优即可获得更稳定、更高效的表现。

GreenTea GC：向“GC 暂停”宣战

为了应对高吞吐量场景下的延迟敏感需求，Go 1.25 带来了实验性的 GreenTea GC。这是一款专门针对“小对象密集型”应用（如日志收集器、OpenTelemetry Collector、K8s 控制器）进行优化的垃圾回收器。

GreenTea GC 改进了内存局部性，并大幅提高了标记阶段的并行性。在典型负载下，总体 GC 开销降低约 40%，显著改善了 P99 尾部延迟。这是 Go 在面对 Rust “零成本抽象”挑战时的一次强力技术回应，证明了带 GC 的语言在高性能领域依然能打。

JSON/v2：零内存分配的极速体验

标准库中的 encoding/json 曾是著名的性能瓶颈，其依赖运行时的反射机制导致了较高的 CPU 和内存消耗。Go 1.25 重写的 encoding/json/v2 彻底改变了这一局面。这次重写带来了 3-10 倍 的反序列化速度提升，并实现了关键的“零堆内存分配”特性。对于 Kubernetes API Server 这种每天处理海量 JSON 配置和状态更新的组件来说，这意味着巨大的 CPU 周期节省和内存压力释放，直接提升了整个集群控制平面的吞吐上限。

基础设施：Kubernetes 与容器运行时的演进

Kubernetes v1.35：更聪明的 AI 调度

作为 Go 语言的“长子”，Kubernetes 在 2025 年 11 月迎来了 v1.35 版本。除了常规的稳定性提升，最引人注目的是其调度器针对 AI/ML 工作负载的进化。这意味着 K8s 能够更精细地处理 AI 训练任务对 GPU、内存等资源的苛刻要求，实现基于阈值的资源匹配。Go 语言高效的并发模型支撑了这一日益复杂的调度逻辑。

同时该新版本还引入了基于阈值的Extended Toleration Operators，新增了 Gt (大于) 和 Lt (小于) 等逻辑。

除了 v1.35 的调度增强，K8s 在 2025 年上半年的两个版本中也引入了多项值得关注的改进：

DRA (Dynamic Resource Allocation) 走向稳定：在 v1.34 中，DRA 的核心 API 将升级为 Stable。这为 GPU 等硬件加速器提供了更加灵活、标准化的资源请求和分配机制，摆脱了过去对非透明参数的依赖。
Sidecar 容器支持增强：虽然 Service Mesh 正在去 Sidecar 化，但 K8s 本身对 Sidecar 的原生支持却在加强。v1.33 引入了 In-place Pod Resize（原地调整 Pod 资源）的 Beta 支持，允许在不重启 Pod 的情况下动态调整容器的 CPU/内存限制，这对有状态应用和长连接服务至关重要。
安全性加固：v1.33 默认启用了对 Linux Pod 的 User Namespaces 支持，显著降低了容器逃逸风险；同时，kubelet 开始支持使用 ServiceAccount Token 拉取镜像，逐步淘汰长期的 Image Pull Secrets。

容器运行时：containerd vs. CRI-O 的双雄格局

在彻底移除 dockershim 后，容器运行时生态形成了双雄并立的局面，且均由 Go 语言驱动：
* containerd：功能全面、极其稳定，支持镜像管理、零停机更新，是 AWS EKS、Google GKE 等云厂商的默认首选。
* CRI-O：极简主义，专为 K8s 设计，启动更快，资源占用更低，适合边缘计算等对资源敏感的场景。

警钟长鸣：containerd 内存泄露事件

2025 年 11 月披露的 containerd 漏洞 (CVE-2025-64329) 给 Go 开发者敲响了警钟。该漏洞存在于 CRI Attach 实现中，用户重复调用 kubectl attach 可能导致 Goroutine 泄露，进而耗尽宿主机内存。这也反向推动了 Go 运行时可观测性的重要性（详见下文）。即便是内存安全的语言，如果并发控制不当，依然会导致资源枯竭。

Operator 的安全模型升级

Kubernetes Operator 是 Go 生态的另一大杀手锏。2025 年，Operator SDK 和 Kubebuilder 终于移除了对外部 kube-rbac-proxy 的依赖，转而使用 controller-runtime 库内置的 WithAuthenticationAndAuthorization 功能。指标端点（Metrics Endpoint）的安全保护逻辑被直接集成在 Go 代码的控制循环中。其带来的价值是架构更简单，攻击面更小，部署 Operator 变得“默认安全”。

架构演进：Service Mesh 与 Serverless 的新篇章

Istio Ambient Mesh：全面去 Sidecar 化

服务网格正在经历一场革命。2025 年，Istio 全力推广 Ambient Mesh 模式，旨在移除侵入式的 Sidecar 代理，提供更轻量、更快速的体验。
* 控制平面：Go 语言编写的控制平面（Istiod）在其中扮演了指挥官的角色，负责管理这一新型架构。
* 多集群突破：Istio 1.27 (Alpha) 引入了 Ambient 模式下的多集群流量管理，允许企业以Active-Active 模式运行高可用服务，利用 Go 驱动的控制逻辑优化跨区域流量成本。

Knative 毕业：Serverless 的成熟里程碑

2025 年 10 月，Knative 正式从 CNCF 毕业，标志着 Go 语言构建的 Serverless 抽象层已经完全成熟。Knative Eventing 新增了 RequestReply 资源，加强了同步与异步工作负载之间的桥接能力，进一步巩固了 Go 在构建复杂事件驱动架构（EDA）中的统治地位。

Go 在 IaC 中的隐形统治

在基础设施即代码（IaC）领域，虽然 Terraform (HCL) 占据前台，但如 Pulumi 和 AWS CDK 等开发者优先平台，正大量利用 Go 语言的静态类型优势和丰富的库生态作为后端逻辑支撑，提升了 IaC 的测试能力和抽象水平。

可观测性：OpenTelemetry 的“默认稳定”战略

OTel Go SDK：从“可用”到“默认稳定”

OpenTelemetry (OTel) 是云原生可观测性的事实标准。2025 年 11 月，OTel 治理委员会宣布了战略调整：确保所有分发版“默认稳定” (stable by default)。

同时，OTel Go SDK 的 Traces 和 Metrics 组件均已达到 Stable 状态，Logs SDK 处于 Beta。这标志着 Go 生态的可观测性基石已完全成熟，企业可放心在生产环境大规模部署。

运行时指标：从“Opt-In”到“Opt-Out”

为了更好地诊断像 containerd 内存泄露这样的问题，OTel Go SIG 正在推进一项关键变更：将 Go Runtime Metrics（如 GC 暂停时间、堆内存使用、Goroutine 数量）从“选择性开启”改为“默认开启” (Opt-Out)。这意味着运维人员能“开箱即用”地看到 Go 应用的内部健康状况，配合 OTel 的语义惯例，能够更早地发现由 GC 或并发引起的潜在风险。

配置简化：YAML/JSON 文件支持

为了降低在 K8s 中的部署难度，OTel Go SDK 正在增强对 YAML/JSON 文件配置的支持，改变了过去过度依赖环境变量的局面，提升了配置的灵活性和易用性。

里程碑：OpenTelemetry eBPF Instrumentation (OBI) 正式发布

2025 年 11 月，OpenTelemetry 社区迎来了一个重磅时刻：OpenTelemetry eBPF Instrumentation (OBI) 发布了首个 Alpha 版本。

零侵入，全覆盖：OBI 利用 eBPF 技术在内核层进行观测，无需修改代码、无需重启服务、无需引入任何应用依赖，即可实现对 HTTP, gRPC, SQL (MySQL, PostgreSQL), Redis, Kafka 等多种协议的自动追踪和指标采集。
多语言一致性：无论你的应用是 Go, Java, Python 还是 Node.js 编写的，OBI 都能提供统一、标准的遥测数据。这对于那些包含遗留系统或多语言技术栈的企业来说，是实现全链路可观测性的“银弹”。
与 SDK 的互补：OBI 并非要取代传统的 SDK 插桩。它更适合作为“基线”观测手段，快速覆盖所有服务；而对于需要深入应用内部逻辑（如业务埋点、复杂上下文传播）的场景，结合使用 OTel Go SDK 依然是最佳实践。

巅峰对决：Go vs. Rust 在 2025

我们在这里回答前面的问题：面对 Rust 的围剿，Go 守住了吗？

Go 的基本盘（铁王座）：在控制平面（Control Plane）、API 网关、K8s Operator 以及企业级微服务等需要快速迭代、高并发协作的领域，Go 依然是绝对王者。其极低的心智负担、极高的开发效率和成熟的生态，是 Rust 短期内难以撼动的。
Rust 的突围（特种兵）：在数据平面（Data Plane）（如 Envoy 插件）、高性能计算等对内存安全和尾部延迟有苛刻要求的领域，Rust 凭借“零 GC”和编译期内存安全检查，确实撕开了一道口子，比 Go 快约 1.5 倍，且没有 GC 抖动。

2025 年的格局：Go 没有坐以待毙。通过 GreenTea GC 降低 40% 的 GC 开销，通过 JSON/v2 消除反射带来的性能损耗，Go 正在努力拉高性能下限，防止被 Rust 侵蚀核心领地。对于大多数云原生应用来说，Go 依然是综合成本（开发效率+运行效率）最低、最稳妥的选择。

总结与建议

2025 年，Go 语言没有停下脚步。通过 Go 1.25 的底层革新，它补齐了在容器化环境和 JSON 处理上的短板；通过 K8s 和 OTel 的持续演进，它在云原生生态中构建了更坚固的防线。

面对 Rust 的围剿，Go 不仅守住了铁王座，还通过自我进化，让这个王座变得更加稳固。

给技术团队的建议：

尽快升级：将核心服务升级到 Go 1.25+，白嫖 Cgroup 感知和 JSON 性能提升，这对于降本增效立竿见影。
拥抱 OTel：采用 OpenTelemetry Go SDK(虽然有些复杂^_^)，并利用默认开启的运行时指标，建立更精细的监控体系，防范 Goroutine 泄露等隐形杀手。
理性选型：对于绝大多数业务服务和控制平面，坚持使用 Go；只有在极少数对延迟极其敏感、且逻辑相对稳定的数据平面组件中，才考虑引入 Rust。

Go 的 2025，是稳中求进、自我革新的一年。云原生的未来，依然写满了 Go 的名字。

参考资料

本文基于 2025 年多份权威技术报告与社区动态整理而成，涵盖 CNCF、Go 官方博客、Kubernetes 发布说明及 OpenTelemetry 社区公告等。

Golang in 2025: Usage, Trends, and Popularity - Medium, accessed November 28, 2025, https://medium.com/@datajournal/golang-in-2025-usage-trends-and-popularity-3379928dd8e2
The Go Ecosystem in 2025: Key Trends in Frameworks, Tools, and Developer Practices, accessed November 28, 2025, https://blog.jetbrains.com/go/2025/11/10/go-language-trends-ecosystem-2025/
Go: Driving The Next Wave of Cloud-Native Infrastructure - Open Source For You, accessed November 28, 2025, https://www.opensourceforu.com/2025/11/go-driving-the-next-wave-of-cloud-native-infrastructure/
Go 1.25 Highlights: How Generics and Performance Define the …, accessed November 28, 2025, https://dev.to/leapcell/go-125-highlights-how-generics-and-performance-define-the-future-of-go-4pdh
Kubernetes v1.35 Sneak Peek, accessed November 28, 2025, https://kubernetes.io/blog/2025/11/26/kubernetes-v1-35-sneak-peek/
Kubernetes v1.35 Release Highlights #2903 - GitHub, accessed November 28, 2025, https://github.com/kubernetes/sig-release/discussions/2903
Top Docker Alternatives in 2025: A Complete Guide - DataCamp, accessed November 28, 2025, https://www.datacamp.com/blog/docker-alternatives
15 Best Docker Alternatives for 2025: Complete Guide with Pros, Cons & Migration, accessed November 28, 2025, https://signoz.io/comparisons/docker-alternatives/
CVE-2025-64329: containerd CRI server: Host memory exhaustion through Attach goroutine leak - GitLab Advisory Database, accessed November 28, 2025, https://advisories.gitlab.com/pkg/golang/github.com/containerd/containerd/v2/CVE-2025-64329/
CVE-2025-64329: containerd CRI Attach Memory DoS - Miggo Security, accessed November 28, 2025, https://www.miggo.io/vulnerability-database/cve/CVE-2025-64329
operator-framework/operator-sdk: SDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding. - GitHub, accessed November 28, 2025, https://github.com/operator-framework/operator-sdk
Repo for the controller-runtime subproject of kubebuilder (sig-apimachinery) - GitHub, accessed November 28, 2025, https://github.com/kubernetes-sigs/controller-runtime
Metrics - The Kubebuilder Book, accessed November 28, 2025, https://book.kubebuilder.io/reference/metrics.html?highlight=metr
Istio / Istio Roadmap for 2025-2026, accessed November 28, 2025, https://istio.io/latest/blog/2025/roadmap/
Cloud Native Computing Foundation Announces Knative’s Graduation | CNCF, accessed November 28, 2025, https://www.cncf.io/announcements/2025/10/08/cloud-native-computing-foundation-announces-knatives-graduation/
The 16 Best Infrastructure As Code (IaC) Tools In 2025 - Apiiro, accessed November 28, 2025, https://apiiro.com/blog/best-iac-tools/
Evolving OpenTelemetry’s Stabilization and Release Practices, accessed November 28, 2025, https://opentelemetry.io/blog/2025/stability-proposal-announcement/
Go - OpenTelemetry, accessed November 28, 2025, https://opentelemetry.io/docs/languages/go/
OpenTelemetry Go 2025 Goals, accessed November 28, 2025, https://opentelemetry.io/blog/2025/go-goals/
Configuration - OpenTelemetry, accessed November 28, 2025, https://opentelemetry.io/docs/collector/configuration/
Prometheus with Grafana: 5 Compelling Use Cases - Tigera.io, accessed November 28, 2025, https://www.tigera.io/learn/guides/prometheus-monitoring/prometheus-grafana/
Top Prometheus Exporters in 2025 and How to Use Them Effectively - GoCodeo, accessed November 28, 2025, https://www.gocodeo.com/post/top-prometheus-exporters-in-2025-and-how-to-use-them-effectively
Rust vs Go in 2025: Comparison of Performance, Complexity, and …, accessed November 28, 2025, https://evrone.com/blog/rustvsgo
Rust vs Go: Which one to choose in 2025 | The RustRover Blog, accessed November 28, 2025, https://blog.jetbrains.com/rust/2025/06/12/rust-vs-go/
Your Complete Guide to KubeCon + CloudNativeCon North America 2025 | CNCF, accessed November 28, 2025, https://www.cncf.io/blog/2025/11/06/your-complete-guide-to-kubecon-cloudnativecon-north-america-2025/

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

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

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

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

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

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

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

13万节点！Google 如何打破 Kubernetes 的物理极限，构建全球最大集群

十一月 26, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/11/26/how-google-built-a-130000-node-k8s-cluster

大家好，我是Tony Bai。

Kubernetes 的官方支持上限通常被认为是 5,000 到 15,000 节点。然而，在 AI 时代的算力军备竞赛中，这个数字显得有些“捉襟见肘”。

近日，Google Cloud 发布了一份重磅技术报告，揭示了他们如何在 GKE (Google Kubernetes Engine) 上成功运行了一个130,000 节点的超大规模集群——这是目前已知全球最大的 Kubernetes 集群，其规模是 GKE 官方支持上限（65,000 节点）的两倍，更是开源 Kubernetes 社区上限的近十倍。

这不是一次规模的堆砌，而是一次涉及控制平面、调度器、存储和网络的系统级工程实践，极具参考价值。Google 是如何做到的？让我们深入其架构内部，一探究竟。

背景：AI 时代的“巨兽”需求

推动这一极限挑战的核心动力，是日益庞大的 AI 工作负载。随着大模型训练对算力需求的指数级增长，客户不再满足于万卡集群，而是向着 10万节点 的规模进军。

在这个量级下，挑战不仅来自芯片的短缺，更来自电力和数据中心的物理限制。一个拥有数万块高性能 GPU 的集群，其功耗可能高达数百兆瓦，必须跨越多个数据中心部署。这要求 Kubernetes 不仅要管理庞大的资源，还要具备跨故障域、跨数据中心的极致编排能力。

核心创新：四大技术支柱

为了支撑起这座“13万节点”的摩天大楼，Google 对 Kubernetes 的底层架构进行了四项关键的“手术”。

1. 读操作的极致优化：一致性缓存

在 13 万节点的集群中，数以百万计的 Pod 和对象会产生海量的 API 请求。如果所有读请求都直接打到 etcd（或 GKE 使用的 Spanner），数据库瞬间就会被压垮。

Google 的解决方案是：让 API Server 直接从内存缓存中服务读请求，同时保证强一致性。

具体来说，就是通过引入 Consistent Reads from Cache (KEP-2340)，API Server 可以利用其内存中的 Watch Cache 来服务 GET 和 LIST 请求。

系统会确保缓存中的数据在服务请求前是可验证的最新状态（verifiably up-to-date），从而在不牺牲一致性的前提下，大幅降低了底层数据库的压力。

同时，通过 Snapshottable API Server Cache (KEP-4988)，API Server 甚至可以直接从内存中构建 B-tree 快照，来服务带有 resourceVersion 的历史数据查询，彻底消除了“读放大”问题。

2. 存储后端的无限扩展：基于 Spanner 的分布式键值存储

标准的 Kubernetes 使用 etcd 作为存储后端，但在 13 万节点的规模下，etcd 的容量和吞吐量成为了瓶颈。

GKE 替换了这一层，使用了一个基于 Google Spanner 的专有键值存储系统。

性能数据：在测试中，该存储系统轻松支撑了 13,000 QPS 的租约 (Lease) 更新操作，确保了 13 万个节点的健康检查心跳畅通无阻。
容量：在峰值时，数据库中存储了超过 100 万个 Kubernetes 对象，依然保持了极低的延迟和极高的稳定性。

3. 调度器的进化：Kueue 与工作负载感知

默认的 Kubernetes 调度器是“Pod 中心”的，它一个个地调度 Pod。但这对于 AI 训练任务来说远远不够——AI 任务通常需要“全有或全无” (All-or-Nothing) 的调度保证（即 Gang Scheduling）。

Google 引入了 Kueue，一个构建在原生调度器之上的作业级 (Job-level) 队列管理器。Kueue 负责决定何时接纳一个作业，基于配额、优先级和公平策略进行裁决。它实现了Gang Scheduling，确保一个训练任务的所有 Pod 要么全部启动，要么全部排队，避免了资源死锁。

4. 数据访问的加速：GCS FUSE 与本地化缓存

对于 AI 训练，数据加载速度至关重要。GKE 利用 Cloud Storage FUSE 配合并行下载和区域性缓存 (Anywhere Cache)，让存储在 GCS 对象存储中的海量数据，能像本地文件系统一样被 Pod 高速访问。这使得数据加载延迟降低了 70%，确保了 GPU 不会因为等待数据而空转。

实战演练：一场 13 万节点的压力测试

为了验证这套架构，Google 设计了一个包含四个阶段的极限压力测试，模拟了真实的 AI 生产环境。下图展示了整个测试的时间线和四个关键阶段。

图注：13万节点压力测试的完整执行时间线

阶段一：基线测试 —— 1000 Pods/秒的狂飙

在一个空集群中，一次性启动 130,000 个 Pod 的大规模训练任务。结果显示，控制平面极其稳定，支撑了高达 1,000 Pods/秒 的创建和调度吞吐量。

图注：控制平面的吞吐量监控

阶段二：混合负载与争抢 —— Kueue 的“铁腕”

测试引入了大量低优先级的批处理作业填满集群，然后突然提交高优先级的微调任务。此时，Kueue 展现了惊人的动态调整能力：它在 93 秒内精准抢占了 39,000 个低优 Pod，瞬间腾出资源给高优任务。

图注：Kueue 正在进行资源调度

阶段三与四：突发流量与弹性恢复

在第三阶段，模拟了“双十一”式的流量洪峰，提交最高优先级的推理服务。系统再次平稳应对，甚至在极高负载下，推理 Pod 的 P99 启动延迟仍控制在 10 秒左右，这对于对延迟敏感的在线服务至关重要。

图注：不同负载类型下的 Pod 启动延迟

最后，当流量退去，系统自动释放资源，重新接纳之前被挂起的低优任务，实现了资源的完美闭环和极致利用。

小结：这就是未来的基础设施

Google 的这次 13 万节点实验，不仅是秀肌肉，更是为整个云原生社区指明了方向。它证明了 Kubernetes 在经过合理的架构优化后，完全有能力承载 AI 时代最苛刻的算力需求。

从内存一致性缓存到工作负载感知的调度，这些在极限场景下打磨出的技术创新，最终都会反哺到普通的 GKE 集群，甚至回馈给开源社区（如 Kueue 和 KEP 提案）。

对于我们每一位架构师而言，这都是生动的一课：真正的可扩展性，不仅仅是堆砌硬件，更是对系统每一个环节——从读写路径到调度逻辑——进行极致的工程优化。

资料链接：https://cloud.google.com/blog/products/containers-kubernetes/how-we-built-a-130000-node-gke-cluster/

聊聊你对“规模极限”的看法

Google的13万节点集群，为我们展示了云原生技术栈在AI时代的巨大潜力。在你看来，Kubernetes或其他云原生技术的下一个“物理极限”会是什么？除了Google提到的这四项优化，你认为还有哪些关键技术能帮助我们突破规模的瓶颈？或者，你在自己的工作中，遇到过哪些有趣的“规模化”挑战和解决方案？

欢迎在评论区留下你的真知灼见，让我们一起探讨未来基础设施的模样！

如果这篇文章让你对大规模系统设计有了新的启发，别忘了点个【赞】和【在看】，并分享给更多对技术极限充满好奇的同伴！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：