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

你有没有想过为什么要使用容器部署多平台应用程序？这只是“追随炒作”的问题吗？在本文中，我将提出一些挑衅性的问题来说明为什么Kubernetes是新的应用程序服务器。

您可能已经注意到大多数语言都被解释并使用“运行时”来执行源代码。理论上，大多数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差异引入的任何错误？
• 您使用的是哪个版本的应用程序服务器？生产环境是使用相同的配置，安全修补程序和库版本吗？
• 在生产部署期间，您是否遇到过由于驱动程序或数据库服务器的不同版本而未在开发环境中遇到的JDBC驱动程序问题？
• 你有没有要求应用服务器管理员创建一个数据源或一个JMS队列，它有一个错字？

上面的所有问题都是由应用程序外部的因素引起的，容器的最大优点之一是您可以部署所有内容（例如，Linux发行版，JVM，应用程序服务器，库，配置，最后，您的应用程序）在预先构建的容器内。此外，执行一个内置了所有内容的容器比将代码移动到生产环境并尝试在不起作用时解决差异要容易得多。由于它易于执行，因此也可以轻松地将同一容器映像扩展为多个副本。

增强您的应用程序

在容器变得非常流行之前，应用程序服务器提供了几个 NFR（非功能性要求）， 例如安全性，隔离性，容错性，配置管理等。作为类比，应用服务器类似CD（光盘）播放器对CD的应用。

作为开发人员，您将负责遵循预定义的标准并以特定格式分发应用程序，而另一方面，应用程序服务器将“执行”您的应用程序并提供可能因不同“品牌”而异的其他功能。 ：在Java世界中，应用程序服务器提供的企业功能标准最近已在Eclipse基础之下发生变化。关于Eclipse Enterprise for Java（ EE4J ）的工作已经产生了   Jakarta EE 。

按照类似CD播放器作为类比，随着容器的提升， 容器镜像 已成为新的CD格式。实际上，容器镜像只不过是用于分发容器的格式。

当您需要向应用程序添加企业功能时，容器的真正好处就会发生。为容器化应用程序提供这些功能的最佳方法是使用Kubernetes作为它们的平台。此外，Kubernetes平台为其他项目（如 Red Hat OpenShift ， Istio 和 Apache OpenWhisk） 提供了良好的基础，可以构建和部署强大的生产质量应用程序。

让我们探讨其中的九个功能：

1 - 服务发现

服务发现是确定如何连接服务的过程。要获得容器和云原生应用程序的许多好处，您需要从容器映像中删除配置，以便在所有环境中使用相同的容器映像。应用程序的外部化配置是 12因子应用程序 的关键原则之一。

。服务发现是从运行时环境获取配置信息的方法之一，而不是在应用程序中进行硬编码。Kubernetes提供开箱即用的 服务发现 。Kubernetes还提供 ConfigMaps 和 Secrets 从应用程序容器中删除配置。当您需要存储用于连接到运行时环境中的数据库之类的服务的凭证时，秘密可以解决一些挑战。

使用Kubernetes，无需使用外部服务器或框架。可以通过Kubernetes YAML文件管理每个运行时环境的环境设置。

2 - 基本调用

可以通过 Ingress 访问来访问在容器内运行的应用程序 - 换句话说，从外部世界到您正在公开的服务的路由。

如果您需要运行一次性作业（例如批处理），或者只是利用群集来计算结果（例如计算Pi的数字），该怎么办？Kubernetes 为此用例提供了 作业对象 。还有一个管理基于时间的工作的 cron工作 。

3 - 弹性

通过使用 ReplicaSets （以前称为复制控制器）在Kubernetes中解决弹性问题。就像Kubernetes的大多数配置一样，ReplicaSet是一种协调所需状态的方法：你告诉Kubernetes系统应该处于什么状态，Kubernetes会弄清楚如何制作它。ReplicaSet控制应该在任何时间运行的应用程序的副本数或精确副本数。

但是，如果您构建的服务比您计划的更受欢迎并且计算机耗尽，会发生什么？您可以使用Kubernetes Horizo​​ntal Pod Autoscaler ，它根据观察到的CPU利用率

4 - 记录

由于您的Kubernetes集群可以并将运行容器化应用程序的多个副本，因此汇总这些日志以便在一个位置查看它们非常重要。此外，为了利用自动缩放（以及其他云原生功能）等优势，您的容器必须是不可变的。因此，您需要将日志存储在容器之外，以便它们在运行期间保持不变。

EFK堆栈包括：

• Elasticsearch （ES），一个存储所有日志的对象存储库
• Fluentd ，从节点收集日志并将其提供给Elasticsearch
• Kibana ，Elasticsearch的Web UI

5 - 监测

虽然日志记录和监控似乎解决了同样的问题，但它们彼此不同。监控是观察，检查，经常警报以及记录。记录仅记录。

Prometheus 是一个开源监控系统，包括时间序列数据库。它可用于存储和查询指标，警报和使用可视化，以深入了解您的系统。 Prometheus 可能是监测Kubernetes集群最受欢迎的选择。

6 - 构建和部署管道

