借助 APISIX Ingress，实现与注册中心的无缝集成

作者张晋涛，API7.ai 云原生技术专家，Apache APISIX PMC 成员，Apache APISIX Ingress Controller 项目维护者。

原文链接

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

背景

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

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

之前我们写了一篇文章专门来介绍微服务架构中的服务发现，
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 记录。

它的形式类似于：

my-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 为例）：

discovery:
   dns:
     servers:
       - "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 为例：

discovery:
  dns:
    servers:
      - "10.96.0.10:53"

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

# httpbin-upstream.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin-upstream
spec:
  discovery:
    type: dns
    serviceName: httpbin.default.svc.cluster.local

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

# httpbin-route.yaml
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
  - name: rule1
    match:
      hosts:
      - local.httpbin.org
      paths:
      - /*
    upstreams:
    - name: httpbin-upstream

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

收益和展望

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

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

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

关于 API7.ai 与 APISIX

API7.ai 是一家提供 API 处理和分析的开源基础软件公司，于 2019 年开源了新一代云原生 API 网关 -- APISIX 并捐赠给 Apache 软件基金会。此后，API7.ai 一直积极投入支持 Apache APISIX 的开发、维护和社区运营。与千万贡献者、使用者、支持者一起做出世界级的开源项目，是 API7.ai 努力的目标。