五种方法判断Kubernetes是否适合你的应用 原创

尽管Kubernetes是一项优秀的技术,但它远不是适合所有应用部署的最佳解决方案。

很多情况下,应用程序现代化的路径是这样的:首先,将应用重构为微服务;接下来,将每个服务容器化;最后,将其部署在Kubernetes上。Kubernetes是一种开源的编排引擎,已经成为运行容器化应用的一种事实标准平台。

问题是,并非所有的现代化都遵循这种路径。很多情况下,Kubernetes并不是现代软件部署之旅的一部分。

尽管Kubernetes是一项优秀的技术,但它远不是适合所有应用部署的最佳解决方案。即使你的应用使用容器作为微服务运行,Kubernetes也不一定是部署这些应用的最佳方式,还有其他更简单的解决方案(例如Amazon ECS或者Lambda)可以用于运行容器。而且,如果你的应用根本不是一组微服务,那么Kubernetes显然也不是运行这些应用的一个好方式。

那么,哪些类型的应用实际上可以通过Kubernetes运行呢?应用具备哪些功能要求或者架构特征的情况下特别适合采用K8(Kubernetes追随者有时候对该平台的叫法)呢,或者反过来,更适合采用替代性的托管解决方案呢?

本文通过介绍使用Kubernetes部署应用之前应该具备的五个关键因素来回答这些问题。我们还将研究Kubernetes工作负载的“反模式”,即团队在选择是否用K8来运行给定工作负载时经常犯的一些错误。

如何判断你的应用是否适合Kubernetes?

在评估应用是否适合通过Kubernetes进行部署的时候,请考虑Kuberbetes与以下每个特征的匹配程度。

1、你的应用是作为小型的、简洁的、独立的可扩展服务运行的

当应用作为一组小型的、简洁的服务运行的时候,它就非常适合Kubernetes。主要原因是Kubernetes可以独立地动态扩展每个服务,反过来意味着你的应用可以最有效地利用可用的托管资源。

相反,作为“单体”运行的应用(也就是说整个应用是作为单一服务运行的)并不能从Kubernetes中受益。选择在K8上运行单体应用,就意味着与选择更简单的部署模型(例如在独立虚拟机上运行该应用)相比,你将面临更多的复杂性,而且也不会获得很多好处,因为单体应用是无法进行细粒度或者动态扩展的。

2、你的应用是与硬件无关的

不需要特定硬件配置的应用可以很好地运行在Kubernetes上,因为你可以使用K8s设置服务器集群并在这些集群之间部署应用。Kubernetes会决定在集群中放置每个应用的位置,并根据需要为应用分配资源。或者,你可以(通常应该可以)定义Kubernetes在部署时应该分配给每个应用的资源最小值。

另一方面,如果你的应用需要严格的CPU或者内存分配(或者需要访问专用硬件设备例如GPU),那么通常把应用直接部署在虚拟机要比K8s集群更有意义。

3、你的应用是众多应用之一,而且这些应用可以在共享基础设施上共存

Kubernetes允许你使用称为命名空间的功能把工作负载彼此分割,命名空间本质上是你可以在单个服务器集群中进行定义的虚拟边界。但是,Kubernetes并不提供在专用虚拟机或者是物理服务器上运行每个应用所获得的“硬”应用隔离。

这意味着,如果你有大量可以共享服务器集群的工作负载,而且每个工作负载都运行着自己的虚拟环境,那么Kubernetes非常适合,而如果你需要工作负载之间有坚如磐石的隔离,那么K8就不是那么好了。如果你只有少量的工作负载,这也没有多大意义,在这种情况下,设置和管理Kubernetes的难度要超过它能带来的价值。

4、你的应用运行多个服务,有些是内部的,有些是外部的

通常,现代应用中只有一些微服务需要是外部的,意味着可以连接到应用外部(但仍在公司网络内部)的资源,而其他服务(例如在应用前端和后端数据库之间内部移动数据的服务)则不需要连接到应用或者是托管这些应用的服务器集群外部。

Kubernetes是此类应用的绝佳解决方案,因为Kubernetes让你能够以细粒度的方式定义哪些服务将面向公司网络,哪些服务仅限内部,而且真正重要的是,它让你可以保存企业网络IP地址,这一点很重要,因为IP地址在企业环境中通常是有限供应的。

5、你的应用需要自定义DNS设置

Kubernetes让管理员可以很好地控制网络名称的解析方式,这对于那些需要自定义域名设置(而不是使用通用DNS服务器)将IP地址映射到主机或服务名称的应用来说非常有用。

大多数传统应用并不需要特殊的DNS设置。但是在手动设置DNS配置的企业环境中,或者对于具有大量需要特殊DNS设置的内部服务应用来说,Kubernetes是很有用处的,因为Kubernetes提供了对DNS一定程度的控制和灵活性,而这在其他类型托管环境中是不具备的。

在什么情况下你绝不应该使用Kubernetes

为了在是否使用Kubernetes的决策过程中多考虑一些背景信息,让我们来看一下什么时候我们不走K8路线的一个例子。

当你有一个单体应用的时候,你决定把它放到Docker容器中。尽管从技术角度来看,Kubernetes能够运行你的容器化单体,但选择在Kubernetes上部署这类应用会让你面临很多挑战,而且几乎不会带来任何好处。

你的应用将无法有效地消耗主机资源,因为Kubernetes无法对应用的不同部分进行单独的扩展。这个应用作为一个整体,只能整体地横向或者是纵向扩展。

你的容器化单体也可能需要在不同的交付阶段(例如开发、测试和生产)进行不同的配置,这意味着你将无法享受到容器在一致性配置方面带来的好处,例如由于配置错误导致的故障几率会降低。

最糟糕的是,你最终也许不得不把安全配置数据(例如访问凭证)拷贝到你的单体容器映像中,这无形中增加了敏感信息落入坏人之手的风险。

底线是,虽然从技术上讲没有什么能够阻止你在Kubernetes以容器的形式运行单体应用,但这么做绝对不是一个好主意。这是在Kubernetes上获取应用的一种方式,但客观上来说这是一种糟糕的方式。

最后,我要强调的是,我并不是反对Kubernetes。Kubernetes确实可以提供很多东西,特别是对于那些以离散微服务的方式运行的应用,这些应用可以在共享集群上运行良好,并且需要特殊的网络配置。

但对于其他应用来说,很可能存在一种替代性的部署解决方案,它的设置和管理都要比Kubernetes更简单,同时还能提供更高的性能、可扩展性和成本节约优势。在你仅仅因为其他人都这么做而加入Kubernetes潮流之前,重要的是退后一步,想想哪种部署策略最适合你特定的应用,而不是最流行的那种。

来源:至顶网软件与服务频道

0赞

好文章,需要你的鼓励

2022

11/10

11:28

分享

点赞

邮件订阅