本文永久链接 – 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 资源匮乏。当未设置资源请求和限制时：

1. 资源匮乏：Pod 可能会获得不足的资源，导致性能下降或失败。这是因为 Kubernetes 会根据这些请求来调度 Pod。如果没有它们，调度器可能会在单个节点上放置过多的 Pod，从而导致资源争用和性能瓶颈。
2. 资源囤积：相反，如果没有限制，一个 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技能，是否也卡在了“熟练”到“精通”的瓶颈期？

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

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

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

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

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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

本文永久链接 – https://tonybai.com/2025/10/22/back-to-go-after-defection-to-java

大家好，我是Tony Bai。

“我离开了 Go，因为我觉得它啰嗦又笨重。我以为编程本该是简单轻松的……但事实证明，河对岸的草不见得更绿。”

近日，在 r/golang 社区，一篇标题为《一篇完全没有建设性但又无比真实的，关于 Go 和 Java 的咆哮》的帖子引发了热议。作者讲述了一个“Gopher 叛逆-回归”的经典故事：因不满 Go 社区对 ORM 和 DI 框架的“抵触”，以及 Go 语言本身的“繁琐”，他转投了企业级 Java 的怀抱。然而，在亲身体验了 Java 生态中无处不在的“魔法”之后，他如今“无比怀念 Golang”。

这篇“咆哮”，与其说是在抱怨，不如说是一次深刻的顿悟。它以一种极具戏剧性的方式，揭示了 Go 与 Java 在设计哲学上的根本冲突，以及 Go 语言“显式优于隐式”这一核心价值观的真正分量。

“魔法”的代价——“我根本不知道火箭从哪儿来”

作者坦言，他最初无法理解人们为何抱怨 Java 的“魔法”。框架“做了所有繁重的工作，你只需要创建和注册工厂，不是吗？”

在亲身实践后，他发出了痛苦的哀嚎：“我终于明白了。我无比痛恨 Java 使用的魔法。你根本不可能知道火箭是从哪里发射的。”

他精准地指出了几个让他崩溃的“魔法”重灾区：

Spring 的依赖注入 (DI)：“@Service my ass”

在 Spring 框架中，一个简单的 @Service 注解，就能让一个类被自动扫描、实例化并注入到任何需要它的地方。这看似便捷，但当系统变得复杂时，它就成了一个黑盒。作者咆哮道：“你只是接受了某个地方、某个时候会调用你的工厂——只要你设置了正确的 profile。@Service my ass。”

这种控制反转 (IoC) 的极致，让代码的调用关系变得极其隐晦。想找到一个 JWT 令牌的验证逻辑在哪里被触发？想知道 PEM 密钥在哪里被设置？祝你好运。这与 Go 中清晰、明确的函数调用和依赖传递，形成了鲜明的对比。

Hibernate 的 ORM：“它写的查询简直骇人听闻”

作者曾是 TypeORM 的忠实拥趸，但 Hibernate 让他领教了重量级 ORM 的恐怖。他质问道：“为什么它不直接用 JOIN，而是去执行那 40 条额外的查询？为什么我只是想取个名字，它却加载了整个银行数据？”

这正是“魔法”的另一面：为了提供一个看似简单的对象操作接口，ORM 在底层生成了极其复杂、低效、且难以预测的 SQL 查询（即著名的 N+1 问题）。当魔法失效，你需要深入调试时，你面对的将是 HQL (Hibernate Query Language) 这种“又一门需要学习的查询语言”，而不是你早已精通的 SQL。

MapStruct 的代码生成：“我如何给它加断点？”

从模型 (Model) 到数据传输对象 (DTO) 的转换，在 Java 中也充满了“魔法”。像 MapStruct 这样的库，通过注解和代码生成，自动完成对象之间的映射。作者的质问直击要害：“你从中得到了什么？我如何给它加一个断点？”

当代码不再是你亲手编写，而是由工具在编译时“变”出来的时候，你就失去了最宝贵的武器：可调试性和可预测性。

社区的激辩——Go 真的“反框架”吗？

这篇“咆哮”自然也引发了社区的激烈辩论。许多评论者指出，作者所憎恨的，并非 Java 语言本身，而是其生态中过度使用“魔法”的特定框架文化（尤其是 Spring 和 Hibernate）。

同时，也有 Gopher 指出，Go 社区并非完全拒绝高级抽象。像 Uber 开源的 fx 框架，就是一个功能强大的依赖注入库；而 gomock 也是从 Go 官方团队交由 Uber 维护的重要项目。

然而，这场辩论最终揭示了一个核心的文化差异：

• Java 企业级生态：倾向于提供“全家桶”式的、重量级的框架。这些框架试图用“魔法”为开发者包办一切，隐藏复杂性。其哲学是“约定优于配置”的极致体现。
• Go 社区生态：更倾向于提供小巧、正交、可组合的库。它鼓励开发者理解并亲手“管道”这些构建块。其哲学是“显式优于隐式”。Go 开发者不害怕“重新发明轮子”，因为他们认为“对轮子的控制权”本身就是一种价值。

重新审视 Go 的“繁琐”——是缺陷，还是守护？

作者的回归之旅，让我们得以用一个全新的视角，重新审视那些曾被他（以及许多初学者）视为“繁琐”的 Go 特性。

if err != nil：繁琐背后的清晰

当社区讨论 Go 的“繁琐”时，99% 的情况下，他们指的都是 if err != nil。然而，在经历了 Java 中可以随时随地抛出、难以追踪的未经检查的异常 (Unchecked Exceptions) 之后，Go 这种将错误作为普通值的处理方式，其优势便凸显出来：

• 清晰的控制流：错误处理路径是代码中明确、可见的一部分，而不是通过 try-catch 或全局异常处理器实现的“隐形跳转”。
• 强制的责任：编译器强制你关注每一个可能出错的地方，这从根本上提升了代码的健壮性。

拥抱 database/sql：显式控制的自由

在关于 ORM 的激烈辩论中，一位 Gopher 的评论掷地有声：“当魔法失效时，从 ORM 回退到 SQL 查询，比从一开始就写 SQL 要痛苦十倍。”

这并非是在断言“Go 社区完全拒绝 ORM”。事实上，Go 生态中拥有像 GORM、ent、sqlc、sqlx 这样流行且功能强大的数据访问工具。然而，与 Java 生态中 Hibernate 几乎一统天下的地位不同，Go 社区对于是否使用 ORM，以及如何使用，始终保持着一种审慎和多元的态度。

这种态度的根源，在于 Go 的标准库 database/sql。它本身并非一个 ORM，而是一个轻量级的、提供了数据库操作最小抽象的接口。它刻意地将开发者保留在离 SQL 很近的地方。

这种“刻意的简陋”，恰恰赋予了开发者一种宝贵的自由：

1. 完全的 SQL 控制权：你永远不必去猜测框架会生成什么样的“怪物”SQL。你可以亲手编写最高效、最符合你业务场景的查询，可以轻松地使用数据库的高级特性，也可以在需要时对查询进行精确的性能调优。
2. 清晰的数据流：数据从数据库行到你的 struct 的映射过程是显式的。无论是 rows.Scan() 还是 sqlx 的 db.StructScan()，你都能清晰地看到数据的流转路径。
3. 更低的认知负荷：学习 database/sql 和基础 SQL，其学习曲线远比掌握一个像 Hibernate 这样庞大、复杂的 ORM 框架要平缓得多。

当然，这意味着你需要编写更多的“繁琐”的 SQL 语句和手动映射代码。但 Go 社区的普遍哲学认为，这种可预测、可控制的“繁琐”，远胜于那种在 90% 的时间里都很神奇，但在剩下的 10% 的时间里会让你陷入调试地狱的“魔法”。

对于许多 Gopher来说，选择 database/sql 或 sqlx 这样的轻量级工具，并非“重新发明轮子”，而是一种主动的选择——选择将复杂性掌握在自己手中，而不是将其外包给一个难以捉摸的黑盒。

小结：简单性的“甜蜜点”

这位“叛逆”Gopher 的回归故事，是一堂关于软件设计哲学的生动课程。它告诉我们，设计一门简单的语言并不容易。

“要让事情变简单，你必须隐藏复杂性。但如果你隐藏了太多的复杂性，你实际上会让事情变得更复杂——因为复杂性只是被隐藏了，而非被消除了。”

Java 的“魔法”生态，通过注解、反射和代码生成，将复杂性深深地隐藏在了一个难以触及的黑盒中。而 Go，则努力地寻找着一个“甜蜜点”：它提供了足够高的抽象（如 Goroutine 和 GC），让你不必关心线程调度和内存分配的底层细节；同时，它又保持了足够的透明度，让你能清晰地看到程序的控制流和数据流。

最终，这场从 Go 到 Java 再回到 Go 的旅程，并非一次简单的技术选择，而是一次深刻的哲学回归。它证明了在长期维护、大规模协作和复杂问题调试的战场上，清晰、显式和可预测性，远比任何华丽的“魔法”都更加珍贵。

资料链接：https://www.reddit.com/r/golang/comments/1o7u5b6/a_completely_unproductive_but_truthful_rant_about/

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

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

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

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

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

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