【.com快译】Kubernetes是一项了不起的技术，我个人在自己的SaaS上实现扩展、部署和管理的过程中受益匪浅。但客观来说，并不是所有人在采用后都能迅速受益。一般有以下几个原因：对容器技术和应用架构不熟悉，不利于发挥Kubernetes的优势。增加的工作量和花费的时间因此，如果你对Kubernetes感兴趣，但不确定是否值得投入必要的时间和资源，那么这篇文章应该更适合你的参考阅读。1.你有使用容器的经验吗？为了了解Kubernetes可以为您做什么，您首先需要了解容器可以提供哪些优势。所以在你花时间开始使用Kubernetes之前，请提前准备好以下几点：1.将你的应用程序容器化首先也是最重要的：你的应用程序必须已经实现了容器化。这意味着您已经定义了设置基本操作系统映像的步骤，将您的应用程序打包到一个文件（通常是Dockerfile）中并进行了安装。完成上述过程以及定义配置应用程序所需的环境变量（例如应用程序使用的数据库的URL、用户名和密码）非常关键。这些确保您的容器镜像可用于Kubernetes。同时，您还需要注意应用程序运行时的各种依赖关系，并了解如何使用它们的容器版本。2.了解存储的工作原理容器通常被设计为仅保存运行应用程序所需的代码。由于拆除和启动容器的过程（这在处理多个容器时非常常见）会破坏存储在容器文件系统中的所有数据，因此任何需要的持久数据都存储在其他地方。在考虑Kubernetes时，您应该了解容器存储是如何设置运行的，以及它如何处理备份数据、在容器之间移动数据以及从容器外部访问数据等问题。Kubernetes通过自动资源配置等功能使存储管理更容易实现。此功能还使您的存储提供商（例如AWSEBS）能够及时创建一些新卷，并在忙于创建新容器时自动挂载它们。3.了解网络的工作原理网络的构建方式会对您使用Kubernetes的方式产生巨大影响。对于初学者来说，重要的是要了解如何将特定系统暴露给外部Internet应用程序（例如数据库），同时保持一些信息隐藏，同时保持服务之间的通信。根据经验，我们需要掌握一些更复杂的背景知识，包括：如何集成负载均衡，以及为每个客户实例定义主机名。这些将使使用Kubernetes变得更加容易。第二，Kubernetes能否解决你目前面临的各种问题？如果你不使用容器来部署你自己的应用程序，那么你可能不需要使用Kubernetes。因为Kubernetes解决了您在尝试扩展基于容器的架构时通常会遇到的问题。这是我认为Kubernetes在尝试解决容器扩展问题时必须提供的东西。1.扩展资源从本质上讲，Kubernetes是一个节点集群，提供可由容器工作负载使用的计算资源。这种集群架构使得扩展或缩减各种资源变得容易。只要你在集群中添加或删除一些节点，Kubernetes就会自动利用这些资源，或者在你现有的资源上重新分配工作负载。这个功能曾经解决了我面临的一个棘手问题。由于我从单个服务器开始，为了能够继续扩展（这本来是一个繁琐的手动过程），我只需要在CLI（命令行界面）中使用一个命令就可以自由定制我的建筑学。放大。2.进行大量更新Kubernetes的另一个能力是：它可以解决所有容器的更新问题。过去，我必须编写一些shell脚本来选择每个相关容器并使用新的图像标签重新创建它们。整个过程不仅耗时一个多小时，甚至无法验证更新是否成功。今天，借助Kubernetes，我可以使用如下单个命令执行更新：//Updateallthepodsofffrontendtoanewimagetage$kubectlrolling-updatefrontend--image=image:v2部分（包括网络、存储等）。从编写自己的脚本来更改模式的角度来看，这是一个巨大的改进。3.自愈功能自愈功能是这里最后需要提到的，但却是Kubernetes最重要的能力。如果Kubernetes在其架构中检测到问题，例如：节点没有响应，或者容器未通过健康检查，它会根据既定步骤重新创建相应的相关部分，直到它们能够恢复运行。这非常有用。如果集群的一部分因为某种原因掉线了，它对应的工作负载应该重新分配，甚至可以让Kubernetes重建整个服务器来解决问题。3.你的应用架构需要改变吗？有时，在您的应用程序中采用Kubernetes就像将方钉钉入圆孔。由于我的应用程序最初是作为多容器部署的多实例平台构建的，所以在迁移到Kubernetes时我没有做太多更改。下面我分享一些我在将自己的工作负载迁移到Kubernetes时学到的东西。1.应用程序启动时间很重要创建新部署时，您必须等待应用程序启动，然后它才可供最终用户使用。这就产生了一个问题：如果部署过程恰好涉及在最终用户按下按钮的那一刻创建新实例，或者在您对所有客户实例执行更新的那一刻，那么您需要重新生成一些podup。因此，在迁移到Kubernetes时，您可能需要对代码库进行一些更改，使启动过程更加高效，从而使最终用户在使用您的产品时不会出现体验下降的情况。2.多租户架构难以调整多租户架构意味着你有一个单一的应用程序实例，它在一个分区的租户环境中管理着所有的最终用户，当然它通常与大家共享一个单一的数据库。如果您的应用程序不是使用集群构建的（将多个服务器联合到一个实例中），那么您不应该使用Kubernetes。通常，我们在使用Kubernetes时，会采用两种架构：多实例架构，即为每个用户分配一个应用实例的多租户架构，具有集群功能，可伸缩使用的资源。对于集群多租户架构，我个人更喜欢多实例架构，因为它们更容易实现。此外，将多租户迁移到多实例架构比添加将各种集群添加到多实例架构的能力要少得多。3.迁移到无状态应用程序是一项巨大的工程Kubernetes的一个重要特性是能够按比例增加和减少部署中的pod数量。但是，如果您的应用程序既不是集群的也不是无状态的，那么这个特性就是一种浪费，因为那些额外的pod既不会被正确配置，也不会在部署期间被使用。在大多数情况下，在Kubernetes中使用无状态进程通常不值得付出代价，因为您需要重写它在应用程序中处理配置的方式。如果你不想花时间将应用程序更改为无状态或swarm模式，那也没关系，毕竟Kubernetes可以提供许多其他方法来帮助你更改为有状态部署模型。当然，这些方法也各自存在着各种各样的问题，本文不做深入探讨。4.是否应该采用Kubernetes？对于是否迁移Kubernetes的问题，你应该考虑它是否真的适合你现在的系统。对于大多数早期创业公司来说，可能不需要Kubernetes；对于一些比较成熟的公司，他们可能已经在其他技术上进行了较大的投资，所以迁移是不可行的。在这里，我认为迁移到Kubernetes的最佳候选者是：一家初创公司希望从最小的、运行的云基础设施转移到更稳定的东西，并使用容器在其生产环境中“赋予”工作负载“能力”。事实上，这是我经历的过程。也就是说，我亲身经历了从资源管理不善和服务器过载导致的周期性停机，到使用和迁移到Kubernetes的整个过程。今天我不再担心我的基础架构。原标题：如何知道是否Kubernetes适合你的SaaS，作者：BenSears
