为什么说Kubernetes是新的应用服务器？
|
EFK 技术栈的组成如下所示：
5. 监控 尽管日志和监控看上去解决的是相同的问题，但是它们之间是不同的。监控是观察、检查、通常还有告警以及记录，而日志则只有记录。 Prometheus 是一个开源的监控系统，它包含了时序数据库。它可以用来存储和查询指标、告警，并使用可视化的方式查看系统内部的运行状况。Prometheus 可能是监控 Kubernetes 集群方面最流行的可选方案。 6. 构建和部署管道 对于你的应用来说，CI/CD(持续集成 / 持续交付)并不是“必备”的要求。但是，CI/CD 通常被认为是成功软件开发和 DevOps 实践的支柱。如果没有经过 CI/CD 管道的话，软件不应该发布到生产环境中。Jez Humble 和 David Farley 合著的《持续交付：发布可靠软件的系统方法》中是这样描述 CD 的：“持续交付能够将各种类型的变更发布到生产环境中，包括新特性、配置变化、缺陷修正以及体验性的功能，或者说以可持续的方式将这些变更安全且快速地交到用户的手里”。 7. 适应性 Kubernetes 为集群本身提供了适应性(resilience)方案，它还提供了 PersistentVolumes 来支持卷(volume)的副本，从而帮助应用实现适应性。Kubernetes 的 ReplicationControllers/ 部署能够确保指定数量的 pod 副本在整个集群中始终正常运行，它会自动处理任何可能出现的节点故障。 结合适应性，容错能够作为一种有效的方式来处理用户对于可靠性和可用性的关切。运行在 Kubernetes 上的应用还可以通过 Istio 的重试规则、断路器和池弹射(pool ejection，即移除掉出现故障的容器——译注)来实现容错。 8. 认证 在 Kubernetes 中，认证可以通过 Istio 的 mutual TLS 认证来实现，它致力于增强微服务及其通信的安全性，而无需服务代码的变更。它会负责： 为每个服务提供一个代表其角色的强标识(identity)，从而允许它能够跨集群和云进行互操作; 保护服务与服务之间的通信，以及终端用户与服务之间的通信; 提供 key 管理系统，自动化 key 和证书生成、分发、轮换和撤销。 另外，值得一提的是，我们还可以在 Kubernetes/OpenShift 集群中运行 Keycloak 以提供认证和授权。Keycloak 是 Red Hat Single Sign-on 的上游产品。 9. 跟踪 基于 Istio 的应用可以配置为使用 Zipkin 或 Jaeger 收集跟踪的 span。不管使用什么语言、框架或平台来构建应用，Istio 都能支持分布式跟踪。 应用服务器会消亡吗? 通过这些功能，你就能意识到 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 应用运行时。 你可以说 Kubernetes/OpenShift 是新的 Linux，甚至可以说“Kubernetes 是新的应用服务器”。但实际上，应用服务器 / 运行时 +OpenShift/Kubernetes + Istio 已经成为了云原生平台的事实标准。 关于作者 （编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |