掌桥专利:专业的专利平台
掌桥专利
首页

基于Eureka服务注册与发现的Kubernetes调度方法

文献发布时间:2023-06-19 12:27:31


基于Eureka服务注册与发现的Kubernetes调度方法

技术领域

本公开的实施例一般涉及数据处理领域,并且更具体地,涉及一种基于Eureka服务注册与发现的Kubernetes调度方法。

背景技术

Eureka是Netflix开发的服务发现框架,本身是一个基于REST的服务。Eureka包含Eureka Server和Eureka Client两个组件,Eureka Server提供服务注册服务,EurekaClient会将信息注册到Eureka Server,然后各个Eureka Client间就能通过EurekaServer获取已经注册服务实例的节点位置信息和状态等信息。

SpringCloud是现有技术中常用的微服务架构。即,一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器和数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。。

Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的Linux或Windows机器上,也可以实现虚拟化。现有的很多服务都是以Docker镜像方式运行在各个服务器上,并且依赖Kubernetes来对服务镜像进行编排。

Kubernetes,是一个开源的、用于管理云平台中多个主机上的容器化的应用。Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。

当前,随着系统复杂度的提升,以及对系统扩展性的要求越来越高,传统的开发架构显然已不能满足开发要求。因此,开发者选择微服务架构(SpringCloud)进行应用开发已成为必然趋势。

但是,开发者利用微服务架构进行应用开发在实际操作过程中,技术人员发现了以下缺陷:

SpringCloud—Eureka服务注册与发现调度困难。即,利用SpringCloud框架进行开发和部署的服务通常都是紧耦合的,服务开发者通过各种方式定义本服务使用的存储资源及本服务依赖的服务资源,部署过程需要了解开发者对存储资源和服务资源的定义和组织结构。因此部署过程困难,难以实现服务的多次快速部署(由于服务部署过程的复杂性),以及实现真正意义上的一次部署多次使用。服务的部署和维护过程对实施和维护人员要求也非常高,不利于服务运营。

发明内容

根据本公开的实施例,提供了一种基于Eureka服务注册与发现的Kubernetes调度方案。

在本公开的第一方面,提供了一种基于Eureka服务注册与发现的Kubernetes调度方法。该方法包括:

从镜像仓库中调取基于Eureka构建的服务的镜像;

将所述服务的镜像部署到Kubernets集群节点的Pod中;

通过网关管理服务配置所述服务的域名;

将对所述域名的访问请求加载到对应的Pod中。

进一步地,所述镜像仓库为Harbor私有镜像仓库。

进一步地,所述服务的镜像包括:

master和worker服务的Docker镜像。

进一步地,基于Eureka构建服务时,使用IP地址进行服务注册。

进一步地,所述将所述服务的镜像部署到Kubernets集群中节点的Pod中包括:

采用Headless的部署方式将所述服务的镜像部署到Kubernets集群中的Pod中。

进一步地,所述通过网关管理服务配置所述服务的域名包括:

所述网关管理服务配置中Kubernetes部署文件的apiVersion选择ambassador/v1,资源类型选择Mapping。

进一步地,所述将对所述域名的访问请求加载到对应的Pod中包括:

通过负载均衡的方式将对所述域名的访问请求加载到对应的Pod中。

进一步地,所述负载均衡的方式包括轮询的访问方式。

在本公开的第二方面,提供了一种电子设备。该电子设备包括:存储器和处理器,所述存储器上存储有计算机程序,所述处理器执行所述程序时实现如以上所述的方法。

在本公开的第三方面,提供了一种计算机可读存储介质,其上存储有计算机程序,所述程序被处理器执行时实现如根据本公开的第一方面的方法。

本申请实施例提供的基于Eureka服务注册与发现的Kubernetes调度方法方法,通过从镜像仓库中调取基于Eureka构建的服务的镜像;将所述服务的镜像部署到Kubernets集群节点的Pod中;通过网关管理服务配置所述服务的域名;将对所述域名的访问请求加载到对应的Pod中,实现了可插入(Pluginable)、可迁移的(Portable)业务(Program)、数据(Data)和服务依赖(Service)的功能。

应当理解,发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征,亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。

附图说明

结合附图并参考以下详细说明,本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中,相同或相似的附图标记表示相同或相似的元素,其中:

图1是根据本申请的基于Eureka服务注册与发现的Kubernetes调度方法的一个实施例的流程图;

图2是根据本申请的基于Eureka服务注册与发现的Kubernetes调度方法中各服务镜像互相注册的示意图;

图3是用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中的附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本公开一部分实施例,而不是全部的实施例。基于本公开中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的全部其他实施例,都属于本公开保护的范围。

另外,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。

名词解析:

Pod-Kubernetes的基本单元。它可以由一个或多个容器组成,这些容器在同一个物理主机内,并共享相同的资源。在Pod内部署的所有容器都可以通过localhost看到其他容器。每个Pod在集群中具有唯一的IP地址。

Service-一组一起工作的Pod。默认情况下,Service在集群内部公开,但也可以暴露在集群外部的外部IP地址上。

需要说明的是,在本申请的实施例中均采用SpringCloud框架。

作为本申请的一个实施例,图1示出了基于Eureka服务注册与发现的Kubernetes调度方法的流程100,包括以下步骤:

S110,从镜像仓库中调取基于Eureka构建的服务的镜像。

其中,所述服务的镜像是通过下述方式构建的:

针对需要用到的服务,分别创建Docker镜像。执行Maven命令将项目编译成一个可执行JAR,创建构建Docker镜像需要的Dockerfile文件。即,将Maven编译的JAR复制到镜像内部。

将所述Docker镜像存储到Harbor私有镜像仓库中。

