Java开发人员如何从JavaEE走上Kubernetes-native(K8s原生)之路 - JAXenter

20-05-27 banq

企业软件开发一直是软件工程最令人兴奋的领域之一,但是,最近十年是一个特别迷人的时期。在2010年代,高度分散的微服务逐渐取代了传统的三层体系结构,基于云的基础设施几乎无限的资源将重量级的应用服务器推向淘汰。

微服务可以在没有重量级运行时环境的情况下运行,因此使用的资源大大减少。部署微服务的最佳方法之一是通过容器,我们可以将其视为小型虚拟机。容器与虚拟机之间最重要的区别是容器不包含操作系统,而是在操作系统内核的用户空间中运行。这使容器在操作系统方面成为准虚拟化,这意味着多个容器可以在一台主机上运行。

除此之外,在容器环境中具有服务的分布式体系结构每个服务需要多个容器。这意味着我们经常有大量的容器,这些容器也必须以协调的方式启动和操作。这是一项巨大的管理工作–想象一下必须从命令行手动启动每个容器。值得庆幸的是,这也是Kubernetes发挥作用的地方。

配置Kubernetes原生环境

Kubernetes协调系统中所有容器之间的关系,例如通信和资源分配。Kubernetes如同一个海港的港口管理员,两者都负责确保大量独立的“船”在有限的空间内同时移动。

这是一项复杂的工作。不过,值得庆幸的是,想要使应用程序适合Kubernetes的开发人员不需要设置无尽的参数列表。相反,开发人员可以通过写出YAML格式的文本配置文件来设置Kubernetes集群,集群中对象的每个规范都在配置文件中详细定义。编写YAML配置文件的风险来自人为错误,考虑到手动键入文件,这是相当大的。尽管存在这种风险,尽管Kubernetes现在可以使用JSON格式的文件,但是YAML仍然是使用的配置文件类型的领导者。

与经典的企业软件开发相比,这一切感觉就像一个新世界。通过大量的抽象,我们可以将Kubernetes本地化(即充分利用Kubernetes的功能)与著名的Java EE应用服务器进行比较。这是因为Kubernetes原生和Java EE安装程序都在分布式物理硬件上运行其应用程序部分。

但是,乍一看,这种在Kubernetes原生和Java EE之间进行的比较是可以接受的,因为容器和Kubernetes系统对应用程序需求本身的关心相对较少。Kubernetes或容器仅提供对硬件配置和抽象的支持-它们不提供对事务或其他编程接口的支持。

用于本地Kubernetes配置的硬件

到目前为止,Kubernetes集群运行的硬件要求尚未确定。为了利用Kubernetes集群提供的高可伸缩性和可靠性的优势,开发人员需要为其分配足够的系统资源。

如果假设一个集群有两个具有2 GB的RAM和4个核心的主节点,以及两个具有1 GB的RAM和2个核心的工作节点,那么Kubernetes集群至少需要6 GB的ram和12个核心。绝对不是可以在大多数台式机上轻松运行的东西。尽管在桌面环境上运行不是Kubernetes的目标,但是开发人员理应正确地想找到一种在本地使用Kubernetes进行开发的方法。

幸运的是,现在有许多较小的学习环境使之成为可能。这些包括MiniKube,MicroK8和OpenShift CodeReady容器,它们都是将Kubernetes带到桌面的单节点集群。根据所选的环境,这样的安装可以在几分钟内完成,开发人员可以开始在本地工作。

为了在更复杂的环境(包括交互)中测试服务,通常没有办法围绕真正的Kubernetes集群。但是,有一些代码就绪容器之类的工具 可以使开发人员的生活更轻松,其中包括Kubernetes群集的全部工具和单节点安装。

Kubernetes的开发人员经验与旧的完全集成的应用程序服务器世界截然不同。虽然使用Kubernetes原生语言是简化开发人员的合乎逻辑的下一步,但这确实意味着要跳到一个更加抽象和复杂的世界。

Kubernetes原生世界也更加灵活。在Kubernetes原生开发的辅助工具仍处于起步阶段时,它也为开发人员提出了一系列引人入胜的新挑战

                   

1
猜你喜欢