Kubernetes 的批评者指南

原文 ↗ Hacker News 讨论 ↗

Kubernetes 让工程师产生两极分化：它是一个强大的容器部署与扩展标准，但也引入了相当大的复杂性，尤其是对那些并不真正需要其全部功能的团队而言。评论者在其优势——云无关 API、丰富工具、自动扩缩容，以及跨环境的“单一接口”——与运维脆弱性、陡峭的学习曲线、YAML/Helm 模板化痛点，以及过度工程化的文化倾向之间进行权衡。许多人认为，更简单的方案（VM、ECS、Docker Compose、Nomad、k3s、Dokku）通常已经足够，而真正的挑战在于根据公司的规模、技能和业务需求选择相称的基础设施，而不是盲目追随炒作。

关于 Kubernetes 的总体立场

  • 许多人认为 Kubernetes 很强大，但过于复杂；也有人认为，这种复杂性与其在大规模真实世界问题中的需求相匹配。
  • 普遍看法是：只有极少数人“需要” k8s 才能生存，但更大一群人发现它在运维上很有帮助。
  • 有些人把它比作 git 或 systemd：核心设计扎实，但用户体验痛苦。

运维复杂性与脆弱性

  • 自管集群被描述得很脆弱：etcd 升级、控制平面规格不足，以及不透明的故障。
  • 托管 k8s（GKE/EKS/AKS）常被推荐用来避免控制平面的麻烦，不过也有人仍然报告频繁出现“奇怪的问题”。
  • 排查失败的 Helm 部署、崩溃循环，以及 operator/CRD 行为，是反复出现的抱怨。

工具链：YAML、Helm、operator、替代方案

  • 人们强烈不喜欢 YAML，尤其是 Helm 的 Go 模板化 YAML；大家报告了细微的空格/模板错误。
  • 提到的替代方案包括：kustomize、envsubst、Jsonnet、Pulumi、Terraform、CDK、cdk8s；有些人更偏好“直接写代码”，而不是模板化 YAML。
  • operator 和 CRD 被视为 k8s 的关键优势之一（可编程基础设施、Ceph/Rook、GitHub operators），同时也是复杂性和集群范围耦合的重要来源。

自动扩缩容、部署与延迟

  • 当 HPA、VPA 和 KEDA 被广泛采用时，会受到称赞；动态调优 HPA 被认为比凌晨 4 点手动扩容更好。
  • 零停机部署是一个主要驱动力；许多人指出，你也可以用更简单的蓝绿部署和反向代理实现这一点。
  • 对于短暂、对延迟敏感的工作负载，k8s 冷启动很难在不深入底层机制的情况下压到约 0.5–2 秒以下；有些人转向 Nomad 或自定义调度器。

云、锁定与可移植性

  • 支持 k8s 的人强调：声明式模型、内置负载均衡/重启、可观测性工具，尤其是跨本地、裸机（k3s）和云环境的云无关 API。
  • 批评者反驳说，真实部署仍然高度依赖各家云的具体实现，而且相对于实际发生频率， “云迁移”被过度强调了。

何时不要使用 Kubernetes 及替代方案

  • 对于简单或小规模系统，许多人更喜欢：ASG、ECS/Fargate、Cloud Run、Docker Compose、Swarm、Nomad、Dokku、带脚本的纯 VM。
  • 家庭实验室用户通常发现 k3s 或仅用 Docker Compose 就已足够。

文化和组织动态

  • K8s 可能变成一种“聪明陷阱”和地位象征，催生平台英雄文化和无休止的工具叠加。
  • 有些人认为，真正的问题是被炒作驱动的采用和误用，而不是技术本身。