如何获知Kubernetes是否适合您的SaaS

• 对于容器技术熟悉程度的缺乏
• 应用架构不利于使用到Kubernetes的优势
• 增加的工作量和所花费的时间

因此，如果你对Kubernetes感兴趣，却又不确定是否值得投入必要的时间与资源的话，那么本文应该比较适合您来参考阅读。

一、您对容器是否有经验?

为了理解Kubernetes能够为您做些什么，您首先需要了解容器能够提供哪些优势。因此在你花时间开始使用Kubernetes之前，请事先准备如下几点：

1.容器化您的应用程序

首先也是最重要的：您的应用程序必须已经实现了容器化。这意味着您已经定义好了相关的步骤来设定一个基本的OS映像，并且将您的应用程序打包成为一个文件(通常是一个Dockerfile)安装进去了。

通过上述过程、以及定义配置应用程序所需的环境变量(如应用程序所使用的数据库的URL、用户名和密码)都是至关重要的。这些能够保证您的容器映像对于Kubernetes来说是可用的。

同时，您还要记下应用程序所需运行时的各种依赖关系，并且理解如何去使用它们的容器版本。

2.理解存储是如何运作的

容器一般被设计为仅保存运行某个应用程序所需的代码。由于对容器进行卸载(tear down)和启动(spin up)的进程(在处理多个容器时，该现象十分常见)都会破坏存储在该容器文件系统中的所有数据，因此任何持久性数据都需要被存储到其他地方。

在考虑Kubernetes时，您应当去理解容器存储是如何被设定运作的，以及如何处理诸如备份数据、在容器之间移动数据、以及从容器外部访问数据等问题。

Kubernetes通过诸如自动资源调配的功能，使得存储管理更易于实现。该功能也使得您的存储提供商(如AWS EBS)在忙于创建新的容器时，会及时创建一些新的卷，并自动加载它们。

3.理解网络是如何运作的

您的网络构建方式会对您使用Kubernetes产生巨大的影响。对于新手来说，了解如何在做好隐藏部分信息的情况下，将特定的系统开放给外部互联网应用(如数据库)，同时保持服务之间的通信是非常重要的。根据经验，我们需要掌握一些更为复杂的背景知识，包括：如何集成负载平衡，以及给每个客户的实例定义主机名等。这些都会使得Kubernetes的使用变得容易得多。

二、Kubernetes能够解决您当前面临的各种问题吗?

如果您并没有使用容器来部署自己的应用，那么您可能就不需要用到Kubernetes了。因为Kubernetes所解决的问题，一般是你在试用和扩展一个基于容器的架构时所碰到的。

下面是我认为Kubernetes在试图解决容器扩展问题时，所能表现出的优势之处。

1.扩展资源

从本质上来说，Kubernetes是一组节点的集群，它提供了可由容器的工作负载所使用的计算资源。这种群集架构能够非常容易地对各种资源进行扩展或缩减。您只要在群集中添加或删除某些节点，Kubernetes就会自动利用这些资源，或者是对您现有资源进行工作负载上的重新分配。

该特性曾经解决了我所面临的一个棘手问题。因为我最初只有一台单独的服务器，为了能够持续扩展(这本来会是一个麻烦的手动过程)，我只需要在CLI(命令行界面中)使用一条命令，就有能力对自己的架构进行自由缩放了。

2.执行大量的更新

Kubernetes的另一个能力是：它能够解决对所有容器的更新问题。过去，我不得不编写一些shell脚本来选择每个相关的容器，并使用新的镜像标签来重新创建它们。整个过程不但要持续一个多小时，而且我都无法去验证更新是否成功。如今，使用了Kubernetes，我就能通过如下的一条命令来执行更新操作：

// Update all the pods of frontend to a new image tage  



$ kubectl rolling-update frontend --image=image:v2 

Kubernetes还允许您基于任何标准、通过各种命令，来更新Kubernetes的任一部分(包括网络、存储等)。从编写自己的脚本来进行架构更改的角度来说，这是一项巨大的进步。

3.自愈功能

自愈功能是最后一个需要在此提及的，却又是Kubernetes最重要的能力。如果Kubernetes在其架构中检测到诸如：某个节点没响应了、或是某个容器未通过健康检查之类的问题出现时，它会根据既定的步骤执行重新创建相应涉及到的部分，一直到它们能够重新恢复运作为止。

这是非常有用的。如果群集中的某个部分因为某种原因而下线时，其对应的工作负载应当被重新分配，而且您甚至可以让Kubernetes重建整个服务器来解决问题。

三、您的应用程序架构是否需要更改?

有时候，在您的应用上采用Kubernetes，就像将一个方木钉打入一个圆孔中。

由于我的应用最初就是被构建为：通过多个容器的部署，产生一个多实例的平台，因此当被迁移到Kubernetes时，我并没有做太多的更改。

下面我分享一些在把自己的工作负载迁移到Kubernetes的过程中所学到的内容。

1.应用的启动时间很重要

当创建新的部署时，您必须等待应用启动之后，才能让最终用户可用。这样就会产生一个问题：如果在最终用户按下某个按钮的时刻，或是在您对所有客户实例上执行更新的那一刻，部署进程正好涉及到创建新的实例的话，那么就需要重新生成一些pod了。

因此在迁移到Kubernetes的时候，您可能需要对代码库进行一些更改，使得启动进程更为高效，以至于最终用户在使用您的产品时，不会产生体验上的下降。

2.调整多租户的架构比较困难

多租户架构意味着您拥有一个单独的应用实例，由它来管理分区租户环境中的所有最终用户，当然它通常会将单个数据库共享给每个人。

如果您的应用不是使用群集的方式构建的话(将多个服务器联合为单个实例)，那么您就不应该去使用Kubernetes。

通常在使用Kubernetes时，我们会采用两种类型的架构：

• 多实例架构，即为每个用户分配一个应用的实例
• 多租户架构，具有群集功能，能够对使用的资源进行向上扩展和向下缩减

相对于群集式的多租户架构而言，我个人更喜欢多实例的架构，因为它们更容易被实施。此外，相对于为多实例架构增加各种群集的能力，将多租户迁移到多实例架构所涉及的工作量要小得多。

3.迁移到无状态应用是一项浩大的工程

Kubernetes的一个重要特点是：在部署中具有向上扩展和向下缩减pod数量的能力。但是，如果您的应用程序既不是群集化的、又不是无状态的，那么此功能就等于浪费，因为在部署过程中，那些额外的pod既不会被正确地配置、又无法被使用到。

大多数情况下，由于您需要在应用中对其处理配置的方式进行重写，因此在Kubernetes中使用无状态的进程往往会得不偿失。

如果您不想花费时间将应用程序改成无状态或群集模式的话，那也没关系，毕竟Kubernetes能提供许多其他的方法，来帮助您改成有状态的部署模式。当然这些方法也会有其自身的各种问题，本文在此就不深入讨论了。

四、到底是否应该采用Kubernetes呢?

对于是否迁移Kubernetes这个问题，您应该考虑它是否真的适合于您当前的系统。对于大多数早期初创公司来说，可能不会需要Kubernetes;而对于一些更成熟的公司来说，他们可能已经在其他技术上有了大量的投入，因此迁移也是不太可行的。