我们在生产环境使用 Kubernetes 多年的体会
生产环境中的 Kubernetes 引发了褒贬不一的反应。许多工程师认为，它的复杂性、运维陷阱（例如证书过期导致集群故障）以及持续不断的升级负担，对于小团队或简单应用来说都不值得；这些场景完全可以运行在 VMs 或更轻量的容器平台上。另一些人则强调它的优势：统一的部署抽象、在本地与云之间的可移植性，以及丰富的工具链——前提是使用托管服务（EKS/AKS/GKE）、避免集群“特化”成雪花、并投入平台团队。讨论还涉及 ECS、Nomad、Ray 和 Proxmox 等替代方案，有状态工作负载与开发环境之间的权衡，以及一种更广泛的担忧：Kubernetes 往往是在“看起来能扩展”而非“已被证明需要”的情况下被过早采用。
小团队与大组织中的 Kubernetes
- 许多人认为 Kubernetes 对小团队/初创公司来说过度复杂；复杂性和维护成本会压垮研发效率。
- 有些人说，只有当你拥有数百名工程师和专门的平台团队时，它才真正说得通。
- 也有人反驳说，团队规模并不如问题复杂度和规模重要；有些人甚至把 k8s 用在个人项目里，因为他们喜欢拥有一个统一的抽象层。
托管集群与自管集群
- 普遍共识是：自己管理控制平面风险很高；证书过期和升级问题曾导致多天宕机。
- 托管服务（EKS/AKS/GKE）被认为可靠得多，能显著减少痛苦，不过也并非绝不会宕机。
- 一些评论者认为，文章中的宕机更多是糟糕的运维实践造成的（没有 manifests/备份、证书管理不当），而不是 k8s 本身的缺陷。
复杂性、抽象层与优势
- 批评者列出了陡峭的学习曲线：PKI/证书、etcd、CNI 网络、DNS、ingress controllers、Helm、GitOps、YAML 蔓延、频繁弃用。
- 支持者强调统一的资源模型：无论本地还是云端都能使用相同的 manifests，可插拔存储/ingress、自动服务发现、扩缩容、故障切换以及节点维护流程。
- 有人把 k8s 描述为很出色的开发/QA 平台（环境一致、容易搭建复杂拓扑），但与更有主见的运行时相比，在生产中“还可以，但不算特别好”。
替代方案与更简单的方法
- 建议的选项包括：ECS、Fargate、Azure Container Apps、Nomad、Ray、Docker Compose/Swarm、Proxmox、Ubuntu MicroCloud、带 CI/CD 的普通 VMs，或者跑在自动扩容服务器上的单体应用。
- 对许多产品而言，评论者认为“几台 VM + 负载均衡器 + 托管数据库”会更便宜、更简单，而且已经足够可扩展。
开发环境与 GitOps
- 一些团队会运行本地/开发集群（kind/k3s/k3d、Tilt、kustomize）或与生产环境相似的小型共享集群，通常还会为 S3 和其他服务提供 mock。
- GitOps（Argo/Flux）的评价不一：有人认为它对于版本管理和漂移检测至关重要；也有人觉得它又增加了一层同步，并更偏好直接使用 Helm/kubectl。
成本、人员配置与总体拥有成本
- 一个常见担忧是：文章很少量化基础设施成本、工程师时间成本，或相较于更简单技术栈的机会成本。
- 还有几条评论指出，即使在托管服务上，维护 k8s 也至少需要部分专职人员投入。
“Learnings” 还是 “lessons”
- 长长的子讨论在辩论“learnings”是企业黑话还是可接受的现代用法；很多人觉得刺耳，也有人为它辩护，认为它有一个有用的细微差别。