APISIX Ingress Controller 与 Service Discovery 集成

クラウドネイティブアプリケーションにおけるサービスディスカバリは必要か？

背景

マイクロサービスアーキテクチャは、現在最も人気のあるアプリケーションアーキテクチャの一つです。アプリケーションのサイズが大きくなるにつれて、アプリケーションの管理がより困難になります。マイクロサービスアーキテクチャは、アプリケーションを複数の小さなサービスコンポーネントに分割することでこの問題を解決しようとします。これらのコンポーネントは、特定のビジネスロジックや機能を完了するために協力して動作します。

これらのコンポーネントは、うまく連携するために動的に通信する必要があります。通常、サービスディスカバリツールを導入する必要があります。以前にマイクロサービスにおけるサービスディスカバリについて紹介する記事を書きました: マイクロサービスにおけるサービスディスカバリとは - API7.ai。

サービスディスカバリを導入することで、コンポーネントを動的に取得できます。他のコンポーネントの名前にのみ注意を払い、デプロイ場所やデプロイIPなどの他の情報に注意を払う必要はありません。

Kubernetesにおけるサービスディスカバリ

Kubernetes環境では、Podが最小のデプロイ可能な単位です。

そして、Kubernetesでは、PodのIPが永続的ではなく、頻繁に変更されるため、コンポーネント間の通信がさらに困難になります。

そのため、Kubernetesにアプリケーションをデプロイする際には、この動的な環境に適応することがさらに重要です。

Kubernetesはこの要件を考慮し、独自のDNSベースのサービスディスカバリメカニズムを提供しています。

KubernetesはServiceという概念を提供しており、これはリバースプロキシに似ています。クライアントはServiceを使用するだけで、背後にカプセル化されたPodを知る必要はありません。

各Serviceには永続的なClusterIPが割り当てられます。そのため、PodのIPが変更されても、他のコンポーネントはServiceの固定されたClusterIPを通じて引き続き連携できます。

同時に、Kubernetesのサービスはクラスタ内のDNSにA/AAAAレコードを自動的に更新します。

レコードは次のようになります:

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

クライアントは、名前空間を跨いだり、同じ名前空間内で解析を行うことができ、コンポーネント間のサービスディスカバリが大幅に容易になります。

ただし、Kubernetes内にない従来のマイクロサービスアーキテクチャでは、通常、サービスディスカバリツールを使用してサービス間の連携を実現します。Kubernetes環境のDNSベースのサービスディスカバリメカニズムに完全に適応するためには、ある程度の変換/移行コストが必要です。

そのため、変換コストを低く抑えたい場合は、元のサービスディスカバリメカニズムを維持する必要があります。

この前提の下で、新しくKubernetesに移行したサービスを公開する最良の方法は何でしょうか？

APISIX Ingressがサービスディスカバリとどのように連携するか？

APISIX Ingressは、KubernetesにおけるIngressコントローラの実装です。データプレーンとしてApache APISIXを使用し、Ingress、カスタムCRD、およびGateway APIを通じてプロキシルールの設定をサポートします。同時に、サービスディスカバリツールとの統合も提供しており、登録されたサービスを簡単にプロキシしてクライアントに公開できます。

このセクションでは、その詳細を説明します。

APISIXのサービスディスカバリサポート

APISIXは、高性能で完全に動的なクラウドネイティブAPIゲートウェイであり、80以上のすぐに使えるプラグインを提供し、ほとんどの使用シナリオをカバーしています。

その優れた機能の一つが、サービスディスカバリツールとの統合です。

APISIXは以下のサービスディスカバリツールと統合できます:

Consul
DNS
Eureka
Nacos

APISIX設定ファイルに以下の設定を追加するだけです（DNSを例として）:

discovery:
   dns:
     servers:
       - "127.0.0.1:8600"          # DNSサーバーの実際のアドレスを使用

これにより、アップストリームを設定する際に、APISIXはサービスディスカバリを通じて実際のアップストリームアドレス情報を動的に解決し、リクエストをプロキシできます。

APISIX Ingressはどのように行うか？

APISIX Ingressは、データプレーンプロキシコンポーネントとしてAPISIXを使用します。サービスディスカバリを初めて統合する際、私たちは2つのオプションを検討しました。

コントロールプレーン統合: Ingressコントローラにサービスディスカバリを設定し、設定を解析して結果をAPISIXに送信し、プロキシを行います。
データプレーン統合: APISIXデータプレーンにサービスディスカバリを設定し、データプレーンが設定の解析とプロキシを行います。

これらの2つのソリューションにはそれぞれ利点がありますが、設定のリアルタイム更新とソリューションの成熟度を考慮して、データプレーン統合ソリューションを選択しました。

このソリューションを使用すると、ユーザーは低コストで統合でき、このソリューションは非常に成熟しており、多くの本番環境での検証を経ています。

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を通じてクライアントにサービスを公開することが非常に便利になります。このAPISIX Ingressの機能は、ほとんどのIngressコントローラがこの統合ソリューションを提供していないため、特徴的です。

お読みいただきありがとうございます。私たちは、APISIX Ingressを構築し、最高のユーザーエクスペリエンスを提供するためにまだ道半ばです！

APIゲートウェイに関する詳細情報については、ブログをご覧いただくか、お問い合わせください。