亲爱的朋友你已经搭建了一个 Kubernetes2024 年 11 月 23 日如果你先阅读《尊敬的先生你已经构建了一个编译器》这篇文章会更易理解。亲爱的朋友我很遗憾地告知你你已然搭建了一个 Kubernetes。我晓得你原本打算“选择稳妥的技术”仅仅运行一些容器。你曾说“Kubernetes 大材小用”“对于简单任务来说太复杂了”。然而六个月后你拥有了一堆无法正常工作的 shell 脚本每次生产环境稍有变动它们就会出错。当然改用 Docker Compose 或许能解决你的问题至少这样会有人为你维护标准的配置文件格式。但等等Compose 仍然不是一个全面的解决方案。你不禁自问“我真的需要为部署、滚动更新、回滚和扩展分别找解决方案吗”肯定不需要。你的应用很简单只有一个后端、一个反向代理、PostgreSQL 数据库和一个任务运行器。于是你继续推进在 deploy.sh 脚本中又增添了几部分内容坚信这是维护这堆临时拼凑方案的最后一步。啊等等不可避免地你有了扩展到第二台服务器的需求。虽然单台服务器能发挥很大作用但很多因素会促使你做出这个决定比如对特殊硬件的需求、高可用性要求或光速限制。你疲惫不堪为部署脚本添加参数并配置防火墙规则从而分散了对本应专注开发和发布的关键功能的注意力。你的一位团队成员建议使用 Tailscale 连接服务器这是一种带有服务发现功能的覆盖网络。之后你就会明白没错你会明白没有比网络配置更难跨越的复杂障碍了。但如果你离职或去度假谁来维护这堆自定义的 shell 脚本谁来处理未经测试的 tarball谁能看懂那些难以理解的 iptables 规则谁会知道你在虚拟机上做的那些未记录的 sysctl 编辑于是你把所有内容都添加到 Ansible 中这样就能将虚拟机视为不可变且可版本控制的。当然你坚信因为没有使用 Kubernetes维护起来会比 Kubernetes 集群容易得多。你暗自感叹这是多么了不起的工程啊。在你避免搭建 Kubernetes 的最后阶段你的经理告诉你你的应用需要以编程方式生成其他容器。生成容器当然需要在你的 Web 应用中挂载 Docker 套接字这非常不安全。你的经理说这不是他的问题。于是你编写了一个单独的服务为你的 Web 应用提供 Docker API 的安全子集。你心想终于完成了不用搭建 Kubernetes。一个标准的配置格式、一种部署方法、一个覆盖网络、服务发现、不可变节点和一个 API 服务器。亲爱的朋友你已经搭建了一个 Kubernetes。致那些想避开 Kubernetes 的人附言我并不是说你永远不能自行开发一套比 Kubernetes 更适合你需求的部署方法也不是说没有什么能比 Kubernetes 更好。我只是想提醒你我的朋友在认为 Kubernetes 过于复杂而将其摒弃之前要确保你理解它所解决的问题。