CI / CD（持续集成/持续交付）管道不是您的应用程序的严格“必须”要求。但是，CI / CD通常被认为是成功的软件开发和 DevOps 实践的支柱。没有CI / CD管道，不应将任何软件部署到生产环境中。由Jez Humble和David Farley 撰写的“  持续交付：通过构建，测试和部署自动化发布的可靠软件 ”一书对CD说：“持续交付是能够更改所有类型 - 包括新功能，配置更改，错误以可持续的方式安全快速地修复和实验 - 进入生产或用户手中。“

7 - 恢复力

虽然Kubernetes为 群集本身 提供了弹性选项，但它还可以通过提供支持复制卷的 PersistentVolumes 来帮助应用程序恢复弹性。Kubernetes的 ReplicationControllers / deploymentments确保在群集中一致地部署指定数量的pod副本，从而自动处理任何可能的 节点 故障。

与弹性一起，容错是解决用户可靠性和可用性问题的有效手段。通过其重试规则，断路​​器和池弹出，也可以通过 Istio 在Kubernetes上运行的应用程序提供容错。你想亲眼看看吗？请参阅 https://learn.openshift.com/servicemesh/7-circuit-breaker上 的Istio Circuit Breaker教程。

8 - 认证

Istio还可以通过其 相互TLS身份验证 来提供Kubernetes中的 身份验证 ，该 身份验证 旨在增强微服务及其通信的安全性，而无需更改服务代码。它负责：

• 为每个服务提供强大的身份，代表其角色，以实现跨群集和云的互操作性
• 确保服务到服务通信和最终用户到服务通信
• 提供密钥管理系统，以自动化密钥和证书生成，分发，轮换和撤销

9 - 追踪

可以将启用了Istio的应用程序配置为使用 Zipkin 或 Jaeger 收集跟踪跨度。无论您使用何种语言，框架或平台构建应用程序，Istio都可以启用分布式跟踪。

应用程序服务器死了吗

通过这些功能，您可以了解Kubernetes + OpenShift + Istio如何真正为您的应用程序提供支持，并提供以前由应用程序服务器或 Netflix OSS 等软件框架负责的功能  。这是否意味着应用服务器已经死了？

在这个新的集装箱化世界中，应用服务器正在变得更像框架。软件开发的发展很自然地导致了应用服务器的发展。这种演变的一个很好的例子是具有 WildFly Swarm 的 Eclipse MicroProfile 规范作为应用程序服务器，它为开发人员提供容错，配置，跟踪，REST（客户端和服务器）等功能。但是，WildFly Swarm和MicroProfile规范设计得非常轻巧。WildFly Swarm没有完整的Java企业应用程序服务器所需的大量组件。相反，它专注于微服务，并拥有足够的应用程序服务器来构建和运行您的应用程序作为一个简单的可执行.jar文件。

此外，Java应用程序可以具有诸如Servlet引擎，数据源池，依赖注入，事务，消息传递等功能。当然，框架可以提供这些功能，但是应用程序服务器还必须拥有在任何环境中构建，运行，部署和管理企业应用程序所需的一切，无论它们是否在容器内。事实上，应用服务器可以在任何地方执行，例如，裸机，虚拟化平台（如 Red Hat Virtualization） ，私有云环境（如   Red Hat OpenStack Platform） ，以及公共云环境（如   Microsoft Azure 或 Amazon Web）服务 。

良好的应用程序服务器可确保提供的API与其实现之间的一致性。开发人员可以确定部署其业务逻辑（需要某些功能）将起作用，因为应用程序服务器开发人员（以及定义的标准）已确保这些组件协同工作并一起发展。此外，一个好的应用服务器还负责最大化吞吐量和可扩展性，因为它将处理来自用户的所有请求; 减少延迟并缩短加载时间，因为它有助于您的应用程序的 可处置性 ; 重量轻，占地面积小，可最大限度地减少硬件资源和成本; 最后，要足够安全以避免任何安全漏洞。

结论

容器镜像已成为分发云原生应用程序的标准打包格式。虽然容器“本身”不能为应用程序提供真正的业务优势，但Kubernetes及其相关项目（如OpenShift和Istio）提供了以前属于应用程序服务器的非功能性需求。

开发人员过去从应用程序服务器或诸如 Netflix OSS之 类的库中获得的大多数非功能性需求  都绑定到特定语言，例如Java。另一方面，当开发人员选择使用Kubernetes + OpenShift + Istio满足这些要求时，他们不会附加到任何特定语言，这可以鼓励为每个用例使用最佳技术/语言。

最后，应用服务器仍然在软件开发中占有一席之地。但是，它们正在变得更像是特定于语言的框架，这是开发应用程序时的一个很好的捷径，因为它们包含许多已经编写和测试过的功能。

迁移到容器，Kubernetes和微服务的最好的事情之一是，您不必为您的应用程序选择单个应用程序服务器，框架，架构风格甚至语言。您可以使用运行现有Java EE应用程序的JBoss EAP轻松部署容器，以及使用Wildfly Swarm或Eclipse Vert.x进行反应式编程的新微服务的其他容器。这些容器都可以通过Kubernetes进行管理。

你可以说 Kubernetes / OpenShift是新的Linux 甚至是：

“Kubernetes是新的应用程序服务器。”

但事实是应用程序服务器/运行时+ OpenShift / Kubernetes + Istio已成为“事实上的”云原生应用程序平台！