藉助 APISIX Ingress，實現與註冊中心的無縫整合

語言: CN / TW / HK

時間 2023-02-18 03:01:59 API7.ai 技術團隊

主題: kubernetes httpbin 人工智慧 apache yaml

作者張晉濤，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 努力的目標。

「其他文章」