【译文】用 Kubernetes 值得吗?

我就直说了:如果仔细研究与 Kubernetes 相关的总体拥有成本 (TCO),更传统的开发方法仍然具有令人信服的优势。在又一次 KubeCon 即将结束之际,也许是时候深入探讨一下这个问题了。

这是一个罕见的立场。自从多年前容器和 Kubernetes 首次出现在云计算领域以来,我就一直在使用它们。我使用这项技术在公共云上设计并构建了大量可扩展的系统,因此我知道它行之有效,而且效果很好。我想说的是,它经常被过度应用。系统构建者的动力来自于时下最酷的孩子们在做什么,而不是找到能带来最大商业价值的解决方案。

因此,我敢肯定,由于这些架构错误的继续存在,数百万美元被浪费掉了。是时候让我们做得更好了。也许您也同意。

需要考虑的问题

在我们进行分析的过程中,你会发现其中有些内容可能适用于你和你的组织,也可能不适用。对很多人来说,说 “看情况 “似乎是一种逃避,但这通常是正确的答案。无论是迁移到云还是构建全新系统,您都必须评估每种工作负载和数据集。您需要做好准备,使用最佳技术解决方案来满足您的系统需求。很抱歉要告诉您一个坏消息。

Kubernetes 带来的复杂程度是传统开发工具无法比拟的。管理 Kubernetes 集群需要深入了解其架构和组件,从网络到存储再到安全。这种复杂性要求技术熟练的人员有能力管理和优化 Kubernetes 环境。

相比之下,传统的开发方法和工具通常依赖于更简单的架构,大多数企业已经具备了相应的管理技能。当然,每个公司的情况会有很大不同,但获得 Kubernetes 技能或培训现有员工的成本通常要比使用该技术带来的好处高得多。

尽管 Kubernetes 承诺通过高效的容器编排降低基础设施成本,但 Kubernetes 集群需要大量的开销。这包括组成集群的节点和管理故障转移所需的资源。此外,如果你有管理冗余和可扩展性的基础设施,也会有所帮助;你需要支付的资源可能远远超出需要。

传统的开发方法可能会使用更多的单体架构。灵活性较低可能会降低初始资本支出和持续成本。我有一个项目使用两种方法构建了相同的系统;传统的单体架构基础设施成本是 Kubernetes 部署成本的三分之一–仅就该特定系统而言。当然,除了在简历上看起来不错之外,使用 Kubernetes 可能还有其他原因。

维护 Kubernetes 环境在操作上非常复杂。需要持续监控、调整和更新,以确保环境安全、高效和可靠。同样,这种持续的维护需要熟练的员工和现代化的工具,这都会导致总体拥有成本上升,在某些情况下甚至会翻倍。

尽管 Kubernetes 可以自动化和简化部署流程,但初始设置和配置可能既耗时又复杂。这可能会延迟许多系统的部署时间和上市时间,使您面临更多潜在错误。传统的开发和部署方法可能需要更多的容器自动化和可扩展性优势。但是,对于某些应用而言,它们往往更简单、部署更快。

这些系统的分布式性质带来了新的风险和故障点。Kubernetes 和基于容器的部署具有很高的可扩展性和容错水平,这也是我们使用它们的原因,但它们确实存在传统开发中看不到的问题。这些问题包括从 “容器蔓延 “到容器生态系统中的安全漏洞,以及需要更新技能才能正确运行的新工具。我发现,故障并不在于何时发生,而在于发生多少次。Kubernetes 部署的故障总是更多。

传统架构提供的可扩展性选项可能较少,但可以提供更易于安全和管理的封闭环境。这意味着成本更低,但功能也更少。有时,这种权衡具有良好的商业意义。

总体拥有成本分析的重要性

尽管 Kubernetes 和容器在可扩展性、效率和资源利用率方面具有显著优势,但它们的总体拥有成本(TCO)有时也会失衡。当然,我发现总体拥有成本分析经常被忽视;那些选择该技术的人并不能很好地把握所做的权衡。我通常会问使用更传统的方法会有什么得失,但得到的往往是茫然的目光和不置可否的回答,这说明没有进行总体拥有成本分析。另一方面,我也经常被问到是否会去 KubeCon,这也是原因之一。

管理 Kubernetes 环境的复杂性和成本凸显了传统开发和部署方法仍然具有价值。事实上,如果你是一家 IT 资源有限的企业,你确实需要关注总体拥有成本。

花在基于 Kubernetes 的系统上的钱会占用其他更迫切需求的资源。我不知道哪家 IT 企业有无限的预算来尝试所有新技术。您需要谨慎选择您的战斗。

本文文字及图片出自 Is Kubernetes worth it?

你也许感兴趣的:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注