Kubernetes 不总是正确的选择

Kubernetes 不总是正确的选择

一个好的工具不在于它的炒作或流行度，而在于它能多好地解决你的问题并融入你的生态系统。

对于没有进入 kubernetes 生态的你，可以参考一下是否已经准备好了。本文译自 Kubernetes Isn’t Always the Right Choice 。

如今，几乎所有的应用程序都可以被封装在容器中执行。容器解决了很多问题，但也带来了新的编排挑战。由于大量团队需要容器编排来构建云原生应用程序，Kubernetes 作为一个强大的工具解决了这个挑战，因此获得了广泛的普及。

在一个管理良好的 Kubernetes 环境中开发，可以提供许多好处，比如自动扩缩容、自我修复、服务发现和负载均衡。然而，拥抱 Kubernetes 的世界通常意味着不仅仅是采用容器编排技术。团队需要从战略上考虑“Kubernetes 是我的解决方案的正确选择吗？”他们必须通过评估这个更广泛问题的几个组成部分来做到这一点。

我的团队构成是否适合 Kubernetes？

对 Kubernetes (K8s) 的能力赞不绝口的文章数不胜数，这不是我们要质疑的。在许多情况下，K8s 是一个正确的选择。也就是说，并非所有团队和项目都适合直接与 Kubernetes 交互和维护。

1. 拥有云原生应用程序的小型创业公司: 这些团队会发现直接管理 Kubernetes 是一个复杂、耗时的分心，而不是实现发布和扩展产品的目标。考虑到他们的规模，团队不会有足够的带宽来管理 Kubernetes 集群的同时开发他们的应用程序。
2. 拥有各种应用类型的企业团队: 对于拥有专业技能的大型团队来说，Kubernetes 是一个绝佳的选择。然而，完全托管的容器运行时或 Kubernetes 即服务产品仍值得考虑。这些服务使有限的 DevOps 资源能够专注于提高团队生产力、开发人员自助服务、成本管理和其他关键事项。
3. 拥有 DevOps 文化的中型公司: 虽然这些团队更有准备迈向 Kubernetes，但这是一个会破坏现有工作流程的重大项目。同样，托管产品可以不需要大量投资就可以解锁 Kubernetes 的许多好处。
4. 软件咨询公司: 虽然这些团队具有适应能力，但依赖 Kubernetes 可能会限制他们为有不同需求的客户提供服务的能力，因为它会推动咨询公司在 Kubernetes 不是最佳方案时仍然建议使用它。

项目有多复杂？Kubernetes 是否过于庞大？

与其确定 Kubernetes 是否满足您的一些要求，不如考虑识别与 Kubernetes 的能力不太匹配或引入不必要复杂性的特定特征和要求。

1. 最低的可伸缩性需求：如果项目的流量一直较低或资源需求可预测且稳定，没有显著的扩展需求，那么 Kubernetes 将引入不必要的开销。在这些情况下，托管容器运行时或虚拟专用服务器（VPS）解决方案通常更具价值。
2. 简单的单体应用程序：如果项目是单体应用程序，依赖性有限，不需要独立可伸缩的服务或极高的实例数量，那么 Kubernetes 对其需求过于复杂。
3. 静态或有限的基础设施：如果项目的基础设施规模较小或静态，资源使用变化不大，那么简化的部署选项，如托管服务或 VPS，将足够。
4. 有限的 DevOps 资源：Kubernetes 需要容器编排的专业知识，这对于具有有限 DevOps 资源的项目或团队不太可行，或者如果团队不愿意投入学习 Kubernetes 的时间。不过，仍然可以在不进行额外投资的情况下实现容器的好处。
5. 原型和短期项目：对于开发周期较短或生产周期有限的项目，Kubernetes 的开销难以合理化。
6. 项目成本限制：如果项目有严格的预算限制，那么建立和维护 Kubernetes 集群的额外成本将不可行。特别是考虑到需要高度熟练的团队成员来执行这项工作的成本。
7. 基础设施要求：Kubernetes 可能需要占用大量资源，需要强大的基础设施才能有效运行。如果您的项目规模较小或中等，资源需求适中，那么使用托管服务或无服务器将更为合适。

仅凭您的需求复杂性本身不会决定 Kubernetes 是否适合您的团队，但可以帮助您倾向于某一方向。如果您直接使用 Kubernetes，它不会自然提高您的产品。它的强大之处在于创建一个强大的平台，使您的产品可以茁壮成长。

Pyramid

图1

这将导致开发工作进一步远离成为您业务基础的方向，而更多地投入到您的产品之下。

这引出了一个真正的问题：我们是在建立一个平台，还是试图加快上市时间，以更快地实现核心业务目标的投资回报？

我们是否具备必要的技能？

Kubernetes 通常以其具有挑战性的学习过程而闻名。什么因素导致了这种复杂性？为了更清楚地表达，我整理了一份基于特定标准的主题列表，这些标准有助于评估提高自己技能所需的努力。

注意：这些复杂性级别将根据个人背景和先前经验而异。

对于缺乏必要的专业知识或没有时间学习的团队，整体开发和部署过程可能会变得令人不堪重负和缓慢，这对于时间紧迫或人手有限的项目不利。

有哪些成本影响？

尽管 Kubernetes 本身是开源且免费的，但运行它并非如此。您需要考虑与基础设施相关的费用，包括服务器、存储和网络的成本，以及隐藏的成本。

第一个隐藏的成本在于管理和维护 - 团队培训、故障排除、维护系统、维护内部工作流程和自助服务基础设施所花费的时间和资源。

由于各种原因，许多人在计算全面的 Kubernetes 环境成本时忽略了这项工作所需的高技能员工的工资。要警惕关于完全托管或无服务器提供的服务与自我管理的 Kubernetes 之间许多不准确的比较。它们通常未考虑员工成本以及由于花费在 Kubernetes 上而导致的失去时间的机会成本。

第二个隐藏成本与 Kubernetes 生态系统有关。拥抱 Kubernetes 世界通常意味着不仅仅是采用一个容器编排平台。这就像踏上一个广阔的大陆，拥有丰富的功能，以及各种供应商提供的各种工具、服务和产品，最终会引入其他成本。

结论

一个好的工具不仅仅是因为它的炒作或流行，而是因为它能很好地解决您的问题并融入到您的生态系统中。在云原生应用程序的领域，Kubernetes 无疑占据了很大一部分讨论。然而，我鼓励团队考虑通过 OpenShift、Docker Swarm 或由 Nitric 等框架协调的无服务器和托管服务等解决方案实现的不同方法的权衡。

在后续文章中，我将探讨一种在不直接依赖 Kubernetes 的情况下创建云原生应用程序的方法。我将深入探讨通过托管服务（如 AWS Lambda、Google CloudRun 和 Azure ContainerApps ）提供的基础设施构建和部署强大、可伸缩和有弹性的云原生应用程序的过程。

这种云中应用程序开发方法是我们正在构建的 Nitric 的灵感来源，该云框架旨在简化在多个云平台上创建、部署和管理应用程序的过程。它提供了在配置底层基础设施时抽象和自动化涉及的复杂性的一致的开发者体验。

对于发现直接互动和管理 Kubernetes 不合适的团队和项目，无论是因为预算限制、资源有限还是技能不足，Nitric 提供了一个途径来利用相同的优势。深入了解 Nitric 的方法，并在 GitHub 上与我们分享您的反馈。