当我们真正衡量Kubernetes总拥有成本(TCO)时，就会发现一种现象，有时候传统的开发方式反而更具优势。如今，这一趋势愈发强烈，已经到了非说不可的时候了。

　　当以Kubernetes为代表的容器技术，出现在云计算领域后，很多企业就一直在使用这样的技术，希望在公有云上构建出更具扩展性的应用。从这个角度来说，Kubernetes是一种可行性应用，而且有着较好的效果。那么，我们现在为什么又说Kubernetes不好呢？原因是Kubernetes被过度使用！

　　Kubernetes过度使用导致资源浪费

　　很多企业使用Kubernetes，只是因为这是一个时髦的技术，而不是从给企业带来最大化商业价值的角度，来考虑整个解决方案的构建！

　　可以想象，随着Kubernetes的持续投入，数百万美元的资金投入被浪费了，如何进一步优化我们的IT投入，这已是很多企业达成的共识！

　　当我们对IT投入进行深入分析时发现，有些技术的确适合企业，但有些应用很多时候可能用不着。很多人都在讲，我们要视情况而定，要量力而行，这绝对不是一句空话，而是实践出真知。企业在进行IT应用部署的时候，一定要正确评估每个工作负载，以及相应的数据集。不管企业是把应用部署到云上，还是构建全新的系统，都需要选择适合企业应用的技术及解决方案。

　　大多数人不知道的是，Kubernetes引入了一种传统开发工具所没有的复杂性。管理Kubernetes集群需要开发人员深入了解其架构和相关的组件，包括从网络到存储再到安全的整个应用过程。这种复杂性往往需要更熟悉Kubernetes环境的专业人员才能操作。

　　相比之下，传统的开发方法和工具通常依赖于更直接的体系结构，这些体系结构可以让企业基于已经拥有的技能集设计应用。当然，不同公司之间，技术水平参差不齐。如果很多公司技术实力雄厚，有大量员工经历了Kubernetes技能培训，那确实更适合使用Kubernetes技术，好处也有很多。

　　开发和维护带来的成本无法预判

　　值得一提的是，维护Kubernetes集群开销很大，尽管Kubernetes对外的口号是，通过高效的容器编排来降低基础设施成本。但实际发生的成本，很多企业可能无法正确预判，比如：组建集群的节点和管理故障转移所需的资源。在实际部署中，如果你拥有运维管理冗余能力，具备可扩展性的基础设施，可能情况会好一些。但通常情况是，企业的支出要大于实际应用。

　　传统的开发方法可能不够灵活，但资本支出会少很多，也不会有大量的后续成本。以一个实际项目执行为例，传统的单体架构在基础设施上的投入成本是Kubernetes部署的三分之一。当然，这一结果只针对特定的业务系统。

　　除了开销大，Kubernetes另一个弊端是环境维护复杂，需要持续的监视、调优和更新，以确保环境安全、高效和可靠。同样，这种持续的维护需要熟练的员工和现代化的工具。从这个角度来看，两者都推高了TCO，在某些情况下，成本还会翻倍。

　　尽管，Kubernetes可以自动化和简化部署应用过程，但初始设置和配置可能既耗时又复杂。这可能会延迟许多系统的部署时间和上市时间，使企业面临更多潜在的风险。传统的开发和部署方法也可以通过容器的方式部署，利用自动化和可伸缩性优势，为开发赋能。在个别场景下，对于某些应用程序而言，传统开发方式通常可以让企业以更简单、更快的方式进行部署。

　　还有一个问题是，很多企业提出的现代化的应用开发方式，比如：分布式特性引入了新的风险和故障点。基于以Kubernetes为代表的容器的部署方式，提供了高可伸缩性和容错级别，这是很多企业使用Kubernetes的原因，但容器技术确实存在我们在传统开发中看不到的问题。这些问题包括从“容器蔓延”到容器生态系统中的安全漏洞，以及需要更新技能才能正确运行它们的新工具。

　　传统架构可能在伸缩性上差了点意思，但提供了更易于保护和管理的更具包容性的环境。而Kubernetes和容器在可伸缩性、效率和资源利用方面，虽然更具显著优势，但总体TCO有时候无法掌控。所以，最终的结论是，Kubernetes环境的复杂性和居高不下的成本支持，让传统开发和部署方式，仍有发展空间。企业可能只有真正在业务有需求的情况下，才会部署Kubernetes，而不是不计任何代价地进行新技术投入。