云世界的一个肮脏小秘密是容器工作负载的总体拥有成本高于应有的水平。
译自 Is Kubernetes worth it?，作者 David Linthicum。
我将直言不讳：在仔细研究与 Kubernetes 相关的总体拥有成本 (TCO) 时，更传统的开发方法仍然具有明显的优势。在我们结束另一场 KubeCon 时，也许是时候深入研究一下了。
这是一个罕见的态度。自多年前容器和 Kubernetes 首次出现在云计算领域以来，我就一直在使用它们。我使用这项技术在公有云上设计并构建了众多可扩展系统，因此我知道它有效，而且效果很好。我的观点是，它经常被过度应用。系统构建者受当下时尚的影响，而不是寻找能带来最大业务价值的解决方案。
因此，我确信随着这些架构错误的持续，数百万美元将被浪费。是时候让我们做得更好了。也许你同意。
在我们进行此分析时，你会发现其中一些内容可能适用于你和你所在的组织，也可能不适用。对许多人来说，“这取决于”似乎是逃避责任，但它通常是正确的答案。无论你是要迁移到云端还是构建全新的系统，都必须评估每个工作负载和数据集。你需要做好准备，为你的系统需求使用最佳技术解决方案。抱歉，我是坏消息的传递者。
Kubernetes 引入了传统开发工具所没有的复杂性级别。管理 Kubernetes 集群需要深入了解其架构和组件，从网络到存储再到安全性。这种复杂性需要能够管理和优化 Kubernetes 环境的熟练人员。
相比之下，传统的开发方法和工具通常依赖于更简单的架构，可以使用大多数企业已经具备的技能集进行管理。当然，这在不同公司之间会有很大差异，但获得 Kubernetes 技能或培训现有员工的成本通常远高于使用这项技术的任何好处。
Kubernetes 集群需要大量的开销，尽管 Kubernetes 承诺通过高效的容器编排来降低基础设施成本。这包括构成集群的节点以及管理故障转移所需的资源。此外，还需要基础设施来管理冗余和可扩展性；你可能需要支付的资源可能远远超过所需资源。
传统的开发方法可能会利用更多单体架构。灵活性较低可能会导致较低的初始资本支出和持续成本。我有一个项目使用这两种方法构建了相同的系统；传统的单体架构基础设施成本是 Kubernetes 部署的三分之一——仅针对该特定系统。当然，除了在简历上看起来不错之外，还有其他理由可以使用 Kubernetes。
维护 Kubernetes 环境在操作上很复杂。 需要持续监控、调整和更新，以确保环境安全、高效和可靠。同样，这种持续维护需要熟练的人员和现代化工具，这两者都会推高 TCO，在某些情况下甚至会使其翻倍。
初始设置和配置可能既耗时又复杂，即使 Kubernetes 可以自动化和简化部署流程。这可能会延迟许多系统的部署时间和上市时间，让你面临更多潜在错误。传统的开发和部署方法可能需要更多容器自动化和可扩展性优势。但是，对于某些应用程序来说，它们通常更简单、部署速度更快。
这些系统的分布式特性引入了新的风险和故障点。 Kubernetes 和基于容器的部署提供了高可扩展性和容错级别，这就是我们使用它们的原因，但它们确实存在我们在传统开发中看不到的问题。这些问题可能从“容器蔓延”到容器生态系统中的安全漏洞，其中需要新的工具来更新技能以正确运行它们。我发现问题不是 何时 会发生，而是 有多少 会发生。Kubernetes 部署的故障总是更多。
传统架构可能提供的可扩展性选项较少，但可以提供一个更容易保护和管理的更受控环境。这意味着成本更低，但功能也更少。有时，这种权衡具有良好的商业意义。
尽管 Kubernetes 和容器在可扩展性、效率和资源利用方面提供了显著的优势，但其 TCO 有时可能会失控。当然，我发现 TCO 分析常常被忽视；选择该技术的人员对所做权衡没有很好的把握。我通常会询问使用更传统方法的权衡利弊，但大多数情况下得到的都是茫然的表情和含糊其辞的回答，这表明没有进行 TCO 分析。另一方面，我经常被问到是否会参加 KubeCon，所以是这个现状。
管理 Kubernetes 环境的复杂性和成本凸显了传统开发和部署方法仍然具有价值。事实上，如果您是一个 IT 资源有限的组织，您确实需要关注 TCO。
在基于 Kubernetes 的系统上花费的资金会从其他更紧迫的需求中抽走资源。我不知道有任何一家 IT 组织拥有无限的预算来尝试所有新技术。您需要仔细选择您的战斗。