CN117938809A - 域名访问路径优化方法、系统和可读存储介质 - Google Patents
域名访问路径优化方法、系统和可读存储介质 Download PDFInfo
- Publication number
- CN117938809A CN117938809A CN202410338660.4A CN202410338660A CN117938809A CN 117938809 A CN117938809 A CN 117938809A CN 202410338660 A CN202410338660 A CN 202410338660A CN 117938809 A CN117938809 A CN 117938809A
- Authority
- CN
- China
- Prior art keywords
- dns
- access
- domain name
- local
- ingress
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 35
- 238000005457 optimization Methods 0.000 title claims abstract description 32
- 238000003860 storage Methods 0.000 title claims abstract description 17
- 238000011144 upstream manufacturing Methods 0.000 claims abstract description 30
- 238000012545 processing Methods 0.000 claims abstract description 23
- 230000008859 change Effects 0.000 claims description 20
- 108090000248 Deleted entry Proteins 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 7
- 238000013507 mapping Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 238000005111 flow chemistry technique Methods 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000013341 scale-up Methods 0.000 description 1
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开的一种域名访问路径优化方法、系统和可读存储介质，其中方法包括：基于节点缓冲存储器接收请求方发出的对访问域名地址的DNS请求；基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，以使得所述DNS请求被其宿主计算节点的访问控制器接收；其中，若所述访问控制器被成功接收，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方；若所述访问控制器未被成功接收，则基于所述预设本地DNS将所述DNS请求转发至当前预设本地DNS上游对应的Kube‑DNS进行处理。本发明能够优化Kubernetes集群内，服务访问方通过Ingress访问另一服务时的网络路径，同时分摊集群内节点的网络IO压力，避免单点拥塞。
Description
技术领域
本发明涉及访问控制和数据处理技术领域，更具体的，涉及一种域名访问路径优化方法、系统和可读存储介质。
背景技术
在Kubernetes集群内，当一个服务或客户端想要以Ingress方式访问同集群内的另一个服务时，通常需要先进行DNS解析，使得后续的访问流量指向Ingress-controller所在的节点，进而使得域名转发成为可能。
但在实际部署当中，DNS对Ingress所暴露的域名通常会解析到有限的几台Kubernetes集群节点上，所造成的结果就是来自Kubernetes集群内部的访问流量会集中在若干台计算节点上，带来节点压力，而节点的网络IO也会成为瓶颈。
当Kubernetes集群规模不断扩大时，管理员可能通过配置更多的集群节点作为域名背后的实际服务器地址，但即使如此也始终无法避免Kubernetes集群内、网络流量跨节点转发带来的网络延迟和潜在流量瓶颈。跨节点访问场景下，网络流量路径通常为：服务访问方所在节点->Ingress-controller所在节点->服务提供方所在节点->Ingress-controller所在节点->服务访问方所在节点。流量必须经过Ingress-controller所在节点，带来了额外的网络延迟和流量瓶颈。
发明内容
本发明的目的是提供一种域名访问路径优化方法、系统和可读存储介质，为了优化Kubernetes集群内，服务访问方通过Ingress访问另一服务时的网络路径，同时分摊集群内节点的网络IO压力，避免单点拥塞。
本发明第一方面提供了一种域名访问路径优化方法，包括以下步骤：
基于节点缓冲存储器接收请求方发出的对访问域名地址的DNS请求；
基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，以使得所述DNS请求被其宿主计算节点的访问控制器接收；其中，
若所述访问控制器被成功接收，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方；
若所述访问控制器未被成功接收，则基于所述预设本地DNS将所述DNS请求转发至当前预设本地DNS上游对应的Kube-DNS进行处理。
本方案中，所述预设本地DNS具体包括Ingress-local-dns，其中，Ingress-local-dns采用DaemonSet方式部署在Kubernetes集群上，以watch API方式监听Kubernetes集群中的Ingress资源变更信息，并基于所述Ingress资源变更信息更新本地缓存记录，其中，所述Ingress资源变更信息至少包括：新创建的Ingress，已删除的Ingress，已更新其元数据中的annotations字段的Ingress。
本方案中，所述基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，具体包括：
基于所述节点缓冲存储器接收请求方发出的DNS请求，其中，所述节点缓冲存储器包括node-cache；
当基于Kubernetes原生DNS体系无法识别所述访问域名地址时，基于node-cache将所述DNS请求转发给Ingress-local-dns；
从而基于Ingress-local-dns将所述访问域名地址解析为当前计算节点本地主网卡的IP地址；
基于所述IP地址识别得到当前DNS请求对应的宿主计算节点的访问控制器，其中，所述访问控制器具体包括Ingress-controller，且Ingress-controller采用DaemonSet方式部署在Kubernetes集群上。
本方案中，当所述访问控制器被成功接收时，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方，其中，若所述服务方与所述请求方在同一个计算节点上，则将所述DNS请求变成当前计算节点内部的转发流量进行转发，若不在同一个计算节点上，则获取所述服务方与所述请求方两个节点之间的最短转发路径进行转发，其中，最短转发路径为预设路径。
本方案中，所述预设本地DNS还用于支持特殊端口的访问域名地址解析，其中，具体包括利用所述预设本地DNS检测多个访问资源中的特殊标识键值对以进行映射，其中，所述特殊端口包括80端口和433端口。
本方案中，当所述DNS请求对应为特殊端口的访问域名地址时，基于所述预设本地DNS将所述DNS解析为访问控制器创建的Kubernetes Service地址，从而基于创建的Kubernetes Service地址转发当前所述DNS请求。
本发明第二方面还提供一种域名访问路径优化系统，包括存储器和处理器，所述存储器中包括域名访问路径优化方法程序，所述域名访问路径优化方法程序被所述处理器执行时实现如下步骤：
基于节点缓冲存储器接收请求方发出的对访问域名地址的DNS请求；
基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，以使得所述DNS请求被其宿主计算节点的访问控制器接收；其中，
若所述访问控制器被成功接收，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方；
若所述访问控制器未被成功接收，则基于所述预设本地DNS将所述DNS请求转发至当前预设本地DNS上游对应的Kube-DNS进行处理。
本方案中，所述预设本地DNS具体包括Ingress-local-dns，其中，Ingress-local-dns采用DaemonSet方式部署在Kubernetes集群上，以watch API方式监听Kubernetes集群中的Ingress资源变更信息，并基于所述Ingress资源变更信息更新本地缓存记录，其中，所述Ingress资源变更信息至少包括：新创建的Ingress，已删除的Ingress，已更新其元数据中的annotations字段的Ingress。
本方案中，所述基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，具体包括：
基于所述节点缓冲存储器接收请求方发出的DNS请求，其中，所述节点缓冲存储器包括node-cache；
当基于Kubernetes原生DNS体系无法识别所述访问域名地址时，基于node-cache将所述DNS请求转发给Ingress-local-dns；
从而基于Ingress-local-dns将所述访问域名地址解析为当前计算节点本地主网卡的IP地址；
基于所述IP地址识别得到当前DNS请求对应的宿主计算节点的访问控制器，其中，所述访问控制器具体包括Ingress-controller，且Ingress-controller采用DaemonSet方式部署在Kubernetes集群上。
本方案中，当所述访问控制器被成功接收时，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方，其中，若所述服务方与所述请求方在同一个计算节点上，则将所述DNS请求变成当前计算节点内部的转发流量进行转发，若不在同一个计算节点上，则获取所述服务方与所述请求方两个节点之间的最短转发路径进行转发，其中，最短转发路径为预设路径。
本方案中，所述预设本地DNS还用于支持特殊端口的访问域名地址解析，其中，具体包括利用所述预设本地DNS检测多个访问资源中的特殊标识键值对以进行映射，其中，所述特殊端口包括80端口和433端口。
本方案中，当所述DNS请求对应为特殊端口的访问域名地址时，基于所述预设本地DNS将所述DNS解析为访问控制器创建的Kubernetes Service地址，从而基于创建的Kubernetes Service地址转发当前所述DNS请求。
本发明第三方面提供了一种计算机可读存储介质，所述计算机可读存储介质中包括机器的一种域名访问路径优化方法程序，所述域名访问路径优化方法程序被处理器执行时，实现如上述任一项所述的一种域名访问路径优化方法的步骤。
本发明公开的一种域名访问路径优化方法、系统和可读存储介质，结合了现有Kubernetes系统所支持的原生技术手段，利用和改造了现有两级DNS的方案，通过增加额外组件，识别用户创建的Ingress资源并为其提供DNS解析，减少了Kubernetes平台内用户Pod、用户服务通过Ingress访问集群内其他服务时的网络转发路径。减少网络转发路径将有助于降低网络延迟，提升性能；由于网络转发路径的改善，避免了Kubernetes平台中部分Ingress-controller宿主节点成为网络流量瓶颈。
本发明同时也支持用户对具有非常规端口的Ingress域名地址的访问。这对于一些默认只支持80、443端口的Ingress-controller是很有价值的扩展。
此外，对Kubernetes平台的用户而言，本发明没有额外引入新的资源，用户任可以按照既有的Kubernetes用法来创建Ingress资源；而对于Kubernetes平台管理员而言，本发明仅存在一些组件部署工作，并不存在对Kubernetes系统的侵入性修改，Kubernetes平台的升级、维护成本完全可以接收。
附图说明
图1示出了本发明一种域名访问路径优化方法的预设本地DNS的架构逻辑示意图；
图2示出了本发明一种域名访问路径优化方法的流程图；
图3示出了本发明一种域名访问路径优化方法的预设本体DNS进行请求与流量处理的示意图；
图4示出了本发明一种域名访问路径优化方法的端口与流量处理示意图；
图5示出了本发明一种域名访问路径优化系统的框图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。
在Kubernetes集群中，用户应用的运行载体是Pod。Pod具有IP，但Pod IP并不稳定，会随着Pod的销毁而被释放；另一方面，Pod IP只能在Kubernetes集群内部使用，无法被集群外部访问。因此，Kubernetes提供了Service这一资源，Service会对Pod IP进行简单的负载均衡，并对具有同一组标签（即labels）的Pod进行服务发现。
相对而言，Service是稳定的，在其生命周期中，如果没有网络策略（即NetworkPolicy）的阻拦，那么来自Kubernetes集群内的服务或客户端总是可以通过访问Service来访问到背后的Pod，进而访问Pod中的服务。同时，Service也提供了NodePort这一使用方式，NodePort使得Service可以利用Kubernetes集群中节点的端口做映射，使得访问集群节点端口的流量转发到访问Service。但受限于Kubernetes集群端口的数量限制以及一些特殊场景IP+端口的访问方式受限，NodePort类型的Service并不总是能满足用户需求。
因而，Kubernetes提供了Ingress这一资源。使用Ingress，用户可以为已有的Service暴露域名。来自Kubernetes集群外的服务或客户端，以及来自Kubernetes集群的其他用户服务或客户端（无论它们是来自同一个Kubernetes namespace还是不同的），都可以通过暴露的域名对Ingress背后的用户Service进行访问。Ingress只是相当于域名的定义，而背后的转发实现是Ingress-controller。Ingress-controller通常以Pod的方式部署在Kubernetes集群中，无论是以Deployment方式部署在选定节点上，还是以DaemonSet方式部署在集群内的多个节点上。虽然Ingress的引入是为了解决Kubernetes集群外部无法直接访问集群内部服务的问题，但是对于来自集群内的服务或客户端，也同样鼓励使用Ingress来进行服务访问，一方面用户可能会对创建网络策略，使得Service访问受限；另一方面，使用Ingress可以带来解耦，当服务提供方要调整Service时，访问方可以避免直接使用Service带来的调整。
本发明的目的为了优化Kubernetes集群内，服务访问方通过Ingress访问另一服务时的网络路径，同时分摊集群内节点的网络IO压力，避免单点拥塞。
本发明利用Kubernetes开源社区下的dns项目。dns项目中提供的镜像，除了kube-dns可以作为Kubernetes集群内的集中式DNS外，还有node-cache可以作为各个节点上分布式的本地DNS代理。node-cache需要以DaemonSet方式部署，而kube-dns则通常以Deployment方式部署。二者在Kubernetes集群内形成二级DNS，即计算节点上Pod内的应用在发起DNS请求时，DNS请求会先到达当前节点的node-cache，即由节点本地的DNS先进行处理；当本地节点DNS无法解析时再向集中式DNS，即kube-dns进行解析处理。
同时，本发明需要Kubernetes集群在部署Ingress-controller组件时，并且采用DaemonSet方式。这使得集群内的每个计算节点上都会运行Ingress-controller的Pod，即计算节点上Pod内的应用在通过Ingress访问集群内的服务时，每个计算节点都具有为本地Pod提供域名转发的能力。在具备如上两点后，本发明的切入点为引入一个新的DNS组件，即本申请说明的预设本地DNS。如图1所示，图中的ingress-local-dns即为所引入的DNS组件，如同Ingress-controller一样，它也采用DaemonSet方式部署，且也以watch API方式监听Kubernetes集群中的Ingress资源。
图2示出了本申请一种域名访问路径优化方法的流程图。
如图2所示，本申请公开了一种域名访问路径优化方法，包括以下步骤：
S202，基于节点缓冲存储器接收请求方发出的对访问域名地址的DNS请求；
S204，基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，以使得所述DNS请求被其宿主计算节点的访问控制器接收；
S206，若所述访问控制器被成功接收，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方；
S208，若所述访问控制器未被成功接收，则基于所述预设本地DNS将所述DNS请求转发至当前预设本地DNS上游对应的Kube-DNS进行处理。
需要说明的是，于本实施例中，如图 3所示，显示为利用本申请提出的预设本体DNS进行请求与流量处理的示意图，具体地，当请求方Pod发出对Ingress域名地址的DNS请求时，DNS请求首先会被节点缓冲存储器node-cache接收，由于Ingress域名地址不被Kubernetes内的原生DNS体系识别，所以node-cache会将DNS请求转发到其上游DNS服务，即ingress-local-dns，对应为所述预设本地DNS，进一步地，由于ingress-local-dns会以Kubernetes watch API的方式监听Kubernetes集群中所有的Ingress资源，因此可以识别Ingress域名地址，而后Ingress-local-dns将Ingress域名地址解析为当前计算节点本地主网卡的IP地址，使得请求方Pod的后续请求流量可以被其宿主计算节点的Ingress-controller接收并处理，从而使得所述DNS请求被其宿主计算节点的访问控制器接收。
进一步地，当请求方Pod的请求流量被其宿主计算节点的Ingress-controller接收后，Ingress-controller会将请求流量进行转发。转发到Ingress对应的KubernetesService，进而转发给Service后端的服务方Pod。如果服务方的Pod恰巧与请求方Pod在同一个计算节点上，那么请求流量就变成了一个计算节点内部的转发流量，减小了流量从计算节点转出去后的绕行开销；而当服务方Pod与请求方Pod不在同一计算节点上时，那么请求流量也是在二者所在的计算节点之间传递，减小了第三者节点带来的开销和延迟；当用户Pod请求未被node-cache缓存的非Ingress域名地址时，node-cache会将DNS请求转发到其上游DNS服务ingress-local-dns，而ingress-local-dns也会进一步将DNS请求转发到其上游DNS服务，即Kube-DNS。
根据本发明实施例，所述预设本地DNS具体包括Ingress-local-dns，其中，Ingress-local-dns采用DaemonSet方式部署在Kubernetes集群上，以watch API方式监听Kubernetes集群中的Ingress资源变更信息，并基于所述Ingress资源变更信息更新本地缓存记录，其中，所述Ingress资源变更信息至少包括：新创建的Ingress，已删除的Ingress，已更新其元数据中的annotations字段的Ingress。
需要说明的是，于本实施例中，按照既有的Kubernetes使用方式创建Ingress资源。通常情况下，用户不会感知到ingress-local-dns的存在。其中:如同现有的Ingress-controller一样，ingress-local-dns也会以Kubernetes watch API的方式监听Ingress资源的变更。这些变更包括：新的Ingress创建，已有的Ingress删除，已有的Ingress更新其元数据中的annotations字段；Ingress-local-dns针对已知类型的Ingress资源变更，更新本地其缓存记录，用于后续应答来自本地用户Pod的面向已知Ingress域名地址的DNS请求。
根据本发明实施例，所述基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，具体包括：
基于所述节点缓冲存储器接收请求方发出的DNS请求，其中，所述节点缓冲存储器包括node-cache；
当基于Kubernetes原生DNS体系无法识别所述访问域名地址时，基于node-cache将所述DNS请求转发给Ingress-local-dns；
从而基于Ingress-local-dns将所述访问域名地址解析为当前计算节点本地主网卡的IP地址；
基于所述IP地址识别得到当前DNS请求对应的宿主计算节点的访问控制器，其中，所述访问控制器具体包括Ingress-controller，且Ingress-controller采用DaemonSet方式部署在Kubernetes集群上。
需要说明的是，上述实施例中说明了节点缓冲存储器接收DNS请求以及如何获取宿主计算节点的访问控制器Ingress-controller的内容，于本实施例中，由于本申请引入的ingress-local-dns充当前述提到的node-cache的上游DNS服务，而ingress-local-dns的上游DNS服务则是前述中提到的Kube-DNS，其中，具体地，节点缓冲存储器node-cache用于接收请求方发出的DNS请求，而后当基于Kubernetes原生DNS体系无法识别所述访问域名地址时，将其转发给预设本地DNS，即Ingress-local-dns，从而利用Ingress-local-dns将所述访问域名地址解析为当前计算节点本地主网卡的IP地址，最后基于所述IP地址识别得到当前DNS请求对应的宿主计算节点的访问控制器，相应地，所述访问控制器Ingress-controller和Ingress-local-dns一样，采用DaemonSet方式部署在Kubernetes集群上。
根据本发明实施例，当所述访问控制器被成功接收时，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方，其中，若所述服务方与所述请求方在同一个计算节点上，则将所述DNS请求变成当前计算节点内部的转发流量进行转发，若不在同一个计算节点上，则获取所述服务方与所述请求方两个节点之间的最短转发路径进行转发，其中，最短转发路径为预设路径。
需要说明的是，于本实施例中，当请求方Pod的请求流量被其宿主计算节点的Ingress-controller接收后，Ingress-controller会将请求流量进行转发，转发到Ingress对应的Kubernetes Service，进而转发给Service后端的服务方Pod，如果服务方的Pod恰巧与请求方Pod在同一个计算节点上，那么请求流量就变成了一个计算节点内部的转发流量，减小了流量从计算节点转出去后的绕行开销，即对应所述服务方与所述请求方在同一个计算节点上，则将所述DNS请求变成当前计算节点内部的转发流量进行转发；而当服务方Pod与请求方Pod不在同一计算节点上时，那么请求流量也是在二者所在的计算节点之间传递，减小了第三者节点带来的开销和延迟，即对应获取所述服务方与所述请求方两个节点之间的最短转发路径进行转发，其中，最短转发路径为预设路径。
根据本发明实施例，所述预设本地DNS还用于支持特殊端口的访问域名地址解析，其中，具体包括利用所述预设本地DNS检测多个访问资源中的特殊标识键值对以进行映射，其中，所述特殊端口包括80端口和433端口。
需要说明的是，于本实施例中，本申请引入的预设本地DNS，即ingress-local-dns支持为Ingress域名地址解析特殊端口，即非80、443的端口，其中，当用户创建Ingress资源时，只需要在Ingress资源的元数据annotations字段中加入特殊标识键值对，该键值对中包含特殊端口信息；因而当ingress-local-dns以watch API监听到这种Ingress资源创建后，会按需为Ingress-controller创建或更新Kubernetes Service。参考图4，ingress-local-dns将负责为Ingress-controller创建的Service，并管理所创建的Service，无需Kubernetes平台管理员创建或管理，ingress-local-dns具备能力来检查当多个Ingress资源都在annotations中配置特殊标识键值对时，它们所定义的特殊端口到“80/443端口”到映射规则是否冲突，例如，用户A的Ingress-1将“30000端口”映射到Ingress-controller的“80端口”，而用户B的Ingress-2将“30000端口”映射为Ingress-controller的“443端口”；此时ingress-local-dns将负责把这两种不同的端口映射关系更新到两个为Ingress-controller创建的Service中。
根据本发明实施例，当所述DNS请求对应为特殊端口的访问域名地址时，基于所述预设本地DNS将所述DNS解析为访问控制器创建的Kubernetes Service地址，从而基于创建的Kubernetes Service地址转发当前所述DNS请求。
需要说明的是，于本实施例中，ingress-local-dns负责管理的、为Ingress-controller创建的Service会设置internalTrafficPolicy为Local。这是Kubernetes原生支持的一种设置，当请求方Pod请求具有该设置的Service时，流量只会转发到请求方Pod宿主计算节点上的、作为目标Service后端的服务方Pod。如果请求方Pod宿主计算节点上没有作为目标Service后端的服务方Pod存在，则请求流量无法被转发，请求失败。但在本发明设计下，由于Ingress-controller以DaemonSet方式部署，因此每个计算节点上都会有Ingress-controller的Pod存在，因此不会出现上述失败场景，并且，当用户Pod请求特殊端口的Ingress域名地址时，基于前述的DNS转发逻辑，ingress-local-dns将会根据Ingress域名记录，将DNS请求解析为对应的为Ingress-controller创建的Kubernetes Service地址。当用户Pod发起请求时，请求流量经过Service处理，最终转发给标准的Ingress-controller “80或443端口”。
图5示出了本发明一种域名访问路径优化系统的框图。
如图5所示，本发明公开了一种域名访问路径优化系统，包括存储器和处理器，所述存储器中包括域名访问路径优化方法程序，所述域名访问路径优化方法程序被所述处理器执行时实现如下步骤：
基于节点缓冲存储器接收请求方发出的对访问域名地址的DNS请求；
基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，以使得所述DNS请求被其宿主计算节点的访问控制器接收；其中，
若所述访问控制器被成功接收，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方；
若所述访问控制器未被成功接收，则基于所述预设本地DNS将所述DNS请求转发至当前预设本地DNS上游对应的Kube-DNS进行处理。
需要说明的是，于本实施例中，如图 3所示，显示为利用本申请提出的预设本体DNS进行请求与流量处理的示意图，具体地，当请求方Pod发出对Ingress域名地址的DNS请求时，DNS请求首先会被节点缓冲存储器node-cache接收，由于Ingress域名地址不被Kubernetes内的原生DNS体系识别，所以node-cache会将DNS请求转发到其上游DNS服务，即ingress-local-dns，对应为所述预设本地DNS，进一步地，由于ingress-local-dns会以Kubernetes watch API的方式监听Kubernetes集群中所有的Ingress资源，因此可以识别Ingress域名地址，而后Ingress-local-dns将Ingress域名地址解析为当前计算节点本地主网卡的IP地址，使得请求方Pod的后续请求流量可以被其宿主计算节点的Ingress-controller接收并处理，从而使得所述DNS请求被其宿主计算节点的访问控制器接收。
进一步地，当请求方Pod的请求流量被其宿主计算节点的Ingress-controller接收后，Ingress-controller会将请求流量进行转发。转发到Ingress对应的KubernetesService，进而转发给Service后端的服务方Pod。如果服务方的Pod恰巧与请求方Pod在同一个计算节点上，那么请求流量就变成了一个计算节点内部的转发流量，减小了流量从计算节点转出去后的绕行开销；而当服务方Pod与请求方Pod不在同一计算节点上时，那么请求流量也是在二者所在的计算节点之间传递，减小了第三者节点带来的开销和延迟；当用户Pod请求未被node-cache缓存的非Ingress域名地址时，node-cache会将DNS请求转发到其上游DNS服务ingress-local-dns，而ingress-local-dns也会进一步将DNS请求转发到其上游DNS服务，即Kube-DNS。
根据本发明实施例，所述预设本地DNS具体包括Ingress-local-dns，其中，Ingress-local-dns采用DaemonSet方式部署在Kubernetes集群上，以watch API方式监听Kubernetes集群中的Ingress资源变更信息，并基于所述Ingress资源变更信息更新本地缓存记录，其中，所述Ingress资源变更信息至少包括：新创建的Ingress，已删除的Ingress，已更新其元数据中的annotations字段的Ingress。
需要说明的是，于本实施例中，按照既有的Kubernetes使用方式创建Ingress资源。通常情况下，用户不会感知到ingress-local-dns的存在。其中:如同现有的Ingress-controller一样，ingress-local-dns也会以Kubernetes watch API的方式监听Ingress资源的变更。这些变更包括：新的Ingress创建，已有的Ingress删除，已有的Ingress更新其元数据中的annotations字段；Ingress-local-dns针对已知类型的Ingress资源变更，更新本地其缓存记录，用于后续应答来自本地用户Pod的面向已知Ingress域名地址的DNS请求。
根据本发明实施例，所述基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，具体包括：
基于所述节点缓冲存储器接收请求方发出的DNS请求，其中，所述节点缓冲存储器包括node-cache；
当基于Kubernetes原生DNS体系无法识别所述访问域名地址时，基于node-cache将所述DNS请求转发给Ingress-local-dns；
从而基于Ingress-local-dns将所述访问域名地址解析为当前计算节点本地主网卡的IP地址；
基于所述IP地址识别得到当前DNS请求对应的宿主计算节点的访问控制器，其中，所述访问控制器具体包括Ingress-controller，且Ingress-controller采用DaemonSet方式部署在Kubernetes集群上。
需要说明的是，上述实施例中说明了节点缓冲存储器接收DNS请求以及如何获取宿主计算节点的访问控制器Ingress-controller的内容，于本实施例中，由于本申请引入的ingress-local-dns充当前述提到的node-cache的上游DNS服务，而ingress-local-dns的上游DNS服务则是前述中提到的Kube-DNS，其中，具体地，节点缓冲存储器node-cache用于接收请求方发出的DNS请求，而后当基于Kubernetes原生DNS体系无法识别所述访问域名地址时，将其转发给预设本地DNS，即Ingress-local-dns，从而利用Ingress-local-dns将所述访问域名地址解析为当前计算节点本地主网卡的IP地址，最后基于所述IP地址识别得到当前DNS请求对应的宿主计算节点的访问控制器，相应地，所述访问控制器Ingress-controller和Ingress-local-dns一样，采用DaemonSet方式部署在Kubernetes集群上。
根据本发明实施例，当所述访问控制器被成功接收时，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方，其中，若所述服务方与所述请求方在同一个计算节点上，则将所述DNS请求变成当前计算节点内部的转发流量进行转发，若不在同一个计算节点上，则获取所述服务方与所述请求方两个节点之间的最短转发路径进行转发，其中，最短转发路径为预设路径。
需要说明的是，于本实施例中，当请求方Pod的请求流量被其宿主计算节点的Ingress-controller接收后，Ingress-controller会将请求流量进行转发，转发到Ingress对应的Kubernetes Service，进而转发给Service后端的服务方Pod，如果服务方的Pod恰巧与请求方Pod在同一个计算节点上，那么请求流量就变成了一个计算节点内部的转发流量，减小了流量从计算节点转出去后的绕行开销，即对应所述服务方与所述请求方在同一个计算节点上，则将所述DNS请求变成当前计算节点内部的转发流量进行转发；而当服务方Pod与请求方Pod不在同一计算节点上时，那么请求流量也是在二者所在的计算节点之间传递，减小了第三者节点带来的开销和延迟，即对应获取所述服务方与所述请求方两个节点之间的最短转发路径进行转发，其中，最短转发路径为预设路径。
根据本发明实施例，所述预设本地DNS还用于支持特殊端口的访问域名地址解析，其中，具体包括利用所述预设本地DNS检测多个访问资源中的特殊标识键值对以进行映射，其中，所述特殊端口包括80端口和433端口。
需要说明的是，于本实施例中，本申请引入的预设本地DNS，即ingress-local-dns支持为Ingress域名地址解析特殊端口，即非80、443的端口，其中，当用户创建Ingress资源时，只需要在Ingress资源的元数据annotations字段中加入特殊标识键值对，该键值对中包含特殊端口信息；因而当ingress-local-dns以watch API监听到这种Ingress资源创建后，会按需为Ingress-controller创建或更新Kubernetes Service。参考图4，ingress-local-dns将负责为Ingress-controller创建的Service，并管理所创建的Service，无需Kubernetes平台管理员创建或管理，ingress-local-dns具备能力来检查当多个Ingress资源都在annotations中配置特殊标识键值对时，它们所定义的特殊端口到“80/443端口”到映射规则是否冲突，例如，用户A的Ingress-1将“30000端口”映射到Ingress-controller的“80端口”，而用户B的Ingress-2将“30000端口”映射为Ingress-controller的“443端口”；此时ingress-local-dns将负责把这两种不同的端口映射关系更新到两个为Ingress-controller创建的Service中。
根据本发明实施例，当所述DNS请求对应为特殊端口的访问域名地址时，基于所述预设本地DNS将所述DNS解析为访问控制器创建的Kubernetes Service地址，从而基于创建的Kubernetes Service地址转发当前所述DNS请求。
需要说明的是，于本实施例中，ingress-local-dns负责管理的、为Ingress-controller创建的Service会设置internalTrafficPolicy为Local。这是Kubernetes原生支持的一种设置，当请求方Pod请求具有该设置的Service时，流量只会转发到请求方Pod宿主计算节点上的、作为目标Service后端的服务方Pod。如果请求方Pod宿主计算节点上没有作为目标Service后端的服务方Pod存在，则请求流量无法被转发，请求失败。但在本发明设计下，由于Ingress-controller以DaemonSet方式部署，因此每个计算节点上都会有Ingress-controller的Pod存在，因此不会出现上述失败场景，并且，当用户Pod请求特殊端口的Ingress域名地址时，基于前述的DNS转发逻辑，ingress-local-dns将会根据Ingress域名记录，将DNS请求解析为对应的为Ingress-controller创建的Kubernetes Service地址。当用户Pod发起请求时，请求流量经过Service处理，最终转发给标准的Ingress-controller “80或443端口”。
本发明第三方面提供了一种计算机可读存储介质，所述计算机可读存储介质中包括一种域名访问路径优化方法程序，所述域名访问路径优化方法程序被处理器执行时，实现如上述任一项所述的一种域名访问路径优化方法的步骤。
本发明公开的一种域名访问路径优化方法、系统和可读存储介质，结合了现有Kubernetes系统所支持的原生技术手段，利用和改造了现有两级DNS的方案，通过增加额外组件，识别用户创建的Ingress资源并为其提供DNS解析，减少了Kubernetes平台内用户Pod、用户服务通过Ingress访问集群内其他服务时的网络转发路径。减少网络转发路径将有助于降低网络延迟，提升性能；由于网络转发路径的改善，避免了Kubernetes平台中部分Ingress-controller宿主节点成为网络流量瓶颈。
本发明同时也支持用户对具有非常规端口的Ingress域名地址的访问。这对于一些默认只支持80、443端口的Ingress-controller是很有价值的扩展。
此外，对Kubernetes平台的用户而言，本发明没有额外引入新的资源，用户任可以按照既有的Kubernetes用法来创建Ingress资源；而对于Kubernetes平台管理员而言，本发明仅存在一些组件部署工作，并不存在对Kubernetes系统的侵入性修改，Kubernetes平台的升级、维护成本完全可以接收。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。
或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机、服务器、或者网络设备等）执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
Claims (10)
1.一种域名访问路径优化方法，其特征在于，包括以下步骤：
基于节点缓冲存储器接收请求方发出的对访问域名地址的DNS请求；
基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，以使得所述DNS请求被其宿主计算节点的访问控制器接收；其中，
若所述访问控制器被成功接收，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方；
若所述访问控制器未被成功接收，则基于所述预设本地DNS将所述DNS请求转发至当前预设本地DNS上游对应的Kube-DNS进行处理。
2.根据权利要求1所述的一种域名访问路径优化方法，其特征在于，所述预设本地DNS具体包括Ingress-local-dns，其中，Ingress-local-dns采用DaemonSet方式部署在Kubernetes集群上，以watch API方式监听Kubernetes集群中的Ingress资源变更信息，并基于所述Ingress资源变更信息更新本地缓存记录，其中，所述Ingress资源变更信息至少包括：新创建的Ingress，已删除的Ingress，已更新其元数据中的annotations字段的Ingress。
3.根据权利要求2所述的一种域名访问路径优化方法，其特征在于，所述基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，具体包括：
基于所述节点缓冲存储器接收请求方发出的DNS请求，其中，所述节点缓冲存储器包括node-cache；
当基于Kubernetes原生DNS体系无法识别所述访问域名地址时，基于node-cache将所述DNS请求转发给Ingress-local-dns；
从而基于Ingress-local-dns将所述访问域名地址解析为当前计算节点本地主网卡的IP地址；
基于所述IP地址识别得到当前DNS请求对应的宿主计算节点的访问控制器，其中，所述访问控制器具体包括Ingress-controller，且Ingress-controller采用DaemonSet方式部署在Kubernetes集群上。
4.根据权利要求3所述的一种域名访问路径优化方法，其特征在于，当所述访问控制器被成功接收时，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方，其中，若所述服务方与所述请求方在同一个计算节点上，则将所述DNS请求变成当前计算节点内部的转发流量进行转发，若不在同一个计算节点上，则获取所述服务方与所述请求方两个节点之间的最短转发路径进行转发，其中，最短转发路径为预设路径。
5.根据权利要求1所述的一种域名访问路径优化方法，其特征在于，所述预设本地DNS还用于支持特殊端口的访问域名地址解析，其中，具体包括利用所述预设本地DNS检测多个访问资源中的特殊标识键值对以进行映射，其中，所述特殊端口包括80端口和433端口。
6.根据权利要求2所述的一种域名访问路径优化方法，其特征在于，当所述DNS请求对应为特殊端口的访问域名地址时，基于所述预设本地DNS将所述DNS解析为访问控制器创建的Kubernetes Service地址，从而基于创建的Kubernetes Service地址转发当前所述DNS请求。
7.一种域名访问路径优化系统，其特征在于，包括存储器和处理器，所述存储器中包括域名访问路径优化方法程序，所述域名访问路径优化方法程序被所述处理器执行时实现如下步骤：
基于节点缓冲存储器接收请求方发出的对访问域名地址的DNS请求；
基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，以使得所述DNS请求被其宿主计算节点的访问控制器接收；其中，
若所述访问控制器被成功接收，则基于所述访问控制器将所述DNS请求转发给服务后端的服务方；
若所述访问控制器未被成功接收，则基于所述预设本地DNS将所述DNS请求转发至当前预设本地DNS上游对应的Kube-DNS进行处理。
8.根据权利要求7所述的一种域名访问路径优化系统，其特征在于，所述预设本地DNS具体包括Ingress-local-dns，其中，Ingress-local-dns采用DaemonSet方式部署在Kubernetes集群上，以watch API方式监听Kubernetes集群中的Ingress资源变更信息，并基于所述Ingress资源变更信息更新本地缓存记录，其中，所述Ingress资源变更信息至少包括：新创建的Ingress，已删除的Ingress，已更新其元数据中的annotations字段的Ingress。
9.根据权利要求8所述的一种域名访问路径优化系统，其特征在于，所述基于节点缓冲存储器将所述DNS请求转发至当前节点缓冲存储器上游对应的预设本地DNS进行处理，具体包括：
基于所述节点缓冲存储器接收请求方发出的DNS请求，其中，所述节点缓冲存储器包括node-cache；
当基于Kubernetes原生DNS体系无法识别所述访问域名地址时，基于node-cache将所述DNS请求转发给Ingress-local-dns；
从而基于Ingress-local-dns将所述访问域名地址解析为当前计算节点本地主网卡的IP地址；
基于所述IP地址识别得到当前DNS请求对应的宿主计算节点的访问控制器。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中包括一种域名访问路径优化方法程序，所述域名访问路径优化方法程序被处理器执行时，实现如权利要求1至6中任一项所述的一种域名访问路径优化方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410338660.4A CN117938809B (zh) | 2024-03-25 | 2024-03-25 | 域名访问路径优化方法、系统和可读存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410338660.4A CN117938809B (zh) | 2024-03-25 | 2024-03-25 | 域名访问路径优化方法、系统和可读存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117938809A true CN117938809A (zh) | 2024-04-26 |
| CN117938809B CN117938809B (zh) | 2024-06-21 |
Family
ID=90768648
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410338660.4A Active CN117938809B (zh) | 2024-03-25 | 2024-03-25 | 域名访问路径优化方法、系统和可读存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117938809B (zh) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111464648A (zh) * | 2020-04-02 | 2020-07-28 | 聚好看科技股份有限公司 | 一种分布式本地dns系统及域名查询方法 |
| US20210344638A1 (en) * | 2018-09-30 | 2021-11-04 | Wangsu Science & Technology Co., Ltd. | Method for network traffic forwarding, request sending, and communication acceleration, forwarding server and node server |
| CN114143203A (zh) * | 2021-11-05 | 2022-03-04 | 华东师范大学 | 一种基于动态服务拓扑映射的Kubernetes容器网络数据包指标采集的方法及系统 |
| CN116418724A (zh) * | 2021-12-31 | 2023-07-11 | 中国移动通信有限公司研究院 | 服务访问方法、装置及负载均衡系统 |
-
2024
- 2024-03-25 CN CN202410338660.4A patent/CN117938809B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210344638A1 (en) * | 2018-09-30 | 2021-11-04 | Wangsu Science & Technology Co., Ltd. | Method for network traffic forwarding, request sending, and communication acceleration, forwarding server and node server |
| CN111464648A (zh) * | 2020-04-02 | 2020-07-28 | 聚好看科技股份有限公司 | 一种分布式本地dns系统及域名查询方法 |
| CN114143203A (zh) * | 2021-11-05 | 2022-03-04 | 华东师范大学 | 一种基于动态服务拓扑映射的Kubernetes容器网络数据包指标采集的方法及系统 |
| CN116418724A (zh) * | 2021-12-31 | 2023-07-11 | 中国移动通信有限公司研究院 | 服务访问方法、装置及负载均衡系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117938809B (zh) | 2024-06-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7818454B2 (en) | Host migration system | |
| US7404201B2 (en) | Data distribution server | |
| US20100030880A1 (en) | Failover in proxy server networks | |
| US20120240184A1 (en) | System and method for on the fly protocol conversion in obtaining policy enforcement information | |
| WO2019237594A1 (zh) | 会话保持方法、装置、计算机设备及存储介质 | |
| CN114827145B (zh) | 服务器集群系统、元数据的访问方法及装置 | |
| US9390156B2 (en) | Distributed directory environment using clustered LDAP servers | |
| CN109151025B (zh) | 基于url的负载均衡方法、装置、计算机存储介质及设备 | |
| CN112261172A (zh) | 服务寻址访问方法、装置、系统、设备及介质 | |
| CN111586201A (zh) | 域名解析系统、方法、设备及存储介质 | |
| US11853806B2 (en) | Cloud computing platform that executes third-party code in a distributed cloud computing network and uses a distributed data store | |
| CN111726400A (zh) | 反向连接的方法、装置和服务端系统 | |
| CN109413224B (zh) | 报文转发方法和装置 | |
| US20050005027A1 (en) | Method and system for obtaining data through an IP transmission network by using an optimized domain name server | |
| US20240214395A1 (en) | Management of bot detection in a content delivery network | |
| US10467143B1 (en) | Event-driven cache | |
| US11134117B1 (en) | Network request intercepting framework for compliance monitoring | |
| CN117938809B (zh) | 域名访问路径优化方法、系统和可读存储介质 | |
| CN114338809B (zh) | 访问控制方法、装置、电子设备和存储介质 | |
| CN116566945A (zh) | 去中心化应用的访问方法、装置、电子设备及存储介质 | |
| CN115242882A (zh) | 一种基于传输层路由访问k8s容器环境的方法及装置 | |
| EP3304865B1 (en) | Systems and methods for server failover and load balancing | |
| CN115604226A (zh) | 基于ecs协议的域名查询方法及装置、存储介质及设备 | |
| US10958580B2 (en) | System and method of performing load balancing over an overlay network | |
| KR20230003490A (ko) | 오케스트레이션된 프록시 서비스 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |