你是否想过我们为什么要使用容器部署多平台应用呢？难道这仅仅是“跟风”吗？在本文中，我将提出一些有挑战性的问题，以佐证我的观点，那就是为什么说Kubernetes是新的应用服务器。
你可能已经注意到了，大多数的语言都是要经过“解释（interpret）”的，并且使用“运行时”来执行源码。在理论上，大多数的Node.js、Python和Ruby代码可以很容易地从一个平台（Windows、Mac、Linux）转换到另一个平台。Java应用则更进一步，它将编译后的Java类转换成了字节码，能够在任何具有JVM（Java虚拟机）的地方运行。
Java生态系统提供了标准的格式来分发同一个应用中的所有Java类。我们可以将这些类打包为JAR（Java Archive）、WAR（Web Archive）以及EAR（Enterprise Archive），在这些格式中包含了前端、后端以及嵌入其中的库。那么我就要问了：你为什么要使用容器来分发Java应用呢？难道它不是已经支持很便利地在不同环境间迁移了吗？
站在开发人员的角度回答这个问题的话，答案可能并不那么明显。但是，我们考虑一下你的开发环境，以及因为开发环境和生产环境的差异可能导致的问题：
你使用Mac、Windows还是Linux？在路径分隔符方面有没有遇到过\和/相关的问题？
你使用什么版本的JDK？是否在开发环境使用Java 10，而在生产环境使用JRE 8？你有没有遇到过JVM差异所引入的bug？
你使用什么版本的应用服务器？生产环境是否使用相同的配置、安全补丁和相同版本的库？
在生产部署的时候，是否遇到过不同版本的驱动或数据库服务器所导致的JDBC驱动问题，而这些问题在开发环境可能并不存在？
你是否请求过应用服务器管理员为你创建数据源或JMS队列，但是在创建的过程中却出现了拼写错误？
所有的这些问题都是由应用之外的因素导致的，容器最大的好处之一就是它能够在一个预先构建的容器中部署所有的内容（比如Linux发行版、JVM、应用服务器、库、配置，最后还有你的应用）。另外，在一个容器中将所有的东西都包含进来能够更容易地将你的代码转移到生产环境中，在它无法正常运行的时候，也更容易分析其中的差异。因为它易于执行，所以也很容易将相同的容器镜像扩展至多个副本。
强化应用在容器流行起来之前，应用服务器提供了一些，比如安全性、隔离性、容错、配置管理等等。打个比方，应用服务器和应用之间的关系就像CD播放器和CD之间的关系一样。
作为开发人员，你应该遵循预定义的标准并按照特定的格式分发应用，而应用服务器会“执行”你的应用并带来一些额外的功能，这些功能因服务器“品牌”的差异而有所不同。注意：在Java领域，应用服务器所提供的企业功能的标准最近转移到了Eclipse基金会。Eclipse Enterprise for Java（EE4J）的工作形成了Jakarta EE。（关于这方面的更多信息，请阅读Jakarta EE官方发布的文章或观看DevNation视频：Jakarta EE：Java EE的未来）。
与CD播放器的类比方式相似，随着容器的流行，容器镜像成为了新的CD格式。实际上，容器镜像仅仅是用来分发容器的格式。（如果你需要更深入地了解容器镜像是什么以及它们如何进行分发的话，请参见容器术语的实用简介。）
容器的真正收益在你需要为应用添加企业级功能时才体现出来。为容器化的应用提供这些功能的最佳方式就是使用Kubernetes作为它们的平台。另外，Kubernetes平台还为其他项目提供了很棒的基础实施，这些项目包括Red Hat OpenShift、Istio以及Apache OpenWhisk，基于这些基础设施能够更容易的构建和部署健壮的生产级质量的应用。
接下来，我们探讨九个这样的功能：
