这也许是一个不太受欢迎的观点，但大多数主流公司最好不要再使用 k8s 了。

你知道那个古老的“以程序员技能写 Hello world ”笑话吗？—— 从一个新手程序员的 printf("hello, world\n") 语句开始，最后结束于高级软件架构工程师令人费解的 Java OOP 模式设计。使用 k8s 就有点像这样。

• 新手系统管理员：

./binary

• 有经验的系统管理员：

在 EC2 上的 ./binary

• DevOp：

在 EC2 上自部署的 CI 管道运行 ./binary

• 高级云编排工程师：

在 EC2 上通过 k8s 编排的自部署 CI 管道运行 ./binary

¯\_(ツ)_/¯

这不意味着 Kubernetes 或者任何这样的东西本身都是坏的，就像 Java 或者 OOP 设计本身并不是坏的一样，但是，在很多情况下，它们被严重地误用，就像在一个 hello world 的程序中可怕地误用 Java 面向对象设计模式一样。对大多数公司而言，系统运维从根本上来说并不十分复杂，此时在这上面应用 k8s 起效甚微。

复杂性本质上来说创造了工作，我十分怀疑使用 k8s 对大多数使用者来说是省时的这一说法。这就好像花一天时间来写一个脚本，用来自动完成一些你一个月进行一次，每次只花 10 分钟完成的工作。这不是一个好的时间投资（特别是你可能会在未来由于扩展或调试这个脚本而进一步投入的更多时间）。

你的部署大概应该需要自动化 – 以免你 最终像 Knightmare 那样 —— 但 k8s 通常可以被一个简单的 shell 脚本所替代。

在我们公司，系统运维团队用了很多时间来设置 k8s 。他们还不得不用了很大一部分时间来更新到新一点的版本（1.6 ➙ 1.8）。结果是如果没有真正深入理解 k8s ，有些东西就没人会真的明白，甚至连深入理解 k8s 这一点也很难（那些 YAML 文件，哦呦！）

在我能自己调试和修复部署问题之前 —— 现在这更难了，我理解基本概念，但在真正调试实际问题的时候，它们并不是那么有用。我不经常用 k8s 足以证明这点。