您的组织真的需要 Kubernetes 吗？

petecheslock在 Twitter 上表达了对无处不在的 Kubernetes 的批评观点：

这条推文激起了热烈的反响，并提出了一个关键问题：您的组织真的需要 Kubernetes 吗？

第 1 部分：我们如何走到这一步

Kubernetes 之旅首先要了解从单体架构到微服务架构的转变以及这种转变旨在解决的问题。

从单体架构到微服务

在软件开发的早期，单体架构是常态。这些是大型的统一代码库，其中所有应用程序的逻辑都紧密耦合并作为单个服务运行。虽然这种方法在简单性和直接性方面具有优点，但它也有显着的缺点，特别是当应用程序规模和复杂性不断增加时。

为了应对这些挑战，业界逐渐转向微服务架构，其中应用程序被划分为更小的、松散耦合的服务。每个微服务都可以独立开发、部署和扩展，提供更大的灵活性和弹性。

然而，这种新架构也带来了自己的一系列挑战。随着服务数量的增长，开发人员必须弄清楚如何有效地管理它们。这包括扩展、部署、网络和容错等任务。

云计算和 Openstack

虚拟机 (VM) 是应对这些挑战的早期解决方案之一。通过允许多个操作系统在单个物理机上运行，虚拟机提供了一种隔离不同应用程序并更好地利用硬件资源的方法。

随后进入了云计算平台时代，OpenStack 是先驱者之一。OpenStack 于 2010 年推出，提供了一种管理数据中心中的大型计算、存储和网络资源池的方法，有效地提供了“基础设施即服务”。然而，OpenStack 因其复杂性和陡峭的学习曲线而臭名昭著，这使其成为许多组织采用的具有挑战性的工具。它仍然适用于某些场景，但从未真正得到每个人所预测的采用。

容器编排的必要性

与这些发展同时，容器化的概念开始受到关注。Docker 于 2013 年推出，是该领域的游戏规则改变者。Docker 可以轻松地在容器中打包和分发软件，包含运行应用程序所需的一切。

虽然 Docker 在微服务的采用方面发挥了重要作用，但它没有提供大规模编排和管理这些容器的解决方案。Docker 自己的原生集群和调度工具 Docker Swarm 虽然易于使用，但缺乏更大、更复杂的部署所需的高级功能和灵活性。

容器编排领域的另一个早期参与者是 Apache Mesos，它专为数据中心管理而设计，可以处理容器化和非容器化工作负载。然而，Mesos 虽然功能强大，但学习曲线陡峭，并且通常被认为对于更简单的用例来说是大材小用。

一个可以弥补这一差距的工具已经搭建好了舞台——提供管理复杂微服务架构所需的功能和灵活性，但没有陡峭的学习曲线。Kubernetes 于 2014 年由 Google 首次发布，成为一个强大的开源平台，可以大规模编排和管理容器。通过为跨主机集群的应用程序容器的部署、扩展和操作提供一致的环境，Kubernetes 被证明是许多组织正在寻求的解决方案。

第 2 部分：Kubernetes 的优势

现在我们已经追溯了 Kubernetes 的起源，接下来让我们深入了解 Kubernetes对全球组织如此有吸引力的原因。

• 提高开发人员生产力 - Kubernetes 可以通过自动化许多手动任务来加快软件开发过程。它为应用程序的部署、扩展和管理提供开箱即用的解决方案，使开发人员能够专注于编写代码而不是管理基础设施。
• 可扩展性——Kubernetes 的关键卖点之一是它自动处理扩展的能力。Kubernetes 调度程序可以在集群中高效地分配工作负载，确保每个容器都有足够的资源来有效运行。它还可以根据需求扩展或缩小应用程序，确保最佳的资源使用。
• 高可用性 - Kubernetes 旨在保持应用程序运行而无需任何停机。它提供内置的自我修复机制，这意味着它可以在节点发生故障时自动替换和重新调度容器。它还可以在节点之间分配容器，以确保工作负载不会受到单点故障的影响。
• 可移植性 - Kubernetes 几乎可以在任何支持容器的平台上运行，包括公共云、私有云和本地服务器。这使其成为寻求混合云或多云战略公司的绝佳选择。

第 3 部分：Kubernetes 的挑战

虽然 Kubernetes 提供了强大的功能和灵活性，但它也面临着挑战。对于组织来说，在决定采用 Kubernetes 之前了解这些非常重要。

