藉助 APISIX Ingress,實現與註冊中心的無縫集成

語言: CN / TW / HK

作者張晉濤,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 了。

how client make requests

收益和展望

通過這種集成,對於已經使用了服務註冊發現組件的用户場景,可以非常方便的通過 APISIX Ingress 將其中的服務暴露給客户端使用。

大多數 Ingress Controller 都是沒有提供這種集成方案的,這也可以增加 APISIX Ingress 的應用場景。

希望 APISIX Ingress 可以更好的滿足用户實際業務場景的需求。

關於 API7.ai 與 APISIX

API7.ai 是一家提供 API 處理和分析的開源基礎軟件公司,於 2019 年開源了新一代雲原生 API 網關 -- APISIX 並捐贈給 Apache 軟件基金會。此後,API7.ai 一直積極投入支持 Apache APISIX 的開發、維護和社區運營。與千萬貢獻者、使用者、支持者一起做出世界級的開源項目,是 API7.ai 努力的目標。