让我们看看如果您决定在自己的 IT 环境中引入 Kubernetes，您可面临哪些选项。

将 Kubernetes 运行在本地还是云上？

如果您想在 Kubernetes 上运行您的应用程序，您必须决定是在本地运行它们（自建的数据中心）还是运行在云上，或者两者兼而有之 - 在混合云解决方案中。

在本地运行 Kubernetes

如果有法规要求您必须在本地运行应用程序，那么在您自己的基础架构上（自建数据中心）运行 Kubernetes 可能是您唯一的选择。这通常意味着您必须自己管理 Kubernetes，但我们稍后会谈到。

Kubernetes 可以直接在裸机上运行，也可以在数据中心的虚拟机上运行。无论哪种情况，您都无法像在云提供商提供的虚拟机中运行集群那样轻松地扩展集群。

在云上部署 Kubernetes

如果您没有本地基础设施，您别无选择，只能在云中运行 Kubernetes。这样做的好处是，如果需要，您可以在短时间内随时扩展集群。如前所述，当集群的当前大小不再足以运行您要部署的所有应用程序时，Kubernetes 本身可以要求云提供商提供额外的虚拟机。

当工作负载数量减少并且一些工作节点没有运行工作负载时，Kubernetes 可以要求云提供商销毁这些节点的虚拟机以降低您的运营成本。集群的这种弹性无疑是在云中运行 Kubernetes 的主要好处之一。

使用混合云解决方案

一个更复杂的选择是在本地运行 Kubernetes，但也允许一部分部署到云上。如果您超出自己数据中心的容量，可以将 Kubernetes 配置为在云中配置额外的节点。这样，您就可以两全其美。大多数情况下，您的应用程序在本地运行而无需虚拟机租赁成本，但在一年可能仅发生几次的短期峰值负载期间，您的应用程序可以通过使用云中的额外资源来处理额外的负载。

如果您的用例需要，您还可以跨多个云提供商或上述任何选项的组合运行 Kubernetes 集群。这可以使用单个控制平面或每个位置的一个控制平面来完成。

选择自己管理 Kubernetes 还是托管？

如果您正在考虑在您的组织中引入 Kubernetes，您需要回答的最重要的问题是您是自己管理 Kubernetes 还是使用其他人为您管理的 Kubernetes （即服务类型）产品。

自己管理 Kubernetes

如果您已经在本地运行应用程序并且有足够的硬件来运行生产就绪的 Kubernetes 集群，那么您的第一直觉可能是自己部署和管理它。如果你问 Kubernetes 社区中的任何人这是否是一个好主意，你通常会得到一个非常明确的“不”。

Kubernetes 带来了大量额外的复杂性。任何想要运行 Kubernetes 集群的人都必须非常熟悉它的内部工作原理。

拆箱即用的 Kubernetes 集群管理是一个价值数十亿美元的行业。在你决定自己管理一个之前，你必须咨询已经做过这种事情的工程师，以了解大多数团队遇到的问题。如果你不这样做，你可能会为失败做好准备。另一方面，使用托管 Kubernetes 集群面临的问题要少得多。

在云上使用托管的 Kubernetes

使用 Kubernetes 比管理它容易十倍。大多数主要的云提供商现在都提供 Kubernetes 即服务。他们负责管理 Kubernetes 及其组件，而您只需像使用云提供商提供的 API 一样使用 Kubernetes API。

使用开源版的还是企业版的 Kubernetes？

最后一个问题是是使用 Kubernetes 的原始开源版本还是扩展的、企业级质量的 Kubernetes 产品。

使用开源版 Kubernetes

Kubernetes 的开源版本由社区维护，代表了 Kubernetes 开发的前沿。这也意味着它可能不像其他选项那样稳定。它也可能缺乏良好的安全默认值。部署 vanilla 版本需要进行大量微调以设置所有内容以供生产使用。

使用企业级 Kubernetes 发行版

在生产中使用 Kubernetes 的更好选择是使用企业级 Kubernetes 发行版，例如 OpenShift 或 Rancher。除了通过更好的默认值提供更高的安全性和性能之外，它们还提供了除了上游 Kubernetes API 中提供的对象类型之外的其他对象类型。例如，vanilla Kubernetes 不包含代表集群用户的对象类型，而商业发行版则包含。它们还提供额外的软件工具，用于在 Kubernetes 上部署和管理知名的第三方应用程序。

当然，扩展和加固 Kubernetes 需要时间，所以这些商业 Kubernetes 发行版通常比 Kubernetes 的上游版本落后一两个版本。它并不像听起来那么糟糕。好处通常大于坏处。

是否应该使用 Kubernetes 吗？

我希望这一章让您对 Kubernetes 感到兴奋，并且迫不及待地想将它融入您的 IT 堆栈。但是要正确结束本章，我们需要说一两句话，什么时候介绍 Kubernetes 不是一个好主意。

您的工作负载是否需要自动化管理？

您需要诚实的第一件事是您是否需要自动化管理您的应用程序。如果您的应用程序是一个大型单体应用程序，那么您绝对不需要 Kubernetes。

即使您部署微服务，使用 Kubernetes 也可能不是最佳选择，尤其是在您的微服务数量非常少的情况下。当天平翻倒时，很难提供准确的数字，因为其他因素也会影响决定。但是，如果您的系统由少于五个微服务组成，那么将 Kubernetes 混入其中可能不是一个好主意。如果您的系统有超过 20 个微服务，您很可能会从 Kubernetes 的集成中受益。如果您的微服务数量介于两者之间，则应考虑其他因素，例如接下来描述的因素。

您能负担得起将工程师的时间投入到学习 Kubernetes 上吗？

Kubernetes 旨在允许应用程序在不知道它们在 Kubernetes 中运行的情况下运行。虽然应用程序本身不需要修改即可在 Kubernetes 中运行，但开发工程师将不可避免地花费大量时间来学习如何使用 Kubernetes，即使操作员是唯一真正需要这些知识的人。

很难告诉您的团队您正在切换到 Kubernetes，并期望只有运维团队开始探索它。开发人员喜欢闪亮的新事物。在撰写本文时，Kubernetes 仍然是一个非常闪亮的东西。

您是否准备好在此期间增加成本？

虽然 Kubernetes 降低了长期运营成本，但在您的组织中引入 Kubernetes 最初会增加培训、雇用新工程师、构建和购买新工具以及可能的额外硬件的成本。除了应用程序使用的资源之外，Kubernetes 还需要额外的计算资源。

不要相信炒作

尽管在撰写本书时 Kubernetes 已经存在了好几年，但我不能说炒作阶段已经结束。最初的兴奋才刚刚开始平静下来，但对于 Kubernetes 的集成是否像看上去的那么必要，很多工程师可能仍然无法做出理性的决定。