• 复杂性——众所周知，Kubernetes 的设置和管理非常复杂。它具有陡峭的学习曲线，需要深入了解其概念和组件才能有效使用。这尤其影响本地环境，您必须完全 DIY 才能采用 Kubernetes。
• 成本 -运行 Kubernetes 集群的财务影响可能很大。虽然软件本身是免费和开源的，但与必要的硬件、云服务和员工培训相关的成本可能会增加。此外，维护和运营 Kubernetes 集群可能（并且将会）需要专门的团队，这意味着额外的人员成本。
• 过度工程——Kubernetes是一个强大的工具，但对于小型项目或团队来说可能有点过头了。对于用例较简单的组织，采用 Kubernetes 可能会导致不必要的复杂性和资源使用。某些工作负载可能会在传统虚拟机上更有效地运行，或者使用更简单的容器管理解决方案。
• 安全性——虽然 Kubernetes 提供了一些内置的安全功能，但它也引入了新的潜在攻击媒介。管理 Kubernetes 集群的安全性需要始终保持警惕并充分了解最佳实践。
• 维护 -维护和升级 Kubernetes 集群可能具有挑战性，特别是对于技术资源有限的组织而言。这包括修补、升级和扩展集群等任务，以及监控和排除出现的问题。因此，许多团队都陷入了过时的版本中。

第 4 部分：做出决定

在决定是否采用 Kubernetes 时，组织领导者需要考虑几个因素。

评估您的需求

了解组织的具体需求和限制是第一步。您想解决什么问题？您正在管理大量微服务吗？您是否正在寻找更好的方法来扩展您的应用程序？您是否遇到很多基础设施可靠性问题？或者您对 Kubernetes 的兴趣是由行业趋势（又名简历驱动开发）驱动的吗？

请记住，Kubernetes 是一个工具，其本身并不是目标。它只有在帮助您实现业务目标时才有价值。避免仅仅因为 Kubernetes（或任何技术）是“新的、闪亮的”东西而其他人都在这样做，就采用它是至关重要的。您选择的技术应该有效且高效地满足您的业务需求。

考虑你的资源

接下来，评估您可以使用的资源。您是否拥有管理 Kubernetes 集群所需的内部技术专业知识？您有资源在 k8s 之上构建平台吗？如果没有，您是否愿意并且能够投资于培训或招聘？

财务资源是另一个需要考虑的因素。虽然 Kubernetes 本身是免费的，但基础设施、人员和运营方面可能会产生大量成本。此外，您还必须使用监控和警报、CI/CD 平台等额外功能来增强 k8s，这可能需要从不同的供应商购买适当的解决方案。

评估替代方案

在加入 Kubernetes 潮流之前，请花时间评估替代方案。您是否已经拥有可以满足您的需求并可扩展的系统？根据您的要求，更简单的容器编排工具、平台即服务，甚至传统的虚拟机可能更适合。

一些需要考虑的选项：

• 谷歌云运行
• 亚马逊云服务器
• Azure 容器
• Heroku
• DigitalOceal应用程序平台

您的云战略是什么？

您的云策略在 Kubernetes 决策中起着至关重要的作用。对于在云中运行应用程序的组织来说，GKE、EKS 或 AKS 等托管 Kubernetes 服务可能是一个不错的选择。这些服务处理大部分 Kubernetes 设置和管理工作，让您的团队能够专注于应用程序开发。

但是，如果您有严格的合规性或安全性要求，或者您只是希望对基础设施有更多的控制权，那么本地 Kubernetes 设置可能是更好的选择。请记住，这种方法需要更多的精力和资源来管理。

评估您的规模需求

评估或考虑组织当前和未来的运营、应用程序和基础设施的规模非常重要。这涉及彻底评估应用程序的规模和复杂性，并确定您是否正在管理大量微服务或是否需要显着的可扩展性。

结论

总之，Kubernetes 是一个强大的工具，可以带来显着的好处，但它并不是一个万能的解决方案。与任何技术决策一样，采用 Kubernetes 应该是基于对组织的需求、资源和替代方案进行仔细评估的战略选择。

俗话说，“为工作选择正确的工具”，Kubernetes 可能是也可能不是适合您组织的工具。

最后，这不是 Kubernetes 好还是坏的问题，而是它是否适合您组织的独特环境。