优选地,通过Eureka Server构建所述镜像时,需使用IP地址进行服务注册,而不使用Eureka的默认注册方式Hostname(主机名称),由此避免服务通过Kubernetes发布后,因Hostname变化而导致服务无法注册的问题。

优选地,各服务镜像之间需进行互相注册,如图2所示。如果不进行互相注册,当存在多个服务时,其中一个服务的节点宕机,会导致整个服务集群瘫痪。而采用服务互相注册时,当其中一个服务的节点发生宕机,并不会影响正常的业务逻辑。

在该步骤中,通过Kubernetes调取存储于所述Harbor私有镜像仓库中的Docker镜像。

S120,将所述服务的镜像部署到Kubernets集群节点的Pod中。

创建Eureka部署文件,用于在Kubernetes中部署Eureka。在本实施例中采用StatefulSet(有状态集)+Headless服务方式来部署Eureka。即,通过StatefulSet(有状态集)+Headless服务方式将所述服务的镜像部署到Kubernets集群节点的Pod中。因为通过StatefulSet(有状态集)方式部署地Eureka Pod名是有序的,同时StatefulSet支持Service Headless方式创建Service来对内部服务访问。如果部署方式为Deployment,那么需要部署多个Deployment对象,比较繁琐。

可选地,通过Headless方式部署的Service不会分配虚拟IP,而是用轮询的访问,每次都直接与Pod的IP进行通信,进而减小了与注册中心通信造成性能损耗。

S130,通过网关管理服务配置所述服务的域名。

在网关管理服务配置中,Kubernetes部署文件的apiVersion选择ambassador/v1,资源类型选择Mapping。进一步地,把所需的内网、外网域名在Kubernetes中的etcd组件(K/V键值对)中配置好,并通过所述网关管理服务配置注册域名。

之后,访问者可通过域名对所述服务(Pod)进行访问。进一步地,所述访问者可通过域名对所述服务(Pod)进行访问包括内部访问和外部访问。

S140,将对所述域名的访问请求加载到对应的Pod中。

当接收到对所述服务(Pod)的域名访问请求时,通过负载均衡的方式将所述访问请求加载到对应的Pod中,以完成对所述服务的调取。优选地,所述负载均衡的方式包括轮询的访问方式。

本实施例的基于Eureka服务注册与发现的Kubernetes调度方法,首先通过Eureka将系统中的服务模块化(通过Eureka创建服务的镜像),将各个服务从整体系统中分离出来,使得各服务之间互相解耦,然后通过Kubernetes调度所述服务的镜像,实现了模块复用的同时,实现了可插入(Pluginable)、可迁移的(Portable)业务(Program)、数据(Data)和服务依赖(Service)的功能。

需要说明的是,所述可插入(Pluginable)、可迁移的(Portable)业务(Program)、数据(Data)和服务依赖(Service)的功能,在各服务之间互相解耦后,均可利用Kubernetes的特性实现。

本申请实施例还提出了一种设备,包括:

一个或多个处理器;

存储装置,用于存储一个或多个程序;

当所述一个或多个程序被所述一个或多个处理器执行,使得所述一个或多个处理器实现上述的基于Eureka服务注册与发现的Kubernetes调度方法。

此外,本申请实施例还提出了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述的基于Eureka服务注册与发现的Kubernetes调度方法。

下面参考图3,其示出了适于用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。图3示出的终端设备仅仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。

如图3所示,计算机系统包括中央处理单元(CPU)301,其可以基于存储在只读存储器(ROM)302中的程序或者从存储部分308加载到随机访问存储器(RAM)303中的程序而执行各种适当的动作和处理。在RAM 303中,还存储有系统操作所需的各种程序和数据。CPU301、ROM 302以及RAM303通过总线304彼此相连。输入/输出(I/O)接口305也连接至总线304。

以下部件连接至I/O接口305:包括键盘、鼠标等的输入部分306;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分307;包括硬盘等的存储部分308;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分309。通信部分309经由诸如因特网的网络执行通信处理。驱动器310也基于需要连接至I/O接口305。可拆卸介质311,诸如磁盘、光盘、磁光盘、半导体存储器等等,基于需要安装在驱动器310上,以便于从其上读出的计算机程序基于需要被安装入存储部分308。

特别地,基于本公开的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,所述计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分309从网络上被下载和安装,和/或从可拆卸介质311被安装。在该计算机程序被中央处理单元(CPU)301执行时,执行本申请的方法中限定的上述功能。

需要说明的是,本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。

附图中的流程图和框图,图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个单元、程序段、或代码的一部分,所述单元、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中,例如,可以描述为:一种处理器包括信息测量单元、行驶轨迹确定单元、映射关系确定单元和驾驶策略生成单元。其中,这些单元的名称在某种情况下并不构成对该单元本身的限定,例如,信息测量单元还可以被描述为“测量本车的状态信息以及周围场景信息的单元”。

作为另一方面,本申请还提供了一种非易失性计算机存储介质,该非易失性计算机存储介质可以是上述实施例中所述装置中所包含的非易失性计算机存储介质;也可以是单独存在,未装配入终端中的非易失性计算机存储介质。上述非易失性计算机存储介质存储有一个或者多个程序,当所述一个或者多个程序被一个设备执行时,使得所述设备:从镜像仓库中调取基于Eureka构建的服务的镜像;将所述服务的镜像部署到Kubernets集群节点的Pod中;通过网关管理服务配置所述服务的域名;将对所述域名的访问请求加载到对应的Pod中。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本申请中所涉及的发明范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离上述发明构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

相关技术
  • 基于Eureka服务注册与发现的Kubernetes调度方法
  • 基于服务质量的Web服务注册与发现系统及其方法
技术分类

06120113299647