面试让我学到的关于 Kubernetes 的事

原文 ↗ Hacker News 讨论 ↗

Kubernetes 作为新的默认选择

  • 许多评论者表示，Kubernetes 实际上已经“赢过”了 VM+systemd 和大多数其他调度器，主要因为：
    • 主要云厂商上的托管服务已经成熟且开箱即用。
    • 围绕它建立起了庞大的工具、公司和人才生态系统。
    • 它充当了基础设施和 GitOps 的“通用语”。

对小团队和初创公司的适配性

  • 对 Kubernetes 何时有意义，存在强烈分歧：
    • 一些人认为，即使是非常小的团队，只要已经是“cloud native”，它也是合理的，因为它带来了统一部署、更容易的上手以及共享知识。
    • 另一些人则认为，2–3 名工程师就采用 k8s 是个危险信号：与其这样，不如直接用虚拟机或更简单的容器平台，没必要增加复杂度。
    • 还有几位认为，文章中那些非技术收益（运营/组织层面）在如此小的规模下并不足以抵消复杂性。

复杂性、升级与生态变化

  • 许多人指出 k8s 不是“自带所有功能”的：ingress、证书管理、DNS、存储和 GitOps 会引入多个控制器，而且它们各自都有升级周期和破坏性变更。
  • 升级节奏被看作：
    • 一项特性（通过“点一下按钮”式的集群升级，实现定期安全更新和漂移控制）。
    • 或一种负担（持续的 API 变动、ingress/gateway 变化、让各个 addon 保持同步）。
  • 一些人强调网络和 DNS 层（例如 CoreDNS 扩展、overlay）对许多初创公司来说过于大材小用。

替代方案和“更简单”的技术栈

  • 经常被提到的有：
    • 传统的“linux + web server + database + language runtime”放在虚拟机上，通常用 Ansible、shell 脚本或 NixOS 管理。
    • 更轻量的调度器和类 PaaS 工具（Nomad、Docker Swarm、ECS/Fargate、Cloud Run、类似 Heroku 的系统、自定义的“kube-lite”项目）。
  • 一个反复出现的模式是：团队先尝试 k8s，然后有些团队又回到更简单、更“boring”的配置，以降低运维负担。

LLM 与易用性

  • 有人声称 LLM 让 k8s 和 Terraform 变得容易得多：可以生成 manifests、Helm charts、仪表盘，并帮助调试集群。
  • 也有人强烈警告，不要用 LLM 去处理你自己并不理解的系统，因为错误往往隐蔽且影响巨大。

有状态工作负载与托管服务

  • 几位评论者认为，持久状态（数据库、blob 存储、缓存）通常最好放在 Kubernetes 之外，通过云厂商的托管服务来管理：
    • 托管服务被认为比集群内的有状态 operator 更可靠，也更容易迁移。
  • 另一些人表示，使用现代的 k8s 原生数据库 operator 也取得了成功，但承认这会带来显著的复杂性。

招聘、炒作与文化

  • Kubernetes 被视为：
    • 对招聘和简历塑造很有吸引力；一些人称之为“resume++”或受炒作驱动。
    • 也是 CTO 的一个安全、标准选择，因为他们希望避免定制基础设施，并依赖广为人知的模式。
  • 有些人批评采用 k8s 其实是在用工具掩盖文化/流程问题，而不是解决根本问题。