istio - Tony Bai

标签 istio 下的文章

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技能再上一个新台阶！

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

7 个常见的 Kubernetes 陷阱（以及我是如何学会避免它们的）

十月 22, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/10/22/seven-kubernetes-pitfalls

大家好，我是Tony Bai。

本文翻译自Kubernetes官方博客《7 Common Kubernetes Pitfalls (and How I Learned to Avoid Them)》一文。

这篇文章的作者Abdelkoddous Lhajouji 以第一人称视角，系统性地梳理了从资源管理、健康检查到安全配置等多个方面，新手乃至资深工程师都极易忽视的关键点。文中的每个“陷阱”都源于真实的生产经验，其规避建议更是极具实践指导意义。无论你是 K8s 初学者还是经验丰富的 SRE，相信都能从中获得启发，审视并改善自己的日常实践。

以下是译文全文，供大家参考。

Kubernetes 有时既强大又令人沮丧，这已经不是什么秘密了。当我刚开始涉足容器编排时，我犯的错误足以整理出一整份陷阱清单。在这篇文章中，我想详细介绍我遇到（或看到别人遇到）的七个大坑，并分享一些如何避免它们的技巧。无论你是刚开始接触 Kubernetes，还是已经在管理生产集群，我都希望这些见解能帮助你避开一些额外的压力。

忽略资源请求（requests）和限制（limits）

陷阱：在 Pod 规范中不指定 CPU 和内存需求。这通常是因为 Kubernetes 并不强制要求这些字段，而且工作负载通常可以在没有它们的情况下启动和运行——这使得在早期配置或快速部署周期中很容易忽略这个疏漏。

背景：在 Kubernetes 中，资源请求和限制对于高效的集群管理至关重要。资源请求确保调度器为每个 Pod 预留适当数量的 CPU 和内存，保证其拥有运行所需的必要资源。资源限制则为 Pod 可以使用的 CPU 和内存设置了上限，防止任何单个 Pod 消耗过多资源，从而可能导致其他 Pod 资源匮乏。当未设置资源请求和限制时：

资源匮乏：Pod 可能会获得不足的资源，导致性能下降或失败。这是因为 Kubernetes 会根据这些请求来调度 Pod。如果没有它们，调度器可能会在单个节点上放置过多的 Pod，从而导致资源争用和性能瓶颈。
资源囤积：相反，如果没有限制，一个 Pod 可能会消耗超过其应有份额的资源，影响同一节点上其他 Pod 的性能和稳定性。这可能导致其他 Pod 因内存不足而被驱逐或被内存溢出（OOM）杀手终止等问题。

如何避免

从适度的 requests 开始（例如 100m CPU，128Mi 内存），然后观察你的应用表现如何。
监控实际使用情况并优化你的设置；HorizontalPodAutoscaler 可以帮助根据指标自动进行扩缩容。
留意 kubectl top pods 或你的日志/监控工具，以确认你没有过度或不足地配置资源。

我的惨痛教训：早期，我从未考虑过内存限制。在我的本地集群上，一切似乎都很好。然后，在一个更大的环境中，Pod 们接二连三地被 OOMKilled。教训惨痛。有关为你的容器配置资源请求和限制的详细说明，请参阅官方 Kubernetes 文档的为容器和 Pod 分配内存资源。

低估存活探针（liveness）和就绪探针（readiness）

陷阱：部署容器时不明确定义 Kubernetes 应如何检查其健康或就绪状态。这往往是因为只要容器内的进程没有退出，Kubernetes 就会认为该容器处于“运行中”状态。在没有额外信号的情况下，Kubernetes 会假设工作负载正在正常运行——即使内部的应用程序没有响应、正在初始化或卡住了。

背景：
存活、就绪和启动探针是 Kubernetes 用来监控容器健康和可用性的机制。

存活探针 决定应用程序是否仍然存活。如果存活检查失败，容器将被重启。
就绪探针 控制容器是否准备好为流量提供服务。在就绪探针通过之前，该容器会从 Service 的端点中移除。
启动探针 帮助区分长时间的启动过程和实际的故障。

如何避免

添加一个简单的 HTTP livenessProbe 来检查一个健康端点（例如 /healthz），以便 Kubernetes 可以重启卡住的容器。
使用一个 readinessProbe 来确保流量在你的应用预热完成前不会到达它。
保持探针简单。过于复杂的检查可能会产生误报和不必要的重启。

我的惨痛教训：我曾有一次忘记为一个需要一些时间来加载的 Web 服务设置就绪探针。用户过早地访问了它，遇到了奇怪的超时，而我花了几个小时挠头苦思。一个 3 行的就绪探针本可以拯救那一天。

有关为容器配置存活、就绪和启动探针的全面说明，请参阅官方 Kubernetes 文档中的配置存活、就绪和启动探针。

“我们就看看容器日志好了”（著名遗言）

陷阱：仅仅依赖通过 kubectl logs 获取的容器日志。这通常是因为该命令快速方便，并且在许多设置中，日志在开发或早期故障排查期间似乎是可访问的。然而，kubectl logs 仅检索当前运行或最近终止的容器的日志，而这些日志存储在节点的本地磁盘上。一旦容器被删除、驱逐或节点重新启动，日志文件可能会被轮替掉或永久丢失。

如何避免

使用 CNCF 工具如 Fluentd 或 Fluent Bit 来集中化日志，聚合所有 Pod 的输出。
采用 OpenTelemetry 以获得日志、指标和（如果需要）追踪的统一视图。这使你能够发现基础设施事件与应用级行为之间的关联。
将日志与 Prometheus 指标配对，以跟踪集群级别的数据以及应用程序日志。如果你需要分布式追踪，可以考虑 CNCF 项目如 Jaeger。

