为什么说Kubernetes是新的应用服务器

本文最初发表于 RedHat开发者博客 ，经原作者Rafael Benevides授权由InfoQ中文站翻译分享。

你是否想过我们为什么要使用容器部署多平台应用呢？难道这仅仅是“跟风”吗？在本文中，我将提出一些有挑战性的问题，以佐证我的观点，那就是为什么说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、应用服务器、库、配置，最后还有你的应用）。另外，在一个容器中将所有的东西都包含进来能够更容易地将你的代码转移到生产环境中，在它无法正常运行的时候，也更容易分析其中的差异。因为它易于执行，所以也很容易将相同的容器镜像扩展至多个副本。

强化应用

在容器流行起来之前，应用服务器提供了一些 非功能性需求（NFR，non-functional requirement） ，比如安全性、隔离性、容错、配置管理等等。打个比方，应用服务器和应用之间的关系就像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 ，基于这些基础设施能够更容易的构建和部署健壮的生产级质量的应用。

接下来，我们探讨九个这样的功能：

1.服务发现

服务发现指的是确定如何连接服务的过程。要获得容器以及云原生应用的很多收益，我们需要将配置从容器镜像中移除出去，这样的话，我们就能把相同的容器镜像应用到所有的环境中。将配置提取到应用外部是 12要素应用 的核心原则之一。服务发现是从运行时环境中获取配置信息的方式之一，这样能够避免将其硬编码到应用之中。Kubernetes自带了 服务发现 。Kubernetes还提供了 ConfigMaps 和[Secrets] ( https://kubernetes.io/docs/concepts/configuration/secret/ )用来将配置从应用容器中移除。在运行时环境中，如果要连接数据库这样的服务，我们会存储凭证信息，Secrets解决了一些这方面所面临的挑战。

借助Kubernetes，我们无需使用外部的服务器或框架。尽管我们可以通过Kubernetes YAML文件管理每个运行时环境的配置，但是Red Hat OpenShift提供了GUI和CLI，能够让DevOps团队更容易地管理配置信息。

2.基本调用

容器中的应用可以通过 Ingress 进行访问，也就是从外部世界路由到你所暴露的服务。OpenShift提供了基于HAProxy的 route objects ，它具有各项功能和负载均衡策略。你可以使用路由功能进行轮流部署。这可以作为一些非常复杂的CI/CD策略的基础。参见下文的“6.构建和部署管道”。

如果你想运行一次性的任务，比如一个批处理或者只是使用集群来计算一个结果（比如计算Pi的位数），那该怎么办呢？针对这种场景，Kubernetes提供了 job objects 。同时还有一个 cron job ，能够管理基于时间的任务。

3.弹性

在Kubernetes中，弹性（elasticity）是通过 ReplicaSets （它过去被称为Replication Controllers）解决的。与面向Kubernetes的大多数配置类似，ReplicaSet是一种协调所需状态的方式：你告诉Kubernetes，系统应该处于各种状态，Kubernetes就能知道如何达到该状态。在任意时间，ReplicaSet都能控制副本的数量或应用程序精确的实例数量。

但是，如果你所构建的服务受欢迎程度超出了预先的规划，计算资源耗尽了该怎么办呢？你可以借助Kubernetes Horizontal Pod Autoscaler ，它会基于观测到的CPU利用率（或所支持的 自定义指标 ，以及应用提供的指标）扩展pod的数量。

4.日志

因为Kubernetes集群能够运行容器化应用的多个副本，所以将这些日志聚合起来，以便于在同一个地方进行查看就变得非常重要了。同时，为了利用自动扩展（以及其他云原生应用的功能）所带来的收益，容器应该是不可变的。所以，我们应该将日志存储在容器之外，这样它们才能跨运行时持久化。OpenShift允许我们部署EFK技术栈来聚合来自主机和应用的日志，即便这些日志来自多个容器甚至已删除的pod均是可以的。

EFK技术栈的组成如下所示：

• Elasticsearch （ES），存储日志内容的对象存储；
• Fluentd ，从节点收集日志并将其发送至Elasticsearch
• Kibana ，针对Elasticsearch的Web UI。

5.监控

尽管日志和监控看上去解决的是相同的问题，但是它们之间是不同的。监控是观察、检查、通常还有告警以及记录，而日志则只有记录。

Prometheus 是一个开源的监控系统，它包含了时序数据库。它可以用来存储和查询指标、告警，并使用可视化的方式查看系统内部的运行状况。Prometheus可能是监控Kubernetes集群方面最流行的可选方案。在 Red Hat开发人员博客 上，有多篇介绍使用 Prometheus 进行监控的文章。在 OpenShift博客 上，也能找到关于Prometheus的文章。

你还可以看到Prometheus和Istio实际结合使用的 教程 。

6.构建和部署管道

对于你的应用来说，CI/CD（持续集成/持续交付）并不是“必备”的要求。但是，CI/CD通常被认为是成功软件开发和 DevOps 实践的支柱。如果没有经过CI/CD管道的话，软件不应该发布到生产环境中。Jez Humble和David Farley合著的《持续交付：发布可靠软件的系统方法》中是这样描述CD的：“持续交付能够将各种类型的变更发布到生产环境中，包括新特性、配置变化、缺陷修正以及体验性的功能，或者说以可持续的方式将这些变更安全且快速地交到用户的手里”。

OpenShift内置提供了CI/CD管道，将其作为“ 构建策略 ”。读者可以查看我两年前录制的 视频 ，其中包含了部署一个全新微服务的Jenkins CI/CD管道样例。

7.适应性

Kubernetes为 集群本身 提供了适应性（resilience）方案，它还提供了 PersistentVolumes 来支持卷（volume）的副本，从而帮助应用实现适应性。Kubernetes的 ReplicationControllers /部署能够确保指定数量的pod副本在整个集群中始终正常运行，它会自动处理任何可能出现的 节点 故障。

结合适应性，容错能够作为一种有效的方式来处理用户对于可靠性和可用性的关切。运行在Kubernetes上的应用还可以通过 Istio 的重试规则、断路器和池弹射（pool ejection，即移除掉出现故障的容器——译注）来实现容错。如果你想自行了解一下的话，可以尝试Istio Circuit Breaker的 教程 。

8.认证

在Kubernetes中，认证可以通过Istio的 mutual TLS认证 来实现，它致力于增强微服务及其通信的安全性，而无需服务代码的变更。它会负责：

• 为每个服务提供一个代表其角色的强标识（identity），从而允许它能够跨集群和云进行互操作；
• 保护服务与服务之间的通信，以及终端用户与服务之间的通信；
• 提供key管理系统，自动化key和证书生成、分发、轮换和撤销。

另外，值得一提的是，我们还可以在Kubernetes/OpenShift集群中运行 Keycloak 以提供认证和授权。Keycloak是Red Hat Single Sign-on的上游产品。关于它的更多信息，请参阅 使用Keycloak简化单点登录 。如果你使用Spring Boot的话，还可以观看DevNation视频： 使用Keycloak保护Spring Boot微服务 或阅读 博客文章 。

9.跟踪

基于Istio的应用可以配置为使用 Zipkin 或 Jaeger 收集跟踪的span。不管使用什么语言、框架或平台来构建应用，Istio都能支持分布式跟踪。关于这方面的知识，可参考该 教程 。读者还可以参见“ 在笔记本电脑上掌握Istio和Jaeger的基础知识 ”以及最近的DevNation视频： 使用Jaeger进行高级的微服务跟踪 。

应用服务器会消亡吗？

通过这些功能，你就能意识到Kubernetes + OpenShift + Istio确实能够增强你的应用，并且提供了一些特性，这些特性以前都是由应用服务器或者像 Netflix OSS 这样的框架来负责的。这是否意味着应用服务器将会消亡呢？

在这个新的容器世界中，应用服务器正在变得越来越像框架。软件开发的演化很自然会导致应用服务器的演化。这种演化的一个例子就是 Eclipse MicroProfile 规范以及 WildFly Swarm 应用服务器，它为开发人员提供了各种特性，比如容错、配置、跟踪、REST（客户端和服务端）等等。WildFly Swarm和MicroProfile规范的设计是非常轻量级的，WildFly Swarm并不包含完整Java企业级应用服务器的各种各样的组件。相反，它关注微服务，只保留了将应用按照简单可执行的“.jar”文件进行构建和运行的功能。在该博客中，你可以阅读到关于 MicroProfile 的更多信息。

另外，Java应用还包括Servlet引擎、数据库池、依赖注入、事务、消息等特性。当然，框架可能会提供这些特性，但是应用服务器必须要具备在任何环境下构建、运行、部署和管理企业级应用所需的各种功能，不管它是不是在容器中运行。实际上，应用服务器可以在任何地方执行，例如，在裸机上、在像 Red Hat Virtualization 这样的虚拟化平台上、在像 Red Hat OpenStack平台 这样的私有云环境中以及在像 Microsoft Azure 或 Amazon Web Services 这样的公有云环境中。

好的应用服务器要确保它所提供的API和具体实现之间的一致性。开发人员可以确信如果他的业务逻辑需要特定的功能，他所部署的逻辑是正常运行的，因为应用服务器开发人员（以及预先定义的标准）能够保证它们之间能够协同工作和协同演化。另外，好的应用服务器还要负责最大化吞吐量和可扩展性，因为它要处理来自用户的所有请求；减少延迟并提升负载能力，它有助于提升应用的 可处置性 ；轻量级的资源占用，最小化硬件资源和成本；最后，还要足够安全，能够防范所有的安全漏洞。对于Java开发人员来说，Red Hat提供了 Red Hat JBoss企业级应用平台 ，满足了现代、模块化应用服务器的所有需求。

结论

容器镜像已经成为分发云原生应用的标准打包格式。尽管容器本身并没有为应用提供任何真正的业务优势，但是Kubernetes及其相关的项目，如OpenShift和Istio，提供了非功能性的需求，而这些需求过去曾是应用服务器的功能的一部分。

开发人员过去所使用的大多数非功能性需求，来源于应用服务器或者像 Netflix OSS 这样的库，这些需求是与特定语言绑定的，比如Java。但是，如果开发人员选择使用Kubernetes + OpenShift + Istio来满足这些需求的话，它们是与任何特定语言都没有关联的，这样的话就能鼓励开发人员针对每个使用场景选择最佳的技术/语言。

最后，在软件开发领域，应用服务器依然有它的位置。但是，它们变得更像是特定语言的框架，在开发应用的时候，这是很简便的，因为它们包含了大量已经编写就绪且经过测试的功能。

转移到容器、Kubernetes和微服务架构时，最棒的事情之一就是不必为应用选择单一的应用服务器、框架、架构风格甚至编程语言。你可以很容易地部署一个含有JBoss EAP的容器，让JBoss EAP运行已有的Java EE应用，其他的容器则可能会包含使用Wildfly Swarm编写的微服务或者使用Eclipse Vert.x编写的反应式程序。这些容器都可以通过Kubernetes进行管理。如果想了解这些概念如何实际运行，参考 Red Hat OpenShift应用运行时 。通过 Launch服务 在线构建和部署示例应用，这些应用可以使用WildFly Swarm、Vert.x、Spring Boot或Node.js。选择“Externalized Configuration”以便于学习如何使用Kubernetes ConfigMaps，这足以让你踏上学习云原生应用的征途。

你可以说 Kubernetes/OpenShift是新的Linux ，甚至可以说“Kubernetes是新的应用服务器”。但实际上，应用服务器/运行时+OpenShift/Kubernetes + Istio已经成为了云原生平台的事实标准。

关于作者

Rafael Benevides是 Red Hat 的开发者体验（Developer Experience）总监，具有多年的各领域IT行业经验，他帮助世界范围内的开发人员和公司提升软件开发的效率。Rafael将自己定位为问题解决者，并乐于分享。他是Apache DeltaSpike PMC成员，该项目曾获得过Duke’s Choice Award，他还会在JavaOne、Devoxx、TDC、DevNexus等技术会议上发表演讲。