APISIX Ingress 支持与注册中心集成的能力

更新时间 2022-12-29

云原生场景下是否需要服务发现

背景

微服务架构是当前最为流行的应用架构之一。 应用被拆分为多个服务组件,通过相互配合共同完成业务的具体逻辑和功能。

随着应用规模的增加和微服务拆分粒度的不同,一套系统内会包含很多个服务组件。 要让这些组件之间可以很好的协同,并且能彼此识别到,通常都需要引入服务注册和发现组件。

之前我们写了一篇文章专门来介绍微服务架构中的服务发现, What Is Service Discovery in Microservices - API7.ai

简单来说,通过引入了服务发现组件,微服务架构中的组件,只需要关注其他组件的名称即可,而无需关注其他组件的部署位置,或者部署 IP 等信息。 通过服务发现组件可以动态的进行获取。

Kubernetes 中的服务发现

在 Kubernetes 环境中,Pod 是最小的调度单元。 而且在 Kubernetes 中,Pod 的 IP 不具备持久性,常常会发生变更。彼此协同的组件,一旦 IP 发生变更,很难再很好的配合工作。

所以将业务部署在 Kubernetes 环境中,如何能适配这种动态的环境就显的更加重要了。

Kubernetes 考虑到了这方面的诉求,它默认提供了基于 DNS 的服务发现机制。

Kubernetes 中有一个概念叫作 Service,它类似于反向代理的作用。客户端仅仅需要知道 Service 的存在,而无需关注它背后的 Pod 的变化,每个 Service 都会分配一个持久化的 ClusterIP 。 这样在业务组件的 Pod IP 发生变化的时候,其他组件仍然可以正常的通过 Service 的 ClusterIP 进行协同。

同时,Kubernetes 中的 Service 会自动的在集群内的 DNS 中添加一条 A 记录。

它的形式类似于:

1my-svc.my-namespace.svc.cluster-domain.example

客户端可以进行相同 namespace 或者跨 namespace 的解析,这就大大的方便了需要协同工作的组件之间进行服务发现。

但是,对于传统的微服务架构,正如本文开头提到的那样,通常是利用服务注册和发现组件来实现服务间协同配合的。 想要完全适配 Kubernetes 环境中基于 DNS 的这种服务发现机制,需要一定的改造成本。

所以,如果想要较低的改造成本,那就需要继续保持原有的服务注册和发现机制。 在这个大前提下,迁移至 Kubernetes 中的服务,如何对外暴露给客户端使用呢?

APISIX Ingress 如何与注册中心联动

APISIX Ingress 是 Kubernetes 中的一种 Ingress controller 实现,使用 APISIX 作为数据面代理组件, 支持通过 Ingress,自定义 CRD,Gateway API 等方式进行代理规则的配置。 同时也提供了与服务注册和发现组件的集成,可以方便的与服务发现组件进行联动。 将注册在其中的服务代理出来,提供给客户端使用。

这一节将具体进行介绍。

APISIX 对服务发现的支持

APISIX 是一个高性能,全动态的云原生 API 网关,提供了 80+ 开箱即用的插件,涵盖了绝大多数用户的使用场景。

其中一个很优秀的能力就是与服务发现组件的集成。

APISIX 可以和以下服务发现组件进行集成使用:

  • Consul
  • DNS
  • Eureka
  • Nacos

仅需要在 APISIX 的配置文件中添加如下配置即可(以 DNS 为例):

1discovery:
2   dns:
3     servers:
4       - "127.0.0.1:8600"          # use the real address of your dns server

这样,在配置上游的时候,APISIX 便可通过服务发现组件动态的解析出实际的上游地址信息,并进行请求的代理。

APISIX Ingress 如何做

APISIX Ingress 使用 APISIX 作为数据面代理组件。 再进行与服务发现组件集成的时候,我们考虑了两种模式。

  • 控制面集成:在 Ingress controller 中配置服务发现组件,并进行配置的解析,将最终结果发送至 APISIX 进行代理;
  • 数据面集成: 在 APISIX 数据面配置服务发现组件,代理时,由数据面进行配置解析和代理;

这两种方案各有优势,但考虑到配置的实时更新,还有方案的成熟度,我们最终选择了数据面集成的方案。 用户使用这种方案时,可以以更加低成本的方式进行接入,而且这种方案已经非常成熟了,经过了大量的生产验证。

在 APISIX Ingress 中如何使用这种方案呢?

首先确保在 APISIX 的配置中已经包含了正确的服务发现组件的配置,以下用 DNS 为例:

1discovery:
2  dns:
3    servers:
4      - "10.96.0.10:53"

创建 ApisixUpstream 资源,它的 discovery 相关的配置根据实际情况进行修改,比如此处设置了 type: dns 和具体要代理的 serviceName:

1# httpbin-upstream.yaml
2apiVersion: apisix.apache.org/v2
3kind: ApisixUpstream
4metadata:
5  name: httpbin-upstream
6spec:
7  discovery:
8    type: dns
9    serviceName: httpbin.default.svc.cluster.local

最后创建一个 ApisixRoute 资源,它的 upstreams 引用刚才创建的 ApisixUpstream 资源即可:

1# httpbin-route.yaml
2apiVersion: apisix.apache.org/v2
3kind: ApisixRoute
4metadata:
5  name: httpbin-route
6spec:
7  http:
8  - name: rule1
9    match:
10      hosts:
11      - local.httpbin.org
12      paths:
13      - /*
14    upstreams:
15    - name: httpbin-upstream

将上述资源都正确创建后,通过 local.httpbin.org 访问,即可访问到 DNS 中已经注册了的 httpbin.default.svc.cluster.local 了。

how client make requests

收益和展望

通过这种集成,对于已经使用了服务注册发现组件的用户场景,可以非常方便的通过 APISIX Ingress 将其中的服务暴露给客户端使用。

大多数 Ingress controller 都是没有提供这种集成方案的,这也可以增加 APISIX Ingress 的应用场景。

希望 APISIX Ingress 可以更好的满足用户实际业务场景的需求。