很多情况下，应用程序现代化的路径是这样的：首先，将应用重构为微服务；接下来，将每个服务容器化；{BANNED}最佳后，将其部署在Kubernetes上。Kubernetes是一种开源的编排引擎，已经成为运行容器化应用的一种事实标准平台。
问题是，并非所有的现代化都遵循这种路径。很多情况下，Kubernetes并不是现代软件部署之旅的一部分。
尽管Kubernetes是一项优秀的技术，但它远不是适合所有应用部署的{BANNED}最佳佳解决方案。即使你的应用使用容器作为微服务运行，Kubernetes也不一定是部署这些应用的{BANNED}最佳佳方式，还有其他更简单的解决方案（例如Amazon ECS或者Lambda）可以用于运行容器。而且，如果你的应用根本不是一组微服务，那么Kubernetes显然也不是运行这些应用的一个好方式。
那么，哪些类型的应用实际上可以通过Kubernetes运行呢？应用具备哪些功能要求或者架构特征的情况下特别适合采用K8（Kubernetes追随者有时候对该平台的叫法）呢，或者反过来，更适合采用替代性的托管解决方案呢？
本文通过介绍使用Kubernetes部署应用之前应该具备的五个关键因素来回答这些问题。我们还将研究Kubernetes工作负载的“反模式”，即团队在选择是否用K8来运行给定工作负载时经常犯的一些错误。
如何判断你的应用是否适合Kubernetes？
在评估应用是否适合通过Kubernetes进行部署的时候，请考虑Kuberbetes与以下每个特征的匹配程度。
1、你的应用是作为小型的、简洁的、独立的可扩展服务运行的
当应用作为一组小型的、简洁的服务运行的时候，它就非常适合Kubernetes。主要原因是Kubernetes可以独立地动态扩展每个服务，反过来意味着你的应用可以{BANNED}最佳有效地利用可用的托管资源。
相反，作为“单体”运行的应用（也就是说整个应用是作为单一服务运行的）并不能从Kubernetes中受益。选择在K8上运行单体应用，就意味着与选择更简单的部署模型（例如在独立虚拟机上运行该应用）相比，你将面临更多的复杂性，而且也不会获得很多好处，因为单体应用是无法进行细粒度或者动态扩展的。
2、你的应用是与硬件无关的
不需要特定硬件配置的应用可以很好地运行在Kubernetes上，因为你可以使用K8s设置服务器集群并在这些集群之间部署应用。Kubernetes会决定在集群中放置每个应用的位置，并根据需要为应用分配资源。或者，你可以（通常应该可以）定义Kubernetes在部署时应该分配给每个应用的资源{BANNED}最佳小值。
另一方面，如果你的应用需要严格的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无法对应用的不同部分进行单独的扩展。这个应用作为一个整体，只能整体地横向或者是纵向扩展。
你的容器化单体也可能需要在不同的交付阶段（例如开发、测试和生产）进行不同的配置，这意味着你将无法享受到容器在一致性配置方面带来的好处，例如由于配置错误导致的故障几率会降低。
{BANNED}最佳糟糕的是，你{BANNED}最佳终也许不得不把安全配置数据（例如访问凭证）拷贝到你的单体容器映像中，这无形中增加了敏感信息落入坏人之手的风险。
底线是，虽然从技术上讲没有什么能够阻止你在Kubernetes以容器的形式运行单体应用，但这么做绝对不是一个好主意。这是在Kubernetes上获取应用的一种方式，但客观上来说这是一种糟糕的方式。
{BANNED}最佳后，我要强调的是，我并不是反对Kubernetes。Kubernetes确实可以提供很多东西，特别是对于那些以离散微服务的方式运行的应用，这些应用可以在共享集群上运行良好，并且需要特殊的网络配置。
但对于其他应用来说，很可能存在一种替代性的部署解决方案，它的设置和管理都要比Kubernetes更简单，同时还能提供更高的性能、可扩展性和成本节约优势。在你仅仅因为其他人都这么做而加入Kubernetes潮流之前，重要的是退后一步，想想哪种部署策略{BANNED}最佳适合你特定的应用，而不是{BANNED}最佳流行的那种。《linux就该这么学》不错的linux自学书籍