我在软件行业摸爬滚打了十余年，形形色色的角色都担任过。以前，遇到一些新兴的工具，人们会认真比较优缺点，而如今却变成了无脑跟着潮流走。

Kubernetes 就是其中之一。如今，在 Kubernetes 上托管应用程序已成为部署应用程序的标准，而无论 Kubernetes 能否带来切实的好处。我希望通过本文，说明使用 Kubernetes 的缺点， Kubernetes 对软件开发周期的破坏、成本的增加，以及对敏捷性的负面影响，从而唤醒软件行业的理智。

使用 Kubernetes 会导致成本增加

假设你是一家中小型初创公司，你的应用程序由几个后端服务、一个数据库、一个缓存服务和一个负载均衡器组成。这个设置包括 2 个托管服务（数据库和缓存）、6 个用于后端服务冗余的小型机器和 2 个负载均衡器（如果正常部署到云的话）。

如果在这个配置中加入 Kubernetes，则仅仅是为了运行额外的sidecar，就不得不使用两倍的机器：三台机器运行Kubernetes的控制平面，另外三台运行etcd集群，同时还需要添加多个内部服务，比如Ingress控制器以及日志和指标收集。

虽然加入 Kubernetes 会导致你的成本翻倍，但实际上对于中小型企业来说，你根本使用不了 Kubernetes 的任何功能。

Kubernetes 的部署非常复杂

一般，正常的设置需要占用 CI/CD 工程师几天的时间，而调试与基础设施相关的问题用时不会超过一两个小时。

然而，Kubernetes 的部署需要渲染模板、设置 CI/CD 运行器、动态生成 kubeconfigs 以确保安全等，通常要占用 CI/CD 工程师不少于一个月的时间才能准备好生产级的环境。为了调试错误，你可能需要花费数天时间来弄清楚哪些涉及底层基础设施、哪些是 Kubernetes，而哪些关系到应用程序本身。我曾经花了 6 个小时调查为什么 CoreDNS 无法注册新服务，最后却发现只是一个非常小的错误。

我们创建了一个高质量的技术交流群，与优秀的人在一起，自己也会优秀起来，赶紧点击加群，享受一起成长的快乐。

Kubernetes 不稳定

由不同的维护者部署许多不同版本的组件，这个想法就注定了 Kubernetes 集群不可能没有错误，从网络 CNI 到控制器，再到自定义操作符，这些对象往往很容易破坏https。

把真实的网络组件封装后放在云的网络虚拟化中，只会让一切变得非常复杂。

版本管理困难

跟踪集群上部署的所有组件的所有版本需要耗费大量时间。你需要投入一个专职工程师来维护第三方平台上的配置，还需要处理由于更新引发的各种故障。

DevOps 工程成本飙升

如果你选择了面向那些资金充裕、不在乎 Kubernetes 带来额外成本的大型企业方案，那么成本飙升是必然的。

受攻击的范围更大

Kubernetes 有其自身的安全漏洞，因此会导致你的应用程序的受攻击的范围翻倍。你是否有预算雇佣安全工程师来处理这个问题，还是说你只有一位 DevOps 工程师，采纳 Kubernetes 后，工程师需要承担更多的安全工作？

Kubernetes 攻击每天都在发生，管理它们并非易事。长期来看，最终你还是需要聘请一名安全工程师来保护这些没有必要的技术栈。

总结

我希望通过这篇文章，让大家看到一些疯狂的技术决策趋势，这些决策只是盲目跟风，并没有太大受益。

最后，如果你正在犹豫是否使用 Kubernetes，请仔细衡量优缺点，认真做比较。