我的惨痛教训：第一次因为一次快速重启而丢失 Pod 日志时，我才意识到 kubectl logs 本身是多么不可靠。从那时起，我为每个集群都设置了一个合适的管道，以避免丢失重要线索。

将开发和生产环境完全等同对待

陷阱：在开发、预发布和生产环境中使用完全相同的设置部署相同的 Kubernetes 清单（manifests）。这通常发生在团队追求一致性和重用时，但忽略了特定于环境的因素——如流量模式、资源可用性、扩缩容需求或访问控制——可能会有显著不同。如果不进行定制，为一个环境优化的配置可能会在另一个环境中导致不稳定、性能不佳或安全漏洞。

如何避免

使用overlays环境或 kustomize 来维护一个共享的基础配置，同时为每个环境定制资源请求、副本数或配置。
将特定于环境的配置提取到 ConfigMaps 和/或 Secrets 中。你可以使用专门的工具，如 Sealed Secrets 来管理机密数据。
为生产环境的规模做好规划。你的开发集群可能用最少的 CPU/内存就能应付，但生产环境可能需要多得多。

我的惨痛教训：有一次，我为了“测试”，在一个小小的开发环境中将 replicaCount 从 2 扩展到 10。我立刻耗尽了资源，并花了半天时间清理残局。哎。

让旧东西到处漂浮

陷阱：让未使用的或过时的资源——如 Deployments、Services、ConfigMaps 或 PersistentVolumeClaims——在集群中持续运行。这通常是因为 Kubernetes 不会自动移除资源，除非得到明确指示，而且没有内置机制来跟踪所有权或过期时间。随着时间的推移，这些被遗忘的对象会累积起来，消耗集群资源，增加云成本，并造成操作上的混乱，尤其是当过时的 Services 或 LoadBalancers 仍在继续路由流量时。

如何避免

为所有东西打上标签，附上用途或所有者标签。这样，你就可以轻松查询不再需要的资源。
定期审计你的集群：运行 kubectl get all -n 来查看实际在运行什么，并确认它们都是合法的。
采用 Kubernetes 的垃圾回收：K8s 文档展示了如何自动移除依赖对象。
利用策略自动化：像 Kyverno 这样的工具可以在一定时期后自动删除或阻止过时的资源，或强制执行生命周期策略，这样你就不必记住每一个清理步骤。

我的惨痛教训：一次hackathon之后，我忘记拆除一个关联到外部负载均衡器的“test-svc”。三周后，我才意识到我一直在为那个负载均衡器付费。捂脸。

过早地深入研究网络

陷阱：在完全理解 Kubernetes 的原生网络原语之前，就引入了高级的网络解决方案——如服务网格（service meshes）、自定义 CNI 插件或多集群通信。这通常发生在团队使用外部工具实现流量路由、可观测性或 mTLS 等功能，而没有首先掌握核心 Kubernetes 网络的工作原理时：包括 Pod 到 Pod 的通信、ClusterIP Services、DNS 解析和基本的 ingress 流量处理。结果，与网络相关的问题变得更难排查，尤其是当overlays网络引入了额外的抽象和故障点时。

如何避免

从小处着手：一个 Deployment、一个 Service 和一个基本的 ingress 控制器，例如基于 NGINX 的控制器（如 Ingress-NGINX）。
确保你理解集群内的流量如何流动、服务发现如何工作以及 DNS 是如何配置的。
只有在你真正需要时，才转向功能完备的网格或高级 CNI 功能，复杂的网络会增加开销。

我的惨痛教训：我曾在一个小型的内部应用上尝试过 Istio，结果花在调试 Istio 本身的时间比调试实际应用还多。最终，我退后一步，移除了 Istio，一切都正常工作了。

对安全和 RBAC 太掉以轻心

陷阱：使用不安全的配置部署工作负载，例如以 root 用户身份运行容器、使用 latest 镜像标签、禁用安全上下文（security contexts），或分配过于宽泛的 RBAC 角色（如 cluster-admin）。这些做法之所以持续存在，是因为 Kubernetes 开箱即用时并不强制执行严格的安全默认设置，而且该平台的设计初衷是灵活而非固执己见。在没有明确的安全策略的情况下，集群可能会持续暴露于容器逃逸、未经授权的权限提升或因未固定的镜像导致的意外生产变更等风险中。

如何避免

使用 RBAC 来定义 Kubernetes 内部的角色和权限。虽然 RBAC 是默认且最广泛支持的授权机制，但 Kubernetes 也允许使用替代的授权方。对于更高级或外部的策略需求，可以考虑像 OPA Gatekeeper（基于 Rego）、Kyverno 或使用 CEL 或 Cedar 等策略语言的自定义 webhook 等解决方案。
将镜像固定到特定的版本（不要再用 :latest！）。这能帮助你确切地知道实际部署的是什么。
研究一下 Pod 安全准入（或其他解决方案，如 Kyverno），以强制执行非 root 容器、只读文件系统等。

我的惨痛教训：我从未遇到过重大的安全漏洞，但我听过足够多的警示故事。如果你不把事情收紧，出问题只是时间问题。

小结：最后的想法

Kubernetes 很神奇，但它不会读心术，如果你不告诉它你需要什么，它不会神奇地做出正确的事。通过牢记这些陷阱，你将避免大量的头痛和时间浪费。错误会发生（相信我，我犯过不少），但每一次都是一个机会，让你更深入地了解 Kubernetes 在底层是如何真正工作的。如果你有兴趣深入研究，官方文档和社区 Slack 是绝佳的下一步。当然，也欢迎分享你自己的恐怖故事或成功技巧，因为归根结底，我们都在这场云原生的冒险中并肩作战。

祝你交付愉快！

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